Prior to 2.6.19 and as of 2.6.31, pci_enable_msix() can return a
positive value to indicate the number of vectors (less than the amount
requested) that can be set up for a given device. Returning this as an
operation value (secondary result) is fine, but (primary) operation
results are expected to be negative (error) or zero (success) according
to the protocol. With the frontend fixed to match the XenoLinux
behavior, the backend can now validly return zero (success) here,
passing the upper limit on the number of vectors in op->value.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
There is an extra and unnecessary call to smp_processor_id()
in cpu_bringup(). Remove it.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The above mentioned patch checks the IOAPIC and if it contains
-1, then it unmaps said IOAPIC. But under Xen we get this:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
PGD 0
Oops: 0002 [#1] SMP
CPU 0
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.2.10-3.fc16.x86_64 #1 Dell Inc. Inspiron
1525 /0U990C
RIP: e030:[<ffffffff8134e51f>] [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
RSP: e02b: ffff8800d42cbb70 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000ffffffef RCX: 0000000000000001
RDX: 0000000000000040 RSI: 00000000ffffffef RDI: 0000000000000001
RBP: ffff8800d42cbb80 R08: ffff8800d6400000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffef
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000010
FS: 0000000000000000(0000) GS:ffff8800df5fe000(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0:000000008005003b
CR2: 0000000000000040 CR3: 0000000001a05000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 1, threadinfo ffff8800d42ca000, task ffff8800d42d0000)
Stack:
00000000ffffffef 0000000000000010 ffff8800d42cbbe0 ffffffff8134f157
ffffffff8100a9b2 ffffffff8182ffd1 00000000000000a0 00000000829e7384
0000000000000002 0000000000000010 00000000ffffffff 0000000000000000
Call Trace:
[<ffffffff8134f157>] xen_bind_pirq_gsi_to_irq+0x87/0x230
[<ffffffff8100a9b2>] ? check_events+0x12+0x20
[<ffffffff814bab42>] xen_register_pirq+0x82/0xe0
[<ffffffff814bac1a>] xen_register_gsi.part.2+0x4a/0xd0
[<ffffffff814bacc0>] acpi_register_gsi_xen+0x20/0x30
[<ffffffff8103036f>] acpi_register_gsi+0xf/0x20
[<ffffffff8131abdb>] acpi_pci_irq_enable+0x12e/0x202
[<ffffffff814bc849>] pcibios_enable_device+0x39/0x40
[<ffffffff812dc7ab>] do_pci_enable_device+0x4b/0x70
[<ffffffff812dc878>] __pci_enable_device_flags+0xa8/0xf0
[<ffffffff812dc8d3>] pci_enable_device+0x13/0x20
The reason we are dying is b/c the call acpi_get_override_irq() is used,
which returns the polarity and trigger for the IRQs. That function calls
mp_find_ioapics to get the 'struct ioapic' structure - which along with the
mp_irq[x] is used to figure out the default values and the polarity/trigger
overrides. Since the mp_find_ioapics now returns -1 [b/c the IOAPIC is filled
with 0xffffffff], the acpi_get_override_irq() stops trying to lookup in the
mp_irq[x] the proper INT_SRV_OVR and we can't install the SCI interrupt.
The proper fix for this is going in v3.5 and adds an x86_io_apic_ops
struct so that platforms can override it. But for v3.4 lets carry this
work-around. This patch does that by providing a slightly different variant
of the fake IOAPIC entries.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit b9136d207f08
xen: initialize platform-pci even if xen_emul_unplug=never
breaks blkfront/netfront by not loading them because of
xen_platform_pci_unplug=0 and it is never set for PV guest.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
As soon as an skb is queued into socket error queue, another thread
can consume it, so we are not allowed to reference skb anymore, or risk
use after free.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As soon as an skb is queued into socket receive_queue, another thread
can consume it, so we are not allowed to reference skb anymore, or risk
use after free.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit dc1f8bf68b ('netdev: change
transmit to limited range type') changed the required return type and
9a1654ba0b ('net: Optimize
hard_start_xmit() return checking') changed the valid numerical
return values.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 08baf56108 ('net:
txq_trans_update() helper') made it unnecessary for most drivers to
set net_device::trans_start (or netdev_queue::trans_start).
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commits d314774cf2 ('netdev: network
device operations infrastructure') and
008298231a ('netdev: add more functions
to netdevice ops') moved and renamed net device operation pointers.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commits e308a5d806 ('netdev: Add
netdev->addr_list_lock protection.') and
e8a0464cc9 ('netdev: Allocate multiple
queues for TX.') introduced more fine-grained locks.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit bea3348eef ('[NET]: Make NAPI
polling independent of struct net_device objects.') removed the
automatic disabling of NAPI polling by dev_close(), and drivers
must now do this themselves.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit e52ac3398c ('net: Use device
model to get driver name in skb_gso_segment()') removed the only
in-tree caller of ethtool ops that doesn't hold the RTNL lock.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A bunch of fixes for regressions (and a few other problems) in 3.4-rc1:
* Fix for regression of mach/io.h cleanup on platforms with PCI or PCMCIA
(adding back the include file on those for now)
* AT91 fixes for usb and spi
* smsc911x ethernet fixes for i.MX
* smsc911x fixes for OMAP
* gpio fixes for Tegra
* A handful of build error and warning fixes for various platforms
* cpufreq kconfig dependencies, build and lowlevel debug fixes for
Samsung platforms
In other words, more or less the regular collection of -rc1/2 type
material. A few of them, in particular the smsc911x for OMAP series, aren't
technically regressions for 3.4, but they're valid fixes and we're still
relatively early in the rc cycle so it seems appropriate to include them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPfmp2AAoJEIwa5zzehBx31hAP/Rs3xdpOpwtPt0YKnvtg5/k7
FyZuhrhihPd2+hJKpzUVPmaal0TdyWgt2kGCl13JrwqWu7xV6VMDakrBPAl/jXwb
3NJU2zjfx+6YJMbgSxid2f/Gv36/p7bBusqGWiU92vOly0Tw4joqZ8ABoO4ti8mK
O1eGbS6Rw5rpHy2u0UkgK3r9xCQxmSJQ1hCezOm7cWmwEhC5pmDe9qKO3Qdbp8tr
XdIE3v0qSv5TuQdPedh8+3JsSx5mub+ZYKKqzWIrbQW5xrqawOKXl4nugrNnustr
aDIoHpAoo4++qt0WJY2wg4/hHoPj2ibHzZqWhktmWj4leMttwTUFnHZm3wvZ55fA
0kp4x6pCsa7J1FhYhCpUVZUS/CcQv8wKBA7RGGUsl/0t52droqFwfYi/YhB6nCMo
zDRHJm+hToZN1/HPiKsyFlM+pQ2nsE/AXs7V5ohf7/GE6w66A5TU/HHolHv3ERvU
QoshX3zPtrAUQEe8WT4bG7HqXaNr/aa080ElYSdlVQ/HfGbIcKcSxzavUvZIZmx2
IYFF3SkpAhVtidcPzdnYJPjNF9c3Kr1w0QLUGgyRkrRp6OSPiPkksmI8gcjlf5l3
runmq36+ktqSz1KnNHBNnSF9aQ6drzCNQ7nqpPXeMaTrZ1jdXNcKTw9eLo/Kr3vB
4UHuqt8hfrcpiUYdXRQ1
=RVTD
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull "ARM: SoC fixes: from Olof Johansson:
"A bunch of fixes for regressions (and a few other problems) in
3.4-rc1:
- Fix for regression of mach/io.h cleanup on platforms with PCI or
PCMCIA (adding back the include file on those for now)
- AT91 fixes for usb and spi
- smsc911x ethernet fixes for i.MX
- smsc911x fixes for OMAP
- gpio fixes for Tegra
- A handful of build error and warning fixes for various platforms
- cpufreq kconfig dependencies, build and lowlevel debug fixes for
Samsung platforms
In other words, more or less the regular collection of -rc1/2 type
material. A few of them, in particular the smsc911x for OMAP series,
aren't technically regressions for 3.4, but they're valid fixes and
we're still relatively early in the rc cycle so it seems appropriate
to include them."
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (60 commits)
ARM: fix __io macro for PCMCIA
ARM: EXYNOS: Fix compiler warning in dma.c file
ARM: EXYNOS: fix ISO C90 warning
ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status
ARM: OMAP2+: hwmod: Restore sysc after a reset
ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules
ARM: OMAP3: clock data: fill in some missing clockdomains
ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock
ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL
ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
gpio: tegra: Iterate over the correct number of banks
gpio: tegra: fix register address calculations for Tegra30
EXYNOS: fix dependency for EXYNOS_CPUFREQ
ARM: at91: dt: remove unit-address part for memory nodes
ARM: at91: fix check of valid GPIO for SPI and USB
USB: ehci-atmel: add needed of.h header file
ARM: at91/NAND DT bindings: add comments
ARM: at91/at91sam9x5.dtsi: fix NAND ale/cle in DT file
USB: ohci-at91: trivial return code name change
...
Pull a few blackfin compile fixes from Bob Liu.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lliubbo/blackfin:
blackfin: update defconfig for bf527-ezkit
blackfin: gpio: fix compile error if !CONFIG_GPIOLIB
blackfin: fix L1 data A overflow link issue
To fix compile error:
drivers/usb/musb/blackfin.h:51:3: error: #error "Please use PIO mode in MUSB
driver on bf52x chip v0.0 and v0.1"
make[4]: *** [drivers/usb/musb/blackfin.o] Error 1
Signed-off-by: Bob Liu <lliubbo@gmail.com>
This patch fix below compile error:
"bfin-uclinux-ld: L1 data A overflow!"
It is due to the recent lib/gen_crc32table.c change:
46c5801eaf
crc32: bolt on crc32c
it added 8KiB more data to __cacheline_aligned which cause blackfin L1 data
cache overflow.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Pull an APM fix from Jiri Kosina:
"One deadlock/race fix from Niel that got introduced when we were
moving away from freezer_*_count() to wait_event_freezable()."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/apm:
APM: fix deadlock in APM_IOC_SUSPEND ioctl
Several people have noticed that crappy SD cards take much longer to
complete multiple block writes than the 300ms that Linux specifies.
Try to work around this by using a three second write timeout instead.
This is a generalized version of a patch from Chase Maupin
<Chase.Maupin@ti.com>, whose patch description said:
* With certain SD cards timeouts like the following have been seen
due to an improper calculation of the dto value:
mmcblk0: error -110 transferring data, sector 4126233, nr 8,
card status 0xc00
* By removing the dto calculation and setting the timeout value
to the maximum specified by the SD card specification part A2
section 2.2.15 these timeouts can be avoided.
* This change has been used by beagleboard users as well as the
Texas Instruments SDK without a negative impact.
* There are multiple discussion threads about this but the most
relevant ones are:
* http://talk.maemo.org/showthread.php?p=1000707#post1000707
* http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html
* Original proposal for this fix was done by Sukumar Ghoral of
Texas Instruments
* Tested using a Texas Instruments AM335x EVM
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch fixes a compile error in drivers/mmc/host/sdhci-dove.c
by including the linux/module.h file.
Signed-off-by: Alf Høgemark <alf@i100.no>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The driver should not try to switch to 1.8V when the SD 3.0 host
controller does not have any UHS capabilities bits set (SDR50, DDR50
or SDR104). See page 72 of "SD Specifications Part A2 SD Host
Controller Simplified Specification Version 3.00" under
"1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the host
capabilities data structure for all V3.0 host controllers, only set them
if SDR104, SDR50 or DDR50 is set in the host capabilities register. This
will prevent the switch to 1.8V later.
Signed-off-by: Al Cooper <acooper@gmail.com>
Acked-by: Arindam Nath <arindam.nath@amd.com>
Acked-by: Philip Rakity <prakity@marvell.com>
Acked-by: Girish K S <girish.shivananjappa@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
This reverts commit e6039832be.
There are reports of MSI breaking SDHCI on multiple chipsets (JMicron
and O2Micro, at least), so this should be reverted until we come up
with a whitelist or something.
Signed-off-by: Chris Ball <cjb@laptop.org>
This reverts commit c16e981b2fd9455af670a69a84f4c8cf07e12658, because
it's no longer useful once MSI support is reverted.
Signed-off-by: Chris Ball <cjb@laptop.org>
mmc_select_powerclass() function returns error if eMMC
VDD level supported by host is between 2.7v to 3.2v.
According to eMMC specification, valid voltage for high
voltage cards is 2.7v to 3.6v. This patch ensures that
2.7v to 3.6v VDD range is treated as valid range.
Also, failure to set the power class shouldn't be treated
as fatal error because even if setting the power class
fails, card can still work in default power class.
If mmc_select_powerclass() returns error, just print
the warning message and go ahead with rest of the card
initialization.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Acked-by: Girish K S <girish.shivananjappa@linaro.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Adding the offset to platform_device resource structure
increments the start address for every insmod operation.
MMC command fails on re-insertion as module due to incorrect register
base. Fix this by updating the ioremap base address only.
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This will delete some boilerplate code, no functional changes.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
If we put probe() on __init section, that will never work for multiple
module insertions/removals.
In order to make it work properly, move probe to __devinit section and
use platform_driver_register() instead of platform_driver_probe().
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
A bunch of non-functional cleanups to the omap_hsmmc driver.
It basically decreases indentation level, drop unneded dereferences
and drop unneded accesses to the platform_device structure.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Call context save api after enabling runtime pm to make sure that
register access in context save api happens with clk enabled.
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host->base) follows immediately.
Reported-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Neil Brown reports that commit 35cd133c
PM: Run the driver callback directly if the subsystem one is not there
breaks suspend for his libertas wifi, because SDIO has a protocol
where the suspend method can return -ENOSYS and this means "There is
no point in suspending, just turn me off". Moreover, the suspend
methods provided by SDIO drivers are not supposed to be called by
the PM core or bus-level suspend routines (which aren't presend for
SDIO). Instead, when the SDIO core gets to suspend the device's
ancestor, it calls the device driver's suspend function, catches the
ENOSYS, and turns the device off.
The commit above breaks the SDIO core's assumption that the device
drivers' callbacks won't be executed if it doesn't provide any
bus-level callbacks. If fact, however, this assumption has never
been really satisfied, because device class or device type suspend
might very well use the driver's callback even without that commit.
The simplest way to address this problem is to make the SDIO core
tell the PM core to ignore driver callbacks, for example by providing
no-operation suspend/resume callbacks at the bus level for it,
which is implemented by this change.
Reported-and-tested-by: Neil Brown <neilb@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
[stable: please apply to 3.3-stable only]
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
When UHS-I card is detected also print the bus speed mode in which
UHS-I card will be running.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
MSI on my O2Micro OZ600 SD card reader is broken. This patch adds a quirk
to disable MSI on these controllers.
Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
There is no need to tune mmc->f_min to a value near 400kHz as the MMC core
begins testing frequencies at 400kHz regardless of the value of mmc->f_min.
As suggested by Guennadi Liakhovetski.
Cc: Magnus Damm <magnus.damm@gmail.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Cao Minh Hiep <hiepcm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
mmc->f_max should be half of the bus clock.
And now that mmc->f_max is not equal to the bus clock the
latter should be used directly to calculate mmc->f_min.
Cc: Magnus Damm <magnus.damm@gmail.com>
Tested-by: Cao Minh Hiep <hiepcm@gmail.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
Correct an off-by one error when calculating the clock divisor in cases
where the host clock is a power of two of the target clock. Previously the
divisor was one greater than the correct value in these cases leading to
the clock being set at half the desired speed.
Thanks to Guennadi Liakhovetski for working with me on the logic for this
change.
Tested-by: Cao Minh Hiep <hiepcm@gmail.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
According to the specifications for SD and (e)MMC default
blocksize (named BLOCKLEN in Spec.) must always be 512
bytes. Since we hardcoded to always use 512 bytes, we do
not explicitly have to set it. Future improvements should
potentially make it possible to use a greater blocksize
than 512 bytes, but until then let's skip this.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: Subhash Jadavani <subhashj@codeauora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add an odd clock divider capability available from v5xx. It also involves
changing the clock divider calculation, and changing the switch-case
statement to use top-down fallthrough.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The HSMCI operates at a rate of up to Master Clock divided by two.
Moreover previous calculation can cause overflows and so wrong
timeouts.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This matches current best practice as one can have runtime PM enabled
without system sleep and CONFIG_PM is defined for both.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
By using devm_ioremap, it also removes a potential memory leak, because
there was no call to iounmap in the probe function.
The call to platform_get_resource was moved just to make it closer to the
place where its result it used.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Chris Ball <cjb@laptop.org>
early v3.4-rc series. Also contains an HSMMC integration refinement
of an earlier hardware bug workaround.
ARM: OMAP3: clock data: fill in some missing clockdomains
ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock
ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL
ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases
ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status
ARM: OMAP2+: hwmod: Restore sysc after a reset
ARM: OMAP: clock: fix race in disable all clocks
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules
ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks
ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached
ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJPfWEKAAoJEMePsQ0LvSpLGqIP/1Mvc3O7+Gs97E8BBR7RVkPC
Uo4aM6NMwkCBozC9XLooS12FFCC1k97aLh7IeEhN5qZ8U/FqkF6qIdMTLzJpSsnD
nuL1JLZGAdd+OtxgbVhjd/3cmK2H94K5XozZrKbC2/fypjDRjh40yk6hIH0zvZU6
+OX6r0kRW9HX6gC2+cAPJzKWaSgVimh6KQxRsevL8xbyPm183/vx2U0E1bicsHrY
rSXcQTo0AanDHNX4bSG3lMXiv+hVxYRpzlhJ1ToPN/fRokWXJjp3oycRYVL4A6KE
8MvvSORhf6yVekB+LOESIEmFNisGl/2zuAPFnZBnHzcpvNTvDB57uSPtUeQjXsUK
6MBgW5okGUU9tihP7m8tmP6kbo0tPdZRtBiJP0KDBflLRFAOgrcWiRQL+8jjus0v
ktHt6h3P71D8MoYN74T6x2/0NP49FXA3RVxuKDoaT3nXXkR7IvVNVXPh15zRTPFe
liTrn0U1Bu34HvpAuR8WRO5W0VgT2DTPQNk7WtZkYlyS1WXLAunDW9+Bv1JHS1MH
zeBZf6SNE1kVLWdNkFaYK0pAXHw8epwsUKeI9ZNIX3y9qdamzvafzeKQUjewPbLm
26KOzr3cuwIb7No7sh3fSpJV/Y8YFPCb9MvvzMg5yhfYf2SL4xYrudhSPcCw9gEy
2pCChl33o4AvxjkUEXjZ
=41FI
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-a2-for-3.4rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes
From Paul Walmsley:
OMAP clock, powerdomain, clockdomain, and hwmod fixes intended for the
early v3.4-rc series. Also contains an HSMMC integration refinement
of an earlier hardware bug workaround.
* tag 'omap-fixes-a2-for-3.4rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending:
ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status
ARM: OMAP2+: hwmod: Restore sysc after a reset
ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules
ARM: OMAP3: clock data: fill in some missing clockdomains
ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock
ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL
ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases
ARM: OMAP: clock: fix race in disable all clocks
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks
ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached
ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data
The platform data is copied into driver's private data and the copy is
used for all access to the platform data. This simpifies the addition
of device tree support for the sdhci-s3c driver.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
max_width member in platform data can be used to derive the mmc bus transfer
width that can be supported by the controller.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
SDHCI controllers on Exynos4 do not include the sdclk divider as per the
sdhci controller specification. This case can be represented using the
sdhci quirk SDHCI_QUIRK_NONSTANDARD_CLOCK instead of using an additional
enum type definition 'clk_types'.
Hence, usage of clk_type member in platform data is removed and the sdhci
quirk is used. In addition to that, since this qurik is SoC specific,
driver data is introduced to represent controllers on SoC's that require
this quirk.
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Jeongbae Seo <jeongbae.seo@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Marvell has agreed to do maintenance on the sky2 driver.
* Add the developer to the maintainers file
* Remove the old reference to the long gone (sk98lin) driver
* Rearrange to fit current topic organization
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a slave comes up, we're unsetting the current_arp_slave without
removing active flags from it, which can lead to situations where we have
more than one slave with active flags in active-backup mode.
To avoid this situation we must remove the active flags from a slave before
removing it as a current_arp_slave.
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jan Beulich