| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Fix to return a negative error code from the bus speed parse
error handling case instead of 0.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
the driver will print a lot of error messages if there was no ACK
received.
i2cdetect normally print a table with all the available devices. If there
is no device on the address, the table will be empty.
Currently with the i2c-eg20t driver, the table is not visible because
the error messages destroy the table.
Error message: pch_i2c_getack return -71
This patch prevent the driver to print the messages to syslog.
The pch_i2c_wait_for_check_xfer function is the only one who is
calling pch_i2c_getack, so we can delete the function and add the
read to pch_i2c_wait_for_check_xfer.
If no ACK is received, the Message will be printed as a dbg
message.
Fixed print message to be a one liner so we can grep for the
error message.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner <wernerandy@gmx.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce support for Broadcom Serial Controller (BSC) I2C bus found
in the Kona family of Mobile SoCs. FIFO hardware is utilized but only
standard mode (100kHz), fast mode (400kHz), fast mode plus (1MHz), and
I2C high-speed (3.4 MHz) bus speeds are supported.
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Matt Porter <matt.porter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
[wsa: fixed Kconfig sorting, squashed broken out patches into one]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
| |
Looks like we're missing two lines needed to make it
work properly with device tree.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
| |
Add the missing clk_disable_unprepare() before return
from wmt_i2c_reset_hardware() in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org # 3.11+
|
|
|
|
|
|
|
|
| |
Newer Intel PCHs with LPSS have the same Designware I2C controllers than
Haswell but the ACPI IDs differ. Add these IDs to the driver list.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
| |
This patch adds the SMBus Device IDs for the Intel Wildcat Point-LP PCH.
Signed-off-by: James Ralston <james.d.ralston@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clk_disable_unprepare in remove causes an imbalance and hence gives
the below crash on module remove. While at it also remove some
duplicate code from probe.
/ $ rmmod i2c-exynos5
[ 6.996374] ------------[ cut here ]------------
[ 6.999523] WARNING: CPU: 2 PID: 1137 at drivers/clk/clk.c:842 clk_disable+0x18/0x24()
[ 7.007403] Modules linked in: i2c_exynos5(-)
[ 7.011747] CPU: 2 PID: 1137 Comm: rmmod Not tainted 3.12.0-next-20131105-00083-g16f4799-dirty #21
[ 7.020696] [<c0014e0c>] (unwind_backtrace+0x0/0xf4) from [<c0011784>] (show_stack+0x10/0x14)
[ 7.029190] [<c0011784>] (show_stack+0x10/0x14) from [<c037acd4>] (dump_stack+0x7c/0xb0)
[ 7.037255] [<c037acd4>] (dump_stack+0x7c/0xb0) from [<c001e0ac>] (warn_slowpath_common+0x6c/0x88)
[ 7.046190] [<c001e0ac>] (warn_slowpath_common+0x6c/0x88) from [<c001e164>] (warn_slowpath_null+0x1c/0x24)
[ 7.055818] [<c001e164>] (warn_slowpath_null+0x1c/0x24) from [<c02dcde4>] (clk_disable+0x18/0x24)
[ 7.064670] [<c02dcde4>] (clk_disable+0x18/0x24) from [<bf0002d4>] (exynos5_i2c_remove+0x1c/0x34 [i2c_exynos5])
[ 7.074736] [<bf0002d4>] (exynos5_i2c_remove+0x1c/0x34 [i2c_exynos5]) from [<c02274a8>] (__device_release_driver+0x58/0xb0)
[ 7.085836] [<c02274a8>] (__device_release_driver+0x58/0xb0) from [<c0227b88>] (driver_detach+0xac/0xb0)
[ 7.095291] [<c0227b88>] (driver_detach+0xac/0xb0) from [<c02271c0>] (bus_remove_driver+0x4c/0xa0)
[ 7.104227] [<c02271c0>] (bus_remove_driver+0x4c/0xa0) from [<c00725dc>] (SyS_delete_module+0x124/0x194)
[ 7.113682] [<c00725dc>] (SyS_delete_module+0x124/0x194) from [<c000e2e0>] (ret_fast_syscall+0x0/0x30)
[ 7.122957] ---[ end trace 23bb6e4e0bf52196 ]---
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support to SSC (Synchronous Serial Controller)
I2C driver. This IP also supports SPI protocol, but this is not
the aim of this driver.
This IP is embedded in all ST SoCs for Set-top box platorms, and
supports I2C Standard and Fast modes.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.
Driver only supports Device Tree method.
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Taekgyun Ko <taeggyun.ko@samsung.com>
Reviewed-by: Simon Glass <sjg@google.com>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Signed-off-by: Andrew Bresticker <abrestic@google.com>
[wsa: rebased to v3.12-rc4 (no of_i2c.h anymore)]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
b720423a2627f045133bec39a31fe2bc0dab86f3
(i2c: rcar: add rcar-H2 support)
added R-Car H2 support on i2c-rcar.
The R-Car I2C type is based on SoC generation
(Gen1 = E1/M1/H1, Gen2 = E2/M2/H2),
but added naming was H1/H2 instead of Gen1/Gen2.
Gen1/Gen2 is better naming on this driver.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
| |
"obj" can't be NULL here.
We already know that "pkg->package.elements" gives us a valid pointer
so the next pointer after that is also non-NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
| |
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
and ARCH_SHMOBILE_MULTI, and increase build testing coverage with
COMPILE_TEST.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
| |
Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The i2c-mux driver requires that the chan_id parameter
passed to the i2c_add_mux_adapter() function is equal
to the reg value for that adapter:
for_each_child_of_node(mux_dev->of_node, child) {
ret = of_property_read_u32(child, "reg", ®);
if (ret)
continue;
if (chan_id == reg) {
priv->adap.dev.of_node = child;
break;
}
}
The i2c-mux-gpio driver uses an internal logical index
for chan_id when calling i2c_add_mux_adapter() instead
of using the reg value.
Because of this, there will problems in selecting the
right adapter when the i2c-mux-gpio's index into
mux->data.values doesn't match the reg value.
An example of such a case:
mux->data.values = { 1, 0 }
For chan_id = 0, i2c-mux will bind the adapter to the
of_node with reg = <0>, but when it will call the
select() callback with chan_id set to 0, the i2c-mux-gpio
will use it as an index into mux->data.values and it will
actually select the bus with reg = <1>.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
Acked-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some gpio chips may have get/set operations that
can sleep. gpio_set_value() only works for chips
which do not sleep, for the others we will get a
kernel warning. Using gpio_set_value_cansleep()
will work for both chips that do sleep and those
who don't.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
Acked-by: Peter Korsgaard <peter.korsgaard@barco.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
|
|
|
|
|
|
|
|
| |
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
| |
The i.MX23 I2C controller is also capable of PIO, but needs a little harder
push to behave. The controller needs to be reset after every PIO/DMA operation
for some reason, otherwise in rare cases, the controller can hang or emit
bytes onto the bus.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analyze and rework the PIO mode operation. The PIO mode operation
was unreliable on MX28, by analyzing the bus with LA, the checks
for when data were available or were to be sent were wrong.
The PIO WRITE has to be completely reworked as it multiple problems.
The MX23 datasheet helped here, see comments in the code for details.
The problems boil down to:
- RUN bit in CTRL0 must be set after DATA register was written
- The PIO transfer must be 4 bytes long tops, otherwise use
clock stretching.
Both of these fixes are implemented.
The PIO READ operation can only be done for up to four bytes as
we are unable to read out the data from the DATA register fast
enough.
This patch also tries to document the investigation within the
code.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
| |
It seems the PIO mode does not work, or at least not like it works
on a i.MX28. Each short transfer needs about one second (without an
error message) but does not send anything on the I2C lines.
Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant. The same data can be
accessed through to_i2c_driver(client->dev.driver). The generated code for both
approaches in more or less the same.
E.g. on ARM the expression client->driver->command(...) generates
...
ldr r3, [r0, #28]
ldr r3, [r3, #32]
blx r3
...
and the expression to_i2c_driver(client->dev.driver)->command(...) generates
...
ldr r3, [r0, #160]
ldr r3, [r3, #-4]
blx r3
...
Other architectures will generate similar code.
All users of the 'driver' field outside of the I2C core have already been
converted. So this only leaves the core itself. This patch converts the
remaining few users in the I2C core and then removes the 'driver' field from the
i2c_client struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Check i2c_client->dev.driver instead to see if a driver is bound to the
device.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Use 'to_i2c_driver(client->dev.driver)' instead to get direct
access to the i2c_driver struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Use 'to_i2c_driver(client->dev.driver)' instead to get direct access to
the i2c_driver struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the later. To get direct access to the i2c_driver struct use
'to_i2c_driver(client->dev.driver)'.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the later.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the later.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
| |
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the later.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
| |
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves the at24.h header from include/linux/i2c to
include/linux/platform_data and updates existing support accordingly.
It also fixes the following checkpatch warning:
WARNING: please, no space before tabs
#436: FILE: include/linux/platform_data/at24.h:31:
+ * ^Iu8 *mac_addr = ethernet_pdata->mac_addr;$
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
| |
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
| |
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the same clock for all device instances is non-portable and obtaining
clock references by an ID without using a device pointer is discouraged.
This is also not needed, because on platforms, where this driver is used,
suitable clocks are available for the I2C controllers, that are children of
the peripheral clock and just pass its rate 1-to-1 to controllers. This
patch switches the driver to obtain references to correct clocks.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
| |
When clk_get() fails, it returns an error code, not a NULL. This patch
fixes such an error handling bug.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
| |
This patch adds Device Tree support to the i2c-rcar driver and respective
documentation.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
| |
There is no need to repeatedly query clock frequency, where it is not
expected to change. The complete loop can also trivially be replaced with
a simple division. A further loop below the one, being simplified, could
also be replaced, but that would get more complicated.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
| |
A recent patch added even more superfluous parenthesis to those, which
already were there. Remove them again.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
|
|
|
|
|
|
|
|
|
| |
The 'name' attribute is needed for all i2c-dev class devices, meaning
it can be created automatically by pointing to it in the class data
structure. This simplifies the code and reduces the probability for race
conditions (the name attribute should exist by the time the device is
announced to user space).
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are a number of USB driver fixes for 3.12-rc3.
These are all for host controller issues that have been reported, and
there's a fix for an annoying error message that gets printed every
time you remove a USB 3 device from the system that's been bugging me
for a while"
* tag 'usb-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: dwc3: add support for Merrifield
USB: fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitialization
USB: Fix breakage in ffs_fs_mount()
fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy
usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit
usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA
usb: chipidea: udc: free pending TD at removal procedure
usb: chipidea: imx: Add usb_phy_shutdown at probe's error path
usb: chipidea: Fix memleak for ci->hw_bank.regmap when removal
usb: chipidea: udc: fix the oops after rmmod gadget
USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd
USB: OHCI: accept very late isochronous URBs
USB: UHCI: accept very late isochronous URBs
USB: iMX21: accept very late isochronous URBs
usbcore: check usb device's state before sending a Set SEL control transfer
xhci: Fix race between ep halt and URB cancellation
usb: Fix xHCI host issues on remote wakeup.
xhci: Ensure a command structure points to the correct trb on the command ring
xhci: Fix oops happening after address device timeout
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add PCI id for Intel Merrifield
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In case of usb phy reinitialization:
e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module
It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset.
So we just check PHY_CLK_VALID bit during the stage with POR, this can be met
by the tricky of checking FSL_SOC_USB_PRICTRL register.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a bunch of failure exits in ffs_fs_mount() with
seriously broken recovery logics. Most of that appears to stem
from misunderstanding of the ->kill_sb() semantics; unlike
->put_super() it is called for *all* superblocks of given type,
no matter how (in)complete the setup had been. ->put_super()
is called only if ->s_root is not NULL; any failure prior to
setting ->s_root will have the call of ->put_super() skipped.
->kill_sb(), OTOH, awaits every superblock that has come from
sget().
Current behaviour of ffs_fs_mount():
We have struct ffs_sb_fill_data data on stack there. We do
ffs_dev = functionfs_acquire_dev_callback(dev_name);
and store that in data.private_data. Then we call mount_nodev(),
passing it ffs_sb_fill() as a callback. That will either fail
outright, or manage to call ffs_sb_fill(). There we allocate an
instance of struct ffs_data, slap the value of ffs_dev (picked
from data.private_data) into ffs->private_data and overwrite
data.private_data by storing ffs into an overlapping member
(data.ffs_data). Then we store ffs into sb->s_fs_info and attempt
to set the rest of the things up (root inode, root dentry, then
create /ep0 there). Any of those might fail. Should that
happen, we get ffs_fs_kill_sb() called before mount_nodev()
returns. If mount_nodev() fails for any reason whatsoever,
we proceed to
functionfs_release_dev_callback(data.ffs_data);
That's broken in a lot of ways. Suppose the thing has failed in
allocation of e.g. root inode or dentry. We have
functionfs_release_dev_callback(ffs);
ffs_data_put(ffs);
done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by
functionfs_release_dev_callback(ffs);
from ffs_fs_mount() (via data.ffs_data). Note that the second
functionfs_release_dev_callback() has every chance to be done to freed memory.
Suppose we fail *before* root inode allocation. What happens then?
ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all,
or it doesn't have a pointer to ffs stored in sb->s_fs_info). And
functionfs_release_dev_callback(data.ffs_data);
is called by ffs_fs_mount(), but here we are in nasal daemon country - we
are reading from a member of union we'd never stored into. In practice,
we'll get what we used to store into the overlapping field, i.e. ffs_dev.
And then we get screwed, since we treat it (struct gfs_ffs_obj * in
disguise, returned by functionfs_acquire_dev_callback()) as struct
ffs_data *, pick what would've been ffs_data ->private_data from it
(*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data
is much bigger) and poke in whatever it points to.
FWIW, there's a minor leak on top of all that in case if ffs_sb_fill()
fails on kstrdup() - ffs is obviously forgotten.
The thing is, there is no point in playing all those games with union.
Just allocate and initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data. And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Cc: stable <stable@vger.kernel.org> # 3.3+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL
bit when USB_EN bit is already set causes instability issues with
PHY_CLK_VLD bit. So USB_EN is set only for IP controller version
below 1.6 before setting ULPI_PHY_CLK_SEL bit
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
direction bit
Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).
The reason is a USB control message
usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.
The kernel thus rejects the IO and thus we see the failure.
Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.
It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to. The device seems to happily deal with that though (and
seems to not really care about this value much).
So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.
The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)
With attached patch, the app in Windows in KVM works.
usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81
I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].
[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If NO_DMA=y:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
Reviewed-and-tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is a pending TD which is not freed after request finishes,
we do this due to a controller bug. This TD needs to be freed when
the driver is removed. It prints below error message when unload
chipidea driver at current code:
"ci_hdrc ci_hdrc.0: dma_pool_destroy ci_hw_td, b0001000 busy"
It indicates the buffer at dma pool are still in use.
This commit will free the pending TD at driver's removal procedure,
it can fix the problem described above.
Acked-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If not, the PHY will be active even the controller is not in use.
We find this issue due to the PHY's clock refcount is not correct
due to -EPROBE_DEFER return after phy's init.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| | |
It needs to free ci->hw_bank.regmap explicitly since it is not managed
resource.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we rmmod gadget, the ci->driver needs to be cleared.
Otherwise, when we plug in usb cable again, the driver will
consider gadget is there, and go to enumeration procedure,
but in fact, it was removed.
ci_hdrc ci_hdrc.0: Connected to host
Unable to handle kernel paging request at virtual address 7f02a42c
pgd = 80004000
[7f02a42c] *pgd=3f13d811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] SMP ARM
Modules linked in: usb_f_acm u_serial libcomposite configfs [last unloaded: g_serial]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0+ #42
task: 807dba88 ti: 807d0000 task.ti: 807d0000
PC is at udc_irq+0x8fc/0xea4
LR is at l2x0_cache_sync+0x5c/0x6c
pc : [<803de7f4>] lr : [<8001d0f0>] psr: 20000193
sp : 807d1d98 ip : 807d1d80 fp : 807d1df4
r10: af809900 r9 : 808184d4 r8 : 00080001
r7 : 00082001 r6 : afb711f8 r5 : afb71010 r4 : ffffffea
r3 : 7f02a41c r2 : afb71010 r1 : 807d1dc0 r0 : afb71068
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 3f01804a DAC: 00000017
Process swapper/0 (pid: 0, stack limit = 0x807d0238)
Stack: (0x807d1d98 to 0x807d2000)
1d80: 00000000 afb71014
1da0: 000040f6 00000000 00000001 00000000 00007530 00000000 afb71010 001dcd65
1dc0: 01000680 00400000 807d1e2c afb71010 0000004e 00000000 00000000 0000004b
1de0: 808184d4 af809900 807d1e0c 807d1df8 803dbc24 803ddf04 afba75c0 0000004e
1e00: 807d1e44 807d1e10 8007a19c 803dbb9c 8108e7e0 8108e7e0 9ceddce0 af809900
1e20: 0000004e 807d0000 0000004b 00000000 00000010 00000000 807d1e5c 807d1e48
1e40: 8007a334 8007a154 af809900 0000004e 807d1e74 807d1e60 8007d3b4 8007a2f0
1e60: 0000004b 807cce3c 807d1e8c 807d1e78 80079b08 8007d300 00000180 807d8ba0
1e80: 807d1eb4 807d1e90 8000eef4 80079aec 00000000 f400010c 807d8ce4 807d1ed8
1ea0: f4000100 96d5c75d 807d1ed4 807d1eb8 80008600 8000eeac 8042699c 60000013
1ec0: ffffffff 807d1f0c 807d1f54 807d1ed8 8000e180 800085dc 807d1f20 00000046
1ee0: 9cedd275 00000010 8108f080 807de294 00000001 807de248 96d5c75d 00000010
1f00: 00000000 807d1f54 00000000 807d1f20 8005ff54 8042699c 60000013 ffffffff
1f20: 9cedd275 00000010 00000005 8108f080 8108f080 00000001 807de248 8086bd00
1f40: 807d0000 00000001 807d1f7c 807d1f58 80426af0 80426950 807d0000 00000000
1f60: 808184c0 808184c0 807d8954 805b886c 807d1f8c 807d1f80 8000f294 80426a44
1f80: 807d1fac 807d1f90 8005f110 8000f288 807d1fac 807d8908 805b4748 807dc86c
1fa0: 807d1fbc 807d1fb0 805aa58c 8005f068 807d1ff4 807d1fc0 8077c860 805aa530
1fc0: ffffffff ffffffff 8077c330 00000000 00000000 807bef88 00000000 10c53c7d
1fe0: 807d88d0 807bef84 00000000 807d1ff8 10008074 8077c594 00000000 00000000
Backtrace:
[<803ddef8>] (udc_irq+0x0/0xea4) from [<803dbc24>] (ci_irq+0x94/0x14c)
[<803dbb90>] (ci_irq+0x0/0x14c) from [<8007a19c>] (handle_irq_event_percpu+0x54/0x19c)
r5:0000004e r4:afba75c0
[<8007a148>] (handle_irq_event_percpu+0x0/0x19c) from [<8007a334>] (handle_irq_event+0x50/0x70)
[<8007a2e4>] (handle_irq_event+0x0/0x70) from [<8007d3b4>] (handle_fasteoi_irq+0xc0/0x16c)
r5:0000004e r4:af809900
[<8007d2f4>] (handle_fasteoi_irq+0x0/0x16c) from [<80079b08>] (generic_handle_irq+0x28/0x38)
r5:807cce3c r4:0000004b
[<80079ae0>] (generic_handle_irq+0x0/0x38) from [<8000eef4>] (handle_IRQ+0x54/0xb4)
r4:807d8ba0 r3:00000180
[<8000eea0>] (handle_IRQ+0x0/0xb4) from [<80008600>] (gic_handle_irq+0x30/0x64)
r8:96d5c75d r7:f4000100 r6:807d1ed8 r5:807d8ce4 r4:f400010c
r3:00000000
[<800085d0>] (gic_handle_irq+0x0/0x64) from [<8000e180>] (__irq_svc+0x40/0x54)
Exception stack(0x807d1ed8 to 0x807d1f20)
1ec0: 807d1f20 00000046
1ee0: 9cedd275 00000010 8108f080 807de294 00000001 807de248 96d5c75d 00000010
1f00: 00000000 807d1f54 00000000 807d1f20 8005ff54 8042699c 60000013 ffffffff
r7:807d1f0c r6:ffffffff r5:60000013 r4:8042699c
[<80426944>] (cpuidle_enter_state+0x0/0xf4) from [<80426af0>] (cpuidle_idle_call+0xb8/0x174)
r9:00000001 r8:807d0000 r7:8086bd00 r6:807de248 r5:00000001
r4:8108f080
[<80426a38>] (cpuidle_idle_call+0x0/0x174) from [<8000f294>] (arch_cpu_idle+0x18/0x5c)
[<8000f27c>] (arch_cpu_idle+0x0/0x5c) from [<8005f110>] (cpu_startup_entry+0xb4/0x148)
[<8005f05c>] (cpu_startup_entry+0x0/0x148) from [<805aa58c>] (rest_init+0x68/0x80)
r7:807dc86c
[<805aa524>] (rest_init+0x0/0x80) from [<8077c860>] (start_kernel+0x2d8/0x334)
[<8077c588>] (start_kernel+0x0/0x334) from [<10008074>] (0x10008074)
Code: e59031e0 e51b203c e24b1034 e2820058 (e5933010)
---[ end trace f874b2c5533c04bc ]---
Kernel panic - not syncing: Fatal exception in interrupt
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|