The kernel oopses in phy_lookup() due to 'phy->init_data' being NULL if we
register PHYs from a device tree probing driver and then call phy_get() on a
device that has no representation in the device tree (e.g. a PCI device).
Checking the pointer before dereferening it and skipping an interation if
it's NULL prevents this kernel oops.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When OMAP_CONTROL_USB was renamed to OMAP_CONTROL_PHY (commit
14da699b), its dependencies were lost in the process. Nothing in the
commit message indicates that this removal was intentional, so I think
it was by accident and the dependencies should be restored.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Roger Quadros <rogerq@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The top-level phy-samsung-usb2 driver may be configured as a
loadable module, which currently causes link errors because
of the dependency on the exynos{5250,4x12,4210}_usb2_phy_config
symbol. Solving this could be achieved by exporting these
symbols, but as the SoC-specific parts of the driver are not
currently built as modules, it seems better to just link
everything into one module and avoid the need for the export.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix driver new_id sysfs-attribute removal deadlock by making sure to
not hold any locks that the attribute operations grab when removing the
attribute.
Specifically, usb_serial_deregister holds the table mutex when
deregistering the driver, which includes removing the new_id attribute.
This can lead to a deadlock as writing to new_id increments the
attribute's active count before trying to grab the same mutex in
usb_serial_probe.
The deadlock can easily be triggered by inserting a sleep in
usb_serial_deregister and writing the id of an unbound device to new_id
during module unload.
As the table mutex (in this case) is used to prevent subdriver unload
during probe, it should be sufficient to only hold the lock while
manipulating the usb-serial driver list during deregister. A racing
probe will then either fail to find a matching subdriver or fail to get
the corresponding module reference.
Since v3.15-rc1 this also triggers the following lockdep warning:
======================================================
[ INFO: possible circular locking dependency detected ]
3.15.0-rc2 #123 Tainted: G W
-------------------------------------------------------
modprobe/190 is trying to acquire lock:
(s_active#4){++++.+}, at: [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
but task is already holding lock:
(table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (table_lock){+.+.+.}:
[<c0075f84>] __lock_acquire+0x1694/0x1ce4
[<c0076de8>] lock_acquire+0xb4/0x154
[<c03af3cc>] _raw_spin_lock+0x4c/0x5c
[<c02bbc24>] usb_store_new_id+0x14c/0x1ac
[<bf007eb4>] new_id_store+0x68/0x70 [usbserial]
[<c025f568>] drv_attr_store+0x30/0x3c
[<c01690e0>] sysfs_kf_write+0x5c/0x60
[<c01682c0>] kernfs_fop_write+0xd4/0x194
[<c010881c>] vfs_write+0xbc/0x198
[<c0108e4c>] SyS_write+0x4c/0xa0
[<c000f880>] ret_fast_syscall+0x0/0x48
-> #0 (s_active#4){++++.+}:
[<c03a7a28>] print_circular_bug+0x68/0x2f8
[<c0076218>] __lock_acquire+0x1928/0x1ce4
[<c0076de8>] lock_acquire+0xb4/0x154
[<c0166b70>] __kernfs_remove+0x254/0x310
[<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
[<c0169fb8>] remove_files.isra.1+0x48/0x84
[<c016a2fc>] sysfs_remove_group+0x58/0xac
[<c016a414>] sysfs_remove_groups+0x34/0x44
[<c02623b8>] driver_remove_groups+0x1c/0x20
[<c0260e9c>] bus_remove_driver+0x3c/0xe4
[<c026235c>] driver_unregister+0x38/0x58
[<bf007fb4>] usb_serial_bus_deregister+0x84/0x88 [usbserial]
[<bf004db4>] usb_serial_deregister+0x6c/0x78 [usbserial]
[<bf005330>] usb_serial_deregister_drivers+0x2c/0x4c [usbserial]
[<bf016618>] usb_serial_module_exit+0x14/0x1c [sierra]
[<c009d6cc>] SyS_delete_module+0x184/0x210
[<c000f880>] ret_fast_syscall+0x0/0x48
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(table_lock);
lock(s_active#4);
lock(table_lock);
lock(s_active#4);
*** DEADLOCK ***
1 lock held by modprobe/190:
#0: (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
stack backtrace:
CPU: 0 PID: 190 Comm: modprobe Tainted: G W 3.15.0-rc2 #123
[<c0015e10>] (unwind_backtrace) from [<c0013728>] (show_stack+0x20/0x24)
[<c0013728>] (show_stack) from [<c03a9a54>] (dump_stack+0x24/0x28)
[<c03a9a54>] (dump_stack) from [<c03a7cac>] (print_circular_bug+0x2ec/0x2f8)
[<c03a7cac>] (print_circular_bug) from [<c0076218>] (__lock_acquire+0x1928/0x1ce4)
[<c0076218>] (__lock_acquire) from [<c0076de8>] (lock_acquire+0xb4/0x154)
[<c0076de8>] (lock_acquire) from [<c0166b70>] (__kernfs_remove+0x254/0x310)
[<c0166b70>] (__kernfs_remove) from [<c0167aa0>] (kernfs_remove_by_name_ns+0x4c/0x94)
[<c0167aa0>] (kernfs_remove_by_name_ns) from [<c0169fb8>] (remove_files.isra.1+0x48/0x84)
[<c0169fb8>] (remove_files.isra.1) from [<c016a2fc>] (sysfs_remove_group+0x58/0xac)
[<c016a2fc>] (sysfs_remove_group) from [<c016a414>] (sysfs_remove_groups+0x34/0x44)
[<c016a414>] (sysfs_remove_groups) from [<c02623b8>] (driver_remove_groups+0x1c/0x20)
[<c02623b8>] (driver_remove_groups) from [<c0260e9c>] (bus_remove_driver+0x3c/0xe4)
[<c0260e9c>] (bus_remove_driver) from [<c026235c>] (driver_unregister+0x38/0x58)
[<c026235c>] (driver_unregister) from [<bf007fb4>] (usb_serial_bus_deregister+0x84/0x88 [usbserial])
[<bf007fb4>] (usb_serial_bus_deregister [usbserial]) from [<bf004db4>] (usb_serial_deregister+0x6c/0x78 [usbserial])
[<bf004db4>] (usb_serial_deregister [usbserial]) from [<bf005330>] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial])
[<bf005330>] (usb_serial_deregister_drivers [usbserial]) from [<bf016618>] (usb_serial_module_exit+0x14/0x1c [sierra])
[<bf016618>] (usb_serial_module_exit [sierra]) from [<c009d6cc>] (SyS_delete_module+0x184/0x210)
[<c009d6cc>] (SyS_delete_module) from [<c000f880>] (ret_fast_syscall+0x0/0x48)
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If no valid CHID value has previously been set on an HWA, writing a
value of all zeros will cause a kernel panic in uwb_radio_stop because
wusbhc->uwb_rc has not been set. This patch skips the call to
uwb_radio_stop if wusbhc->uwb_rc has not been initialized.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nesting a spin_lock_irq/unlock_irq inside a lock that has already
disabled interrupts will enable interrupts before we are ready when
spin_unlock_irq is called. This patch converts the inner lock to use
spin_lock and spin_unlock instead.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch converts the use of spin_lock_irq/spin_unlock_irq to
spin_lock_irqsave/spin_unlock_irqrestore in uwb_rc_set_drp_cmd_done
which is called from a USB completion handler. There are also
whitespace cleanups to make checkpatch.pl happy.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w=2
For external PHY (like ulpi), it needs to configure portsc.pts before
visit viewport, or the viewport can't be visited. so phy_phymode_configure
needs to be called before usb_phy_init.
See: cd0b42c2a6d2a74244f0053f8960f5dad5842278
It may not the best solution, but it can work for all situations.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Cc: shc_work@mail.ru
Cc: denis@eukrea.com
Cc: festevam@gmail.com
Cc: stable <stable@vger.kernel.org> # 3.14
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quite a few fixes this time since I lost v3.15-rc2
window.
Most fixes are MUSB which learned to remove its debugfs directories
properly, got a fix for PHY handling and now knows that it should
make sure its clocks aren't gated before trying to access registers.
ffs got a race fix between ffs_epfile_io() and ffs_func_eps_disable().
dwc3 got a fix for system suspend/resume and now only iterates over
valid endpoints when trying to resize TX fifos.
usb_get_phy() now will properly return an error if try_module_get() fails.
We also have a revert for a NAPI conversion on the ethernet gadget which
was causing a kernel BUG.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTVTiZAAoJEIaOsuA1yqREKHAP/ip+Exini4jKaVTnZkOSQkct
gc+SLRKEt2C+/VmoFJkGa3EzcCr6jNvGO4rrYUjgLti9+nON+/qjWof3AmrP9gIs
z1ZBXj4I2dOq7gILRlUdfuj5H3UAOg799mn+6DnPkjidR1PqqBlD1EoTFoGqh4Lc
bqiWout3R9aWoYjmFLYS6eXFQGeDCHdtSloVXUxYjMHsrNRIv4XL9DDGwcY2gGxc
6qskSCKP5HSCJbwS7jb4pf+J5nCuKASLTAGroSy8mV2cWxfGj+jLXegr4IdjaH0V
73UkMcufacncvhxA3GTEdjQTy6aBKGnLyZgSEIk30RvDz6C1z4J6v2lffm49bpaa
wnZ3g4AToagiXSeWUsi50Ri7oaksFnLSxCh6JYZ0CvTrbMhM3b1/R0r+hB/r5xba
xsjGIZPpp8CCx31cID/FNMP8gxBgtwCAE0WvYl5WlUl5ESXWyt6fQQAlCZLb4kny
fBgoM1IMuirQXKqNC62gSSKsSqSzZbJVK7dTc+nJFxDjRmmcgdrM1VuQyJMVY8rh
DklMYmfYTdP1JL410Ee3Z50c0SriUS3FLuDqkGd5pbKhbuGWTvoogPRY5d3pewrQ
Tq+O4GhYMlluDK9UF8BM4cbXQMu3ov2ddmm9H9ZH71fmVp8CFMdI0s5Q7BZGryh/
+9aatVH5usptuIiZrRlw
=aYvY
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.15-rc3
Quite a few fixes this time since I lost v3.15-rc2
window.
Most fixes are MUSB which learned to remove its debugfs directories
properly, got a fix for PHY handling and now knows that it should
make sure its clocks aren't gated before trying to access registers.
ffs got a race fix between ffs_epfile_io() and ffs_func_eps_disable().
dwc3 got a fix for system suspend/resume and now only iterates over
valid endpoints when trying to resize TX fifos.
usb_get_phy() now will properly return an error if try_module_get() fails.
We also have a revert for a NAPI conversion on the ethernet gadget which
was causing a kernel BUG.
Signed-of-by: Felipe Balbi <balbi@ti.com>
A couple of things here:
- Fixes for pbias that didn't make it in during the merge window due to
the driver coming in via MMC. The conversion to use helpers is a
fix as it implements list_voltage() which the main user (MMC) relies
on for correct functioning.
- Change the !REGULATOR stub for optional regulators to return an
error rather than a dummy; this is more in keeping with the intended
use of optional regulators and fixes some issues seen MMC where it
got confused by a dummy being provided.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTWP4ZAAoJELSic+t+oim9D54P/1iF292i/GenPCAHJo/kIV/j
uoiTcE5igqVoEeEtseqkSOy2Wsf9rukNZvQOyyioT6Pm6f+zOKW7pLPuJZmjqiHk
9FOJYfQcoiYL7HpDMIAAANl5rSHlmDZPs4T40+pHh3LJB/NTnrig5MA0tfW7tcyi
TF4PadYavvNwUYivE8NrMJs0qnuzqiXvEFIqZCxR7zm0AYqdVMkI27f4uKTRodcW
8K8VkQ7F7gDyoCiD8ptviB6v9o2WofnZfLI+9qbxexKmb6TFRrvzTkQ8UdyV9LDs
pLstzJsef7IGUDD6F/i3joKzB8Dp9Qp0+ykrffIbRfm+2Jo0xWXX+h9Ko10m1jji
zhzi/dgWp+e7SkXNaWB4hX1mD+jO6KHEg7RRF0GG4Gv6Jql6shDqNwMLHS8TH/s3
owKHdIaYHoyOx73xTJEePFbHgZTc+7YcC9NPtPe0bN2uheSMV9aHePiLoKuzx832
ee6dPIqoMU/g8zvY5CPqLqdqx1Z64MNTg52QraGsYhQ7ik9cHf0cArp5QAbMjnKI
XC7VY0Fulc0rlKkmCQ3KKxs3w+ahRgrdC+Ogne5SHQsB+5eHSGw+t3MIXWq/iiaE
XwuAQKWIy/DbkG3LgcqQGCA5RgwNWO4lJ13mENtJ4CmYDqO0qDIEdKdZ0lqnLsz+
5siSNt87fIcj5BpX2ZRm
=t/Ad
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of things here:
- Fixes for pbias that didn't make it in during the merge window due
to the driver coming in via MMC. The conversion to use helpers is
a fix as it implements list_voltage() which the main user (MMC)
relies on for correct functioning.
- Change the !REGULATOR stub for optional regulators to return an
error rather than a dummy; this is more in keeping with the
intended use of optional regulators and fixes some issues seen MMC
where it got confused by a dummy being provided"
* tag 'regulator-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Return error in get optional stub
regulator: pbias: Convert to use regmap helper functions
regulator: pbias: Fix is_enabled callback implementation
A few driver specific fixes here:
- SH HSPI was dealing with its clocks incorrectly which meant it didn't
work on some SoCs, fixing this also requires a small fix to one of
the SoC clock trees to avoid breaking existing users.
- The SiRF driver appears to have had several quality problems, it's
fairly new and not widely used so this isn't too worrying.
- A brute force fix for excessive locking in the Atmel driver, it needs
further investigation but this deals with the immediate issue.
- A build fix for the Blackfin driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTWPNeAAoJELSic+t+oim9VOYP/1s4R3EsLg/CoO6T3jqDqizZ
0jnQgqTUi11q8+5ozLdt0zhmGOwmoTaqP3RhNqntwFyMucEWmBjrJcRlcmbfq5ve
IWAArM++RvzCgUmK2DfnQ+KxvLNbdDzO6Q+DIzUb1lia5T64Ope3JBWUG2CT5YSE
Yhi1qaktVWP57toZQmuidW+Q48d+fBxdzQ8VIfP1q2GqISwuabALjzp0I+oG5Sa1
3yd0037WmIYXUM+dKMijPQjNtB4FLJ545RR+Y5s9RXn9Pq/KpLL2aVCaPbDW36Oz
bK4zO80mS6zfurk9Yi7RiOV1uTCd/dg4G2MLTzrtP5LgdKpqthVElKbLJUv9cv0z
gZ19wFM0tGe3raxUsXUlcxAyETiNPP+pm6QriS9rgrdazIiS0gP6tvpfU8Szxv3o
EJMJEQ76ieuVA8LVLskPehNYTl5z4CiISS8SrBUdvV4P96RdyD4rGLdDJw5PDIEL
GBEpdcg48QFt6twO52xAQEzRx0T98c/C0GGYR38CbRiNFFZCh5IAr0po1iwTY3WC
vR/2YJw2Lf/+rf6Hu0cNuFd1csaTBQqh6x4JqVHdmL+xIqut2yhP3DLynK9+APR2
6oIHameZGAY1s0iDpCbeEZoTJF0uJw4+qV3xpCDnSTwiBQoD8whwJUnrFyKb1Mo2
+T5hNKls3vDpNwVPFueU
=kM6u
-----END PGP SIGNATURE-----
Merge tag 'spi-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A few driver specific fixes here:
- SH HSPI was dealing with its clocks incorrectly which meant it
didn't work on some SoCs, fixing this also requires a small fix to
one of the SoC clock trees to avoid breaking existing users.
- The SiRF driver appears to have had several quality problems, it's
fairly new and not widely used so this isn't too worrying.
- A brute force fix for excessive locking in the Atmel driver, it
needs further investigation but this deals with the immediate
issue.
- A build fix for the Blackfin driver"
* tag 'spi-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: atmel: Fix scheduling while atomic bug
spi: sh-hspi: Do not specifically request shyway_clk clock
ARM: shmobile: r8a7778: Use clks as MSTP007 parent
spi: sirf: make GPIO chipselect function work well
spi: sirf: set SPI controller in RISC IO chipselect mode
spi: sirf: correct TXFIFO empty interrupt status bit
spi: bfin5xx: fix build error
It is possible by passing a netlink socket to a more privileged
executable and then to fool that executable into writing to the socket
data that happens to be valid netlink message to do something that
privileged executable did not intend to do.
To keep this from happening replace bare capable and ns_capable calls
with netlink_capable, netlink_net_calls and netlink_ns_capable calls.
Which act the same as the previous calls except they verify that the
opener of the socket had the desired permissions as well.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a seg fault on 'ethtool -A' entry if the
interface is down. Obviously we need to have the
phy device initialized / "connected" (see of_phy_connect())
to be able to advertise pause frame capabilities.
Fixes: 23402bddf9e56eecb27bbd1e5467b3b79b3dbe58
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o In case QLC_83XX_MBX_CMD_NO_WAIT command type the calling
function does not free the memory as it does not wait for
response. So free it when get a response from adapter after
sending the command.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some firmware versions fails to reset the lock during
initialization. Force reset firmware API lock during driver
probe to ensure lock availability.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 1a699476e258 "ACPI / hotplug / PCI: Hotplug notifications from
acpi_bus_notify()" changed the root notify handler, acpi_bus_notify(),
to block unknown type norifications, but it overlooked the fact that
they might be propagated to drivers via the ->notify() callback.
Fix the problem by allowing drivers to receive unknown type
notifications via ->notify() as before.
Fixes: 1a699476e258 (ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify())
Reported-and-tested-by: Mantas Mikulėnas <grawity@gmail.com>
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are two breaks missing there. The result is that userspace
receives multiple messages which might be confusing.
Introduced-by: 3d249d4c "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
I was told that the Cadence macb driver is also useful on Microblaze.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Redefine some macros that were conditioned upon SMC_DEBUG level.
By allowing compiler to verify parameters used by these macros
unconditionally, we can flag compilation failures.
Compiler will still optimize out the unused code path depending on
SMC_DEBUG, so this is a net gain.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull libata fixes from Tejun Heo:
"Dan updated tag allocation to accomodate devices which choke when tags
jump back and forth. Quite a few ahci MSI related fixes. A couple
config dependency fixes and other misc fixes"
* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata/ahci: accommodate tag ordered controllers
ahci: Do not receive interrupts sent by dummy ports
ahci: Use pci_enable_msi_exact() instead of pci_enable_msi_range()
ahci: Ensure "MSI Revert to Single Message" mode is not enforced
ahci: do not request irq for dummy port
pata_samsung_cf: fix ata_host_activate() failure handling
pata_arasan_cf: fix ata_host_activate() failure handling
ata: fix i.MX AHCI driver dependencies
pata_at91: fix ata_host_activate() failure handling
libata: Update queued trim blacklist for M5x0 drives
libata: make AHCI_XGENE depend on PHY_XGENE
The restart/power off implementation in the vexpress driver
used to obtain the config function when necessary. This was
wrong in two respects:
1. It required memory allocation with disabled interrupts
(it worked, but lockdep - when enabled - reported warnings).
2. Used jiffies-based timeout, while jiffies are not running
at this stage of system shutdown (therefore a config
transaction error - if happened - would have never be reported).
Fixed by pre-allocating the config function per device
and using mdelay for timeout.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
[grant.likely: fixed failure when root node specifies the interrupt parent]
Signed-off-by: Grant Likely <grant.likely@linaro.org>
According to:"On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification July 27, 2012 Revision 2.0 version 1.1a"
- add a_wait_vrise to a_wait_vfall
- update condition from a_wait_vrise to a_wait_bcon
Signed-off-by: Li Jun <b47624@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The Tegra124 clock driver currently provides 3 clocks that don't actually
exist; 2 for NAND and one for UART5/UARTE. Delete these.
Cc: <stable@vger.kernel.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
An implementation error should not crash the kernel if it is avoidable.
Replace BUG() with WARN_ONCE().
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In Matt Ropers primary plane series a set of prep patches like
commit af2b653bfb4ef40931b4d101ca842ce0c5da57ef
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Apr 1 15:22:32 2014 -0700
drm/i915: Restrict plane loops to only operate on overlay planes (v2)
ensured that all exisiting users of the mode_config->plane_list
wouldn't change behaviour. Unfortunately tegra seems to have fallen
through the cracks. Fix it.
This regression was introduced in
commit e13161af80c185ecd8dc4641d0f5df58f9e3e0af
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Apr 1 15:22:38 2014 -0700
drm: Add drm_crtc_init_with_planes() (v2)
The result was that we've unref'ed the fb for the primary plane twice,
leading to a use-after free bug. This is because the drm core will
already set crtc->primary->fb to NULL and do the unref for us, and the
crtc disable hook is called by the drm crtc helpers for exactly this
case.
Aside: Now that the fbdev helpers clean up planes there's no longer a
need to do this in drivers. So this could probably be nuked entirely
in linux-next.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The 'label' attribute was always created but returned -ENOENT
if there is no label and such behaviour is undefined from
libsensors' point of view.
Fixed by providing is_visible method in the attributes group,
so the attribute is not created at all when unnecessary.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver used to directly us a DT 'compatible' property for
the 'name' attribute of the hwmon devices. Unfortunately it
contains '-' which is illegal in this context. It messes up
libsensors and thus every application using it.
Fixed by providing equivalent (and simpler) name strings.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If the allocation fails then we dereference the NULL in the error path.
Just return directly.
Fixes: ed27ff1db869 ('clk: Versatile Express clock generators ("osc") driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:
commit 93a25a9e2d67765c3092bfaac9b855d95e39df97
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 6 09:40:43 2014 +0100
drm/i915: Disable full ppgtt by default
By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
means full, all other values are reserved.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:51 2014 -0800
drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
v2: Add a debug message to track the discard of the BIOS fb.
v3: Ville pointed out the difference between ref/unref
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77767
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We already check that the buffer object we're accessing is registered with
the file. Now also make sure that we can't DMA across buffer object boundaries.
v2: Code commenting update.
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Work around BIOSes that don't report the entire Intel MCH area.
MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a
PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts.
Some BIOSes still report a PNP0C02 resource that is only 16KB, which means
the rest of the MCH space is consumed but unreported.
This can cause resource map sanity check warnings or (theoretically) a
device conflict if we assigned the unreported space to another device.
The Intel perf event uncore driver tripped over this when it claimed the
MCH region:
resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.
References: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic
Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In usbdux_ao_cmd(), the channels for the command are transfered from the
cmd->chanlist and stored in the private data 'ao_chanlist'. The channel
numbers are bit-shifted when stored so that they become the "command"
that is transfered to the device. The channel to command conversion
results in the 'ao_chanlist' having these values for the channels:
channel 0 -> ao_chanlist = 0x00
channel 1 -> ao_chanlist = 0x40
channel 2 -> ao_chanlist = 0x80
channel 3 -> ao_chanlist = 0xc0
The problem is, the usbduxsub_ao_isoc_irq() function uses the 'chan' value
from 'ao_chanlist' to access the 'ao_readback' array in the private data.
So instead of accessing the array as 0, 1, 2, 3, it accesses it as 0x00,
0x40, 0x80, 0xc0.
Fix this by storing the raw channel number in 'ao_chanlist' and doing the
bit-shift when creating the command.
Fixes: a998a3db530bff80 "staging: comedi: usbdux: cleanup the private data 'outBuffer'"
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Acked-by: Bernd Porr <mail@berndporr.me.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The goal of this patch is to fix rtnelink notification. The main problem was
about notification for fdb entry with more than one remote. Before the patch,
when a remote was added to an existing fdb entry, the kernel advertised the
first remote instead of the added one. Also when a remote was removed from a fdb
entry with several remotes, the deleted remote was not advertised.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In ksz9021_load_values_from_of() val2 to val4 aren't tested against their
initialization value.
This causes the test to always succeed, and this value to be used as if it
was loaded from the devicetree instead of being ignored, in case of a
missing/invalid property in the ethernet OF device node.
As a result, the value "0" is written to the relevant registers.
Change the conditions to test against the right initialization value.
Signed-off-by: Hubert Chaumette <hchaumette@adeneo-embedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull input updates from Dmitry Torokhov:
"The main change is that we now publish "firmware ID" for the serio
devices to help userspace figure out the kind of touchpads it is
dealing with: i8042 will export PS/2 port's PNP IDs as firmware IDs.
You will also get more quirks for Synaptics touchpads in various
Lenovo laptops, a change to elantech driver to recognize even more
models, and fixups to wacom and couple other drivers"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: elantech - add support for newer elantech touchpads
Input: soc_button_array - fix a crash during rmmod
Input: synaptics - add min/max quirk for ThinkPad T431s, L440, L540, S1 Yoga and X1
Input: synaptics - report INPUT_PROP_TOPBUTTONPAD property
Input: Add INPUT_PROP_TOPBUTTONPAD device property
Input: i8042 - add firmware_id support
Input: serio - add firmware_id sysfs attribute
Input: wacom - handle 1024 pressure levels in wacom_tpc_pen
Input: wacom - references to 'wacom->data' should use 'unsigned char*'
Input: wacom - override 'pressure_max' with value from HID_USAGE_PRESSURE
Input: wacom - use full 32-bit HID Usage value in switch statement
Input: wacom - missed the last bit of expresskey for DTU-1031
Input: ads7846 - fix device usage within attribute show
Input: da9055_onkey - remove use of regmap_irq_get_virq()
There is a missing 0 entry from the MOD_SEL3 table.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The extra entry in the table makes SCIFA0_B, and all
peripherals after it, fail.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since we set up device wake-up interrupts as pinctrl-single
interrupts, we now must use the standard request_irq and
related functions to manage them.
If the pin interrupts are enabled for some pins at boot,
the wake-up events can show up as constantly pending
at least on omaps and will hang the system unless the related
device driver clears the event at the device.
To fix this, let's clear the interrupt flags during init,
and print out a warning so the board maintainers can update
their drivers to do proper request_irq for the driver specific
wake-up events.
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
s/interrupts-names/interrupt-names/g
s/clocks-names/clock-names/g
Some of the binding files and device tree files get this wrong and the
kernel won't be able to pick it up. Fix them up now so that they don't
get widely used.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by : Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.
The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.
This regression was introduced in
commit e9cb81a22841908b1c075156b409a538d09c8466
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Nov 21 13:47:23 2013 -0200
drm/i915: get a runtime PM reference when the panel VDD is on
v2: - Rebase
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the gmch_pfit state to
it.
3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.
-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Newer elantech touchpads are not recognized by the current driver, since it
fails to detect their firmware version number. This prevents more advanced
touchpad features from being usable such as two-finger scrolling. This
patch allows newer touchpads to be detected and be fully functional. Tested
on Sony Vaio SVF13N17PXB.
Signed-off-by: Jordan Rife <jrife0@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When the system has zero or one button available, trying to rmmod
soc_button_array will cause crash. Fix this by properly handling -ENODEV
in probe().
Signed-off-by: Lejun Zhu <lejun.zhu@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Fix the platform data support for the at91 adc driver.
* A couple of related follow up patches get the support working again
for at91sam9260 and at91sam9g45 as the earlier patch results in a device
name change.
* A default timer value in the at91 adc driver was bonkers. Make it sane.
* Fix incorrect reporting of the integration time for the cm32181 light sensor
* Fix a missing break in the ad2s1200 driver which would have give a false
error return.
* Make sure buffer scan mask queries from userspace return 0/1 rather than
a fairly random value depending on their implementation of test_bit
* Fix leak of the i2c client and a null pointer dereference in the cm36651
driver.
* Fix a build warning on avr32 for the mxs-lradc (not exactly a critical
combination - but the issue was real).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTSX1HAAoJEFSFNJnE9BaIGkoQAIotGana51TXPo9KYnQJaCYH
+xBfaaXEaR69lARoXT8SDGzyXPCQNOEbVfsXRwrVQ4Wl8x2hP8n9YdUrAHzZ/8O/
Wf8Z0jb81Q+KNJ+SMMgcy4kK5OU71EMMk5fbocPzD+WfQ+WlDr+My1F3yZ5UIvOM
nOUF6QCcYA0MN7dopEVIqyP8HZhrxR1YUvgzqOmp1fteYL4gFCU006WPSI30GxEv
fMM8MiWbbn9xjOsR7SBzaLEo0Hv3YC92zwSAuJxGClH/+9cKogWAaE/PiNUO3y6A
+2D0KQnGRopKy4j/QCjdPZsTmYDBxQ9vMlUOtRlOf1XAVjL6pZu2EJ2/ereShLW6
B4rev23tqgk9nyNk/Li4n+5krzvPqqOcbWNW1la769DkEt7LU+YU+hiShkDm1+0M
6hwxPd6gQxg0QUjuusi1+B5JqweAv+mEcCsQ+ga6ZK61X9bNJ6c/4YF451rkNhc6
mlC3ZqBvDALmNSVdCas0GOGHLaeWxfoT7E9G6p62h9uBVerqZ6epvlAUC6JOHotc
/qz/D1VL1+ptPAawXiFSNOb8RMJogdBfjPB9bOlYQSSHV3eF0RVNK6FQiqvc4mFX
or1pPG6lDLGm6g3NcDEjxEEVThevQpEwKmpM0TCEUMiIuxSHYN/M//P2PSeDvYwk
9k8x3fJae7dWNsGIT92y
=HMr3
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.15a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First found of IIO fixes for the 3.15 cycle.
* Fix the platform data support for the at91 adc driver.
* A couple of related follow up patches get the support working again
for at91sam9260 and at91sam9g45 as the earlier patch results in a device
name change.
* A default timer value in the at91 adc driver was bonkers. Make it sane.
* Fix incorrect reporting of the integration time for the cm32181 light sensor
* Fix a missing break in the ad2s1200 driver which would have give a false
error return.
* Make sure buffer scan mask queries from userspace return 0/1 rather than
a fairly random value depending on their implementation of test_bit
* Fix leak of the i2c client and a null pointer dereference in the cm36651
driver.
* Fix a build warning on avr32 for the mxs-lradc (not exactly a critical
combination - but the issue was real).
A label just before a brace needs a following semicolon (empty statement).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
