summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)Author
2014-04-24Merge tag 'vexpress/fixes-for-3.15' of ↵Arnd Bergmann
git://git.linaro.org/people/pawel.moll/linux into fixes ARM Versatile Express fixes for 3.15 This series contains straight-forward fixes for different Versatile Express infrastructure drivers: - NULL pointer dereference on the error path in the clk driver - out of boundary array access in the dcscb driver - broken restart/power off implementation - mis-interpreted voltage unit in the spc driver * tag 'vexpress/fixes-for-3.15' of git://git.linaro.org/people/pawel.moll/linux: ARM: vexpress/TC2: Convert OPP voltage to uV before storing power/reset: vexpress: Fix restart/power off operation arm/mach-vexpress: array accessed out of bounds clk: vexpress: NULL dereference on error path Includes an update to 3.15-rc2 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-04-24of/irq: do irq resolution in platform_get_irqRob Herring
Currently we get the following kind of errors if we try to use interrupt phandles to irqchips that have not yet initialized: irq: no irq domain found for /ocp/pinmux@48002030 ! ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184() Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012 (show_stack+0x14/0x1c) (dump_stack+0x6c/0xa0) (warn_slowpath_common+0x64/0x84) (warn_slowpath_null+0x1c/0x24) (of_device_alloc+0x144/0x184) (of_platform_device_create_pdata+0x44/0x9c) (of_platform_bus_create+0xd0/0x170) (of_platform_bus_create+0x12c/0x170) (of_platform_populate+0x60/0x98) This is because we're wrongly trying to populate resources that are not yet available. It's perfectly valid to create irqchips dynamically, so let's fix up the issue by resolving the interrupt resources when platform_get_irq is called. And then we also need to accept the fact that some irqdomains do not exist that early on, and only get initialized later on. So we can make the current WARN_ON into just into a pr_debug(). We still attempt to populate irq resources when we create the devices. This allows current drivers which don't use platform_get_irq to continue to function. Once all drivers are fixed, this code can be removed. Suggested-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Grant Likely <grant.likely@linaro.org>
2014-04-24can: slcan: Fix spinlock variantAlexander Stein
slc_xmit is called within softirq context and locks sl->lock, but slcan_write_wakeup is not softirq context, so we need to use spin_[un]lock_bh! Detected using kernel lock debugging mechanism. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: fix return value from can_get_bittiming()Oliver Hartkopp
When trying to set a data bitrate on non CAN FD devices the 'ip' tool answers with: RTNETLINK answers: Unknown error 524 Rename '-ENOTSUPP' to '-EOPNOTSUPP' so that 'ip' answers correctly: RTNETLINK answers: Operation not supported Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: sja1000_isa: add locking for indirect register access modeOliver Hartkopp
When accessing the SJA1000 controller registers in the indirect access mode, writing the register number and reading/writing the data has to be an atomic attempt. As the sja1000_isa driver is an old style driver with a fixed number of instances the locking variable depends on the same index like all the other configuration elements given on the module command line. As a positive side effect dev->dev_id is populated by the instance index, which was missing in 3e66d0138c05d9 ("can: populate netdev::dev_id for udev discrimination"). Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can_pci: enable PCI bus master only for MSIWolfgang Grandegger
Coverity complains that c_can_pci_probe() calls pci_enable_msi() without checking the result: CID 712278 (#1 of 1): Unchecked return value (CHECKED_RETURN) 3. check_return: Calling pci_enable_msi_block without checking return value (as is done elsewhere 88 out of 105 times). 88 pci_enable_msi(pdev); This is CID 712278. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Reported-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: use proper type for 'instance'Wolfram Sang
Commit 6439fbce1075 (can: c_can: fix error checking of priv->instance in probe()) found the warning but applied a suboptimal solution. Since, both pdev->id and of_alias_get_id() return integers, it makes sense to convert the variable to an integer and avoid the cast. Signed-off-by: Wolfram Sang <wsa@sang-engineering.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Speed up tx buffer invalidationThomas Gleixner
It's suffcient to kill the TXIE bit in the message control register even if the documentation of C and D CAN says that it's not allowed to do that while MSGVAL is set. Reality tells a different story and this change gives us another 2% of CPU back for not waiting on I/O. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Remove tx lockingThomas Gleixner
Mark suggested to use one IF for the softirq and the other for the xmit function to avoid the xmit lock. That requires to write the frame into the interface first, then handle the echo skb and store the dlc before committing the TX request to the message ram. We use an atomic to handle the active buffers instead of reading the MSGVAL register as thats way faster especially on PCH/x86. Suggested-by: Mark <mark5@del-llc.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Use proper u32 variables in c_can_write_msg_object()Thomas Gleixner
Instead of obfuscating the code by artificial 16 bit splits use the proper 32 bit assignments and split the result when writing to the interface. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Cleanup c_can_write_msg_object()Thomas Gleixner
Remove the MASK from the TX transfer side. Make the code readable and get rid of the annoying IFX_WRITE_XXX_16BIT macros which are just obfuscating the code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Cleanup c_can_msg_obj_put/get()Thomas Gleixner
Sigh! Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Cleanup c_can_inval_msg_object()Thomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Cleanup setup of receive buffersThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Cleanup c_can_read_msg_object()Thomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Cleanup irq enable/disableThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Work around C_CAN RX wreckageThomas Gleixner
Alexander reported that the new optimized handling of the RX fifo causes random packet loss on Intel PCH C_CAN hardware. After a few fruitless debugging sessions I got hold of a PCH (eg20t) afflicted system. That machine does not have the CAN interface wired up, but it was possible to reproduce the issue with the HW loopback mode. As Alexander observed correctly, clearing the NewDat flag along with reading out the message buffer causes that issue on C_CAN, while D_CAN handles that correctly. Instead of restoring the original message buffer handling horror the following workaround solves the issue: transfer buffer to IF without clearing the NewDat handle the message clear NewDat bit That's similar to the original code but conditional for C_CAN. I really wonder why all user manuals (C_CAN, Intel PCH and some more) recommend to clear the NewDat bit right away. The knows it all Oracle operated by Gurgle does not unearth any useful information either. I simply cannot believe that we are the first to uncover that HW issue. Reported-and-tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Disable rx split as workaroundThomas Gleixner
The RX buffer split causes packet loss in the hardware: What happens is: RX Packet 1 --> message buffer 1 (newdat bit is not cleared) RX Packet 2 --> message buffer 2 (newdat bit is not cleared) RX Packet 3 --> message buffer 3 (newdat bit is not cleared) RX Packet 4 --> message buffer 4 (newdat bit is not cleared) RX Packet 5 --> message buffer 5 (newdat bit is not cleared) RX Packet 6 --> message buffer 6 (newdat bit is not cleared) RX Packet 7 --> message buffer 7 (newdat bit is not cleared) RX Packet 8 --> message buffer 8 (newdat bit is not cleared) Clear newdat bit in message buffer 1 Clear newdat bit in message buffer 2 Clear newdat bit in message buffer 3 Clear newdat bit in message buffer 4 Clear newdat bit in message buffer 5 Clear newdat bit in message buffer 6 Clear newdat bit in message buffer 7 Clear newdat bit in message buffer 8 Now if during that clearing of newdat bits, a new message comes in, the HW gets confused and drops it. It does not matter how many of them you clear. I put a delay between clear of buffer 1 and buffer 2 which was long enough that the message should have been queued either in buffer 1 or buffer 9. But it did not show up anywhere. The next message ended up in buffer 1. So the hardware lost a packet of course without telling it via one of the error handlers. That does not happen on all clear newdat bit events. I see one of 10k packets dropped in the scenario which allows us to reproduce. But the trace looks always the same. Not splitting the RX Buffer avoids the packet loss but can cause reordering. It's hard to trigger, but it CAN happen. With that mode we use the HW as it was probably designed for. We read from the buffer 1 upwards and clear the buffer as we get the message. That's how all microcontrollers use it. So I assume that the way we handle the buffers was never really tested. According to the public documentation it should just work :) Let the user decide which evil is the lesser one. [ Oliver Hartkopp: Provided a sane config option and help text and made me switch to favour potential and unlikely reordering over packet loss ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Get rid of pointless interruptsThomas Gleixner
The driver handles pointlessly TWO interrupts per packet. The reason is that it enables the status interrupt which fires for each rx and tx packet and it enables the per message object interrupts as well. The status interrupt merily acks or in case of D_CAN ignores the TX/RX state and then the message object interrupt fires. The message objects interrupts are only useful if all message objects have hardware filters activated. But we don't have that and its not simple to implement in that driver without rewriting it completely. So we can ditch the message object interrupts and handle the RX/TX right away from the status interrupt. Instead of TWO we handle ONE. Note: We must keep the TXIE/RXIE bits in the message buffers because the status interrupt alone is not reliable enough in corner cases. If we ever have the need for HW filtering, then this code needs a complete overhaul and we can think about it then. For now we prefer a lower interrupt load. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Avoid status register update for D_CANThomas Gleixner
On D_CAN the RXOK, TXOK and LEC bits are cleared/set on read of the status register. No need to update them. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Simplify buffer reenablingThomas Gleixner
Instead of writing to the message object we can simply clear the NewDat bit with the get method. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Always update error statsThomas Gleixner
If the allocation of the error skb fails, we still want to see the error statistics. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Fix berr reportingThomas Gleixner
Reading the LEC type with return (mode & ENABLED) && (status & LEC_MASK); is not guaranteed to return (status & LEC_MASK) if the enabled bit in mode is set. It's guaranteed to return 0 or !=0. Remove the inline function and call unconditionally into the berr_handling code and return early when the reporting is disabled. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Handle state change correctlyThomas Gleixner
If the allocation of an error skb fails, the state change handling returns w/o doing any work. That leaves the interface in a wreckaged state as the internal status is wrong. Split the interface handling and the skb handling. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Do not access skb after net_receive_skb()Thomas Gleixner
There is no guarantee that the skb is in the same state after calling net_receive_skb(). It might be freed or reused. Not really harmful as its a read access, except you turn on the proper debugging options which catch a use after free. The whole can subsystem is full of this. Copy and paste .... Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Make bus off interrupt disable logic workThomas Gleixner
The state change handler is called with device interrupts disabled already. So no point in disabling them again when we enter bus off state. But what's worse is that we reenable the interrupts at the end of NAPI poll unconditionally. So c_can_start() which is called from the restart timer can trigger interrupts which confuse the hell out of the half reinitialized driver/hw. Remove the pointless device interrupt disable in the BUS_OFF handler and prevent reenabling the device interrupts at the end of the poll routine when the current state is BUS_OFF. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can: Fix startup logicThomas Gleixner
c_can_start() enables interrupts way too early. The first enabling happens when setting the control mode in c_can_chip_config() and then again at the end of the function. But that happens before napi_enable() and that means that an interrupt which comes in will disable interrupts again and call napi_schedule, which ignores the request and the later napi_enable() is not making thinks work either. So the interface is up with all device interrupts disabled. Move the device interrupt after napi_enable() and add it to the other callsites of c_can_start() in c_can_set_mode() and c_can_power_up() Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24can: c_can_pci: Set the type of the IP coreThomas Gleixner
All type checks in c_can.c are != BOSCH_D_CAN so nobody noticed so far that the pci code does not update the type information. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-04-24phy: fix kernel oops in phy_lookup()Sergei Shtylyov
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>
2014-04-24phy: restore OMAP_CONTROL_PHY dependenciesJean Delvare
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>
2014-04-24phy: exynos: fix building as a moduleArnd Bergmann
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>
2014-04-24USB: serial: fix sysfs-attribute removal deadlockJohan Hovold
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>
2014-04-24usb: wusbcore: fix panic in wusbhc_chid_setThomas Pugliese
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>
2014-04-24usb: wusbcore: convert nested lock to use spin_lock instead of spin_lock_irqThomas Pugliese
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>
2014-04-24uwb: don't call spin_unlock_irq in a USB completion handlerThomas Pugliese
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>
2014-04-24usb: chipidea: coordinate usb phy initialization for different phy typePeter Chen
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>
2014-04-24Merge tag 'fixes-for-v3.15-rc3' of ↵Greg Kroah-Hartman
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>
2014-04-24Merge tag 'regulator-v3.15-rc2' of ↵Linus Torvalds
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
2014-04-24Merge tag 'spi-v3.15-rc2' of ↵Linus Torvalds
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
2014-04-24net: Use netlink_ns_capable to verify the permisions of netlink messagesEric W. Biederman
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>
2014-04-24gianfar: Check if phydev present on ethtool -AClaudiu Manoil
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>
2014-04-24qlcnic: Fix memory leak.Rajesh Borundia
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>
2014-04-24qlcnic: Reset firmware API lock at driver load timeSony Chacko
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>
2014-04-24ACPI / notify: Do not block unknown type notifications in root handlerRafael J. Wysocki
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>
2014-04-24team: forbid incorrect fall-through in notifierJiri Pirko
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>
2014-04-24net: cadence: Fix architecture dependenciesJean Delvare
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>
2014-04-24smc91x: improve definition of debug macrosZi Shen Lim
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>
2014-04-24Merge branch 'for-3.15-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata 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
2014-04-24power/reset: vexpress: Fix restart/power off operationPawel Moll
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>
2014-04-24of: selftest: add deferred probe interrupt testRob Herring
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>