The .conf_reg of MX51_PAD_SD2_CMD__CSPI_MOSI should be 0x7bc rather
than NO_PAD. This error will cause SD2 probe failure.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In function pinctrl_get_locked, pointer p is returned on
error, and also return on no_error.
So, we just return it with no error test.
It's pretty the same in function pinctrl_lookup_state_locked:
state is returned in every case, so we drop the error test
and just return state.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
As struct device is used as a function argument, it should at
least be declared (device.h is not included).
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The irqdomain conversion failed to notice that we do not always
have a DT node to dereference, fix this up by using a simple
dev_err() that also tells the name of the device.
Cc: Loic Pallardy <loic.pallardy@st.com>
Cc: Patrice Chotard <patrice.chotard@stericsson.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2ec8663f9c03a96f2c328c7c483603c31d62ad37 (lmo) rsp.
497e5ff03f (kernel.org) [MIPS: Malta: Move
PIIX4 PCI fixup to where it belongs.] attempted to move this PCI fixup
but really only added it at it's new location without deleting the old
instance.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The ath79 platform code allows to run a single kernel image on various
SoCs which are based on the 24Kc and 74Kc cores. The current code
explicitely disables the DSP ASE, but that is available in the 74Kc core.
Remove the override in order to let the kernel to detect the availability
of the DSP ASE at runtime.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4222/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The current implementation of synchronise_count_{master,slave} blocks
slave CPUs in early boot until all of them come up. This no longer
works because blocking a CPU with interrupts off after notifying the
CPU to be online causes problems with the current kernel.
Specifically, after the workqueue changes
(commit a08489c569 "Pull workqueue changes from Tejun Heo")
the CPU_ONLINE notification callback workqueue_cpu_up_callback()
will hang on wait_for_completion(&idle_rebind.done), if the slave
CPUs are blocked for synchronize_count_slave().
The changes are to update synchronize_count_{master,slave}() to handle
one CPU at a time and to call synchronise_count_master() in __cpu_up()
so that the CPU_ONLINE notification goes out only after the COP0 COUNT
register is synchronized.
[ralf@linux-mips.org: This matter only to those few platforms which are
using the cp0 counter as their clocksource which are XLP, XLR and MIPS'
CMP solution.]
Signed-off-by: Jayachandran C <jchandra@broadcom.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4216/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
BCM6338 and BCM6348 have a message control register width of 8 bits, instead
of 16-bits like what the SPI driver assumes right now. Also the SPI message
type shift value of 14 is actually 6 for these SoCs.
This resulted in transmit FIFO corruption because we were writing 16-bits
to an 8-bits wide register, thus spanning on the first byte of the transmit
FIFO, which had already been filed in bcm63xx_spi_fill_txrx_fifo().
Fix this by passing the message control register width and message type
shift through platform data back to the SPI driver so that it can use
it properly.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: grant.likely@secretlab.ca
Cc: spi-devel-general@lists.sourceforge.net
Cc: jonas.gorski@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/3983/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In case a series of R_MIPS_HI16 relocations was not followed by an
R_MIPS_LO16 relocation we were leaking the hi16 relocation chain.
Handle that error and return an error.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The relocation code was essentially taken from the 2.4 modutils which
perform relocation in userspace. In 2.6 relocation of multiple modules
may be performed in parallel by the in-kernel loader so the global
variable mips_hi16_list won't fly anymore. Fix race by moving it into
mod_arch_specific.
[ralf@linux-mips.org: folded in Tony's followup fix. Thanks Tony!]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Tony Wu <tung7970@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/4189/
Commit 6f5d2e970452b5c86906adcb8e7ad246f535ba39 (lmo) /
477c4b0740 (kernel.org) [[MIPS: VPE: Free
relocation chain on error.] fixed the same issue in the vpe loader in 2009
but back then the same bug in module.c went unfixed.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Reported-by: Akhilesh Kumar <akhilesh.lxr@gmail.com>
Without this udelay(1) PCI idsel does not work correctly on the
"singleboard" (T-Mobile Surfbox) for the MiniPCI device. The result is
that PCI configuration fails and the MiniPCI card is not detected
correctly. Instead of
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff]
pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
pci 0000:00:03.0: BAR 0: assigned [mem 0x40000000-0x4000ffff]
pci 0000:00:00.0: BAR 0: assigned [mem 0x40010000-0x40010fff]
pci 0000:00:00.1: BAR 0: assigned [mem 0x40011000-0x40011fff]
We see only the CardBus device:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff]
pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
pci 0000:00:00.0: BAR 0: assigned [mem 0x40000000-0x40000fff]
pci 0000:00:00.1: BAR 0: assigned [mem 0x40001000-0x40001fff]
Later the device driver shows this error:
ath5k 0000:00:03.0: cannot remap PCI memory region
ath5k: probe of 0000:00:03.0 failed with error -5
I assume that the logic chip which usually supresses the signal to the CardBus
card has some settling time and without the delay it would still let the
Cardbus interfere with the response from the MiniPCI card.
What I cannot explain is why this behaviour shows up now and not in earlier
kernel versions before. Maybe older PCI code was slower?
Signed-off-by: Bruno Randolf <br1@einfach.org>
Cc: linux-mips@linux-mips.org
Cc: manuel.lauss@googlemail.com
Cc: florian@openwrt.org
Patchwork: https://patchwork.linux-mips.org/patch/4087/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It is needed in order to get rid of the following errors:
arch/mips/ath79/clock.c:353:13: error: redefinition of 'clk_get'
include/linux/clk.h:281:27: note: previous definition of 'clk_get' was here
arch/mips/ath79/clock.c:377:5: error: redefinition of 'clk_enable'
include/linux/clk.h:295:19: note: previous definition of 'clk_enable' was here
arch/mips/ath79/clock.c:383:6: error: redefinition of 'clk_disable'
include/linux/clk.h:300:20: note: previous definition of 'clk_disable' was here
arch/mips/ath79/clock.c:388:15: error: redefinition of 'clk_get_rate'
include/linux/clk.h:302:29: note: previous definition of 'clk_get_rate' was here
arch/mips/ath79/clock.c:394:6: error: redefinition of 'clk_put'
include/linux/clk.h:291:20: note: previous definition of 'clk_put' was here
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4170/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The currently assigned IRQ number to the OHCI controller is incorrect for
the AR7240 SoC, and that leads to the following error message from the
OHCI driver:
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ath79-ohci ath79-ohci: Atheros built-in OHCI controller
ath79-ohci ath79-ohci: new USB bus registered, assigned bus number 1
ath79-ohci ath79-ohci: irq 14, io mem 0x1b000000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb 1-1: new full-speed USB device number 2 using ath79-ohci
ath79-ohci ath79-ohci: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
Fix this by using the correct IRQ number.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4168/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Since 3.6.0-rc1, We are getting many messages like:
WARNING: at kernel/irq/irqdomain.c:444 irq_domain_associate_many+0x23c/0x260()
Modules linked in:
Call Trace:
[<ffffffff814cb698>] dump_stack+0x8/0x34
[<ffffffff81133d00>] warn_slowpath_common+0x78/0xa8
[<ffffffff81187e44>] irq_domain_associate_many+0x23c/0x260
[<ffffffff81187f38>] irq_create_mapping+0xd0/0x220
[<ffffffff81188104>] irq_create_of_mapping+0x7c/0x158
[<ffffffff813e5f08>] irq_of_parse_and_map+0x28/0x40
.
.
.
Both the CIU and GPIO interrupt domains were somewhat screwed up.
For the CIU domain, we need to call irq_domain_associate() for each of
the preassigned irq numbers. For the GPIO domain, we were applying
the register bit offset in octeon_irq_gpio_xlat, but it should be done
in octeon_irq_gpio_map instead.
Also: Reserve all 8 'core' irqs for the 'core' irq_chip so that they
don't get used by the other domains. Remove unused OCTEON_IRQ_*
symbols.
Signed-off-by: David Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4190/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Mar 2 19:38:30 2012 +0100
drm/i915: enable gmbus on gen2
Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging
fallback to CRT EDID reads.
LKML-Reference: <201207251020.47637.maciej.rutecki@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Alex Ferrando <alferpal@gmail.com>
Cc: stable@vger.kernel.org (for 3.4+3.5)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Refactor the connector update part of intel_ddc_get_modes() into a separate
intel_connector_update_modes() function for reuse. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
Tested-by: Alex Ferrando <alferpal@gmail.com>
Cc: stable@vger.kernel.org (for 3.4+3.5)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They've changed it ... for no apparent reason. Meh.
V2: remove unused 'is_hsw' field.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After reset we unconditionally reinitialize lists. If the context switch
hasn't yet completed before the suspend, the default context object will
end up on lists that are going to go away when we resume.
The patch forces the context switch to be synchronous before suspend
assuring that the active/inactive tracking is correct at the time of
resume.
References: https://bugs.freedesktop.org/show_bug.cgi?id=52429
Tested-by: Guang A Yang <guang.a.yang@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The EDID returned by drm_get_edid() was never freed.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fixes a regression bug in pscsi_transport_complete() callback
code where *pt was being NULL dereferenced during REPORT_LUNS handling,
that was introduced with the spc/sbc refactoring in:
commit 1fd032ee10
Author: Christoph Hellwig <hch@infradead.org>
Date: Sun May 20 11:59:15 2012 -0400
target: move code for CDB emulation
As this is a special case for pscsi_parse_cdb() to call spc_parse_cdb() to
allow TCM to handle REPORT_LUN emulation, pscsi_plugin_task will have not
been allocated..
So now in pscsi_transport_complete() just check for existence of *pt and
return for this special case.
Reported-by: Alex Elsayed <eternaleye+usenet@gmail.com>
Cc: Alex Elsayed <eternaleye+usenet@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch changes the vhost_scsi_target->vhost_wwpn[] type used
by VHOST_SCSI_* ioctls to 'char *' as requested by Blue Swirl in
order to match the latest QEMU vhost-scsi RFC-v3 userspace code.
Queuing this up into target-pending/master for a -rc3 PULL.
Reported-by: Blue Swirl <blauwirbel@gmail.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
I am hitting this bug when the target is low in memory that fails the
alloc_page() for the newly submitted command. This is a sort of off-by-one
bug causing NULL pointer dereference in __free_page() since 'i' here is
really the counter of total pages that have been successfully allocated here.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Open-FCoE.org <devel@open-fcoe.org>
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Stop doing a pile of work related to debugging messages when
the ft_debug_logging flag is not set. Use unlikely to add the
check in a way that the check can be inlined without inlining the
whole thing.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch contains the post RFC-v5 (post-merge) changes, this includes:
- Add locking comment
- Move vhost_scsi_complete_cmd ahead of TFO callbacks in order to
drop forward declarations
- Drop extra '!= NULL' usage in vhost_scsi_complete_cmd_work()
- Change vhost_scsi_*_handle_kick() to use pr_debug
- Fix possible race in vhost_scsi_set_endpoint() for vs->vs_tpg checking
+ assignment.
- Convert tv_tpg->tpg_vhost_count + ->tv_tpg_port_count from atomic_t ->
int, and make sure reference is protected by ->tv_tpg_mutex.
- Drop unnecessary vhost_scsi->vhost_ref_cnt
- Add 'err:' label for exception path in vhost_scsi_clear_endpoint()
- Add enum for VQ numbers, add usage in vhost_scsi_open()
- Add vhost_scsi_flush() + vhost_scsi_flush_vq() following
drivers/vhost/net.c
- Add smp_wmb() + vhost_scsi_flush() call during vhost_scsi_set_features()
- Drop unnecessary copy_from_user() usage with GET_ABI_VERSION ioctl
- Add missing vhost_scsi_compat_ioctl() caller for vhost_scsi_fops
- Fix function parameter definition first line to follow existing
vhost code style
- Change 'vHost' usage -> 'vhost' in handful of locations
- Change -EPERM -> -EBUSY usage for two failures in tcm_vhost_drop_nexus()
- Add comment for tcm_vhost_workqueue in tcm_vhost_init()
- Make GET_ABI_VERSION return 'int' + add comment in tcm_vhost.h
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Cc: Zhi Yong Wu <wuzhy@cn.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
There is no specific atomic64 support code for any m68k CPUs, so we should
select CONFIG_GENERIC_ATOMC64 for all. Remove the existing per CPU selection
of this and select it for all m68k.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
A race exists where creating cgroups and also updating the priomap
may result in losing a priomap update. This is because priomap
writers are not protected by rtnl_lock.
Move priority writer into rtnl_lock()/rtnl_unlock().
CC: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A socket fd passed in a SCM_RIGHTS datagram was not getting
updated with the new tasks cgrp prioidx. This leaves IO on
the socket tagged with the old tasks priority.
To fix this add a check in the scm recvmsg path to update the
sock cgrp prioidx with the new tasks value.
Thanks to Al Viro for catching this.
CC: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add lock to prevent a race with a file closing and also remove
useless and ugly sscanf code. The extra code was never needed
and the case it supposedly protected against is in fact handled
correctly by sock_from_file as pointed out by Al Viro.
CC: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We drop packet unconditionally when we fail to mirror it. This is not intended
in some cases. Consdier for kvm guest, we may mirror the traffic of the bridge
to a tap device used by a VM. When kernel fails to mirror the packet in
conditions such as when qemu crashes or stop polling the tap, it's hard for the
management software to detect such condition and clean the the mirroring
before. This would lead all packets to the bridge to be dropped and break the
netowrk of other virtual machines.
To solve the issue, the patch does not drop packets when kernel fails to mirror
it, and only drop the redirected packets.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This allows the normal error-paths to handle the error, rather than
making a special call to complete_request_key() just for this instance.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Tested-by: William Dauchy <wdauchy@gmail.com>
Cc: stable@vger.kernel.org [>= 3.4]
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
idmap_pipe_downcall already clears this field if the upcall succeeds,
but if it fails (rpc.idmapd isn't running) the field will still be set
on the next call triggering a BUG_ON(). This patch tries to handle all
possible ways that the upcall could fail and clear the idmap key data
for each one.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Tested-by: William Dauchy <wdauchy@gmail.com>
Cc: stable@vger.kernel.org [>= 3.4]
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
These mostly consist of fixes from Lars-Peter Clausen that were
the first part of a large series reworking the drivers concerned.
Turns out these drivers had quite a wealth of minor bugs.
Also here are some build warning fixes for lm3533-als and
adjd_s111 (both new drives in this cycle).
Final elements are a a div factor overflow and a warning
related fix in a couple of Analog Devices drivers.
All in all nothing major, but a worthwhile bunch of short
fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJQLUxMAAoJEFSFNJnE9BaI1PgQALfDZXRXLaR3zxp+ZJMZsY6e
LkGbi0PioGXyJG0/a5KYTTntFGrWTR6RDhofG1AAMiUCvfmR68a5E4dS3C+huHx4
5yvoiFo2W70Cuavne34C15ObmCX2sBQx9T0i1xMCbqizjN7hfwCsM2gyieMJ3/so
xhxV1wvztqJOfLY93fGZUe7sz9vZa34fdZ5cgAQqF1GpO9awDY/fvMb6ecAJjPqV
qxgsmdXhYJ0v41ukjnvZbebeHZKcbf6Ffo1DGLCvjw8w8h1JMdg8/gXuwmj3RLcY
Y/oUvfUFGOx0RRkbGamgxhwo2STQ9SDwUohzblIufY38HFAEfiBFueJ7IctxXy6K
HPdm0UL4nDgs751rOh5on3lbiv4wX0RHsXwkoKIXlueK0rptQ+uA+Uq/irCnEfJy
xxn0X03kaNMgNtI3EK3/PbEsPpDEoVpeNHFW+ikVl6FBCjRpraoxnNGMg6ajV9kH
U0Wigwj0vVZdVwpUQAXZoz1so/i00mC5pHOt+3znReEdgJkV63AnlY69IbjvxoLi
3eq50EMZUsxbCQdDdIIADPtabwxKRN2rphRMb/eAG/6ZAJCYZWrhrli/OTUmqzXs
4MaYEPyAjpUiyABVtKzONtSccP640kz3YSIg6ZKwGGYoI0/jXTlrXTlsKQUeNOtn
ll/kwhqy1mXYW+Q7kpj3
=+LMV
-----END PGP SIGNATURE-----
Merge tag 'v3.6-rc1-iio-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
IIO fixes for v3.6-rc1
These mostly consist of fixes from Lars-Peter Clausen that were
the first part of a large series reworking the drivers concerned.
Turns out these drivers had quite a wealth of minor bugs.
Also here are some build warning fixes for lm3533-als and
adjd_s111 (both new drives in this cycle).
Final elements are a a div factor overflow and a warning
related fix in a couple of Analog Devices drivers.
All in all nothing major, but a worthwhile bunch of short
fixes.
Instead of using the private field xdr->p from struct xdr_stream,
use the public xdr_stream_pos().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Currently, we do not take into account the size of the 16 byte
struct nfs4_cached_acl header, when deciding whether or not we should
cache the acl data. Consequently, we will end up allocating an
8k buffer in order to fit a maximum size 4k acl.
This patch adjusts the calculation so that we limit the cache size
to 4k for the acl header+data.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Resetting the cursor xdr->p to a previous value is not a safe
practice: if the xdr_stream has crossed out of the initial iovec,
then a bunch of other fields would need to be reset too.
Fix this issue by using xdr_enter_page() so that the buffer gets
page aligned at the bitmap _before_ we decode it.
Also fix the confusion of the ACL length with the page buffer length
by not adding the base offset to the ACL length...
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org
This allows distros to remove the line from their modprobe
configuration.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Some systems have a modprobe.d/nfs.conf file that sets an nfs4 alias
pointing to nfs.ko, rather than nfs4.ko. This can prevent the v4 module
from loading on mount, since the kernel sees that something named "nfs4"
has already been loaded. To work around this, I've renamed the modules
to "nfsv2.ko" "nfsv3.ko" and "nfsv4.ko".
I also had to move the nfs4_fs_type back to nfs.ko to ensure that `mount
-t nfs4` still works.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
This patch adds support for maxim ds1825 based 1-wire temperature sensors.
Signed-off-by: Raphael Assenat <raph@8d.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ll_device_want_to_wakeup(): Fix the NULL pointer check on pdata->chip_awake,
which is performed on the wrong function pointer
Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix below build warnings:
CC [M] drivers/iio/light/lm3533-als.o
drivers/iio/light/lm3533-als.c:667:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: (near initialization for 'dev_attr_in_illuminance0_thresh_either_en.show') [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: (near initialization for 'dev_attr_in_illuminance0_thresh_either_en.store') [enabled by default]
Signed-off-by: Axel Lin <axel.lin@gmail.com>
The values reported by the AD7780 are unsigned with a binary offset:
0x000000 is negative fullscale
0x800000 is zeroscale
0xffffff is positive fullscale
So mark the channel in the channel spec as unsigned rather than signed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The temperature channel reports values in degree Kelvin with sensitivity of 5630
codes per degree. If the chip is configured in bipolar mode there is an
additional binary offset of 0x800000 and the sensitivity is divided by two.
Currently the driver does the mapping from the raw value to degree Celsius when
doing a manual conversion. This has several disadvantages, the major one being
that it does not work for buffered mode, also by doing the division by the
sensitivity in the driver the precession of the reported value is needlessly
reduced.
Furthermore the current calculation only works in bipolar mode and the current
scale is of by a factor of 1000.
This patch modifies the driver to report correct offset and scale values in
both unipolar and bipolar mode and to report the raw temperature value
for manual conversions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In bipolar mode there is a a binary offset of 2**(N-1) (with N being the number
of bits) on the reported value. Currently this value is subtracted when doing a
manual read. While this works for manual channel readings it does not work for
buffered mode. So report the offset in the channels offset property, which will
work in both modes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The values reported by the AD7793 are unsigned.
In uniploar mode:
0x000000 is zeroscale
0xffffff is fullscale
In bipolar mode:
0x000000 is negative fullscale
0x800000 is zeroscale
0xffffff is positive fullscale
In bipolar mode there is a binary offset, but the values are still unsigned.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Shawn Guo