Re: [linux-sunxi] Re: [PATCH v4 1/2] ehci-platform: Add support for controllers with multiple reset lines
Hi, On 04-03-16 05:35, Greg Kroah-Hartman wrote: On Sat, Feb 27, 2016 at 05:58:58PM +0100, Hans de Goede wrote: From: Reinder de Haan At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple reset lines, the controller will not initialize while the reset for its companion is still asserted, which means we need to de-assert 2 resets for the controller to work. Signed-off-by: Reinder de Haan Signed-off-by: Hans de Goede Acked-by: Alan Stern Acked-by: Rob Herring --- Changes in v2: -Use the new reset_control_[de]assert_shared reset-controller functions Changes in v3: -Adjust for changes to shared-reset reset-controller functions Changes in v4: -Fix Ugly continuation line This breaks the build horribly :( As does patch 2/2, ugh. As said in the cover letter: "These patches apply on top of the related reset-controller patches which have just been merged here: git://git.pengutronix.de/git/pza/linux.git reset/next" I guess I should have done s/apply on top of/depend on/ in the above bit. These patches apply fine without those changes, but indeed they will not build. You may want to ask Philipp Zabel (added to the To: list) to create a topic branch for this which you can merge into your tree. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function
Hi, "Felipe F. Tonello" writes: > [ text/plain ] > Since f_midi_transmit is called by both ALSA and USB frameworks, it can > potentially cause a race condition between both calls. This is bad because the > way f_midi_transmit is implemented can't handle concurrent calls. This is due > to the fact that the usb request fifo looks for the next element and only if > it has data to process it enqueues the request, otherwise re-uses it. If both > (ALSA and USB) frameworks calls this function at the same time, the > kfifo_seek() will return the same usb_request, which will cause a race > condition. > > To solve this problem a syncronization mechanism is necessary. In this case it > is used a spinlock since f_midi_transmit is also called by > usb_request->complete > callback in interrupt context. > > On benchmarks realized by me, spinlocks were more efficient then scheduling > the f_midi_transmit tasklet in process context and using a mutex to > synchronize. Also it performs better then previous implementation that > allocated a usb_request for every new transmit made. behaves better in what way ? Also, previous implementation would not suffer from this concurrency problem, right ? -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: phy: mxs: Add DT bindings to configure TX settings
Jaret Cantu writes: > [ text/plain ] > The TX settings can be calibrated for particular hardware. The > phy is reset by Linux, so this cannot be handled by the bootloader. > > The TRM mentions that the maximum resistance should be used for the > DN/DP calibration in order to pass USB certification. > > The values for the TX registers are poorly described in the TRM. > The meanings of the register values were taken from another > Freescale-provided document: > https://community.freescale.com/message/566147#comment-566912 > > Signed-off-by: Jaret Cantu unfortunately it's too late for v4.6 as we won't get anybody from DT to agree with this in time. Once v4.5 final is tagged, please resend and Cc devicetree mailinglist too. thanks -- balbi signature.asc Description: PGP signature
Re: Page allocation failure (order 7) in UAS code
Hi, On 04-03-16 08:13, Yves-Alexis Perez wrote: On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote: Hi, On 01-03-16 10:42, Yves-Alexis Perez wrote: Hi, [sorry if this is not the right point for reporting bugs, I took the email addresses from MAINTAINERS but please point me to the correct place if needed] I have an external USB drive (Samsung M3), which apparently uses the UAS code. Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), I can't mount the drive anymore after a while (few hours/days uptime). Just plugging the disk, I get page allocation failure in kernel logs: Can you try building a kernel with the following line in drivers/usb/storage/uas.c : .can_queue = 65536, /* Is there a limit on the _host_ ? */ (around line 815) Replaced with .can_queue = MAX_CMNDS, That should help as MAX_CMNDS is 256, so claiming that we can queue more is not helpful, and that likely is what is causing this quite high order alloc. After a few days, it seems that it does work fine, although I can't say anything about sides effects. Thanks for testing, there shouldn't be any side-effects, I'll turn this into a proper patch, add a: Reported-and-tested-by: Yves-Alexis Perez line to the comit msg and submit this upstream. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes
Hi,
"Felipe F. Tonello" writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
> powered from the host, which is not correct because this configuration is
> device
> specific, not a USB-MIDI requirement.
>
> This patch adds two modules parameters, bmAttributes and MaxPower, that allows
> the user to set those flags. The default values are what the gadget used to
> use
> for backward compatibility.
>
> Signed-off-by: Felipe F. Tonello
> ---
> drivers/usb/gadget/legacy/gmidi.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/gmidi.c
> b/drivers/usb/gadget/legacy/gmidi.c
> index fc2ac150f5ff..0553435cc360 100644
> --- a/drivers/usb/gadget/legacy/gmidi.c
> +++ b/drivers/usb/gadget/legacy/gmidi.c
> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
> module_param(out_ports, uint, S_IRUGO);
> MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>
> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
> +module_param(bmAttributes, uint, S_IRUGO);
> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's bmAttributes
> parameter");
> +
> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
> +module_param(MaxPower, uint, S_IRUGO);
> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration Descriptor's
> bMaxPower parameter");
you didn't run checkpatch, did you ? Also, are you sure you will need to
change this by simply reloading the module ? I'm not convinced.
> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
> .label = "MIDI Gadget",
> .bConfigurationValue = 1,
> /* .iConfiguration = DYNAMIC */
> - .bmAttributes = USB_CONFIG_ATT_ONE,
nack, nackety nack nack nack :-)
USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
give users the oportunity to violate USB spec.
--
balbi
signature.asc
Description: PGP signature
Re: Page allocation failure (order 7) in UAS code
On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote: > Hi, > > On 01-03-16 10:42, Yves-Alexis Perez wrote: > > > > Hi, > > > > [sorry if this is not the right point for reporting bugs, I took the email > > addresses from MAINTAINERS but please point me to the correct place if > > needed] > > > > I have an external USB drive (Samsung M3), which apparently uses the UAS > > code. > > Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), > > I > > can't mount the drive anymore after a while (few hours/days uptime). Just > > plugging the disk, I get page allocation failure in kernel logs: > Can you try building a kernel with the following line in > drivers/usb/storage/uas.c : > > .can_queue = 65536, /* Is there a limit on the _host_ ? */ > > (around line 815) Replaced with > > .can_queue = MAX_CMNDS, > > That should help as MAX_CMNDS is 256, so claiming that we can queue more > is not helpful, and that likely is what is causing this quite high order > alloc. After a few days, it seems that it does work fine, although I can't say anything about sides effects. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes
"Felipe F. Tonello" writes: > [ text/plain ] > Signed-off-by: Felipe F. Tonello no commit log == no commit -- balbi signature.asc Description: PGP signature
Re: [PATCH 5/5] usb: gadget: f_midi: updated copyright
"Felipe F. Tonello" writes: > [ text/plain ] > Signed-off-by: Felipe F. Tonello no commit log == no commit > --- > drivers/usb/gadget/function/f_midi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/gadget/function/f_midi.c > b/drivers/usb/gadget/function/f_midi.c > index 9a9e6112e224..5c7f5c780fda 100644 > --- a/drivers/usb/gadget/function/f_midi.c > +++ b/drivers/usb/gadget/function/f_midi.c > @@ -5,6 +5,9 @@ > * Developed for Thumtronics by Grey Innovation > * Ben Williamson > * > + * Copyright (C) 2015,2016 ROLI Ltd. > + * Felipe F. Tonello Did you check with your company's lawyer that your changes are enough to justify a copyright ? -- balbi signature.asc Description: PGP signature
Re: [PATCH 0/5] MIDI USB Gadget improvements
Hi, "Felipe F. Tonello" writes: > [ text/plain ] > Patches are pretty much self-described. > > Patch 1 is revised from comments. you really need to describe what you changed. This also should have v2 on subject line. I guess it's too late to get this in v4.6 merge window as I'm already applying the last few patches and plan to send a pull request in a few minutes. -- balbi signature.asc Description: PGP signature
Re: [PATCH v4 1/2] ehci-platform: Add support for controllers with multiple reset lines
On Sat, Feb 27, 2016 at 05:58:58PM +0100, Hans de Goede wrote: > From: Reinder de Haan > > At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple > reset lines, the controller will not initialize while the reset for > its companion is still asserted, which means we need to de-assert > 2 resets for the controller to work. > > Signed-off-by: Reinder de Haan > Signed-off-by: Hans de Goede > Acked-by: Alan Stern > Acked-by: Rob Herring > --- > Changes in v2: > -Use the new reset_control_[de]assert_shared reset-controller functions > Changes in v3: > -Adjust for changes to shared-reset reset-controller functions > Changes in v4: > -Fix Ugly continuation line This breaks the build horribly :( As does patch 2/2, ugh. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] usb and xhci fixes for usb-next 4.6
On Thu, Feb 18, 2016 at 05:55:47PM +0200, Mathias Nyman wrote: > Hi Greg > > A few more patches for 4.6. > At least the first one would be important to get with the rest of the > USB 3.1 SSP Isoc patches to 4.6 > Without it the SSP Isoc endpoint companion descriptor parsing > may mess up the normal SS endpoint companion parsing. I've only applied 2/3 and 3/3. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: core: add power sequence for USB devices
On Fri, Mar 04, 2016 at 03:23:05AM +0100, Andrew Lunn wrote: > On Fri, Mar 04, 2016 at 10:02:42AM +0800, Peter Chen wrote: > > On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote: > > > On Thu, Mar 3, 2016 at 4:01 AM, Peter Chen wrote: > > > > Some hard-wired USB devices need to do power sequence to let the > > > > device work normally, the typical power sequence like: enable USB > > > > PHY clock, toggle reset pin, etc. But current Linux USB driver > > > > lacks of such code to do it, it may cause some hard-wired USB devices > > > > works abnormal or can't be recognized by controller at all. > > > > > > > > In this patch, it will do power on sequence at hub's probe for all > > > > devices under this hub (includes root hub) if this device is described > > > > at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect, > > > > it will do power off sequence. > > > > > > > > Signed-off-by: Peter Chen > > > > --- > > > > .../devicetree/bindings/usb/usb-device.txt | 41 +- > > > > drivers/usb/core/Makefile | 2 +- > > > > drivers/usb/core/hub.c | 32 + > > > > drivers/usb/core/pwrseq.c | 149 > > > > + > > > > include/linux/usb/of.h | 10 ++ > > > > 5 files changed, 232 insertions(+), 2 deletions(-) > > > > create mode 100644 drivers/usb/core/pwrseq.c > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt > > > > b/Documentation/devicetree/bindings/usb/usb-device.txt > > > > index 1c35e7b..c7a298c 100644 > > > > --- a/Documentation/devicetree/bindings/usb/usb-device.txt > > > > +++ b/Documentation/devicetree/bindings/usb/usb-device.txt > > > > @@ -13,8 +13,37 @@ Required properties: > > > > - reg: the port number which this device is connecting to, the range > > > >is 1-31. > > > > > > > > +Optional properties: > > > > +- usb-pwrseq: the power sequence handler which need to do before this > > > > USB > > > > + device can work. > > > > +- clocks: the input clock for USB device. > > > > +- clock-frequency: the frequency for device's clock. > > > > +- reset-gpios: Should specify the GPIO for reset. > > > > +- reset-duration-us: the duration in microsecond for assert reset > > > > signal. > > > > > > So we sorted out how to describe USB devices in DT, but now we don't > > > use it? > > > > We only know USB device after USB bus finds it, but without power > > on sequence, the USB bus can't find it. > > Not really true. Device tree says it exists, you just cannot see it > yet. The fact it is in device tree means it is soldered on the board > and really is there. So when the host controller enumerates the bus, > it should run the power sequence of all child nodes to make them > appear. > Yes, it is my patch doing. My words "We only know USB device after USB bus finds it" means the USB common code only create the USB device, and assign its .of_node after USB bus finds it. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: chipidea: host: let the hcd know's parent device node
On Fri, Mar 04, 2016 at 03:17:30AM +0100, Andrew Lunn wrote: > > > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c > > > > index 053bac9..55120ef 100644 > > > > --- a/drivers/usb/chipidea/host.c > > > > +++ b/drivers/usb/chipidea/host.c > > > > @@ -109,15 +109,25 @@ static int host_start(struct ci_hdrc *ci) > > > > struct ehci_hcd *ehci; > > > > struct ehci_ci_priv *priv; > > > > int ret; > > > > + struct device *dev = ci->dev; > > > > > > > > - if (usb_disabled()) > > > > + if (usb_disabled() || !dev) > > > > return -ENODEV; > > > > > > > > - hcd = usb_create_hcd(&ci_ehci_hc_driver, ci->dev, > > > > dev_name(ci->dev)); > > > > + /* > > > > +* USB Core will try to get child node under roothub, > > > > +* but chipidea core has no of_node, and the child node > > > > +* for controller is located at glue layer's node which > > > > +* is chipidea core's parent. > > > > +*/ > > > > + if (dev->parent && dev->parent->of_node) > > > > + dev->of_node = dev->parent->of_node; > > > > > > Is this a good idea? Two devices with the same of_node? > > > > > > > This is only for chipidea driver whose host controller device > > doesn't have entry at dts, but other host controller driver which > > supports device tree should have its entry at dts. > > > > > I know the networking code assumes of_node values are unique, and uses > > > it to find a device. Are you 100% sure the USB code does not make this > > > assumption. > > > > > > > The controller device is the root for USB device, the common > > USB code will not touch its glue layer device (controller's parent). > > I'm just thinking about code like: > > of_find_spi_master_by_node(), of_find_net_device_by_node(), > of_find_backlight_by_node(), etc. > > If somebody was to implement an of_find_usb_host_by_node() are you > 100% sure the right node will be found? This seems like a bug waiting > to happen. Yes, almost 100% sure it is ok since the common USB code will never use its root's parent node to match or get something. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: core: add power sequence for USB devices
On Fri, Mar 04, 2016 at 10:02:42AM +0800, Peter Chen wrote: > On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote: > > On Thu, Mar 3, 2016 at 4:01 AM, Peter Chen wrote: > > > Some hard-wired USB devices need to do power sequence to let the > > > device work normally, the typical power sequence like: enable USB > > > PHY clock, toggle reset pin, etc. But current Linux USB driver > > > lacks of such code to do it, it may cause some hard-wired USB devices > > > works abnormal or can't be recognized by controller at all. > > > > > > In this patch, it will do power on sequence at hub's probe for all > > > devices under this hub (includes root hub) if this device is described > > > at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect, > > > it will do power off sequence. > > > > > > Signed-off-by: Peter Chen > > > --- > > > .../devicetree/bindings/usb/usb-device.txt | 41 +- > > > drivers/usb/core/Makefile | 2 +- > > > drivers/usb/core/hub.c | 32 + > > > drivers/usb/core/pwrseq.c | 149 > > > + > > > include/linux/usb/of.h | 10 ++ > > > 5 files changed, 232 insertions(+), 2 deletions(-) > > > create mode 100644 drivers/usb/core/pwrseq.c > > > > > > diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt > > > b/Documentation/devicetree/bindings/usb/usb-device.txt > > > index 1c35e7b..c7a298c 100644 > > > --- a/Documentation/devicetree/bindings/usb/usb-device.txt > > > +++ b/Documentation/devicetree/bindings/usb/usb-device.txt > > > @@ -13,8 +13,37 @@ Required properties: > > > - reg: the port number which this device is connecting to, the range > > >is 1-31. > > > > > > +Optional properties: > > > +- usb-pwrseq: the power sequence handler which need to do before this USB > > > + device can work. > > > +- clocks: the input clock for USB device. > > > +- clock-frequency: the frequency for device's clock. > > > +- reset-gpios: Should specify the GPIO for reset. > > > +- reset-duration-us: the duration in microsecond for assert reset signal. > > > > So we sorted out how to describe USB devices in DT, but now we don't > > use it? > > We only know USB device after USB bus finds it, but without power > on sequence, the USB bus can't find it. Not really true. Device tree says it exists, you just cannot see it yet. The fact it is in device tree means it is soldered on the board and really is there. So when the host controller enumerates the bus, it should run the power sequence of all child nodes to make them appear. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: chipidea: host: let the hcd know's parent device node
> > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c > > > index 053bac9..55120ef 100644 > > > --- a/drivers/usb/chipidea/host.c > > > +++ b/drivers/usb/chipidea/host.c > > > @@ -109,15 +109,25 @@ static int host_start(struct ci_hdrc *ci) > > > struct ehci_hcd *ehci; > > > struct ehci_ci_priv *priv; > > > int ret; > > > + struct device *dev = ci->dev; > > > > > > - if (usb_disabled()) > > > + if (usb_disabled() || !dev) > > > return -ENODEV; > > > > > > - hcd = usb_create_hcd(&ci_ehci_hc_driver, ci->dev, dev_name(ci->dev)); > > > + /* > > > + * USB Core will try to get child node under roothub, > > > + * but chipidea core has no of_node, and the child node > > > + * for controller is located at glue layer's node which > > > + * is chipidea core's parent. > > > + */ > > > + if (dev->parent && dev->parent->of_node) > > > + dev->of_node = dev->parent->of_node; > > > > Is this a good idea? Two devices with the same of_node? > > > > This is only for chipidea driver whose host controller device > doesn't have entry at dts, but other host controller driver which > supports device tree should have its entry at dts. > > > I know the networking code assumes of_node values are unique, and uses > > it to find a device. Are you 100% sure the USB code does not make this > > assumption. > > > > The controller device is the root for USB device, the common > USB code will not touch its glue layer device (controller's parent). I'm just thinking about code like: of_find_spi_master_by_node(), of_find_net_device_by_node(), of_find_backlight_by_node(), etc. If somebody was to implement an of_find_usb_host_by_node() are you 100% sure the right node will be found? This seems like a bug waiting to happen. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: core: add power sequence for USB devices
On Thu, Mar 03, 2016 at 01:31:56PM -0500, Alan Stern wrote:
> On Thu, 3 Mar 2016, Peter Chen wrote:
>
> > Some hard-wired USB devices need to do power sequence to let the
> > device work normally, the typical power sequence like: enable USB
> > PHY clock, toggle reset pin, etc. But current Linux USB driver
> > lacks of such code to do it, it may cause some hard-wired USB devices
> > works abnormal or can't be recognized by controller at all.
> >
> > In this patch, it will do power on sequence at hub's probe for all
> > devices under this hub (includes root hub) if this device is described
> > at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect,
> > it will do power off sequence.
> >
> > Signed-off-by: Peter Chen
>
>
> > +static int hub_of_pwrseq(struct usb_device *hdev, bool on)
> > +{
> > + struct device *parent;
> > + struct device_node *node;
> > + int ret = 0;
> > +
> > + if (hdev->parent)
> > + parent = &hdev->dev;
> > + else
> > + parent = bus_to_hcd(hdev->bus)->self.controller;
> > +
> > + for_each_child_of_node(parent->of_node, node) {
> > + ret = on ? usb_child_pwrseq_on(node)
> > + : usb_child_pwrseq_off(node);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
>
> If you get a failure, do you want to leave the power to all the
> preceding devices turned on? It seems to me you should either turn all
> of them back off, or else continue trying to turn on power for the
> remaining children.
>
Thanks, I will show error message for that device, and continue to turn
on power for the remaining children.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
On Thu, Mar 03, 2016 at 11:30:53PM +0100, Maciej S. Szmigiero wrote:
> Hi Peter,
>
> On 03.03.2016 11:01, Peter Chen wrote:
> > From: Peter Chen
> >
> > The current dts describes USB HUB's property at USB controller's
> > entry, it is improper. The USB HUB should be the child node
> > under USB controller.
> >
> > Signed-off-by: Peter Chen
>
> Thanks for patches!
>
> VID:PID for hub on UDOO board is 0424:2514.
>
> I've tested these patches on this board and was able to make USB work
> again with following DT changes:
> diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> index d3e54e4..4956de7 100644
> --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> @@ -9,6 +9,8 @@
> *
> */
>
> +#include
> +
> / {
> chosen {
> stdout-path = &uart2;
> @@ -18,21 +27,11 @@
> reg = <0x1000 0x4000>;
> };
>
> - regulators {
> - compatible = "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - reg_usb_h1_vbus: regulator@0 {
> - compatible = "regulator-fixed";
> - reg = <0>;
> - regulator-name = "usb_h1_vbus";
> - regulator-min-microvolt = <500>;
> - regulator-max-microvolt = <500>;
> - enable-active-high;
> - startup-delay-us = <2>; /* USB2415 requires a POR of 1
> us minimum */
> - gpio = <&gpio7 12 0>;
> - };
> + usb2415_pwrseq: usb2415_pwrseq {
> + compatible = "usb-pwrseq";
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> + reset-duration-us = <3000>;
> };
>
> sound {
> @@ -163,9 +218,16 @@
> &usbh1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usbh>;
> - vbus-supply = <®_usb_h1_vbus>;
> - clocks = <&clks 201>;
> status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hub: usb2415@01 {
> + compatible = "usb424,2514";
> + reg = <1>;
> + usb-pwrseq = <&usb2415_pwrseq>;
> + };
> };
>
> &usdhc3 {
>
>
Thank you very much.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: core: add power sequence for USB devices
On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote: > On Thu, Mar 3, 2016 at 4:01 AM, Peter Chen wrote: > > Some hard-wired USB devices need to do power sequence to let the > > device work normally, the typical power sequence like: enable USB > > PHY clock, toggle reset pin, etc. But current Linux USB driver > > lacks of such code to do it, it may cause some hard-wired USB devices > > works abnormal or can't be recognized by controller at all. > > > > In this patch, it will do power on sequence at hub's probe for all > > devices under this hub (includes root hub) if this device is described > > at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect, > > it will do power off sequence. > > > > Signed-off-by: Peter Chen > > --- > > .../devicetree/bindings/usb/usb-device.txt | 41 +- > > drivers/usb/core/Makefile | 2 +- > > drivers/usb/core/hub.c | 32 + > > drivers/usb/core/pwrseq.c | 149 > > + > > include/linux/usb/of.h | 10 ++ > > 5 files changed, 232 insertions(+), 2 deletions(-) > > create mode 100644 drivers/usb/core/pwrseq.c > > > > diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt > > b/Documentation/devicetree/bindings/usb/usb-device.txt > > index 1c35e7b..c7a298c 100644 > > --- a/Documentation/devicetree/bindings/usb/usb-device.txt > > +++ b/Documentation/devicetree/bindings/usb/usb-device.txt > > @@ -13,8 +13,37 @@ Required properties: > > - reg: the port number which this device is connecting to, the range > >is 1-31. > > > > +Optional properties: > > +- usb-pwrseq: the power sequence handler which need to do before this USB > > + device can work. > > +- clocks: the input clock for USB device. > > +- clock-frequency: the frequency for device's clock. > > +- reset-gpios: Should specify the GPIO for reset. > > +- reset-duration-us: the duration in microsecond for assert reset signal. > > So we sorted out how to describe USB devices in DT, but now we don't > use it? We only know USB device after USB bus finds it, but without power on sequence, the USB bus can't find it. > I know this is similar to what was done for MMC, but I really > don't like it. > > Just put all these properties into the device nodes. The parent can > then scan for children and handle the power sequencing with generic > code. I think it is safe to assume that if these properties are > present, they need to be handled for device detection. We may still > need something device specific to handle some devices at some point, > but that is true either way. > It is two different things, one is power sequence which needs to be done before the device can be detected. Another is the features for this USB devices, it can be handled after this device has been recognized. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] usb: misc: add driver for Intel drcfg controlled port mux
On 03/04/2016 09:44 AM, Greg Kroah-Hartman wrote:
> On Fri, Mar 04, 2016 at 09:38:58AM +0800, Lu Baolu wrote:
>>
>> On 03/04/2016 12:14 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Mar 03, 2016 at 02:37:42PM +0800, Lu Baolu wrote:
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
Signed-off-by: Wu Hao
Reviewed-by: Felipe Balbi
---
MAINTAINERS| 1 +
drivers/usb/misc/Kconfig | 7 ++
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/intel-mux-drcfg.c | 174
+
4 files changed, 183 insertions(+)
create mode 100644 drivers/usb/misc/intel-mux-drcfg.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f321e4..20eb873 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11396,6 +11396,7 @@ S: Supported
F:drivers/usb/misc/mux.c
F:include/linux/usb/mux.h
F:drivers/usb/misc/intel-mux-gpio.c
+F:drivers/usb/misc/intel-mux-drcfg.c
USB PRINTER DRIVER (usblp)
M:Pete Zaitcev
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 33e6386..befd910 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -281,3 +281,10 @@ config INTEL_MUX_GPIO
help
Say Y here to enable support for Intel dual role port mux
controlled by GPIOs.
+
+config INTEL_MUX_DRCFG
+ tristate "Intel dual role port mux controlled by register"
+ select USB_MUX
+ help
+Say Y here to enable support for Intel dual role port mux
+controlled by the Dual Role Configuration Registers.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index da4fb4e..c4d19a0 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_USB_LINK_LAYER_TEST)+= lvstest.o
obj-$(CONFIG_USB_MUX) += mux.o
obj-$(CONFIG_INTEL_MUX_GPIO) += intel-mux-gpio.o
+obj-$(CONFIG_INTEL_MUX_DRCFG) += intel-mux-drcfg.o
diff --git a/drivers/usb/misc/intel-mux-drcfg.c
b/drivers/usb/misc/intel-mux-drcfg.c
new file mode 100644
index 000..29081c5
--- /dev/null
+++ b/drivers/usb/misc/intel-mux-drcfg.c
@@ -0,0 +1,174 @@
+/**
+ * intel-mux-drcfg.c - Driver for Intel USB mux via register
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define INTEL_MUX_CFG00x00
+#define INTEL_MUX_CFG10x04
+#define CFG0_SW_IDPIN BIT(20)
+#define CFG0_SW_IDPIN_EN BIT(21)
+#define CFG0_SW_VBUS_VALIDBIT(24)
+#define CFG1_SW_MODE BIT(29)
+#define CFG1_POLL_TIMEOUT 1000
+
+struct intel_usb_mux {
+ struct usb_mux_dev umdev;
+ void __iomem *regs;
+ u32 cfg0_ctx;
+};
+
+static inline int intel_mux_drcfg_switch(struct usb_mux_dev *umdev, bool
host)
+{
+ struct intel_usb_mux *mux;
+ unsigned long timeout;
+ u32 data;
+
+ mux = container_of(umdev, struct intel_usb_mux, umdev);
+
+ /* Check and set mux to SW controlled mode */
+ data = readl(mux->regs + INTEL_MUX_CFG0);
+ if (!(data & CFG0_SW_IDPIN_EN)) {
+ data |= CFG0_SW_IDPIN_EN;
+ writel(data, mux->regs + INTEL_MUX_CFG0);
+ }
+
+ /*
+ * Configure CFG0 to switch the mux and VBUS_VALID bit is
+ * required for device mode.
+ */
+ data = readl(mux->regs + INTEL_MUX_CFG0);
+ if (host)
+ data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+ else
+ data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+ writel(data, mux->regs + INTEL_MUX_CFG0);
+
+ /*
+ * Polling CFG1 for safety, most case it takes about 600ms
+ * to finish mode switching, set TIMEOUT long enough.
+ */
+ timeout = jiffies + msecs_to_jiffies(CFG1_POLL_TIMEOUT);
+
+ /* Polling on CFG1 register to confirm mode switch. */
+ while (!time_after(jiffies, timeout)) {
+ data = readl(mux->regs + INTEL_MUX_CFG1);
+ if (!(host ^ (data & CFG1_SW_MODE)))
+ return 0;
Re: [PATCH 2/3] usb: chipidea: host: let the hcd know's parent device node
On Thu, Mar 03, 2016 at 03:42:47PM +0100, Andrew Lunn wrote: > On Thu, Mar 03, 2016 at 06:01:15PM +0800, Peter Chen wrote: > > From: Peter Chen > > > > Since the hcd (chipidea core device) has no device node, so > > if we want to describe the child node under the hcd, we had > > to put it under its parent's node (glue layer device), and > > in the code, we need to let the hcd knows glue layer's code, > > then the USB core can handle this node. > > > > Signed-off-by: Peter Chen > > --- > > drivers/usb/chipidea/host.c | 18 ++ > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c > > index 053bac9..55120ef 100644 > > --- a/drivers/usb/chipidea/host.c > > +++ b/drivers/usb/chipidea/host.c > > @@ -109,15 +109,25 @@ static int host_start(struct ci_hdrc *ci) > > struct ehci_hcd *ehci; > > struct ehci_ci_priv *priv; > > int ret; > > + struct device *dev = ci->dev; > > > > - if (usb_disabled()) > > + if (usb_disabled() || !dev) > > return -ENODEV; > > > > - hcd = usb_create_hcd(&ci_ehci_hc_driver, ci->dev, dev_name(ci->dev)); > > + /* > > +* USB Core will try to get child node under roothub, > > +* but chipidea core has no of_node, and the child node > > +* for controller is located at glue layer's node which > > +* is chipidea core's parent. > > +*/ > > + if (dev->parent && dev->parent->of_node) > > + dev->of_node = dev->parent->of_node; > > Is this a good idea? Two devices with the same of_node? > This is only for chipidea driver whose host controller device doesn't have entry at dts, but other host controller driver which supports device tree should have its entry at dts. > I know the networking code assumes of_node values are unique, and uses > it to find a device. Are you 100% sure the USB code does not make this > assumption. > The controller device is the root for USB device, the common USB code will not touch its glue layer device (controller's parent). -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] usb: misc: add driver for Intel drcfg controlled port mux
On Fri, Mar 04, 2016 at 09:38:58AM +0800, Lu Baolu wrote:
>
>
> On 03/04/2016 12:14 AM, Greg Kroah-Hartman wrote:
> > On Thu, Mar 03, 2016 at 02:37:42PM +0800, Lu Baolu wrote:
> >> Several Intel PCHs and SOCs have an internal mux that is used to
> >> share one USB port between device controller and host controller.
> >> The mux is handled through the Dual Role Configuration Register.
> >>
> >> Signed-off-by: Heikki Krogerus
> >> Signed-off-by: Lu Baolu
> >> Signed-off-by: Wu Hao
> >> Reviewed-by: Felipe Balbi
> >> ---
> >> MAINTAINERS| 1 +
> >> drivers/usb/misc/Kconfig | 7 ++
> >> drivers/usb/misc/Makefile | 1 +
> >> drivers/usb/misc/intel-mux-drcfg.c | 174
> >> +
> >> 4 files changed, 183 insertions(+)
> >> create mode 100644 drivers/usb/misc/intel-mux-drcfg.c
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 0f321e4..20eb873 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -11396,6 +11396,7 @@ S: Supported
> >> F:drivers/usb/misc/mux.c
> >> F:include/linux/usb/mux.h
> >> F:drivers/usb/misc/intel-mux-gpio.c
> >> +F:drivers/usb/misc/intel-mux-drcfg.c
> >>
> >> USB PRINTER DRIVER (usblp)
> >> M:Pete Zaitcev
> >> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> >> index 33e6386..befd910 100644
> >> --- a/drivers/usb/misc/Kconfig
> >> +++ b/drivers/usb/misc/Kconfig
> >> @@ -281,3 +281,10 @@ config INTEL_MUX_GPIO
> >>help
> >> Say Y here to enable support for Intel dual role port mux
> >> controlled by GPIOs.
> >> +
> >> +config INTEL_MUX_DRCFG
> >> + tristate "Intel dual role port mux controlled by register"
> >> + select USB_MUX
> >> + help
> >> +Say Y here to enable support for Intel dual role port mux
> >> +controlled by the Dual Role Configuration Registers.
> >> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> >> index da4fb4e..c4d19a0 100644
> >> --- a/drivers/usb/misc/Makefile
> >> +++ b/drivers/usb/misc/Makefile
> >> @@ -32,3 +32,4 @@ obj-$(CONFIG_USB_LINK_LAYER_TEST)+= lvstest.o
> >>
> >> obj-$(CONFIG_USB_MUX) += mux.o
> >> obj-$(CONFIG_INTEL_MUX_GPIO) += intel-mux-gpio.o
> >> +obj-$(CONFIG_INTEL_MUX_DRCFG) += intel-mux-drcfg.o
> >> diff --git a/drivers/usb/misc/intel-mux-drcfg.c
> >> b/drivers/usb/misc/intel-mux-drcfg.c
> >> new file mode 100644
> >> index 000..29081c5
> >> --- /dev/null
> >> +++ b/drivers/usb/misc/intel-mux-drcfg.c
> >> @@ -0,0 +1,174 @@
> >> +/**
> >> + * intel-mux-drcfg.c - Driver for Intel USB mux via register
> >> + *
> >> + * Copyright (C) 2016 Intel Corporation
> >> + * Author: Heikki Krogerus
> >> + * Author: Lu Baolu
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#define INTEL_MUX_CFG00x00
> >> +#define INTEL_MUX_CFG10x04
> >> +#define CFG0_SW_IDPIN BIT(20)
> >> +#define CFG0_SW_IDPIN_EN BIT(21)
> >> +#define CFG0_SW_VBUS_VALIDBIT(24)
> >> +#define CFG1_SW_MODE BIT(29)
> >> +#define CFG1_POLL_TIMEOUT 1000
> >> +
> >> +struct intel_usb_mux {
> >> + struct usb_mux_dev umdev;
> >> + void __iomem *regs;
> >> + u32 cfg0_ctx;
> >> +};
> >> +
> >> +static inline int intel_mux_drcfg_switch(struct usb_mux_dev *umdev, bool
> >> host)
> >> +{
> >> + struct intel_usb_mux *mux;
> >> + unsigned long timeout;
> >> + u32 data;
> >> +
> >> + mux = container_of(umdev, struct intel_usb_mux, umdev);
> >> +
> >> + /* Check and set mux to SW controlled mode */
> >> + data = readl(mux->regs + INTEL_MUX_CFG0);
> >> + if (!(data & CFG0_SW_IDPIN_EN)) {
> >> + data |= CFG0_SW_IDPIN_EN;
> >> + writel(data, mux->regs + INTEL_MUX_CFG0);
> >> + }
> >> +
> >> + /*
> >> + * Configure CFG0 to switch the mux and VBUS_VALID bit is
> >> + * required for device mode.
> >> + */
> >> + data = readl(mux->regs + INTEL_MUX_CFG0);
> >> + if (host)
> >> + data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
> >> + else
> >> + data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
> >> + writel(data, mux->regs + INTEL_MUX_CFG0);
> >> +
> >> + /*
> >> + * Polling CFG1 for safety, most case it takes about 600ms
> >> + * to finish mode switching, set TIMEOUT long enough.
> >> + */
> >> + timeout = jiffies + msecs_to_jiffies(CFG1_POLL_TIMEOUT);
> >> +
> >> + /* Polling on CFG1 register to confirm mode switch. */
> >> + while (!time_after(jiffies, timeout)) {
> >> + data = readl(mux->regs + INTEL_MUX_CFG1);
> >> + if (!(host ^ (data & CFG1_SW_MODE)))
> >> + return 0;
> >> + /* interval for polling is set to ab
Re: [PATCH 5/7] usb: misc: add driver for Intel drcfg controlled port mux
On 03/04/2016 12:12 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 02:37:42PM +0800, Lu Baolu wrote: >> Several Intel PCHs and SOCs have an internal mux that is used to >> share one USB port between device controller and host controller. >> The mux is handled through the Dual Role Configuration Register. >> >> Signed-off-by: Heikki Krogerus >> Signed-off-by: Lu Baolu >> Signed-off-by: Wu Hao >> Reviewed-by: Felipe Balbi >> --- >> MAINTAINERS| 1 + >> drivers/usb/misc/Kconfig | 7 ++ >> drivers/usb/misc/Makefile | 1 + >> drivers/usb/misc/intel-mux-drcfg.c | 174 >> + > If you are going to start having a bunch of these, please make a new > directory, drivers/usb/mux/ ? Sure. I can put them in drivers/usb/mux. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] usb: misc: add driver for Intel drcfg controlled port mux
On 03/04/2016 12:14 AM, Greg Kroah-Hartman wrote:
> On Thu, Mar 03, 2016 at 02:37:42PM +0800, Lu Baolu wrote:
>> Several Intel PCHs and SOCs have an internal mux that is used to
>> share one USB port between device controller and host controller.
>> The mux is handled through the Dual Role Configuration Register.
>>
>> Signed-off-by: Heikki Krogerus
>> Signed-off-by: Lu Baolu
>> Signed-off-by: Wu Hao
>> Reviewed-by: Felipe Balbi
>> ---
>> MAINTAINERS| 1 +
>> drivers/usb/misc/Kconfig | 7 ++
>> drivers/usb/misc/Makefile | 1 +
>> drivers/usb/misc/intel-mux-drcfg.c | 174
>> +
>> 4 files changed, 183 insertions(+)
>> create mode 100644 drivers/usb/misc/intel-mux-drcfg.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0f321e4..20eb873 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11396,6 +11396,7 @@ S: Supported
>> F: drivers/usb/misc/mux.c
>> F: include/linux/usb/mux.h
>> F: drivers/usb/misc/intel-mux-gpio.c
>> +F: drivers/usb/misc/intel-mux-drcfg.c
>>
>> USB PRINTER DRIVER (usblp)
>> M: Pete Zaitcev
>> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
>> index 33e6386..befd910 100644
>> --- a/drivers/usb/misc/Kconfig
>> +++ b/drivers/usb/misc/Kconfig
>> @@ -281,3 +281,10 @@ config INTEL_MUX_GPIO
>> help
>>Say Y here to enable support for Intel dual role port mux
>>controlled by GPIOs.
>> +
>> +config INTEL_MUX_DRCFG
>> +tristate "Intel dual role port mux controlled by register"
>> +select USB_MUX
>> +help
>> + Say Y here to enable support for Intel dual role port mux
>> + controlled by the Dual Role Configuration Registers.
>> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
>> index da4fb4e..c4d19a0 100644
>> --- a/drivers/usb/misc/Makefile
>> +++ b/drivers/usb/misc/Makefile
>> @@ -32,3 +32,4 @@ obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
>>
>> obj-$(CONFIG_USB_MUX) += mux.o
>> obj-$(CONFIG_INTEL_MUX_GPIO)+= intel-mux-gpio.o
>> +obj-$(CONFIG_INTEL_MUX_DRCFG) += intel-mux-drcfg.o
>> diff --git a/drivers/usb/misc/intel-mux-drcfg.c
>> b/drivers/usb/misc/intel-mux-drcfg.c
>> new file mode 100644
>> index 000..29081c5
>> --- /dev/null
>> +++ b/drivers/usb/misc/intel-mux-drcfg.c
>> @@ -0,0 +1,174 @@
>> +/**
>> + * intel-mux-drcfg.c - Driver for Intel USB mux via register
>> + *
>> + * Copyright (C) 2016 Intel Corporation
>> + * Author: Heikki Krogerus
>> + * Author: Lu Baolu
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define INTEL_MUX_CFG0 0x00
>> +#define INTEL_MUX_CFG1 0x04
>> +#define CFG0_SW_IDPIN BIT(20)
>> +#define CFG0_SW_IDPIN_ENBIT(21)
>> +#define CFG0_SW_VBUS_VALID BIT(24)
>> +#define CFG1_SW_MODEBIT(29)
>> +#define CFG1_POLL_TIMEOUT 1000
>> +
>> +struct intel_usb_mux {
>> +struct usb_mux_dev umdev;
>> +void __iomem *regs;
>> +u32 cfg0_ctx;
>> +};
>> +
>> +static inline int intel_mux_drcfg_switch(struct usb_mux_dev *umdev, bool
>> host)
>> +{
>> +struct intel_usb_mux *mux;
>> +unsigned long timeout;
>> +u32 data;
>> +
>> +mux = container_of(umdev, struct intel_usb_mux, umdev);
>> +
>> +/* Check and set mux to SW controlled mode */
>> +data = readl(mux->regs + INTEL_MUX_CFG0);
>> +if (!(data & CFG0_SW_IDPIN_EN)) {
>> +data |= CFG0_SW_IDPIN_EN;
>> +writel(data, mux->regs + INTEL_MUX_CFG0);
>> +}
>> +
>> +/*
>> + * Configure CFG0 to switch the mux and VBUS_VALID bit is
>> + * required for device mode.
>> + */
>> +data = readl(mux->regs + INTEL_MUX_CFG0);
>> +if (host)
>> +data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
>> +else
>> +data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
>> +writel(data, mux->regs + INTEL_MUX_CFG0);
>> +
>> +/*
>> + * Polling CFG1 for safety, most case it takes about 600ms
>> + * to finish mode switching, set TIMEOUT long enough.
>> + */
>> +timeout = jiffies + msecs_to_jiffies(CFG1_POLL_TIMEOUT);
>> +
>> +/* Polling on CFG1 register to confirm mode switch. */
>> +while (!time_after(jiffies, timeout)) {
>> +data = readl(mux->regs + INTEL_MUX_CFG1);
>> +if (!(host ^ (data & CFG1_SW_MODE)))
>> +return 0;
>> +/* interval for polling is set to about 5ms */
>> +usleep_range(5000, 5100);
>> +}
>> +
>> +return -ETIMEDOUT;
>> +}
>> +
>> +static int intel_mux_drcfg_cable_set(struct usb_mux_dev *umdev)
>> +{
>> +dev_dbg(umdev->dev, "drcfg mux switch to HOST\n");
>> +
>> +return intel_m
Re: [PATCH 3/7] usb: misc: add common code for Intel dual role port mux
On 03/04/2016 12:15 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 02:37:40PM +0800, Lu Baolu wrote: >> +#if IS_ENABLED(CONFIG_USB_MUX) >> +extern int usb_mux_register(struct usb_mux_dev *mux); >> +extern int usb_mux_unregister(struct device *dev); >> +extern struct usb_mux_dev *usb_mux_get_dev(struct device *dev); > This api needs a lot of work, for such a "tiny" api, it's obviously > pretty incorrect. Please fix it up to be sane... Sure. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
答复: Re:
Thank you very much for your reply, Your reply can solve our problems, thank you Best Regards, Pengcheng Li -邮件原件- 发件人: Matthew Dharm [mailto:mdharm-...@one-eyed-alien.net] 发送时间: 2016年3月3日 23:45 收件人: Lipengcheng 抄送: gre...@linuxfoundation.org; linux-usb@vger.kernel.org 主题: Re: The delay is present because we discovered many usb-storage devices that were not ready to accept commands immediately after insertion. We studied the behavior of Microsoft Windows and discovered it used a small delay before sending commands to the device, and thus we also implemented a delay. Some devices will work with delay_use = 0. Some will not. Matt On Thu, Mar 3, 2016 at 4:24 AM, Lipengcheng wrote: > Hi, > >Please tell me why the process to delay to call in the 1s? The > delay_use = 0, we also found no side effects.So we can set the delay_use = 0? > > > > drivers/usb/storage/usb.c > > > > Best Regards, > > Pengcheng Li -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux
Re: [PATCH 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver
Hi Lu,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.5-rc6 next-20160303]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-add-support-for-Intel-dual-role-port-mux/20160303-144241
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: mn10300-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mn10300
All error/warnings (new ones prefixed by >>):
drivers/mfd/intel-vuport.c: In function 'vuport_probe':
drivers/mfd/intel-vuport.c:39:17: warning: unused variable 'dev'
[-Wunused-variable]
struct device *dev = &pdev->dev;
^
drivers/mfd/intel-vuport.c: At top level:
>> drivers/mfd/intel-vuport.c:63:1: warning: data definition has no type or
>> storage class
MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
^
>> drivers/mfd/intel-vuport.c:63:1: error: type defaults to 'int' in
>> declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
>> drivers/mfd/intel-vuport.c:63:1: warning: parameter names (without types) in
>> function declaration
In file included from include/linux/acpi.h:27:0,
from drivers/mfd/intel-vuport.c:12:
include/linux/device.h:1337:1: warning: data definition has no type or
storage class
module_init(__driver##_init); \
^
include/linux/platform_device.h:228:2: note: in expansion of macro
'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^
drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro
'module_platform_driver'
module_platform_driver(vuport_driver);
^
include/linux/device.h:1337:1: error: type defaults to 'int' in declaration
of 'module_init' [-Werror=implicit-int]
module_init(__driver##_init); \
^
include/linux/platform_device.h:228:2: note: in expansion of macro
'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^
drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro
'module_platform_driver'
module_platform_driver(vuport_driver);
^
drivers/mfd/intel-vuport.c:75:1: warning: parameter names (without types) in
function declaration
In file included from include/linux/acpi.h:27:0,
from drivers/mfd/intel-vuport.c:12:
include/linux/device.h:1342:1: warning: data definition has no type or
storage class
module_exit(__driver##_exit);
^
include/linux/platform_device.h:228:2: note: in expansion of macro
'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^
drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro
'module_platform_driver'
module_platform_driver(vuport_driver);
^
include/linux/device.h:1342:1: error: type defaults to 'int' in declaration
of 'module_exit' [-Werror=implicit-int]
module_exit(__driver##_exit);
^
include/linux/platform_device.h:228:2: note: in expansion of macro
'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^
drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro
'module_platform_driver'
module_platform_driver(vuport_driver);
^
drivers/mfd/intel-vuport.c:75:1: warning: parameter names (without types) in
function declaration
>> drivers/mfd/intel-vuport.c:77:15: error: expected declaration specifiers or
>> '...' before string constant
MODULE_AUTHOR("Lu Baolu ");
^
drivers/mfd/intel-vuport.c:78:20: error: expected declaration specifiers or
'...' before string constant
MODULE_DESCRIPTION("Intel virtual USB port");
^
drivers/mfd/intel-vuport.c:79:16: error: expected declaration specifiers or
'...' before string constant
MODULE_LICENSE("GPL v2");
^
drivers/mfd/intel-vuport.c:59:30: warning: 'vuport_acpi_match' defined but
not used [-Wunused-variable]
static struct acpi_device_id vuport_acpi_match[] = {
^
In file included from include/linux/acpi.h:27:0,
from drivers/mfd/intel-vuport.c:12:
drivers/mfd/intel-vuport.c:75:24: warning: 'vuport_driver_init' defined but
not used [-Wunused-function]
module_platform_driver(vuport_driver);
^
include/linux/device.h:1333:19: note: in definition of macro 'module_driver'
s
Re: [PATCH 3/7] usb: misc: add common code for Intel dual role port mux
On 03/04/2016 12:10 AM, Greg Kroah-Hartman wrote:
> On Thu, Mar 03, 2016 at 02:37:40PM +0800, Lu Baolu wrote:
>> Several Intel PCHs and SOCs have an internal mux that is used to
>> share one USB port between device controller and host controller.
>>
>> A usb port mux could be abstracted as the following elements:
>> 1) mux state: HOST or PERIPHERAL;
>> 2) an extcon cable which triggers the change of mux state between
>>HOST and PERIPHERAL;
>> 3) The required action to do the real port switch.
>>
>> This patch adds the common code to handle usb port mux. With this
>> common code, the individual mux driver, which always is platform
>> dependent, could focus on the real operation of mux switch.
>>
>> Signed-off-by: Lu Baolu
>> Reviewed-by: Heikki Krogerus
>> Reviewed-by: Felipe Balbi
>> ---
>> MAINTAINERS | 7 ++
>> drivers/usb/misc/Kconfig | 4 ++
>> drivers/usb/misc/Makefile | 2 +
>> drivers/usb/misc/mux.c| 172
>> ++
>> include/linux/usb/mux.h | 71 +++
>> 5 files changed, 256 insertions(+)
>> create mode 100644 drivers/usb/misc/mux.c
>> create mode 100644 include/linux/usb/mux.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index d894ee2..45f1e1e 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11389,6 +11389,13 @@ T: git
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>> S: Maintained
>> F: drivers/usb/phy/
>>
>> +USB PORT MUX DRIVER
>> +M: Lu Baolu
>> +L: linux-usb@vger.kernel.org
>> +S: Supported
>> +F: drivers/usb/misc/mux.c
>> +F: include/linux/usb/mux.h
>> +
>> USB PRINTER DRIVER (usblp)
>> M: Pete Zaitcev
>> L: linux-usb@vger.kernel.org
>> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
>> index f7a7fc2..6496d17 100644
>> --- a/drivers/usb/misc/Kconfig
>> +++ b/drivers/usb/misc/Kconfig
>> @@ -3,6 +3,10 @@
>> #
>> comment "USB Miscellaneous drivers"
>>
>> +config USB_MUX
>> +select EXTCON
>> +def_bool n
>> +
>> config USB_EMI62
>> tristate "EMI 6|2m USB Audio interface support"
>> ---help---
>> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
>> index 45fd4ac..fd79dd5 100644
>> --- a/drivers/usb/misc/Makefile
>> +++ b/drivers/usb/misc/Makefile
>> @@ -29,3 +29,5 @@ obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
>>
>> obj-$(CONFIG_USB_SISUSBVGA) += sisusbvga/
>> obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
>> +
>> +obj-$(CONFIG_USB_MUX) += mux.o
> "mux.ko" is a _VERY_ generic name of a kernel module. Please make this
> much more specific to your chip as this will not work for any other
> platform that has this type of functionality.
>
> Same goes for all of your exported symbols.
Sure. I will change the module name to "intel-mux", and change
the exported symbols to "intel_usb_mux_*".
>
>
>> diff --git a/drivers/usb/misc/mux.c b/drivers/usb/misc/mux.c
>> new file mode 100644
>> index 000..e353fff
>> --- /dev/null
>> +++ b/drivers/usb/misc/mux.c
>> @@ -0,0 +1,172 @@
>> +/**
>> + * mux.c - USB Port Mux support
>> + *
>> + * Copyright (C) 2016 Intel Corporation
>> + *
>> + * Author: Lu Baolu
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static int usb_mux_change_state(struct usb_mux *mux, int state)
>> +{
>> +int ret;
>> +struct usb_mux_dev *umdev = mux->umdev;
>> +
>> +dev_WARN_ONCE(umdev->dev, !mutex_is_locked(&mux->mux_mutex),
>> +"mutex is unlocked\n");
>> +
>> +mux->mux_state = state;
>> +
>> +if (mux->mux_state)
>> +ret = umdev->cable_set_cb(umdev);
>> +else
>> +ret = umdev->cable_unset_cb(umdev);
>> +
>> +return ret;
>> +}
>> +
>> +static int usb_mux_notifier(struct notifier_block *nb,
>> +unsigned long event, void *ptr)
>> +{
>> +struct usb_mux *mux;
>> +int state;
>> +int ret = NOTIFY_DONE;
>> +
>> +mux = container_of(nb, struct usb_mux, nb);
>> +
>> +state = extcon_get_cable_state(mux->obj.edev,
>> +mux->umdev->cable_name);
>> +
>> +if (mux->mux_state == -1 || mux->mux_state != state) {
>> +mutex_lock(&mux->mux_mutex);
>> +ret = usb_mux_change_state(mux, state);
>> +mutex_unlock(&mux->mux_mutex);
>> +}
>> +
>> +return ret;
>> +}
>> +
>> +static ssize_t mux_debug_read(struct file *file, char __user *user_buf,
>> +size_t len, loff_t *offset)
>> +{
>> +struct usb_mux *mux = file->private_data;
>> +char output_buf[16];
>> +
>> +memset(output_buf, 0, sizeof(output_buf));
>> +if (mux->mux_state)
>> +strcpy(output_buf, "host\n");
>> +else
>> +strcpy(output_buf, "peripheral\n");
>> +
>> +return simpl
Re: [PATCH 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver
Hi Lu, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.5-rc6 next-20160303] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-add-support-for-Intel-dual-role-port-mux/20160303-144241 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing config: parisc-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=parisc All warnings (new ones prefixed by >>): drivers/mfd/intel-vuport.c: In function 'vuport_probe': drivers/mfd/intel-vuport.c:39:17: warning: unused variable 'dev' [-Wunused-variable] struct device *dev = &pdev->dev; ^ drivers/mfd/intel-vuport.c: At top level: drivers/mfd/intel-vuport.c:63:1: warning: data definition has no type or storage class MODULE_DEVICE_TABLE(acpi, vuport_acpi_match); ^ drivers/mfd/intel-vuport.c:63:1: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int] drivers/mfd/intel-vuport.c:63:1: warning: parameter names (without types) in function declaration In file included from include/linux/acpi.h:27:0, from drivers/mfd/intel-vuport.c:12: include/linux/device.h:1337:1: warning: data definition has no type or storage class module_init(__driver##_init); \ ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^ >> drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro >> 'module_platform_driver' module_platform_driver(vuport_driver); ^ include/linux/device.h:1337:1: error: type defaults to 'int' in declaration of 'module_init' [-Werror=implicit-int] module_init(__driver##_init); \ ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^ >> drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro >> 'module_platform_driver' module_platform_driver(vuport_driver); ^ In file included from include/linux/linkage.h:6:0, from include/linux/kernel.h:6, from include/linux/list.h:8, from include/linux/resource_ext.h:17, from include/linux/acpi.h:26, from drivers/mfd/intel-vuport.c:12: include/linux/export.h:36:30: warning: parameter names (without types) in function declaration #define THIS_MODULE ((struct module *)0) ^ include/linux/platform_device.h:198:34: note: in expansion of macro 'THIS_MODULE' __platform_driver_register(drv, THIS_MODULE) ^ include/linux/device.h:1335:9: note: in expansion of macro 'platform_driver_register' return __register(&(__driver) , ##__VA_ARGS__); \ ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^ >> drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro >> 'module_platform_driver' module_platform_driver(vuport_driver); ^ In file included from include/linux/acpi.h:27:0, from drivers/mfd/intel-vuport.c:12: include/linux/device.h:1342:1: warning: data definition has no type or storage class module_exit(__driver##_exit); ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^ >> drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro >> 'module_platform_driver' module_platform_driver(vuport_driver); ^ include/linux/device.h:1342:1: error: type defaults to 'int' in declaration of 'module_exit' [-Werror=implicit-int] module_exit(__driver##_exit); ^ include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' module_driver(__platform_driver, platform_driver_register, \ ^ >> drivers/mfd/intel-vuport.c:75:1: note: in expansion of macro >> 'module_platform_driver' module_platform_driver(vuport_driver); ^ In file included from include/linux/linkage.h:6:0, from include/linux/kernel.h:6, from include/linux/list.h:8, from incl
Re: [PATCH 3/3] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
Hi Peter,
On 03.03.2016 11:01, Peter Chen wrote:
> From: Peter Chen
>
> The current dts describes USB HUB's property at USB controller's
> entry, it is improper. The USB HUB should be the child node
> under USB controller.
>
> Signed-off-by: Peter Chen
Thanks for patches!
VID:PID for hub on UDOO board is 0424:2514.
I've tested these patches on this board and was able to make USB work
again with following DT changes:
diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index d3e54e4..4956de7 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
*
*/
+#include
+
/ {
chosen {
stdout-path = &uart2;
@@ -18,21 +27,11 @@
reg = <0x1000 0x4000>;
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reg_usb_h1_vbus: regulator@0 {
- compatible = "regulator-fixed";
- reg = <0>;
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- startup-delay-us = <2>; /* USB2415 requires a POR of 1
us minimum */
- gpio = <&gpio7 12 0>;
- };
+ usb2415_pwrseq: usb2415_pwrseq {
+ compatible = "usb-pwrseq";
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ reset-duration-us = <3000>;
};
sound {
@@ -163,9 +218,16 @@
&usbh1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh>;
- vbus-supply = <®_usb_h1_vbus>;
- clocks = <&clks 201>;
status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub: usb2415@01 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ usb-pwrseq = <&usb2415_pwrseq>;
+ };
};
&usdhc3 {
Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] ohci-platform: Add support for controllers with multiple reset lines
On Sat, Feb 27, 2016 at 05:58:59PM +0100, Hans de Goede wrote: > At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple > reset lines, the controller will not initialize while the reset for > its companion is still asserted, which means we need to de-assert > 2 resets for the controller to work. > > Signed-off-by: Hans de Goede > Acked-by: Alan Stern > --- > Changes in v2: > -New patch in v2 of this patch-set, to complement the identical patch for > the ehci-platform code > Changes in v3: > -Adjust for changes to shared-reset reset-controller functions > Changes in v4: > -Fix Ugly continuation line > --- > Documentation/devicetree/bindings/usb/usb-ohci.txt | 2 +- Acked-by: Rob Herring > drivers/usb/host/ohci-platform.c | 43 > -- > 2 files changed, 24 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] ehci-platform: Add support for controllers with multiple reset lines
On Sat, Feb 27, 2016 at 05:58:58PM +0100, Hans de Goede wrote: > From: Reinder de Haan > > At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple > reset lines, the controller will not initialize while the reset for > its companion is still asserted, which means we need to de-assert > 2 resets for the controller to work. > > Signed-off-by: Reinder de Haan > Signed-off-by: Hans de Goede > Acked-by: Alan Stern > --- > Changes in v2: > -Use the new reset_control_[de]assert_shared reset-controller functions > Changes in v3: > -Adjust for changes to shared-reset reset-controller functions > Changes in v4: > -Fix Ugly continuation line > --- > Documentation/devicetree/bindings/usb/usb-ehci.txt | 2 +- Acked-by: Rob Herring > drivers/usb/host/ehci-platform.c | 41 > -- > 2 files changed, 24 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc2: Add support for Lantiq ARX and XRX SoCs
On Sat, Feb 27, 2016 at 12:31:24PM +0200, Antti Seppälä wrote: > Add support for Lantiq ARX and XRX SoC families to the dwc2 driver. > > Signed-off-by: Antti Seppälä > --- > Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++ Acked-by: Rob Herring > drivers/usb/dwc2/platform.c| 34 > ++ > 2 files changed, 36 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net,stable] qmi_wwan: add Sierra Wireless EM74xx device ID
From: Bjørn Mork Date: Tue, 1 Mar 2016 14:31:02 +0100 > The MC74xx and EM74xx modules use different IDs by default, according > to the Lenovo EM7455 driver for Windows. > > Signed-off-by: Bjørn Mork Applied and queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: mxs: Add DT bindings to configure TX settings
The TX settings can be calibrated for particular hardware. The
phy is reset by Linux, so this cannot be handled by the bootloader.
The TRM mentions that the maximum resistance should be used for the
DN/DP calibration in order to pass USB certification.
The values for the TX registers are poorly described in the TRM.
The meanings of the register values were taken from another
Freescale-provided document:
https://community.freescale.com/message/566147#comment-566912
Signed-off-by: Jaret Cantu
---
.../devicetree/bindings/phy/mxs-usb-phy.txt| 10
drivers/usb/phy/phy-mxs-usb.c | 48
2 files changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
index 379b84a..2f11e27 100644
--- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
@@ -12,6 +12,16 @@ Required properties:
- interrupts: Should contain phy interrupt
- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series
+Optional properties:
+- fsl,tx-cal-45-dn: Integer [30-55]. Resistance (in ohms) of switchable
+ high-speed trimming resistor connected in parallel with the 45 ohm resistor
+ that terminates the DN output signal. Default: 45
+- fsl,tx-cal-45-dp: Integer [30-55]. Resistance (in ohms) of switchable
+ high-speed trimming resistor connected in parallel with the 45 ohm resistor
+ that terminates the DP output signal. Default: 45
+- fsl,tx-d-cal: Integer [79-119]. Current trimming value (as a percentage) of
+ the 17.78mA TX reference current. Default: 100
+
Example:
usbphy1: usbphy@020c9000 {
compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 00bfea0..fdbdeb1 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -27,6 +27,7 @@
#define DRIVER_NAME "mxs_phy"
#define HW_USBPHY_PWD 0x00
+#define HW_USBPHY_TX 0x10
#define HW_USBPHY_CTRL 0x30
#define HW_USBPHY_CTRL_SET 0x34
#define HW_USBPHY_CTRL_CLR 0x38
@@ -38,6 +39,10 @@
#define HW_USBPHY_IP_SET 0x94
#define HW_USBPHY_IP_CLR 0x98
+#define GM_USBPHY_TX_TXCAL45DP(x)(((x) & 0xf) << 16)
+#define GM_USBPHY_TX_TXCAL45DN(x)(((x) & 0xf) << 8)
+#define GM_USBPHY_TX_D_CAL(x)(((x) & 0xf) << 0)
+
#define BM_USBPHY_CTRL_SFTRST BIT(31)
#define BM_USBPHY_CTRL_CLKGATE BIT(30)
#define BM_USBPHY_CTRL_OTG_ID_VALUEBIT(27)
@@ -164,6 +169,8 @@ struct mxs_phy {
const struct mxs_phy_data *data;
struct regmap *regmap_anatop;
int port_id;
+ u32 tx_reg_set;
+ u32 tx_reg_mask;
};
static inline bool is_imx6q_phy(struct mxs_phy *mxs_phy)
@@ -185,6 +192,20 @@ static void mxs_phy_clock_switch_delay(void)
usleep_range(300, 400);
}
+static void mxs_phy_tx_init(struct mxs_phy *mxs_phy)
+{
+ void __iomem *base = mxs_phy->phy.io_priv;
+ u32 phytx;
+
+ /* Update TX register if there is anything to write */
+ if (mxs_phy->tx_reg_mask) {
+ phytx = readl(base + HW_USBPHY_TX);
+ phytx &= ~mxs_phy->tx_reg_mask;
+ phytx |= mxs_phy->tx_reg_set;
+ writel(phytx, base + HW_USBPHY_TX);
+ }
+}
+
static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
{
int ret;
@@ -214,6 +235,8 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
if (mxs_phy->data->flags & MXS_PHY_NEED_IP_FIX)
writel(BM_USBPHY_IP_FIX, base + HW_USBPHY_IP_SET);
+ mxs_phy_tx_init(mxs_phy);
+
return 0;
}
@@ -400,6 +423,8 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
writel(BM_USBPHY_CTRL_CLKGATE,
x->io_priv + HW_USBPHY_CTRL_CLR);
writel(0, x->io_priv + HW_USBPHY_PWD);
+
+ mxs_phy_tx_init(mxs_phy);
}
return 0;
@@ -459,6 +484,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
int ret;
const struct of_device_id *of_id;
struct device_node *np = pdev->dev.of_node;
+ u32 val;
of_id = of_match_device(mxs_phy_dt_ids, &pdev->dev);
if (!of_id)
@@ -491,6 +517,28 @@ static int mxs_phy_probe(struct platform_device *pdev)
}
}
+ /* Precompute which bits of the TX register are to be updated, if any */
+ if (!of_property_read_u32(np, "fsl,tx-cal-45-dn", &val) &&
+ val >= 30 && val <= 55) {
+ val = (55 - val) * 15 / 25; /* translate to 4-bit value */
+ mxs_phy->tx_reg_mask |= GM_USBPHY_TX_TXCAL45DN(~0);
+ mxs_phy->tx_reg_set |= GM_USBPHY_TX_TXCAL45DN(val);
+
[PATCH net,stable] cdc_ncm: toggle altsetting to force reset before setup
Some devices will silently fail setup unless they are reset first.
This is necessary even if the data interface is already in
altsetting 0, which it will be when the device is probed for the
first time. Briefly toggling the altsetting forces a function
reset regardless of the initial state.
This fixes a setup problem observed on a number of Huawei devices,
appearing to operate in NTB-32 mode even if we explicitly set them
to NTB-16 mode.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index dc0212c3cc28..be927964375b 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -837,7 +837,11 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct
usb_interface *intf, u8 data_
iface_no = ctx->data->cur_altsetting->desc.bInterfaceNumber;
- /* reset data interface */
+ /* Reset data interface. Some devices will not reset properly
+* unless they are configured first. Toggle the altsetting to
+* force a reset
+*/
+ usb_set_interface(dev->udev, iface_no, data_altsetting);
temp = usb_set_interface(dev->udev, iface_no, 0);
if (temp) {
dev_dbg(&intf->dev, "set interface failed\n");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: core: add power sequence for USB devices
On Thu, Mar 3, 2016 at 4:01 AM, Peter Chen wrote: > Some hard-wired USB devices need to do power sequence to let the > device work normally, the typical power sequence like: enable USB > PHY clock, toggle reset pin, etc. But current Linux USB driver > lacks of such code to do it, it may cause some hard-wired USB devices > works abnormal or can't be recognized by controller at all. > > In this patch, it will do power on sequence at hub's probe for all > devices under this hub (includes root hub) if this device is described > at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect, > it will do power off sequence. > > Signed-off-by: Peter Chen > --- > .../devicetree/bindings/usb/usb-device.txt | 41 +- > drivers/usb/core/Makefile | 2 +- > drivers/usb/core/hub.c | 32 + > drivers/usb/core/pwrseq.c | 149 > + > include/linux/usb/of.h | 10 ++ > 5 files changed, 232 insertions(+), 2 deletions(-) > create mode 100644 drivers/usb/core/pwrseq.c > > diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt > b/Documentation/devicetree/bindings/usb/usb-device.txt > index 1c35e7b..c7a298c 100644 > --- a/Documentation/devicetree/bindings/usb/usb-device.txt > +++ b/Documentation/devicetree/bindings/usb/usb-device.txt > @@ -13,8 +13,37 @@ Required properties: > - reg: the port number which this device is connecting to, the range >is 1-31. > > +Optional properties: > +- usb-pwrseq: the power sequence handler which need to do before this USB > + device can work. > +- clocks: the input clock for USB device. > +- clock-frequency: the frequency for device's clock. > +- reset-gpios: Should specify the GPIO for reset. > +- reset-duration-us: the duration in microsecond for assert reset signal. So we sorted out how to describe USB devices in DT, but now we don't use it? I know this is similar to what was done for MMC, but I really don't like it. Just put all these properties into the device nodes. The parent can then scan for children and handle the power sequencing with generic code. I think it is safe to assume that if these properties are present, they need to be handled for device detection. We may still need something device specific to handle some devices at some point, but that is true either way. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB-serial fixes for v4.5-rc7
On Thu, Mar 03, 2016 at 05:34:11PM +0100, Johan Hovold wrote: > Hi Greg, > > Here's a final set of fixes for 4.5-rc. > > Thanks, > Johan > > > The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af: > > Linux 4.5-rc6 (2016-02-28 08:41:20 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-4.5-rc7 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: core: add power sequence for USB devices
On Thu, 3 Mar 2016, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
>
> In this patch, it will do power on sequence at hub's probe for all
> devices under this hub (includes root hub) if this device is described
> at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect,
> it will do power off sequence.
>
> Signed-off-by: Peter Chen
> +static int hub_of_pwrseq(struct usb_device *hdev, bool on)
> +{
> + struct device *parent;
> + struct device_node *node;
> + int ret = 0;
> +
> + if (hdev->parent)
> + parent = &hdev->dev;
> + else
> + parent = bus_to_hcd(hdev->bus)->self.controller;
> +
> + for_each_child_of_node(parent->of_node, node) {
> + ret = on ? usb_child_pwrseq_on(node)
> + : usb_child_pwrseq_off(node);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
If you get a failure, do you want to leave the power to all the
preceding devices turned on? It seems to me you should either turn all
of them back off, or else continue trying to turn on power for the
remaining children.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] usb: ohci: nxp: remove direct clock management
On Thu, 3 Mar 2016, Vladimir Zapolskiy wrote: > The change removes direct clock management from NXP LPC32xx USB OHCI > driver done by accessing platform clock control registers, also > after switching the platform to a common clock framework there is > no need to look for and enable all parent clocks, clock management > is delegated to the CCF driver. > > The change is wanted for v4.6, because in this release LPC32xx will > be finally switched to the CCF, otherwise USB OHCI may be broken: > > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > ohci-nxp: OHCI NXP driver > usb-ohci 3102.ohci: failed to acquire USB PLL > usb-ohci: probe of 3102.ohci failed with error -2 > > I'm adding Roland to Cc, however in fact the platform is unmaintained. > > Vladimir Zapolskiy (2): > usb: ohci: nxp: remove direct access to clock controller registers > usb: ohci: nxp: remove USB PLL and USB OTG clock management > > drivers/usb/host/ohci-nxp.c | 80 > ++--- > 1 file changed, 10 insertions(+), 70 deletions(-) For both patches: Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about PM enable with usb driver
On Thu, 3 Mar 2016, yoma sophian wrote: > hi all: > When I porting my platform ehci driver on kernel v4.1, > I get back trace like below without plug in any device and just insert > usb-common.ko, usbcore.ko and ehci-hcd.ko. > (and detail is show in the attachment) > > It seems caused by the PM related thread that is wakened up, even > there is no device plug in and step in null pointer. > Is there any callback function or flag in ehci-platform.c that we > should check that will trigger the related PM work thread? The work thread is triggered in order to suspend the EHCI controller's bus. > Appreciate your kind help in advance, > > > Backtrace: > [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from > [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd]) Since there aren't any devices registered on the USB bus yet, ehci_handle_start_intr_unlink() should do nothing. It iterates over ehci->intr_unlink, but that list should be empty. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: mos7840.c Support RS485 mode in B&B Electronics USOPTL4-4P and USOPTL4-2P
On Thu, 3 Mar 2016, Johan Hovold wrote: On Wed, Mar 02, 2016 at 09:36:55AM -0800, Aaron Marburg wrote: On Wed, 2 Mar 2016, Oliver Neukum wrote: On Tue, 2016-03-01 at 09:54 -0800, amarb...@apl.washington.edu wrote: From: Aaron Marburg The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the Moschip 7840/7820. For correct operation in RS-485, the chip must be configured in “RS-485 mode” through the scratchpad register as per the datasheet. This strobes the DTR line on transmission, enabling the driver on the RS485 transceiver chip. I think if you include a config option to do this, you should also enable the canonical way of using an ioctl(). That means you need to support rs485_config(). Regards Oliver Thank you for that pointer, I was not familiar with that IOCTL. I will see what's required for implementation. Yeah, we really don't want to add new module options. Either see if you can make this fit with the rs485 ioctl, or do this based on the driver_data field in the id_table (e.g. set a feature flags there) as we don't want to sprinkle the driver with ID-conditionals. The ioctl is the right approach. I'll implement the appropriate callbacks. I will also look into a feature-flag option. As far as I know, these particular B&B hubs will only work in RS485 mode, so I believe it makes sense to enable RS485 by default for those models. Thanks, Aaron
Re: [PATCH v2] usb: hcd: out of bounds access in for_each_companion
On Thu, 3 Mar 2016, Robert Dobrowolski wrote: > On BXT platform Host Controller and Device Controller figure as > same PCI device but with different device function. HCD should not > pass data to Device Controller but only to Host Controllers. > Checking if companion device is Host Controller, otherwise skip. > > Signed-off-by: Robert Dobrowolski > --- > drivers/usb/core/hcd-pci.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c > index 9eb1cff..b8b580e 100644 > --- a/drivers/usb/core/hcd-pci.c > +++ b/drivers/usb/core/hcd-pci.c > @@ -74,6 +74,15 @@ static void for_each_companion(struct pci_dev *pdev, > struct usb_hcd *hcd, > if (companion->bus != pdev->bus || > PCI_SLOT(companion->devfn) != slot) > continue; > + > + /* > + * Companion device should be either UHCI,OHCI or EHCI host > + * controller, otherwise skip. > + */ > + if (companion->class != CL_UHCI && companion->class != CL_OHCI > && > + companion->class != CL_EHCI) > + continue; > + > companion_hcd = pci_get_drvdata(companion); > if (!companion_hcd || !companion_hcd->self.root_hub) > continue; > Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb mouse quirks
On Thu, 3 Mar 2016, Paolo Minazzi wrote:
> Dear all,
> I have 3 wired usb optical mouse
> [1] Logitech 0x046D:0xC077
> [2] Logitech 0x046D:0xC05A
> [3] Microsoft 0x045E:0x0737
>
> I always used 3.10 kernel and all mice have the problem of
> disconnection after 62 seconds.
> I got the latest kernel 4.5-rc3 and I have discovered about quirks and
> HID_QUIRK_ALWAYS_POLL.
>
> Looking at the kernel 4.5-rc3 ...
>
> For [1] Logitech 0x046D:0xC077
> there is already a line in quirks
> { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077, HID_QUIRK_ALWAYS_POLL }
> but the #define seems broken:
> #define USB_DEVICE_ID_LOGITECH_C077 0xc007
> Someone can confirm ?
>
> For [2] Logitech 0x046D:0xC05A all seems already ok. Quirk is already present.
>
> For [3] Microsoft 0x045E:0x0737 the support for HID_QUIRK_ALWAYS_POLL
> seems missing.
>
> The final patch should be (against 4.5-rc3) should be
>
> =
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index b6ff6e7..d788de2 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -600,7 +600,7 @@
> #define USB_VENDOR_ID_LOGITECH 0x046d
> #define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e
> #define USB_DEVICE_ID_LOGITECH_T6510xb00c
> -#define USB_DEVICE_ID_LOGITECH_C0770xc007
> +#define USB_DEVICE_ID_LOGITECH_C0770xc077
> #define USB_DEVICE_ID_LOGITECH_RECEIVER0xc101
> #define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110
> #define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f
> @@ -670,6 +670,7 @@
>
> #define USB_VENDOR_ID_MICROSOFT0x045e
> #define USB_DEVICE_ID_SIDEWINDER_GV0x003b
> +#define USB_DEVICE_ID_MS_MOUSE_500 0x0737
> #define USB_DEVICE_ID_MS_OFFICE_KB 0x0048
> #define USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0 0x009d
> #define USB_DEVICE_ID_MS_NE4K 0x00db
Aren't these entries supposed to be in numerical order?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] USB-serial fixes for v4.5-rc7
Hi Greg, Here's a final set of fixes for 4.5-rc. Thanks, Johan The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af: Linux 4.5-rc6 (2016-02-28 08:41:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.5-rc7 for you to fetch changes up to 04fdbc825ffc02fb098964b92de802fff44e73fd: USB: qcserial: add Sierra Wireless EM74xx device ID (2016-03-02 09:35:32 +0100) USB-serial fixes for v4.5-rc7 Here are some new device ids and a patch removing the mxu11x0 driver, which turned out not to be needed. Signed-off-by: Johan Hovold Bjørn Mork (1): USB: qcserial: add Sierra Wireless EM74xx device ID Daniele Palmas (1): USB: serial: option: add support for Telit LE922 PID 0x1045 Johan Hovold (1): Revert "USB: serial: add Moxa UPORT 11x0 driver" Patrik Halfar (1): USB: qcserial: add Dell Wireless 5809e Gobi 4G HSPA+ (rev3) Vittorio Alfieri (1): USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder Yegor Yefremov (1): USB: serial: option: add support for Quectel UC20 drivers/usb/serial/Kconfig| 16 - drivers/usb/serial/Makefile |1 - drivers/usb/serial/cp210x.c |1 + drivers/usb/serial/mxu11x0.c | 1006 - drivers/usb/serial/option.c |5 + drivers/usb/serial/qcserial.c |7 +- 6 files changed, 11 insertions(+), 1025 deletions(-) delete mode 100644 drivers/usb/serial/mxu11x0.c -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine
Hi Clemens, On 03/03/16 11:38, Clemens Ladisch wrote: > Felipe Ferreri Tonello wrote: >> On 02/03/16 21:09, Clemens Ladisch wrote: >>> Felipe F. Tonello wrote: This refactor results in a cleaner state machine code >>> >>> It increases the number of states, and now juggles two state variables. >>> I cannot agree to it being cleaner. >> >> Yes, it increases the number of states. That was done in order to >> actually implement a proper finite state machine with one state at a >> time and a transition state. > > I know, "clean" is subjective. Clean is subjective, yes. However, based on our common sense and experience we can discern on what is clean and what is not. There is also good literature about the subject that we can always consider. > But in what way was the old state > machine not "proper"? Because it didn't reflect all the correct and possible MIDI states and there was no transitional state. > > And how is handling two states (port->state and next_state) cleaner? > As far as I can tell, the requirement for a separate variable comes not > from any inherent complexity of the state machine itself, but only > because the transmit_packet function was inlined. next_state is a transitional state, thus the temporal nature. This patch doesn't change any functionality. But the important thing here is that it improves the driver maintainability by making the state machine cleaner (which is one of the most important pieces of code of the driver). I call it clean because on each circumstance of each state it's clear on what is about to happen to the USB request and to the port's buffers. I confess I would not spend the time on it just for puritanisms, but I found myself a hard time while debugging it. -- Felipe 0x92698E6A.asc Description: application/pgp-keys
Re: [PATCH 3/7] usb: misc: add common code for Intel dual role port mux
On Thu, Mar 03, 2016 at 02:37:40PM +0800, Lu Baolu wrote: > +#if IS_ENABLED(CONFIG_USB_MUX) > +extern int usb_mux_register(struct usb_mux_dev *mux); > +extern int usb_mux_unregister(struct device *dev); > +extern struct usb_mux_dev *usb_mux_get_dev(struct device *dev); This api needs a lot of work, for such a "tiny" api, it's obviously pretty incorrect. Please fix it up to be sane... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] usb: misc: add driver for Intel drcfg controlled port mux
On Thu, Mar 03, 2016 at 02:37:42PM +0800, Lu Baolu wrote:
> Several Intel PCHs and SOCs have an internal mux that is used to
> share one USB port between device controller and host controller.
> The mux is handled through the Dual Role Configuration Register.
>
> Signed-off-by: Heikki Krogerus
> Signed-off-by: Lu Baolu
> Signed-off-by: Wu Hao
> Reviewed-by: Felipe Balbi
> ---
> MAINTAINERS| 1 +
> drivers/usb/misc/Kconfig | 7 ++
> drivers/usb/misc/Makefile | 1 +
> drivers/usb/misc/intel-mux-drcfg.c | 174
> +
> 4 files changed, 183 insertions(+)
> create mode 100644 drivers/usb/misc/intel-mux-drcfg.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0f321e4..20eb873 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11396,6 +11396,7 @@ S:Supported
> F: drivers/usb/misc/mux.c
> F: include/linux/usb/mux.h
> F: drivers/usb/misc/intel-mux-gpio.c
> +F: drivers/usb/misc/intel-mux-drcfg.c
>
> USB PRINTER DRIVER (usblp)
> M: Pete Zaitcev
> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> index 33e6386..befd910 100644
> --- a/drivers/usb/misc/Kconfig
> +++ b/drivers/usb/misc/Kconfig
> @@ -281,3 +281,10 @@ config INTEL_MUX_GPIO
> help
> Say Y here to enable support for Intel dual role port mux
> controlled by GPIOs.
> +
> +config INTEL_MUX_DRCFG
> + tristate "Intel dual role port mux controlled by register"
> + select USB_MUX
> + help
> + Say Y here to enable support for Intel dual role port mux
> + controlled by the Dual Role Configuration Registers.
> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> index da4fb4e..c4d19a0 100644
> --- a/drivers/usb/misc/Makefile
> +++ b/drivers/usb/misc/Makefile
> @@ -32,3 +32,4 @@ obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
>
> obj-$(CONFIG_USB_MUX)+= mux.o
> obj-$(CONFIG_INTEL_MUX_GPIO) += intel-mux-gpio.o
> +obj-$(CONFIG_INTEL_MUX_DRCFG)+= intel-mux-drcfg.o
> diff --git a/drivers/usb/misc/intel-mux-drcfg.c
> b/drivers/usb/misc/intel-mux-drcfg.c
> new file mode 100644
> index 000..29081c5
> --- /dev/null
> +++ b/drivers/usb/misc/intel-mux-drcfg.c
> @@ -0,0 +1,174 @@
> +/**
> + * intel-mux-drcfg.c - Driver for Intel USB mux via register
> + *
> + * Copyright (C) 2016 Intel Corporation
> + * Author: Heikki Krogerus
> + * Author: Lu Baolu
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define INTEL_MUX_CFG0 0x00
> +#define INTEL_MUX_CFG1 0x04
> +#define CFG0_SW_IDPINBIT(20)
> +#define CFG0_SW_IDPIN_EN BIT(21)
> +#define CFG0_SW_VBUS_VALID BIT(24)
> +#define CFG1_SW_MODE BIT(29)
> +#define CFG1_POLL_TIMEOUT1000
> +
> +struct intel_usb_mux {
> + struct usb_mux_dev umdev;
> + void __iomem *regs;
> + u32 cfg0_ctx;
> +};
> +
> +static inline int intel_mux_drcfg_switch(struct usb_mux_dev *umdev, bool
> host)
> +{
> + struct intel_usb_mux *mux;
> + unsigned long timeout;
> + u32 data;
> +
> + mux = container_of(umdev, struct intel_usb_mux, umdev);
> +
> + /* Check and set mux to SW controlled mode */
> + data = readl(mux->regs + INTEL_MUX_CFG0);
> + if (!(data & CFG0_SW_IDPIN_EN)) {
> + data |= CFG0_SW_IDPIN_EN;
> + writel(data, mux->regs + INTEL_MUX_CFG0);
> + }
> +
> + /*
> + * Configure CFG0 to switch the mux and VBUS_VALID bit is
> + * required for device mode.
> + */
> + data = readl(mux->regs + INTEL_MUX_CFG0);
> + if (host)
> + data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
> + else
> + data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
> + writel(data, mux->regs + INTEL_MUX_CFG0);
> +
> + /*
> + * Polling CFG1 for safety, most case it takes about 600ms
> + * to finish mode switching, set TIMEOUT long enough.
> + */
> + timeout = jiffies + msecs_to_jiffies(CFG1_POLL_TIMEOUT);
> +
> + /* Polling on CFG1 register to confirm mode switch. */
> + while (!time_after(jiffies, timeout)) {
> + data = readl(mux->regs + INTEL_MUX_CFG1);
> + if (!(host ^ (data & CFG1_SW_MODE)))
> + return 0;
> + /* interval for polling is set to about 5ms */
> + usleep_range(5000, 5100);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int intel_mux_drcfg_cable_set(struct usb_mux_dev *umdev)
> +{
> + dev_dbg(umdev->dev, "drcfg mux switch to HOST\n");
> +
> + return intel_mux_drcfg_switch(umdev, true);
> +}
> +
> +static int intel_mux_drcfg_cable_unset(struct usb_mux_dev *umdev)
> +{
> + dev_dbg(umdev->dev, "drcf
Re: [PATCH 5/7] usb: misc: add driver for Intel drcfg controlled port mux
On Thu, Mar 03, 2016 at 02:37:42PM +0800, Lu Baolu wrote: > Several Intel PCHs and SOCs have an internal mux that is used to > share one USB port between device controller and host controller. > The mux is handled through the Dual Role Configuration Register. > > Signed-off-by: Heikki Krogerus > Signed-off-by: Lu Baolu > Signed-off-by: Wu Hao > Reviewed-by: Felipe Balbi > --- > MAINTAINERS| 1 + > drivers/usb/misc/Kconfig | 7 ++ > drivers/usb/misc/Makefile | 1 + > drivers/usb/misc/intel-mux-drcfg.c | 174 > + If you are going to start having a bunch of these, please make a new directory, drivers/usb/mux/ ? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: misc: add common code for Intel dual role port mux
On Thu, Mar 03, 2016 at 02:37:40PM +0800, Lu Baolu wrote:
> Several Intel PCHs and SOCs have an internal mux that is used to
> share one USB port between device controller and host controller.
>
> A usb port mux could be abstracted as the following elements:
> 1) mux state: HOST or PERIPHERAL;
> 2) an extcon cable which triggers the change of mux state between
>HOST and PERIPHERAL;
> 3) The required action to do the real port switch.
>
> This patch adds the common code to handle usb port mux. With this
> common code, the individual mux driver, which always is platform
> dependent, could focus on the real operation of mux switch.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Heikki Krogerus
> Reviewed-by: Felipe Balbi
> ---
> MAINTAINERS | 7 ++
> drivers/usb/misc/Kconfig | 4 ++
> drivers/usb/misc/Makefile | 2 +
> drivers/usb/misc/mux.c| 172
> ++
> include/linux/usb/mux.h | 71 +++
> 5 files changed, 256 insertions(+)
> create mode 100644 drivers/usb/misc/mux.c
> create mode 100644 include/linux/usb/mux.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d894ee2..45f1e1e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11389,6 +11389,13 @@ T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> S: Maintained
> F: drivers/usb/phy/
>
> +USB PORT MUX DRIVER
> +M: Lu Baolu
> +L: linux-usb@vger.kernel.org
> +S: Supported
> +F: drivers/usb/misc/mux.c
> +F: include/linux/usb/mux.h
> +
> USB PRINTER DRIVER (usblp)
> M: Pete Zaitcev
> L: linux-usb@vger.kernel.org
> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> index f7a7fc2..6496d17 100644
> --- a/drivers/usb/misc/Kconfig
> +++ b/drivers/usb/misc/Kconfig
> @@ -3,6 +3,10 @@
> #
> comment "USB Miscellaneous drivers"
>
> +config USB_MUX
> + select EXTCON
> + def_bool n
> +
> config USB_EMI62
> tristate "EMI 6|2m USB Audio interface support"
> ---help---
> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> index 45fd4ac..fd79dd5 100644
> --- a/drivers/usb/misc/Makefile
> +++ b/drivers/usb/misc/Makefile
> @@ -29,3 +29,5 @@ obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
>
> obj-$(CONFIG_USB_SISUSBVGA) += sisusbvga/
> obj-$(CONFIG_USB_LINK_LAYER_TEST)+= lvstest.o
> +
> +obj-$(CONFIG_USB_MUX)+= mux.o
"mux.ko" is a _VERY_ generic name of a kernel module. Please make this
much more specific to your chip as this will not work for any other
platform that has this type of functionality.
Same goes for all of your exported symbols.
> diff --git a/drivers/usb/misc/mux.c b/drivers/usb/misc/mux.c
> new file mode 100644
> index 000..e353fff
> --- /dev/null
> +++ b/drivers/usb/misc/mux.c
> @@ -0,0 +1,172 @@
> +/**
> + * mux.c - USB Port Mux support
> + *
> + * Copyright (C) 2016 Intel Corporation
> + *
> + * Author: Lu Baolu
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +static int usb_mux_change_state(struct usb_mux *mux, int state)
> +{
> + int ret;
> + struct usb_mux_dev *umdev = mux->umdev;
> +
> + dev_WARN_ONCE(umdev->dev, !mutex_is_locked(&mux->mux_mutex),
> + "mutex is unlocked\n");
> +
> + mux->mux_state = state;
> +
> + if (mux->mux_state)
> + ret = umdev->cable_set_cb(umdev);
> + else
> + ret = umdev->cable_unset_cb(umdev);
> +
> + return ret;
> +}
> +
> +static int usb_mux_notifier(struct notifier_block *nb,
> + unsigned long event, void *ptr)
> +{
> + struct usb_mux *mux;
> + int state;
> + int ret = NOTIFY_DONE;
> +
> + mux = container_of(nb, struct usb_mux, nb);
> +
> + state = extcon_get_cable_state(mux->obj.edev,
> + mux->umdev->cable_name);
> +
> + if (mux->mux_state == -1 || mux->mux_state != state) {
> + mutex_lock(&mux->mux_mutex);
> + ret = usb_mux_change_state(mux, state);
> + mutex_unlock(&mux->mux_mutex);
> + }
> +
> + return ret;
> +}
> +
> +static ssize_t mux_debug_read(struct file *file, char __user *user_buf,
> + size_t len, loff_t *offset)
> +{
> + struct usb_mux *mux = file->private_data;
> + char output_buf[16];
> +
> + memset(output_buf, 0, sizeof(output_buf));
> + if (mux->mux_state)
> + strcpy(output_buf, "host\n");
> + else
> + strcpy(output_buf, "peripheral\n");
> +
> + return simple_read_from_buffer(user_buf, len, offset,
> + output_buf, strlen(output_buf));
> +}
> +
> +static ssize_t mux_debug_write(struct file *file, const char __user
> *user_buf,
> + size_t count, loff_t *offset)
> +{
> + struct usb
Re: [PATCH v2] usb: hcd: out of bounds access in for_each_companion
On Thu, Mar 03, 2016 at 10:00:05AM +0100, Robert Dobrowolski wrote: > Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i > moze zawierac informacje poufne. W razie przypadkowego otrzymania tej > wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; > jakiekolwiek > przegladanie lub rozpowszechnianie jest zabronione. > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). If you are not the intended recipient, > please contact the sender and delete all copies; any review or distribution by > others is strictly prohibited. Ok, now deleted. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
The delay is present because we discovered many usb-storage devices that were not ready to accept commands immediately after insertion. We studied the behavior of Microsoft Windows and discovered it used a small delay before sending commands to the device, and thus we also implemented a delay. Some devices will work with delay_use = 0. Some will not. Matt On Thu, Mar 3, 2016 at 4:24 AM, Lipengcheng wrote: > Hi, > >Please tell me why the process to delay to call in the 1s? The delay_use > = 0, we also found no side effects.So we can set the delay_use = 0? > > > > drivers/usb/storage/usb.c > > > > Best Regards, > > Pengcheng Li -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dmaengine: sun4i: support module autoloading
On Sun, Feb 21, 2016 at 10:26:35PM -0300, Emilio López wrote: > From: Emilio López > > MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on > supported systems. This commit adds the missing line so it loads > automatically when building it as a module and running on a system > with the early sunxi DMA engine. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: mos7840.c Support RS485 mode in B&B Electronics USOPTL4-4P and USOPTL4-2P
On Wed, Mar 02, 2016 at 09:36:55AM -0800, Aaron Marburg wrote: > On Wed, 2 Mar 2016, Oliver Neukum wrote: > > > On Tue, 2016-03-01 at 09:54 -0800, amarb...@apl.washington.edu wrote: > >> From: Aaron Marburg > >> > >> The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the > >> Moschip 7840/7820. For correct operation in RS-485, the chip must be > >> configured in “RS-485 mode” through the scratchpad register as per the > >> datasheet. This strobes the DTR line on transmission, enabling the driver > >> on the RS485 transceiver chip. > > > > I think if you include a config option to do this, you should > > also enable the canonical way of using an ioctl(). That means > > you need to support rs485_config(). > > > > Regards > > Oliver > > > > Thank you for that pointer, I was not familiar with that IOCTL. I will > see what's required for implementation. Yeah, we really don't want to add new module options. Either see if you can make this fit with the rs485 ioctl, or do this based on the driver_data field in the id_table (e.g. set a feature flags there) as we don't want to sprinkle the driver with ID-conditionals. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: musb: tx fifo flush warning
On 2016-03-03, Bin Liu wrote: >> Using next-20160302 I can very reliably hit this warning on an AM335x >> BeagleBone by playing a short audio file over USB-Audio: >> >> $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE >> /usr/share/sounds/alsa/Front_Center.wav >> >> $ aplay -l >> List of PLAYBACK Hardware Devices >> card 1: Audio [USB Audio], device 0: USB Audio [USB Audio] >> Subdevices: 1/1 >> Subdevice #0: subdevice #0 >> >> The audio file is part of the alsa-utils package. The USB-Audio >> device is never disconnected. Simply playing the file triggers the >> warning. Any hints/suggestions how I should debug this? > > In general, it seems this tx fifo flush error has been there for > years, it happens when tearing down an active endpoint in some unknown > conditions. But I haven't seen a such case in which musb stops > working. Actually, I am tracking down an issue where musb _does_ stop working. With the above "aplay" example, I can reproduce a hang with the musb on v3.19 and v4.0. Sometimes it takes up to an hour to reproduce the hang, so I am slowly moving to newer kernels to see how far I can reproduce the hang. I have not been able to reproduce a hang with next-20160302 (yet?), but I do get your warning and the backtrace looks very similar to what I see in the hang situation on the older kernel versions. > In this case, does musb still work or is audio playback broken after > the warning message? In this (next-20160302) case musb does continue to work. In my debugging of the older kernels I can perfectly identify when the situation for a potential hang happens. Most of the time it does not hang there, but 100% of the hangs were in that exact situation. So I suspect a race condition exists there. > Does the issue happen in any previous kernel? Trying to think if there > is any regression in next-20160302... I will continue trying to reproduce the hang with newer kernels. I haven't tried anything between v4.0 and next-20160302 yet. I will post again when I have more data. John Ogness -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] usb: misc: add driver for Intel drcfg controlled port mux
Hi Lu,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.5-rc6 next-20160303]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-add-support-for-Intel-dual-role-port-mux/20160303-144241
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: arm64-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All error/warnings (new ones prefixed by >>):
drivers/usb/misc/intel-mux-drcfg.c: In function 'intel_mux_drcfg_switch':
>> drivers/usb/misc/intel-mux-drcfg.c:42:2: error: implicit declaration of
>> function 'readl' [-Werror=implicit-function-declaration]
data = readl(mux->regs + INTEL_MUX_CFG0);
^
>> drivers/usb/misc/intel-mux-drcfg.c:45:3: error: implicit declaration of
>> function 'writel' [-Werror=implicit-function-declaration]
writel(data, mux->regs + INTEL_MUX_CFG0);
^
drivers/usb/misc/intel-mux-drcfg.c: In function 'intel_mux_drcfg_probe':
>> drivers/usb/misc/intel-mux-drcfg.c:108:2: error: implicit declaration of
>> function 'devm_ioremap_nocache' [-Werror=implicit-function-declaration]
mux->regs = devm_ioremap_nocache(dev, start, size);
^
>> drivers/usb/misc/intel-mux-drcfg.c:108:12: warning: assignment makes pointer
>> from integer without a cast
mux->regs = devm_ioremap_nocache(dev, start, size);
^
cc1: some warnings being treated as errors
vim +/readl +42 drivers/usb/misc/intel-mux-drcfg.c
36 unsigned long timeout;
37 u32 data;
38
39 mux = container_of(umdev, struct intel_usb_mux, umdev);
40
41 /* Check and set mux to SW controlled mode */
> 42 data = readl(mux->regs + INTEL_MUX_CFG0);
43 if (!(data & CFG0_SW_IDPIN_EN)) {
44 data |= CFG0_SW_IDPIN_EN;
> 45 writel(data, mux->regs + INTEL_MUX_CFG0);
46 }
47
48 /*
49 * Configure CFG0 to switch the mux and VBUS_VALID bit is
50 * required for device mode.
51 */
52 data = readl(mux->regs + INTEL_MUX_CFG0);
53 if (host)
54 data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
55 else
56 data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
57 writel(data, mux->regs + INTEL_MUX_CFG0);
58
59 /*
60 * Polling CFG1 for safety, most case it takes about 600ms
61 * to finish mode switching, set TIMEOUT long enough.
62 */
63 timeout = jiffies + msecs_to_jiffies(CFG1_POLL_TIMEOUT);
64
65 /* Polling on CFG1 register to confirm mode switch. */
66 while (!time_after(jiffies, timeout)) {
67 data = readl(mux->regs + INTEL_MUX_CFG1);
68 if (!(host ^ (data & CFG1_SW_MODE)))
69 return 0;
70 /* interval for polling is set to about 5ms */
71 usleep_range(5000, 5100);
72 }
73
74 return -ETIMEDOUT;
75 }
76
77 static int intel_mux_drcfg_cable_set(struct usb_mux_dev *umdev)
78 {
79 dev_dbg(umdev->dev, "drcfg mux switch to HOST\n");
80
81 return intel_mux_drcfg_switch(umdev, true);
82 }
83
84 static int intel_mux_drcfg_cable_unset(struct usb_mux_dev *umdev)
85 {
86 dev_dbg(umdev->dev, "drcfg mux switch to DEVICE\n");
87
88 return intel_mux_drcfg_switch(umdev, false);
89 }
90
91 static int intel_mux_drcfg_probe(struct platform_device *pdev)
92 {
93 struct intel_usb_mux *mux;
94 struct usb_mux_dev *umdev;
95 struct device *dev = &pdev->dev;
96 u64 start, size;
97 int ret;
98
99 mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
100 if (!mux)
101 return -ENOMEM;
102
103 ret = device_property_read_u64(dev, "reg-start", &start);
104 ret |= device_property_read_u64(dev, "reg-size", &size);
105 if (ret)
106 return -ENODEV;
107
> 108 mux->regs = devm_ioremap_nocache(dev, start, size);
109 if (!mux->regs)
110 return -ENOMEM;
111
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
some questions about PM enable with usb driver
hi all: When I porting my platform ehci driver on kernel v4.1, I get back trace like below without plug in any device and just insert usb-common.ko, usbcore.ko and ehci-hcd.ko. (and detail is show in the attachment) It seems caused by the PM related thread that is wakened up, even there is no device plug in and step in null pointer. Is there any callback function or flag in ehci-platform.c that we should check that will trigger the related PM work thread? Appreciate your kind help in advance, Backtrace: [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd]) r6:ede8152c r5:ede81480 r4:ede81300 r3:ede81550 [] (ehci_bus_suspend [ehci_hcd]) from [] (hcd_bus_suspend+0xd0/0x1dc [usbcore]) r10:0400 r9:edd8e940 r8:0001 r7:bf024928 r6:0007 r5:ede82f80 r4:ede81300 [] (hcd_bus_suspend [usbcore]) from [] (generic_suspend+0x24/0x44 [usbcore]) r8:0402 r7:0001 r6:0007 r5: r4:ede82f80 [] (generic_suspend [usbcore]) from [] (usb_suspend_both+0x108/0x1a8 [usbcore]) [] (usb_suspend_both [usbcore]) from [] (usb_runtime_suspend+0x38/0x78 [usbcore]) r10:0003 r9:0008 r8: r7:6113 r6:ede82f80 r5:ede82fe8 r4: r3:0001 [] (usb_runtime_suspend [usbcore]) from [] (__rpm_callback+0x44/0x6c) r6:bf0145c4 r5:ede82fe8 r4:ede83058 r3: [] (__rpm_callback) from [] (rpm_callback+0x78/0x90) r6: r5:0008 r4:ede82fe8 r3:0004 [] (rpm_callback) from [] (rpm_suspend+0x28c/0x4a8) r5:0008 r4:ede82fe8 [] (rpm_suspend) from [] (__pm_runtime_suspend+0x40/0x8c) r10: r9: r8:eedd7400 r7:6113 r6:0008 r5:ede83058 r4:ede82fe8 [] (__pm_runtime_suspend) from [] (usb_runtime_idle+0x34/0x3c [usbcore]) r7:0002 r6:bf014660 r5:ede82fe8 r4:ede82fe8 [] (usb_runtime_idle [usbcore]) from [] (__rpm_callback+0x44/0x6c) r4:ede83058 r3: [] (__rpm_callback) from [] (rpm_idle+0x148/0x2ec) r6:eedd3240 r5: r4:ede82fe8 r3:bf01d80c [] (rpm_idle) from [] (pm_runtime_work+0x70/0x9c) r8:eedd7400 r7:c06e6100 r6:eedd3240 r5:ede83058 r4:ede830b4 r3: [] (pm_runtime_work) from [] (process_one_work+0x250/0x428) r5:ede830b4 r4:ee0aa500 [] (process_one_work) from [] (worker_thread+0x2d0/0x424) r10: r9:ee0aa518 r8:eedd3260 r7:c06e6100 r6:eedd3240 r5:eedd3240 r4:ee0aa500 [] (worker_thread) from [] (kthread+0xf8/0x10c) r10: r9: r8: r7:c003c68c r6:ee0aa500 r5: r4:ee0bcc00 [] (kthread) from [] (ret_from_fork+0x14/0x3c) r7: r6: r5:c00411b8 r4:ee0bcc00 Code: e5930028 e5942114 e152 0a08 (e8930005) bus: 'usb': registered bus: 'usb': add driver usbfs usbcore: registered new interface driver usbfs bus: 'usb': add driver hub usbcore: registered new interface driver hub bus: 'usb': add driver usb usbcore: registered new device driver usb ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver bus: 'platform': add driver Platform-ehci bus: 'platform': driver_probe_device: matched device fc1f.ehci with driver Platform-ehci bus: 'platform': really_probe: probing driver Platform-ehci with device fc1f.ehci [USB] 2015-04-16v2 pdev : fc1f.ehci Platform-ehci fc1f.ehci: Platform EHCI Platform-ehci fc1f.ehci: new USB bus registered, assigned bus number 1 Platform-ehci fc1f.ehci: irq 10, io mem 0xfc1f mapped f023e000 Platform-ehci fc1f.ehci: USB 2.0 started, EHCI 1.00, overcurrent ignored usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: Platform EHCI usb usb1: Manufacturer: Linux 4.1.10+ ehci_hcd usb usb1: SerialNumber: Platfor
Re: usb: musb: tx fifo flush warning
Hi John, On Thu, Mar 03, 2016 at 03:38:10PM +0100, John Ogness wrote: > Hi Bin, > > Using next-20160302 I can very reliably hit this warning on an AM335x > BeagleBone by playing a short audio file over USB-Audio: > > $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE > /usr/share/sounds/alsa/Front_Center.wav > > $ aplay -l > List of PLAYBACK Hardware Devices > card 1: Audio [USB Audio], device 0: USB Audio [USB Audio] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > The audio file is part of the alsa-utils package. The USB-Audio device > is never disconnected. Simply playing the file triggers the warning. Any > hints/suggestions how I should debug this? In general, it seems this tx fifo flush error has been there for years, it happens when tearing down an active endpoint in some unknown conditions. But I haven't seen a such case in which musb stops working. In this case, does musb still work or is audio playback broken after the warning message? Does the issue happen in any previous kernel? Trying to think if there is any regression in next-20160302... Regards, -Bin. > > Here is the dmesg output: > > [ cut here ] > WARNING: CPU: 0 PID: 0 at /linux/drivers/usb/musb/musb_host.c:139 > musb_h_tx_flush_fifo+0xd4/0xf8 [musb_hdrc] > musb-hdrc musb-hdrc.1.auto: Could not flush host TX10 fifo: csr: 2403 > Modules linked in: musb_am335x musb_dsps musb_hdrc snd_usb_audio snd_hwdep > snd_usbmidi_lib snd_rawmidi > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-next-20160302 #75 > Hardware name: Generic AM33XX (Flattened Device Tree) > Backtrace: > [] (dump_backtrace) from [] (show_stack+0x18/0x1c) > r6: r5: r4:60010193 r3: > [] (show_stack) from [] (dump_stack+0x94/0xb4) > [] (dump_stack) from [] (__warn+0xd8/0x104) > r6:bf050428 r5: r4:c0c01a98 r3: > [] (__warn) from [] (warn_slowpath_fmt+0x40/0x48) > r10:ca08a010 r8:ca08ab80 r7:bf0510cc r6:d104cc10 r5:bf050ef0 r4:2403 > [] (warn_slowpath_fmt) from [] > (musb_h_tx_flush_fifo+0xd4/0xf8 [musb_hdrc]) > r3:bf04f9ac r2:bf050460 > [] (musb_h_tx_flush_fifo [musb_hdrc]) from [] > (musb_cleanup_urb+0xc8/0x144 [musb_hdrc]) > r10:d104cc10 r9:bf0510cc r8: r7: r6:ca0896d4 r5:cf4d8f00 > r4:ca08ab80 > [] (musb_cleanup_urb [musb_hdrc]) from [] > (musb_urb_dequeue+0xf4/0x12c [musb_hdrc]) > r10:8200 r9:0001 r8:a0010193 r7: r6:ca08a010 r5:ca080f80 > r4:cf4d8f00 > [] (musb_urb_dequeue [musb_hdrc]) from [] > (unlink1+0x34/0x118) > r10:13e8 r9:2e6c r8:ca0873ec r7:ff98 r6:cf6ff000 r5:cf4d8f00 > r4:cf4d8f00 r3:bf0487f8 > [] (unlink1) from [] (usb_hcd_unlink_urb+0x58/0x8c) > r8:ca0873ec r7:ff98 r6:a0010193 r5:cf545000 r4:cf4d8f00 r3:cf545000 > [] (usb_hcd_unlink_urb) from [] (usb_unlink_urb+0x34/0x50) > r7:ca086000 r6:ca0873f0 r5:ca086000 r4: > [] (usb_unlink_urb) from [] (deactivate_urbs+0xd4/0xf4 > [snd_usb_audio]) > [] (deactivate_urbs [snd_usb_audio]) from [] > (snd_usb_endpoint_stop+0x38/0x70 [snd_usb_audio]) > r10:5dc0 r8:cf471000 r7: r6: r5: r4:ca086000 > [] (snd_usb_endpoint_stop [snd_usb_audio]) from [] > (stop_endpoints+0x64/0x7c [snd_usb_audio]) > r5:cf4f6674 r4:cf4f6610 > [] (stop_endpoints [snd_usb_audio]) from [] > (snd_usb_substream_playback_trigger+0x9c/0xc0 [snd_usb_audio]) > r6:0001 r5:cf4f6200 r4:cf4f6610 r3:cf4fe000 > [] (snd_usb_substream_playback_trigger [snd_usb_audio]) from > [] (snd_pcm_do_stop+0x5c/0x60) > r4:c0876b34 r3:bf024d94 > [] (snd_pcm_do_stop) from [] > (snd_pcm_action_single+0x40/0x80) > [] (snd_pcm_action_single) from [] > (snd_pcm_drain_done+0x1c/0x24) > r7:cf4f6200 r6:00011940 r5:5dc0 r4:4650 > [] (snd_pcm_drain_done) from [] > (snd_pcm_update_state+0xd8/0x108) > [] (snd_pcm_update_state) from [] > (snd_pcm_update_hw_ptr0+0x1bc/0x3d8) > r5:00011940 r4:cf4fe000 > [] (snd_pcm_update_hw_ptr0) from [] > (snd_pcm_period_elapsed+0x7c/0xbc) > r10:03c0 r9:0004 r8:ca086000 r7:0120 r6:60010193 r5:cf4fe000 > r4:cf4f6200 > [] (snd_pcm_period_elapsed) from [] > (prepare_playback_urb+0x2ac/0x578 [snd_usb_audio]) > r6:cf5ad900 r5:cf5ad940 r4:cf4f6610 r3: > [] (prepare_playback_urb [snd_usb_audio]) from [] > (prepare_outbound_urb+0x4c/0x224 [snd_usb_audio]) > r10:c0c82800 r9: r8:bf02420c r7:ca086000 r6:cf5ad900 r5:ca0861e8 > r4:ca086000 > [] (prepare_outbound_urb [snd_usb_audio]) from [] > (snd_complete_urb+0x108/0x26c [snd_usb_audio]) > r10:c0c82800 r9: r8:cf6ff0dc r7: r6:cf5ad900 r5:ca0861e8 > r4:ca086000 > [] (snd_complete_urb [snd_usb_audio]) from [] > (__usb_hcd_giveback_urb+0x74/0x110) > r7: r6: r5:60010113 r4:cf5ad900 > [] (__usb_hcd_giveback_urb) from [] > (usb_giveback_urb_bh+0xa4/0xf4 > r7:cf6ff0e0 r6:cf6ff0e4 r5: r4:c0c01e18 > [] (usb_giveback_urb_bh) from [] > (tasklet_hi_action+0x8c/0x138) > r8:c0b64348 r7:c0c02b14 r6: r5:cf6ff0f0 r4:cf6ff0ec >
Re: [PATCH 2/3] usb: chipidea: host: let the hcd know's parent device node
On Thu, Mar 03, 2016 at 06:01:15PM +0800, Peter Chen wrote: > From: Peter Chen > > Since the hcd (chipidea core device) has no device node, so > if we want to describe the child node under the hcd, we had > to put it under its parent's node (glue layer device), and > in the code, we need to let the hcd knows glue layer's code, > then the USB core can handle this node. > > Signed-off-by: Peter Chen > --- > drivers/usb/chipidea/host.c | 18 ++ > 1 file changed, 14 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c > index 053bac9..55120ef 100644 > --- a/drivers/usb/chipidea/host.c > +++ b/drivers/usb/chipidea/host.c > @@ -109,15 +109,25 @@ static int host_start(struct ci_hdrc *ci) > struct ehci_hcd *ehci; > struct ehci_ci_priv *priv; > int ret; > + struct device *dev = ci->dev; > > - if (usb_disabled()) > + if (usb_disabled() || !dev) > return -ENODEV; > > - hcd = usb_create_hcd(&ci_ehci_hc_driver, ci->dev, dev_name(ci->dev)); > + /* > + * USB Core will try to get child node under roothub, > + * but chipidea core has no of_node, and the child node > + * for controller is located at glue layer's node which > + * is chipidea core's parent. > + */ > + if (dev->parent && dev->parent->of_node) > + dev->of_node = dev->parent->of_node; Is this a good idea? Two devices with the same of_node? I know the networking code assumes of_node values are unique, and uses it to find a device. Are you 100% sure the USB code does not make this assumption. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb: musb: tx fifo flush warning
Hi Bin, Using next-20160302 I can very reliably hit this warning on an AM335x BeagleBone by playing a short audio file over USB-Audio: $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE /usr/share/sounds/alsa/Front_Center.wav $ aplay -l List of PLAYBACK Hardware Devices card 1: Audio [USB Audio], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 The audio file is part of the alsa-utils package. The USB-Audio device is never disconnected. Simply playing the file triggers the warning. Any hints/suggestions how I should debug this? Here is the dmesg output: [ cut here ] WARNING: CPU: 0 PID: 0 at /linux/drivers/usb/musb/musb_host.c:139 musb_h_tx_flush_fifo+0xd4/0xf8 [musb_hdrc] musb-hdrc musb-hdrc.1.auto: Could not flush host TX10 fifo: csr: 2403 Modules linked in: musb_am335x musb_dsps musb_hdrc snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-next-20160302 #75 Hardware name: Generic AM33XX (Flattened Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6: r5: r4:60010193 r3: [] (show_stack) from [] (dump_stack+0x94/0xb4) [] (dump_stack) from [] (__warn+0xd8/0x104) r6:bf050428 r5: r4:c0c01a98 r3: [] (__warn) from [] (warn_slowpath_fmt+0x40/0x48) r10:ca08a010 r8:ca08ab80 r7:bf0510cc r6:d104cc10 r5:bf050ef0 r4:2403 [] (warn_slowpath_fmt) from [] (musb_h_tx_flush_fifo+0xd4/0xf8 [musb_hdrc]) r3:bf04f9ac r2:bf050460 [] (musb_h_tx_flush_fifo [musb_hdrc]) from [] (musb_cleanup_urb+0xc8/0x144 [musb_hdrc]) r10:d104cc10 r9:bf0510cc r8: r7: r6:ca0896d4 r5:cf4d8f00 r4:ca08ab80 [] (musb_cleanup_urb [musb_hdrc]) from [] (musb_urb_dequeue+0xf4/0x12c [musb_hdrc]) r10:8200 r9:0001 r8:a0010193 r7: r6:ca08a010 r5:ca080f80 r4:cf4d8f00 [] (musb_urb_dequeue [musb_hdrc]) from [] (unlink1+0x34/0x118) r10:13e8 r9:2e6c r8:ca0873ec r7:ff98 r6:cf6ff000 r5:cf4d8f00 r4:cf4d8f00 r3:bf0487f8 [] (unlink1) from [] (usb_hcd_unlink_urb+0x58/0x8c) r8:ca0873ec r7:ff98 r6:a0010193 r5:cf545000 r4:cf4d8f00 r3:cf545000 [] (usb_hcd_unlink_urb) from [] (usb_unlink_urb+0x34/0x50) r7:ca086000 r6:ca0873f0 r5:ca086000 r4: [] (usb_unlink_urb) from [] (deactivate_urbs+0xd4/0xf4 [snd_usb_audio]) [] (deactivate_urbs [snd_usb_audio]) from [] (snd_usb_endpoint_stop+0x38/0x70 [snd_usb_audio]) r10:5dc0 r8:cf471000 r7: r6: r5: r4:ca086000 [] (snd_usb_endpoint_stop [snd_usb_audio]) from [] (stop_endpoints+0x64/0x7c [snd_usb_audio]) r5:cf4f6674 r4:cf4f6610 [] (stop_endpoints [snd_usb_audio]) from [] (snd_usb_substream_playback_trigger+0x9c/0xc0 [snd_usb_audio]) r6:0001 r5:cf4f6200 r4:cf4f6610 r3:cf4fe000 [] (snd_usb_substream_playback_trigger [snd_usb_audio]) from [] (snd_pcm_do_stop+0x5c/0x60) r4:c0876b34 r3:bf024d94 [] (snd_pcm_do_stop) from [] (snd_pcm_action_single+0x40/0x80) [] (snd_pcm_action_single) from [] (snd_pcm_drain_done+0x1c/0x24) r7:cf4f6200 r6:00011940 r5:5dc0 r4:4650 [] (snd_pcm_drain_done) from [] (snd_pcm_update_state+0xd8/0x108) [] (snd_pcm_update_state) from [] (snd_pcm_update_hw_ptr0+0x1bc/0x3d8) r5:00011940 r4:cf4fe000 [] (snd_pcm_update_hw_ptr0) from [] (snd_pcm_period_elapsed+0x7c/0xbc) r10:03c0 r9:0004 r8:ca086000 r7:0120 r6:60010193 r5:cf4fe000 r4:cf4f6200 [] (snd_pcm_period_elapsed) from [] (prepare_playback_urb+0x2ac/0x578 [snd_usb_audio]) r6:cf5ad900 r5:cf5ad940 r4:cf4f6610 r3: [] (prepare_playback_urb [snd_usb_audio]) from [] (prepare_outbound_urb+0x4c/0x224 [snd_usb_audio]) r10:c0c82800 r9: r8:bf02420c r7:ca086000 r6:cf5ad900 r5:ca0861e8 r4:ca086000 [] (prepare_outbound_urb [snd_usb_audio]) from [] (snd_complete_urb+0x108/0x26c [snd_usb_audio]) r10:c0c82800 r9: r8:cf6ff0dc r7: r6:cf5ad900 r5:ca0861e8 r4:ca086000 [] (snd_complete_urb [snd_usb_audio]) from [] (__usb_hcd_giveback_urb+0x74/0x110) r7: r6: r5:60010113 r4:cf5ad900 [] (__usb_hcd_giveback_urb) from [] (usb_giveback_urb_bh+0xa4/0xf4 r7:cf6ff0e0 r6:cf6ff0e4 r5: r4:c0c01e18 [] (usb_giveback_urb_bh) from [] (tasklet_hi_action+0x8c/0x138) r8:c0b64348 r7:c0c02b14 r6: r5:cf6ff0f0 r4:cf6ff0ec [] (tasklet_hi_action) from [] (__do_softirq+0xec/0x240) r10:c0c02080 r9: r8:0100 r7:c0c02080 r6: r5:c0c02080 r4: r3:c01390d4 [] (__do_softirq) from [] (irq_exit+0xa8/0x120) r10:cf004000 r9:c0c029e0 r8:0044 r7: r6: r5:c0b6756c r4:c0c02b14 [] (irq_exit) from [] (__handle_domain_irq+0x78/0xe4) r4:c0c02b14 r3:c017a968 [] (__handle_domain_irq) from [] (omap_intc_handle_irq+0x38/0x98) r10:c0c029d8 r8:c0b68638 r7:c0c01f4c r6: r5:60010013 r4:c0cb00c0 [] (omap_intc_handle_irq) from [] (__irq_svc+0x54/0x70) Exception stack(0xc0c01f18 to 0xc0c01f60) 1f00: 0001 1f20: c0c01f78 c011
Re: [PATCH] asix: do not free array priv->mdio->irq
On Thu, Mar 03, 2016 at 01:27:56PM +, Colin King wrote:
> From: Colin Ian King
>
> Used to be allocated and required freeing, but now
> priv->mdio->irq is now a fixed sized array and should no longer be
> free'd.
>
> Issue detected using static analysis with CoverityScan
>
> Fixes: e7f4dc3536a400 ("mdio: Move allocation of interrupts into core")
> Signed-off-by: Colin Ian King
Reviewed-by: Andrew Lunn
Thanks
Andrew
> ---
> drivers/net/usb/ax88172a.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/usb/ax88172a.c b/drivers/net/usb/ax88172a.c
> index 224e7d8..cf77f2d 100644
> --- a/drivers/net/usb/ax88172a.c
> +++ b/drivers/net/usb/ax88172a.c
> @@ -134,7 +134,6 @@ static void ax88172a_remove_mdio(struct usbnet *dev)
>
> netdev_info(dev->net, "deregistering mdio bus %s\n", priv->mdio->id);
> mdiobus_unregister(priv->mdio);
> - kfree(priv->mdio->irq);
> mdiobus_free(priv->mdio);
> }
>
> --
> 2.7.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] asix: do not free array priv->mdio->irq
From: Colin Ian King
Used to be allocated and required freeing, but now
priv->mdio->irq is now a fixed sized array and should no longer be
free'd.
Issue detected using static analysis with CoverityScan
Fixes: e7f4dc3536a400 ("mdio: Move allocation of interrupts into core")
Signed-off-by: Colin Ian King
---
drivers/net/usb/ax88172a.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/usb/ax88172a.c b/drivers/net/usb/ax88172a.c
index 224e7d8..cf77f2d 100644
--- a/drivers/net/usb/ax88172a.c
+++ b/drivers/net/usb/ax88172a.c
@@ -134,7 +134,6 @@ static void ax88172a_remove_mdio(struct usbnet *dev)
netdev_info(dev->net, "deregistering mdio bus %s\n", priv->mdio->id);
mdiobus_unregister(priv->mdio);
- kfree(priv->mdio->irq);
mdiobus_free(priv->mdio);
}
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] Re: [RFC 09/15] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 21:40:23 Krzysztof Kozlowski wrote: > >> select MFD_SYSCON > >> diff --git a/drivers/media/platform/exynos4-is/Kconfig > >> b/drivers/media/platform/exynos4-is/Kconfig > >> index 57d42c6172c5..c4317b99d257 100644 > >> --- a/drivers/media/platform/exynos4-is/Kconfig > >> +++ b/drivers/media/platform/exynos4-is/Kconfig > >> @@ -17,6 +17,7 @@ config VIDEO_S5P_FIMC > >> tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver" > >> depends on I2C > >> depends on HAS_DMA > >> + depends on HAS_IOMEM# For MFD_SYSCON > >> select VIDEOBUF2_DMA_CONTIG > >> select V4L2_MEM2MEM_DEV > > > > This is guarded by HAS_DMA, which implies HAS_IOMEM afaik. > > Looking at Kconfigs - no, it is not implied (or am I missing > something)... and sometimes dependency on HAS_IOMEM is next to > HAS_DMA. > > Ah, you are right: UML has no DMA and no IOMEM, but s390 can have IOMEM (if PCI is enabled) and always sets HAS_DMA. In practice, I think the HAS_DMA symbol is not as well-defined as it should be, it basically refers to the presence of the dma-mapping.h API, and that only really makes sense when you also have IOMEM, so there might be an implied dependency between the two, but it's not enforced or actually true. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb mouse quirks
Paolo Minazzi writes:
> [ text/plain ]
> Dear all,
> I have 3 wired usb optical mouse
> [1] Logitech 0x046D:0xC077
> [2] Logitech 0x046D:0xC05A
> [3] Microsoft 0x045E:0x0737
>
> I always used 3.10 kernel and all mice have the problem of
> disconnection after 62 seconds.
> I got the latest kernel 4.5-rc3 and I have discovered about quirks and
> HID_QUIRK_ALWAYS_POLL.
>
> Looking at the kernel 4.5-rc3 ...
>
> For [1] Logitech 0x046D:0xC077
> there is already a line in quirks
> { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077, HID_QUIRK_ALWAYS_POLL }
> but the #define seems broken:
> #define USB_DEVICE_ID_LOGITECH_C077 0xc007
yeah, seems like that needs patching.
> Someone can confirm ?
>
> For [2] Logitech 0x046D:0xC05A all seems already ok. Quirk is already present.
>
> For [3] Microsoft 0x045E:0x0737 the support for HID_QUIRK_ALWAYS_POLL
> seems missing.
>
> The final patch should be (against 4.5-rc3) should be
>
> =
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index b6ff6e7..d788de2 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -600,7 +600,7 @@
> #define USB_VENDOR_ID_LOGITECH 0x046d
> #define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e
> #define USB_DEVICE_ID_LOGITECH_T6510xb00c
> -#define USB_DEVICE_ID_LOGITECH_C0770xc007
> +#define USB_DEVICE_ID_LOGITECH_C0770xc077
> #define USB_DEVICE_ID_LOGITECH_RECEIVER0xc101
> #define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110
> #define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f
> @@ -670,6 +670,7 @@
>
> #define USB_VENDOR_ID_MICROSOFT0x045e
> #define USB_DEVICE_ID_SIDEWINDER_GV0x003b
> +#define USB_DEVICE_ID_MS_MOUSE_500 0x0737
> #define USB_DEVICE_ID_MS_OFFICE_KB 0x0048
> #define USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0 0x009d
> #define USB_DEVICE_ID_MS_NE4K 0x00db
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 7dd0953..09c8bed 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -93,6 +93,7 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER,
> HID_QUIRK_NO_INIT_REPORTS },
> + { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_MOUSE_500,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
> HID_QUIRK_NO_INIT_REPORTS },
> =
patch looks okay to me, but you need to send it as a proper patch. Have
a look at Documentation/SubmittingPatches and that should answer all
your questions.
cheers
--
balbi
signature.asc
Description: PGP signature
Re: [RFC 08/15] rtc: at91sam9: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 13:27:59 Geert Uytterhoeven wrote: > On Thu, Mar 3, 2016 at 11:55 AM, Arnd Bergmann wrote: > > On Thursday 03 March 2016 17:03:34 Krzysztof Kozlowski wrote: > >> index 0da40e2e4280..5c530b6b125d 100644 > >> --- a/drivers/rtc/Kconfig > >> +++ b/drivers/rtc/Kconfig > >> @@ -1302,6 +1302,7 @@ config RTC_DRV_AT91RM9200 > >> config RTC_DRV_AT91SAM9 > >> tristate "AT91SAM9 RTT as RTC" > >> depends on ARCH_AT91 || COMPILE_TEST > >> + depends on HAS_IOMEM# For MFD_SYSCON > >> select MFD_SYSCON > >> help > >> Some AT91SAM9 SoCs provide an RTT (Real Time Timer) block which > >> > > > > This is technically correct, but the entire RTC menu is hidden > > inside of 'depends on !UML && !S390', so we won't ever get there > > on any configuration that does not use HAS_IOMEM. > > > > If we did, all other RTC drivers would also fail. > > So UML has no RTC. Should/can it use RTC_DRV_GENERIC? I think nothing should use that, even if it could ;-) Funny enough, RTC_DRV_GENERIC would probably actually work if you run UML as root and set iopl() to allow port access, but we don't really want it to mess with the host RTC. I don't know where UML gets it real time, but it doesn't actually need much other than calling clock_gettime(CLOCK_REALTIME, ...) to get the host time. Presumably it uses some variation of that. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb mouse quirks
Dear all,
I have 3 wired usb optical mouse
[1] Logitech 0x046D:0xC077
[2] Logitech 0x046D:0xC05A
[3] Microsoft 0x045E:0x0737
I always used 3.10 kernel and all mice have the problem of
disconnection after 62 seconds.
I got the latest kernel 4.5-rc3 and I have discovered about quirks and
HID_QUIRK_ALWAYS_POLL.
Looking at the kernel 4.5-rc3 ...
For [1] Logitech 0x046D:0xC077
there is already a line in quirks
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077, HID_QUIRK_ALWAYS_POLL }
but the #define seems broken:
#define USB_DEVICE_ID_LOGITECH_C077 0xc007
Someone can confirm ?
For [2] Logitech 0x046D:0xC05A all seems already ok. Quirk is already present.
For [3] Microsoft 0x045E:0x0737 the support for HID_QUIRK_ALWAYS_POLL
seems missing.
The final patch should be (against 4.5-rc3) should be
=
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b6ff6e7..d788de2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -600,7 +600,7 @@
#define USB_VENDOR_ID_LOGITECH 0x046d
#define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e
#define USB_DEVICE_ID_LOGITECH_T6510xb00c
-#define USB_DEVICE_ID_LOGITECH_C0770xc007
+#define USB_DEVICE_ID_LOGITECH_C0770xc077
#define USB_DEVICE_ID_LOGITECH_RECEIVER0xc101
#define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110
#define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f
@@ -670,6 +670,7 @@
#define USB_VENDOR_ID_MICROSOFT0x045e
#define USB_DEVICE_ID_SIDEWINDER_GV0x003b
+#define USB_DEVICE_ID_MS_MOUSE_500 0x0737
#define USB_DEVICE_ID_MS_OFFICE_KB 0x0048
#define USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0 0x009d
#define USB_DEVICE_ID_MS_NE4K 0x00db
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 7dd0953..09c8bed 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -93,6 +93,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_MOUSE_500,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
=
Regards,
Paolo Minazzi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [RFC 06/15] pinctrl: rockchip: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 17:03 GMT+09:00 Krzysztof Kozlowski : > The MFD_SYSCON depends on HAS_IOMEM so when selecting it avoid unmet > direct dependencies. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/pinctrl/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig > index fb8200b8e8ec..dc7ab58d4d74 100644 > --- a/drivers/pinctrl/Kconfig > +++ b/drivers/pinctrl/Kconfig > @@ -131,6 +131,7 @@ config PINCTRL_MESON > > config PINCTRL_ROCKCHIP > bool > + depends on HAS_IOMEM# For MFD_SYSCON > select PINMUX False alarm, no need for the patch (non-selectable symbol) Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [RFC 07/15] pinctrl: mvebu: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 17:03 GMT+09:00 Krzysztof Kozlowski : > The MFD_SYSCON depends on HAS_IOMEM so when selecting it avoid unmet > direct dependencies. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/pinctrl/mvebu/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig > index 170602407c0d..13685923729c 100644 > --- a/drivers/pinctrl/mvebu/Kconfig > +++ b/drivers/pinctrl/mvebu/Kconfig > @@ -7,6 +7,7 @@ config PINCTRL_MVEBU > > config PINCTRL_DOVE > bool > + depends on HAS_IOMEM# For MFD_SYSCON > select PINCTRL_MVEBU > select MFD_SYSCON False alarm, no need for the patch (non-selectable symbol) Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [RFC 12/15] soc: qcom: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 17:03 GMT+09:00 Krzysztof Kozlowski : > The MFD_SYSCON depends on HAS_IOMEM so when selecting it avoid unmet > direct dependencies. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/soc/qcom/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > index 461b387d03cc..24de48134c15 100644 > --- a/drivers/soc/qcom/Kconfig > +++ b/drivers/soc/qcom/Kconfig > @@ -4,6 +4,7 @@ > config QCOM_GSBI > tristate "QCOM General Serial Bus Interface" > depends on ARCH_QCOM > +depends on HAS_IOMEM # For MFD_SYSCON > select MFD_SYSCON False alarm, no need for the patch (this depends on ARCH_QCOM). Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [RFC 13/15] staging: media: omap4iss: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 17:03 GMT+09:00 Krzysztof Kozlowski : > The MFD_SYSCON depends on HAS_IOMEM so when selecting it avoid unmet > direct dependencies. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/staging/media/omap4iss/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/media/omap4iss/Kconfig > b/drivers/staging/media/omap4iss/Kconfig > index 46183464ee79..7dea072172aa 100644 > --- a/drivers/staging/media/omap4iss/Kconfig > +++ b/drivers/staging/media/omap4iss/Kconfig > @@ -2,6 +2,7 @@ config VIDEO_OMAP4 > tristate "OMAP 4 Camera support" > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 > depends on HAS_DMA > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > select VIDEOBUF2_DMA_CONTIG > ---help--- False alarm, no need for the patch (this depends on ARCH_OMAP4). Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] Re: [RFC 09/15] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 19:57 GMT+09:00 Arnd Bergmann : > On Thursday 03 March 2016 17:03:35 Krzysztof Kozlowski wrote: >> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig >> index 201f5c296a95..e5931e434fa2 100644 >> --- a/drivers/media/platform/Kconfig >> +++ b/drivers/media/platform/Kconfig >> @@ -79,6 +79,7 @@ config VIDEO_OMAP3 >> depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3 >> depends on HAS_DMA && OF >> depends on OMAP_IOMMU >> + depends on HAS_IOMEM# For MFD_SYSCON >> select ARM_DMA_USE_IOMMU >> select VIDEOBUF2_DMA_CONTIG > > This is only built for OMAP3, so we won't get here without HAS_IOMEM Indeed. > >> select MFD_SYSCON >> diff --git a/drivers/media/platform/exynos4-is/Kconfig >> b/drivers/media/platform/exynos4-is/Kconfig >> index 57d42c6172c5..c4317b99d257 100644 >> --- a/drivers/media/platform/exynos4-is/Kconfig >> +++ b/drivers/media/platform/exynos4-is/Kconfig >> @@ -17,6 +17,7 @@ config VIDEO_S5P_FIMC >> tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver" >> depends on I2C >> depends on HAS_DMA >> + depends on HAS_IOMEM# For MFD_SYSCON >> select VIDEOBUF2_DMA_CONTIG >> select V4L2_MEM2MEM_DEV > > This is guarded by HAS_DMA, which implies HAS_IOMEM afaik. Looking at Kconfigs - no, it is not implied (or am I missing something)... and sometimes dependency on HAS_IOMEM is next to HAS_DMA. BR, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] Re: [RFC 11/15] power: reset: keystone: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 21:33 GMT+09:00 Sebastian Reichel : > Hi, > > On Thu, Mar 03, 2016 at 12:00:14PM +0100, Arnd Bergmann wrote: >> On Thursday 03 March 2016 17:03:37 Krzysztof Kozlowski wrote: >> > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig >> > index 0a6408a39c66..0f34846ae80d 100644 >> > --- a/drivers/power/reset/Kconfig >> > +++ b/drivers/power/reset/Kconfig >> > @@ -141,6 +141,7 @@ config POWER_RESET_XGENE >> > config POWER_RESET_KEYSTONE >> > bool "Keystone reset driver" >> > depends on ARCH_KEYSTONE >> > + depends on HAS_IOMEM# For MFD_SYSCON >> > select MFD_SYSCON >> > help >> > Reboot support for the KEYSTONE SoCs. >> > >> >> This is platform specific, but we should probably add || COMPILE_TEST >> along with the HAS_IOMEM dependency. > > Sounds sensible. Will you guys send an updated patch? > Sure, I'll make some compile tests and send a v2. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] Re: [RFC 04/15] irqchip: st: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 21:28 GMT+09:00 Arnd Bergmann : > On Thursday 03 March 2016 21:00:57 Krzysztof Kozlowski wrote: >> > >> > Not user visible. >> >> Hmmm... you are right (here and in other patches) but why am I getting >> all these errors: >> warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X >> && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && >> TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && >> S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && >> RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM >> && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which >> has unmet direct dependencies (HAS_IOMEM) >> ? >> (ARCH=um, allyesconfig) > > The problem is that Kconfig will just print any option that > selects the one that has a missing dependency, but doesn't > show which of those are actually enabled. Indeed... but apparently putting direct HAS_IOMEM dependency on these symbols silences the Kconfig warning. >> Adding depends here (and in other places) really helps... but it >> should not have any impact... > > I think patch 5 by itself would have been sufficient. Thanks for analysis. Since all patches are independent (and IMHO the last one is not needed really) so I won't resend the patchset. Instead let maintainer pick what is meaningful. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 11/15] power: reset: keystone: Add missing MFD_SYSCON dependency on HAS_IOMEM
Hi, On Thu, Mar 03, 2016 at 12:00:14PM +0100, Arnd Bergmann wrote: > On Thursday 03 March 2016 17:03:37 Krzysztof Kozlowski wrote: > > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig > > index 0a6408a39c66..0f34846ae80d 100644 > > --- a/drivers/power/reset/Kconfig > > +++ b/drivers/power/reset/Kconfig > > @@ -141,6 +141,7 @@ config POWER_RESET_XGENE > > config POWER_RESET_KEYSTONE > > bool "Keystone reset driver" > > depends on ARCH_KEYSTONE > > + depends on HAS_IOMEM# For MFD_SYSCON > > select MFD_SYSCON > > help > > Reboot support for the KEYSTONE SoCs. > > > > This is platform specific, but we should probably add || COMPILE_TEST > along with the HAS_IOMEM dependency. Sounds sensible. Will you guys send an updated patch? -- Sebastian signature.asc Description: PGP signature
Re: [rtc-linux] Re: [RFC 04/15] irqchip: st: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 21:00:57 Krzysztof Kozlowski wrote: > > > > Not user visible. > > Hmmm... you are right (here and in other patches) but why am I getting > all these errors: > warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X > && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && > TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && > S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && > RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM > && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which > has unmet direct dependencies (HAS_IOMEM) > ? > (ARCH=um, allyesconfig) The problem is that Kconfig will just print any option that selects the one that has a missing dependency, but doesn't show which of those are actually enabled. > Adding depends here (and in other places) really helps... but it > should not have any impact... I think patch 5 by itself would have been sufficient. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 09/15] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thu, Mar 3, 2016 at 11:57 AM, Arnd Bergmann wrote:
>> --- a/drivers/media/platform/exynos4-is/Kconfig
>> +++ b/drivers/media/platform/exynos4-is/Kconfig
>> @@ -17,6 +17,7 @@ config VIDEO_S5P_FIMC
>> tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver"
>> depends on I2C
>> depends on HAS_DMA
>> + depends on HAS_IOMEM# For MFD_SYSCON
>> select VIDEOBUF2_DMA_CONTIG
>> select V4L2_MEM2MEM_DEV
>
> This is guarded by HAS_DMA, which implies HAS_IOMEM afaik.
No systems around with HV-based DMA?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 08/15] rtc: at91sam9: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thu, Mar 3, 2016 at 11:55 AM, Arnd Bergmann wrote:
> On Thursday 03 March 2016 17:03:34 Krzysztof Kozlowski wrote:
>> index 0da40e2e4280..5c530b6b125d 100644
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -1302,6 +1302,7 @@ config RTC_DRV_AT91RM9200
>> config RTC_DRV_AT91SAM9
>> tristate "AT91SAM9 RTT as RTC"
>> depends on ARCH_AT91 || COMPILE_TEST
>> + depends on HAS_IOMEM# For MFD_SYSCON
>> select MFD_SYSCON
>> help
>> Some AT91SAM9 SoCs provide an RTT (Real Time Timer) block which
>>
>
> This is technically correct, but the entire RTC menu is hidden
> inside of 'depends on !UML && !S390', so we won't ever get there
> on any configuration that does not use HAS_IOMEM.
>
> If we did, all other RTC drivers would also fail.
So UML has no RTC. Should/can it use RTC_DRV_GENERIC?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] Re: [RFC 15/15] mfd: syscon: Fix build of missing ioremap on UM
2016-03-03 19:50 GMT+09:00 Arnd Bergmann :
> On Thursday 03 March 2016 17:03:41 Krzysztof Kozlowski wrote:
>> Since commit c89c0114955a ("mfd: syscon: Set regmap max_register in
>> of_syscon_register") the syscon uses ioremap so it fails on COMPILE_TEST
>> without HAS_IOMEM:
>>
>> drivers/mfd/syscon.c: In function ‘of_syscon_register’:
>> drivers/mfd/syscon.c:67:9: error: implicit declaration of function ‘ioremap’
>> [-Werror=implicit-function-declaration]
>> base = ioremap(res.start, resource_size(&res));
>> ^
>> drivers/mfd/syscon.c:67:7: warning: assignment makes pointer from integer
>> without a cast [-Wint-conversion]
>> base = ioremap(res.start, resource_size(&res));
>>^
>> drivers/mfd/syscon.c:109:2: error: implicit declaration of function
>> ‘iounmap’ [-Werror=implicit-function-declaration]
>> iounmap(base);
>>
>> When selecting MFD_SYSCON, depend on HAS_IOMEM to avoid unmet direct
>> dependencies.
>>
>> Reported-by: kbuild test robot
>> Fixes: c89c0114955a ("mfd: syscon: Set regmap max_register in
>> of_syscon_register")
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>
> Thanks for looking into this, the patches all look right to me, but
> I fear we are forever playing catch-up here, as the number of syscon users
> is only growing, and it's not obvious to the average driver developer
> why they have to select this symbol.
Actually I screwed something because entire MFD menuconfig (including
MFD_SYSCON) is already guarded by if HAS_IOMEM.
I was fixing the problem from the end (the build error) and then hit
these unmet direct dependencies (mentioned this in other mail).
I think this patch 15/15 is not needed.
>
> Interestingly, when I try to build an allmodconfig kernel for UML,
> it seems to reject any driver calling ioremap/iounmap but not
> the wrapper functions around that (of_iomap, devm_ioremap,
> devm_ioremap_resource, ...)
The declaration of devm-like functions is always there. However it
should fail during linking stage (see my other patches like for
thermal, nvram etc. this is still in progress because I did not manage
to build allyesconfig on UML yet).
> or the actual accessors that make no
> sense without ioremap (readl, writel, inb, outb, iowrite32, ...).
>
> I've played with this a bit, and arrived at the patch below, is this
> something we want as well?
>
> Arnd
>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index aa21dc55eb15..2e5b1e525a1d 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -1034,6 +1034,7 @@ config MFD_SUN6I_PRCM
>>
>> config MFD_SYSCON
>> bool "System Controller Register R/W Based on Regmap"
>> + depends on HAS_IOMEM
>> select REGMAP_MMIO
>> help
>> Select this option to enable accessing system control registers
>>
>
>
> arch/um/include/asm/io.h |1 +
> drivers/char/Kconfig |3 +++
> drivers/char/mem.c | 16
> drivers/clocksource/Kconfig|3 +++
> drivers/fmc/Kconfig|1 +
> drivers/fpga/Kconfig |1 +
> drivers/hwtracing/intel_th/Kconfig |1 +
> drivers/mfd/Kconfig|1 +
> drivers/misc/altera-stapl/Kconfig |2 +-
> drivers/mtd/chips/Kconfig |4
> drivers/mtd/lpddr/Kconfig |1 +
> drivers/mtd/maps/Kconfig |3 ++-
> drivers/mtd/nand/Kconfig |2 +-
> drivers/mtd/spi-nor/Kconfig|1 +
> drivers/net/can/Kconfig|1 +
> drivers/net/hamradio/Kconfig |9 ++---
> drivers/nvmem/Kconfig |1 +
> drivers/phy/Kconfig|9 +++--
> drivers/power/reset/Kconfig|4 +++-
> drivers/staging/comedi/Kconfig |6 +-
> drivers/thermal/Kconfig| 11 +--
For some of these I already started fixing:
https://lkml.org/lkml/2016/3/3/147
http://comments.gmane.org/gmane.linux.kernel/2167664
> include/linux/irq.h|2 ++
> include/linux/mtd/cfi.h|2 ++
> include/linux/mtd/map.h|2 ++
> kernel/resource.c |2 ++
> lib/Kconfig|7 ++-
> mm/bootmem.c |4 ++--
> 27 files changed, 85 insertions(+), 15 deletions(-)
>
> diff --git a/arch/um/include/asm/io.h b/arch/um/include/asm/io.h
> new file mode 100644
> index 000..618ff13
> --- /dev/null
> +++ b/arch/um/include/asm/io.h
> @@ -0,0 +1 @@
> +/* no IOPORT or IOMEM suport */
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index a043107..f6dc17a 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -8,6 +8,7 @@ source "drivers/tty/Kconfig"
>
> config DEVMEM
> bool "/dev/mem virtual device support"
> + depends on HAS_IOMEM
> default y
> help
> Say Y here if you want to support the /dev/mem device.
> @@ -17,6 +18,7 @@ config DEVMEM
>
>
Re: [rtc-linux] Re: [RFC 04/15] irqchip: st: Add missing MFD_SYSCON dependency on HAS_IOMEM
2016-03-03 19:53 GMT+09:00 Arnd Bergmann : > On Thursday 03 March 2016 17:03:30 Krzysztof Kozlowski wrote: >> config ST_IRQCHIP >> bool >> select REGMAP >> + depends on HAS_IOMEM# For MFD_SYSCON >> select MFD_SYSCON >> help >> Enables SysCfg Controlled IRQs on STi based platforms. >> > > Not user visible. Hmmm... you are right (here and in other patches) but why am I getting all these errors: warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM) ? (ARCH=um, allyesconfig) Adding depends here (and in other places) really helps... but it should not have any impact... Thanks for comments, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine
Felipe Ferreri Tonello wrote: > On 02/03/16 21:09, Clemens Ladisch wrote: >> Felipe F. Tonello wrote: >>> This refactor results in a cleaner state machine code >> >> It increases the number of states, and now juggles two state variables. >> I cannot agree to it being cleaner. > > Yes, it increases the number of states. That was done in order to > actually implement a proper finite state machine with one state at a > time and a transition state. I know, "clean" is subjective. But in what way was the old state machine not "proper"? And how is handling two states (port->state and next_state) cleaner? As far as I can tell, the requirement for a separate variable comes not from any inherent complexity of the state machine itself, but only because the transmit_packet function was inlined. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver
Hi Lu,
[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.5-rc6 next-20160303]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-add-support-for-Intel-dual-role-port-mux/20160303-144241
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: openrisc-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All warnings (new ones prefixed by >>):
drivers/mfd/intel-vuport.c: In function 'vuport_probe':
>> drivers/mfd/intel-vuport.c:39:17: warning: unused variable 'dev'
drivers/mfd/intel-vuport.c: At top level:
drivers/mfd/intel-vuport.c:59:30: warning: 'vuport_acpi_match' defined but
not used
vim +/dev +39 drivers/mfd/intel-vuport.c
23 { "vbus_en-gpios", &vbus_gpio, 1 },
24 { "usb_mux-gpios", &mux_gpio, 1 },
25 { },
26 };
27
28 static const struct mfd_cell intel_vuport_mfd_cells[] = {
29 {
30 .name = "extcon-usb-gpio",
31 },
32 {
33 .name = "intel-mux-gpio",
34 },
35 };
36
37 static int vuport_probe(struct platform_device *pdev)
38 {
> 39 struct device *dev = &pdev->dev;
40 int ret;
41
42 ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
acpi_usb_gpios);
43 if (ret)
44 return ret;
45
46 return mfd_add_devices(&pdev->dev, 0, intel_vuport_mfd_cells,
47 ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [RFC 14/15] usb: xhci: mtk: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:40 Krzysztof Kozlowski wrote: > index 8c20ebbc049c..f759a778d606 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -45,6 +45,7 @@ config USB_XHCI_PLATFORM > > config USB_XHCI_MTK > tristate "xHCI support for Mediatek MT65xx" > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > depends on ARCH_MEDIATEK || COMPILE_TEST > ---help--- > This already has the dependency, as it depends on XHCD_PLATFORM which depends on HAS_IOMEM. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 11/15] power: reset: keystone: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:37 Krzysztof Kozlowski wrote: > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig > index 0a6408a39c66..0f34846ae80d 100644 > --- a/drivers/power/reset/Kconfig > +++ b/drivers/power/reset/Kconfig > @@ -141,6 +141,7 @@ config POWER_RESET_XGENE > config POWER_RESET_KEYSTONE > bool "Keystone reset driver" > depends on ARCH_KEYSTONE > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > help > Reboot support for the KEYSTONE SoCs. > This is platform specific, but we should probably add || COMPILE_TEST along with the HAS_IOMEM dependency. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/15] net: ethernet: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:36 Krzysztof Kozlowski wrote: > The MFD_SYSCON depends on HAS_IOMEM so when selecting it avoid unmet > direct dependencies. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/net/ethernet/hisilicon/Kconfig | 1 + > drivers/net/ethernet/stmicro/stmmac/Kconfig | 6 ++ > drivers/net/ethernet/ti/Kconfig | 1 + > 3 files changed, 8 insertions(+) > > diff --git a/drivers/net/ethernet/hisilicon/Kconfig > b/drivers/net/ethernet/hisilicon/Kconfig > index 74beb1867230..6a9c91781bf9 100644 > --- a/drivers/net/ethernet/hisilicon/Kconfig > +++ b/drivers/net/ethernet/hisilicon/Kconfig > @@ -26,6 +26,7 @@ config HIX5HD2_GMAC > config HIP04_ETH > tristate "HISILICON P04 Ethernet support" > select MARVELL_PHY > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > select HNS_MDIO > ---help--- Geert added a HAS_DMA dependency in linux-next, which takes care of this, although it's still technically correct as well. > diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig > b/drivers/net/ethernet/stmicro/stmmac/Kconfig > index cec147d1d34f..d6902bf6e90f 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig > +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig > @@ -16,6 +16,7 @@ if STMMAC_ETH > config STMMAC_PLATFORM > tristate "STMMAC Platform bus support" > depends on STMMAC_ETH > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > default y > ---help--- NET_VENDOR_STMICRO depends on HAS_IOMEM, so we are good here for the entire directory. > diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig > index e7f0b7d95b65..ec56cebe929d 100644 > --- a/drivers/net/ethernet/ti/Kconfig > +++ b/drivers/net/ethernet/ti/Kconfig > @@ -62,6 +62,7 @@ config TI_CPSW_ALE > config TI_CPSW > tristate "TI CPSW Switch Support" > depends on ARCH_DAVINCI || ARCH_OMAP2PLUS > + depends on HAS_IOMEM# For MFD_SYSCON > select TI_DAVINCI_CPDMA > select TI_DAVINCI_MDIO > select TI_CPSW_PHY_SEL > This again is platform specific, so the chagnge is not needed. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 09/15] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:35 Krzysztof Kozlowski wrote: > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 201f5c296a95..e5931e434fa2 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -79,6 +79,7 @@ config VIDEO_OMAP3 > depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3 > depends on HAS_DMA && OF > depends on OMAP_IOMMU > + depends on HAS_IOMEM# For MFD_SYSCON > select ARM_DMA_USE_IOMMU > select VIDEOBUF2_DMA_CONTIG This is only built for OMAP3, so we won't get here without HAS_IOMEM > select MFD_SYSCON > diff --git a/drivers/media/platform/exynos4-is/Kconfig > b/drivers/media/platform/exynos4-is/Kconfig > index 57d42c6172c5..c4317b99d257 100644 > --- a/drivers/media/platform/exynos4-is/Kconfig > +++ b/drivers/media/platform/exynos4-is/Kconfig > @@ -17,6 +17,7 @@ config VIDEO_S5P_FIMC > tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver" > depends on I2C > depends on HAS_DMA > + depends on HAS_IOMEM# For MFD_SYSCON > select VIDEOBUF2_DMA_CONTIG > select V4L2_MEM2MEM_DEV This is guarded by HAS_DMA, which implies HAS_IOMEM afaik. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 05/15] phy: hi6220: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:31 Krzysztof Kozlowski wrote: > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -225,6 +225,7 @@ config PHY_MT65XX_USB3 > config PHY_HI6220_USB > tristate "hi6220 USB PHY support" > depends on (ARCH_HISI && ARM64) || COMPILE_TEST > + depends on HAS_IOMEM# For MFD_SYSCON > select GENERIC_PHY > select MFD_SYSCON > help > -- > 2.5.0 > This is indeed required, and seems to be what caused the problem you saw in the first place. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 08/15] rtc: at91sam9: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:34 Krzysztof Kozlowski wrote: > index 0da40e2e4280..5c530b6b125d 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -1302,6 +1302,7 @@ config RTC_DRV_AT91RM9200 > config RTC_DRV_AT91SAM9 > tristate "AT91SAM9 RTT as RTC" > depends on ARCH_AT91 || COMPILE_TEST > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > help > Some AT91SAM9 SoCs provide an RTT (Real Time Timer) block which > This is technically correct, but the entire RTC menu is hidden inside of 'depends on !UML && !S390', so we won't ever get there on any configuration that does not use HAS_IOMEM. If we did, all other RTC drivers would also fail. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 04/15] irqchip: st: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:30 Krzysztof Kozlowski wrote: > config ST_IRQCHIP > bool > select REGMAP > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > help > Enables SysCfg Controlled IRQs on STi based platforms. > Not user visible. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/15] clocksource: atmel: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:27 Krzysztof Kozlowski wrote: > > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > index c346be650892..5927944b46e0 100644 > --- a/drivers/clocksource/Kconfig > +++ b/drivers/clocksource/Kconfig > @@ -239,6 +239,7 @@ config ATMEL_PIT > > config ATMEL_ST > bool > + depends on HAS_IOMEM# For MFD_SYSCON > select CLKSRC_OF > select MFD_SYSCON > looking at this again, there is no need for the dependency here, as it is not a user-selectable symbol. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 03/15] hwspinlock: qcom: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:29 Krzysztof Kozlowski wrote: > diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig > index 73a401662853..5ab2d51dc147 100644 > --- a/drivers/hwspinlock/Kconfig > +++ b/drivers/hwspinlock/Kconfig > @@ -21,6 +21,7 @@ config HWSPINLOCK_OMAP > config HWSPINLOCK_QCOM > tristate "Qualcomm Hardware Spinlock device" > depends on ARCH_QCOM > + depends on HAS_IOMEM# For MFD_SYSCON > select HWSPINLOCK > select MFD_SYSCON > help > This is only needed if we add "|| COMPILE_TEST", right now the driver is limited to ARCH_QCOM. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/15] dmaengine: nxp: Add missing MFD_SYSCON dependency on HAS_IOMEM
On Thursday 03 March 2016 17:03:28 Krzysztof Kozlowski wrote: > index c77f214c9466..7fbf96bff280 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -290,6 +290,7 @@ config LPC18XX_DMAMUX > bool "NXP LPC18xx/43xx DMA MUX for PL080" > depends on ARCH_LPC18XX || COMPILE_TEST > depends on OF && AMBA_PL08X > + depends on HAS_IOMEM# For MFD_SYSCON > select MFD_SYSCON > help > AMBA_PL08X implies HAS_IOMEM, so this is not needed explicitly Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 15/15] mfd: syscon: Fix build of missing ioremap on UM
On Thursday 03 March 2016 17:03:41 Krzysztof Kozlowski wrote:
> Since commit c89c0114955a ("mfd: syscon: Set regmap max_register in
> of_syscon_register") the syscon uses ioremap so it fails on COMPILE_TEST
> without HAS_IOMEM:
>
> drivers/mfd/syscon.c: In function ‘of_syscon_register’:
> drivers/mfd/syscon.c:67:9: error: implicit declaration of function ‘ioremap’
> [-Werror=implicit-function-declaration]
> base = ioremap(res.start, resource_size(&res));
> ^
> drivers/mfd/syscon.c:67:7: warning: assignment makes pointer from integer
> without a cast [-Wint-conversion]
> base = ioremap(res.start, resource_size(&res));
>^
> drivers/mfd/syscon.c:109:2: error: implicit declaration of function ‘iounmap’
> [-Werror=implicit-function-declaration]
> iounmap(base);
>
> When selecting MFD_SYSCON, depend on HAS_IOMEM to avoid unmet direct
> dependencies.
>
> Reported-by: kbuild test robot
> Fixes: c89c0114955a ("mfd: syscon: Set regmap max_register in
> of_syscon_register")
> Signed-off-by: Krzysztof Kozlowski
> ---
Thanks for looking into this, the patches all look right to me, but
I fear we are forever playing catch-up here, as the number of syscon users
is only growing, and it's not obvious to the average driver developer
why they have to select this symbol.
Interestingly, when I try to build an allmodconfig kernel for UML,
it seems to reject any driver calling ioremap/iounmap but not
the wrapper functions around that (of_iomap, devm_ioremap,
devm_ioremap_resource, ...) or the actual accessors that make no
sense without ioremap (readl, writel, inb, outb, iowrite32, ...).
I've played with this a bit, and arrived at the patch below, is this
something we want as well?
Arnd
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index aa21dc55eb15..2e5b1e525a1d 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1034,6 +1034,7 @@ config MFD_SUN6I_PRCM
>
> config MFD_SYSCON
> bool "System Controller Register R/W Based on Regmap"
> + depends on HAS_IOMEM
> select REGMAP_MMIO
> help
> Select this option to enable accessing system control registers
>
arch/um/include/asm/io.h |1 +
drivers/char/Kconfig |3 +++
drivers/char/mem.c | 16
drivers/clocksource/Kconfig|3 +++
drivers/fmc/Kconfig|1 +
drivers/fpga/Kconfig |1 +
drivers/hwtracing/intel_th/Kconfig |1 +
drivers/mfd/Kconfig|1 +
drivers/misc/altera-stapl/Kconfig |2 +-
drivers/mtd/chips/Kconfig |4
drivers/mtd/lpddr/Kconfig |1 +
drivers/mtd/maps/Kconfig |3 ++-
drivers/mtd/nand/Kconfig |2 +-
drivers/mtd/spi-nor/Kconfig|1 +
drivers/net/can/Kconfig|1 +
drivers/net/hamradio/Kconfig |9 ++---
drivers/nvmem/Kconfig |1 +
drivers/phy/Kconfig|9 +++--
drivers/power/reset/Kconfig|4 +++-
drivers/staging/comedi/Kconfig |6 +-
drivers/thermal/Kconfig| 11 +--
include/linux/irq.h|2 ++
include/linux/mtd/cfi.h|2 ++
include/linux/mtd/map.h|2 ++
kernel/resource.c |2 ++
lib/Kconfig|7 ++-
mm/bootmem.c |4 ++--
27 files changed, 85 insertions(+), 15 deletions(-)
diff --git a/arch/um/include/asm/io.h b/arch/um/include/asm/io.h
new file mode 100644
index 000..618ff13
--- /dev/null
+++ b/arch/um/include/asm/io.h
@@ -0,0 +1 @@
+/* no IOPORT or IOMEM suport */
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a043107..f6dc17a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -8,6 +8,7 @@ source "drivers/tty/Kconfig"
config DEVMEM
bool "/dev/mem virtual device support"
+ depends on HAS_IOMEM
default y
help
Say Y here if you want to support the /dev/mem device.
@@ -17,6 +18,7 @@ config DEVMEM
config DEVKMEM
bool "/dev/kmem virtual device support"
+ depends on HAS_IOMEM
default y
help
Say Y here if you want to support the /dev/kmem device. The
@@ -94,6 +96,7 @@ config BFIN_OTP_WRITE_ENABLE
config PRINTER
tristate "Parallel printer support"
depends on PARPORT
+ depends on HAS_IOPORT
---help---
If you intend to attach a printer to the parallel port of your Linux
box (as opposed to using a serial printer; if the connector at the
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 4f6f94c..eedd129 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -91,6 +91,7 @@ void __weak unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
}
#endif
+#ifdef CONFIG_DEVMEM
/*
* This funcion reads the *physical* memory. The f_pos points directly to the
* memory
[PATCH 0/3] Add power sequence for hard-wired USB devices
Hi all, I have a patch for adding device tree support for USB device [1] some days ago, this is a follow-up to support the USB devices which need to do some power sequence like enabling USB PHY clock, toggling reset gpio, etc, before this device can work normal. I have seen some use cases for it. In the 1st patch, the USB HUB driver will iterate all its sub devices described at dts, and do power on sequence if there is a phandle "usb-pwrseq" for it. The user can add its specific clock and reset pin in its dts to support this feature. In the 2nd patch, there is a workaround for chipidea driver to let the hcd know its device node. In the 3rd patch, it is a user case for this problem. @Maciej @Fabio, would you kind to test it at udoo boards, and supply the related vid/pid for this HUB? @troy, would you kind add your dts for it at nitrogen6x board? [1] http://www.spinics.net/lists/linux-usb/msg136698.html Peter Chen (3): usb: core: add power sequence for USB devices usb: chipidea: host: let the hcd know's parent device node ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property .../devicetree/bindings/usb/usb-device.txt | 41 +- arch/arm/boot/dts/imx6qdl-udoo.dtsi| 35 ++--- drivers/usb/chipidea/host.c| 18 ++- drivers/usb/core/Makefile | 2 +- drivers/usb/core/hub.c | 32 + drivers/usb/core/pwrseq.c | 149 + include/linux/usb/of.h | 10 ++ 7 files changed, 260 insertions(+), 27 deletions(-) create mode 100644 drivers/usb/core/pwrseq.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] usb: core: add power sequence for USB devices
Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.
In this patch, it will do power on sequence at hub's probe for all
devices under this hub (includes root hub) if this device is described
at dts and there is a phandle "usb-pwrseq" for it. At hub_disconnect,
it will do power off sequence.
Signed-off-by: Peter Chen
---
.../devicetree/bindings/usb/usb-device.txt | 41 +-
drivers/usb/core/Makefile | 2 +-
drivers/usb/core/hub.c | 32 +
drivers/usb/core/pwrseq.c | 149 +
include/linux/usb/of.h | 10 ++
5 files changed, 232 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/core/pwrseq.c
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..c7a298c 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,8 +13,37 @@ Required properties:
- reg: the port number which this device is connecting to, the range
is 1-31.
+Optional properties:
+- usb-pwrseq: the power sequence handler which need to do before this USB
+ device can work.
+- clocks: the input clock for USB device.
+- clock-frequency: the frequency for device's clock.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
Example:
+/ {
+ ...
+
+ hub_genesys_1_pwrseq: hub_genesys_1_pwrseq {
+ compatible = "usb-pwrseq";
+ reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+ reset-duration-us = <10>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ };
+
+ ethernet_asix_2_pwrseq: ethernet_asix_2_pwrseq {
+ compatible = "usb-pwrseq";
+ reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* ethernet_rst */
+ reset-duration-us = <20>;
+ clock-frequency = <2400>;
+ clocks = <&clks IMX6QDL_CLK_CKO1>;
+ };
+
+ ...
+};
+
&usb1 {
status = "okay";
@@ -24,5 +53,15 @@ Example:
hub: genesys@1 {
compatible = "usb5e3,608";
reg = <1>;
+ usb-pwrseq = <&hub_genesys_1_pwrseq>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: asix@1 {
+ compatible = "usbb95,1708";
+ reg = <1>;
+ usb-pwrseq = <ðernet_asix_1_pwrseq>;
+ };
};
-}
+};
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..9cdc548 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -5,7 +5,7 @@
usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
usbcore-y += devio.o notify.o generic.o quirks.o devices.o
-usbcore-y += port.o of.o
+usbcore-y += port.o of.o pwrseq.o
usbcore-$(CONFIG_PCI) += hcd-pci.o
usbcore-$(CONFIG_ACPI) += usb-acpi.o
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 0f82db4..0091428 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -1680,6 +1682,27 @@ static void hub_release(struct kref *kref)
kfree(hub);
}
+static int hub_of_pwrseq(struct usb_device *hdev, bool on)
+{
+ struct device *parent;
+ struct device_node *node;
+ int ret = 0;
+
+ if (hdev->parent)
+ parent = &hdev->dev;
+ else
+ parent = bus_to_hcd(hdev->bus)->self.controller;
+
+ for_each_child_of_node(parent->of_node, node) {
+ ret = on ? usb_child_pwrseq_on(node)
+ : usb_child_pwrseq_off(node);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static unsigned highspeed_hubs;
static void hub_disconnect(struct usb_interface *intf)
@@ -1722,6 +1745,10 @@ static void hub_disconnect(struct usb_interface *intf)
kfree(hub->buffer);
pm_suspend_ignore_children(&intf->dev, false);
+
+ if (hub_of_pwrseq(hdev, false))
+ dev_err(&hdev->dev, "failed to do power operations off\n");
+
kref_put(&hub->kref, hub_release);
}
@@ -1731,6 +1758,7 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+ int ret;
desc = i
[PATCH 2/3] usb: chipidea: host: let the hcd know's parent device node
From: Peter Chen
Since the hcd (chipidea core device) has no device node, so
if we want to describe the child node under the hcd, we had
to put it under its parent's node (glue layer device), and
in the code, we need to let the hcd knows glue layer's code,
then the USB core can handle this node.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/host.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 053bac9..55120ef 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -109,15 +109,25 @@ static int host_start(struct ci_hdrc *ci)
struct ehci_hcd *ehci;
struct ehci_ci_priv *priv;
int ret;
+ struct device *dev = ci->dev;
- if (usb_disabled())
+ if (usb_disabled() || !dev)
return -ENODEV;
- hcd = usb_create_hcd(&ci_ehci_hc_driver, ci->dev, dev_name(ci->dev));
+ /*
+* USB Core will try to get child node under roothub,
+* but chipidea core has no of_node, and the child node
+* for controller is located at glue layer's node which
+* is chipidea core's parent.
+*/
+ if (dev->parent && dev->parent->of_node)
+ dev->of_node = dev->parent->of_node;
+
+ hcd = usb_create_hcd(&ci_ehci_hc_driver, dev, dev_name(dev));
if (!hcd)
return -ENOMEM;
- dev_set_drvdata(ci->dev, ci);
+ dev_set_drvdata(dev, ci);
hcd->rsrc_start = ci->hw_bank.phys;
hcd->rsrc_len = ci->hw_bank.size;
hcd->regs = ci->hw_bank.abs;
@@ -143,7 +153,7 @@ static int host_start(struct ci_hdrc *ci)
if (ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON) {
ret = regulator_enable(ci->platdata->reg_vbus);
if (ret) {
- dev_err(ci->dev,
+ dev_err(dev,
"Failed to enable vbus regulator, ret=%d\n",
ret);
goto put_hcd;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
From: Peter Chen
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller.
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx6qdl-udoo.dtsi | 35 ++-
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 1211da8..d8a4274 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
*
*/
+#include
+
/ {
chosen {
stdout-path = &uart2;
@@ -17,23 +19,6 @@
memory {
reg = <0x1000 0x4000>;
};
-
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reg_usb_h1_vbus: regulator@0 {
- compatible = "regulator-fixed";
- reg = <0>;
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- startup-delay-us = <2>; /* USB2415 requires a POR of 1
us minimum */
- gpio = <&gpio7 12 0>;
- };
- };
};
&fec {
@@ -119,11 +104,19 @@
};
&usbh1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usbh>;
- vbus-supply = <®_usb_h1_vbus>;
- clocks = <&clks 201>;
status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hub: usb2415@01 {
+ compatible = "usb,";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ reset-duration-us = <3000>;
+ };
};
&usdhc3 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RESEND] usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable()
A udc driver should set the giveback status to -ESHUTDOWN in usb_ep_disable(). Otherwise, a gadget driver (e.g. g_serial) might request next data wrongly and it is possible to cause kernel panic. Signed-off-by: Yoshihiro Shimoda --- drivers/usb/renesas_usbhs/mod_gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c b/drivers/usb/renesas_usbhs/mod_gadget.c index 657f967..664b263 100644 --- a/drivers/usb/renesas_usbhs/mod_gadget.c +++ b/drivers/usb/renesas_usbhs/mod_gadget.c @@ -561,7 +561,7 @@ static int usbhsg_pipe_disable(struct usbhsg_uep *uep) if (!pkt) break; - usbhsg_queue_pop(uep, usbhsg_pkt_to_ureq(pkt), -ECONNRESET); + usbhsg_queue_pop(uep, usbhsg_pkt_to_ureq(pkt), -ESHUTDOWN); } usbhs_pipe_disable(pipe); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable()
Hi Felipe, > From: Felipe Balbi [mailto:ba...@kernel.org] > Sent: Thursday, March 03, 2016 6:22 PM > > Hi Yoshihiro, > > Yoshihiro Shimoda writes: > > [ text/plain ] > > Hi Felipe, > > > > Oops, I completely forgot this patch. > > Would you review this patch? Or should I resend it? > > I confirmed that this patch could be applied on your latest > > testing/fixes branch. > > I don't seem to have the original patch in my inbox. Would you mind > resending ? Sure. I will resend this patch soon. Best regards, Yoshihiro Shimoda > Thanks > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Freezable workqueue blocks non-freezable workqueue during the system resume process
Hello, On Wed 02-03-16 11:00:58, Tejun Heo wrote: > On Fri, Feb 26, 2016 at 02:19:20PM +0800, Peter Chen wrote: > > On Thu, Feb 25, 2016 at 05:01:12PM -0500, Tejun Heo wrote: > > > Hello, Peter. > > > > > > On Wed, Feb 24, 2016 at 03:24:30PM +0800, Peter Chen wrote: > > > > > You might want to complain to the block-layer people about this. I > > > > > don't know if anything can be done to fix it. > > > > > > > > > > Or maybe flush_work and flush_delayed_work can be changed to avoid > > > > > blocking if the workqueue is frozen. Tejun? > > > > > > > > > > > > > I have a patch to show the root cause of this issue. > > > > > > > > http://www.spinics.net/lists/linux-usb/msg136815.html > > > > > > I don't get it. Why would it deadlock? Shouldn't things get rolling > > > once the workqueues are thawed? > > > > The workqueue writeback can't be thawed due to driver's resume > > (dpm_complete) is lock nested, and can't be finished. > > Ugh... that's nasty. I wonder whether the right thing to do is making > writeback workers non-freezable. IOs are supposed to be blocked from > lower layer anyway. Jan, what do you think? Well no, at least currently IO is not blocked in lower layers AFAIK - for that you'd need to freeze block devices & filesystems and there are issues with that (Jiri Kosina was the last one which was trying to make this work AFAIR). And I think you need to stop writeback (and generally any IO) to be generated so that it doesn't interact in a strange way with device drivers being frozen. So IMO until suspend freezes filesystems & devices properly you have to freeze writeback workqueue. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable()
Hi Yoshihiro, Yoshihiro Shimoda writes: > [ text/plain ] > Hi Felipe, > > Oops, I completely forgot this patch. > Would you review this patch? Or should I resend it? > I confirmed that this patch could be applied on your latest > testing/fixes branch. I don't seem to have the original patch in my inbox. Would you mind resending ? Thanks -- balbi signature.asc Description: PGP signature
RE: [PATCH] usb: gadget: renesas_usb3: Use ARCH_RENESAS
Hi Simon-san, > From: Simon Horman [mailto:horms+rene...@verge.net.au] > Sent: Wednesday, March 02, 2016 11:17 AM > > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. > > Signed-off-by: Simon Horman Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda > --- > drivers/usb/gadget/udc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Based on usb-gadget/next > > diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig > index ff4f8a6735d6..7c289416f87d 100644 > --- a/drivers/usb/gadget/udc/Kconfig > +++ b/drivers/usb/gadget/udc/Kconfig > @@ -176,7 +176,7 @@ config USB_RENESAS_USBHS_UDC > > config USB_RENESAS_USB3 > tristate 'Renesas USB3.0 Peripheral controller' > - depends on ARCH_SHMOBILE || COMPILE_TEST > + depends on ARCH_RENESAS || COMPILE_TEST > help > Renesas USB3.0 Peripheral controller is a USB peripheral controller > that supports super, high, and full speed USB 3.0 data transfers. > -- > 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
