[PATCH v5 1/2] ARM: dts: imx27.dtsi: change the clock information for usb

[Peter Chen]

For imx27, it needs three clocks to let the controller work,
the old code is wrong, and usbmisc has not included clock handling
code any more. Without this patch, it will cause below data
abort when accessing usbmisc registers.

usbcore: registered new interface driver usb-storage
Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600
pgd = c0004000
[f4424600] *pgd=1452(bad)
Internal error: : 8 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-next-20150701-dirty #3089
Hardware name: Freescale i.MX27 (Device Tree Support)
task: c7832b60 ti: c783e000 task.ti: c783e000
PC is at usbmisc_imx27_init+0x4c/0xbc
LR is at usbmisc_imx27_init+0x40/0xbc
pc : []lr : []psr: 6093
sp : c783fe08  ip :   fp : 
r10: c0576434  r9 : 009c  r8 : c7a773a0
r7 : 0100  r6 : 6013  r5 : c7a776f0  r4 : c7a773f0
r3 : f4424600  r2 :   r1 : 0001  r0 : 0001
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005317f  Table: a0004000  DAC: 0017
Process swapper (pid: 1, stack limit = 0xc783e190)
Stack: (0xc783fe08 to 0xc784)

Signed-off-by: Peter Chen 
Reported-by: Fabio Estevam 
Tested-by: Fabio Estevam 
Acked-by: Shawn Guo 
Cc:  #v4.1+
---
 arch/arm/boot/dts/imx27.dtsi | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index feb9d34..f818ea4 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -486,7 +486,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024000 0x200>;
interrupts = <56>;
-   clocks = <&clks IMX27_CLK_USB_IPG_GATE>;
+   clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
+   <&clks IMX27_CLK_USB_AHB_GATE>,
+   <&clks IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 0>;
status = "disabled";
};
@@ -495,7 +498,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024200 0x200>;
interrupts = <54>;
-   clocks = <&clks IMX27_CLK_USB_IPG_GATE>;
+   clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
+   <&clks IMX27_CLK_USB_AHB_GATE>,
+   <&clks IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 1>;
dr_mode = "host";
status = "disabled";
@@ -505,7 +511,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024400 0x200>;
interrupts = <55>;
-   clocks = <&clks IMX27_CLK_USB_IPG_GATE>;
+   clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
+   <&clks IMX27_CLK_USB_AHB_GATE>,
+   <&clks IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
status = "disabled";
@@ -515,7 +524,6 @@
#index-cells = <1>;
compatible = "fsl,imx27-usbmisc";
reg = <0x10024600 0x200>;
-   clocks = <&clks IMX27_CLK_USB_AHB_GATE>;
};
 
sahara2: sahara@10025000 {
-- 
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 v5 0/2] usb: change clock information for chipidea

[Peter Chen]

This patch set changes usb clock information for legacy i.mx platforms.
At these platforms, they needs three clocks to let controller work.

Fabio, would you please help to test again, I am sorry to let you
test again.

Changes for v5:
- Using one line code for two devm_clk_get error message
- disable clocks should be inverse with enable clocks

Changes for v4:
- Following Rob Herring suggestion, if the platforms can get
clock using their dev_id, then, they are legacy platforms which
need three clocks to let controller work. If the dev_id is NULL,
then it only needs one clock.
- Only includes bug fix patches in this set, for new changes, will
through the next-tree.

Changes for v3:
- Delete property "needs-three-clocks", and using of_device_id->data
  to differentiate platforms
- change  #v3.19+ to  #v4.1+

Changes for v2:
- Add imx25 & imx27 dts change
- Add Fabio's tested-by and Cc:  #v3.19+
- Some typo and commit description

Peter Chen (2):
  ARM: dts: imx27.dtsi: change the clock information for usb
  usb: chipidea: imx: refine clock operations to adapt for all platforms

 arch/arm/boot/dts/imx27.dtsi   |  16 +++--
 drivers/usb/chipidea/ci_hdrc_imx.c | 131 -
 2 files changed, 125 insertions(+), 22 deletions(-)

-- 
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 v5 2/2] usb: chipidea: imx: refine clock operations to adapt for all platforms

[Peter Chen]

Some i.mx platforms need three clocks to let controller work, but
others only need one, refine clock operation to adapt for all
platforms, it fixes a regression found at i.mx27.

Signed-off-by: Peter Chen 
Tested-by: Fabio Estevam 
Cc:  #v4.1+
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 131 -
 1 file changed, 113 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 6ccbf60..7c9b630 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -84,6 +84,12 @@ struct ci_hdrc_imx_data {
struct imx_usbmisc_data *usbmisc_data;
bool supports_runtime_pm;
bool in_lpm;
+   /* SoC before i.mx6 (except imx23/imx28) needs three clks */
+   bool need_three_clks;
+   struct clk *clk_ipg;
+   struct clk *clk_ahb;
+   struct clk *clk_per;
+   /* - */
 };
 
 /* Common functions shared by usbmisc drivers */
@@ -135,6 +141,102 @@ static struct imx_usbmisc_data 
*usbmisc_get_init_data(struct device *dev)
 }
 
 /* End of common functions shared by usbmisc drivers*/
+static int imx_get_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret = 0;
+
+   data->clk_ipg = devm_clk_get(dev, "ipg");
+   if (IS_ERR(data->clk_ipg)) {
+   /* If the platform only needs one clocks */
+   data->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(data->clk)) {
+   ret = PTR_ERR(data->clk);
+   dev_err(dev,
+   "Failed to get clks, err=%ld,%ld\n",
+   PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
+   return ret;
+   }
+   return ret;
+   }
+
+   data->clk_ahb = devm_clk_get(dev, "ahb");
+   if (IS_ERR(data->clk_ahb)) {
+   ret = PTR_ERR(data->clk_ahb);
+   dev_err(dev,
+   "Failed to get ahb clock, err=%d\n", ret);
+   return ret;
+   }
+
+   data->clk_per = devm_clk_get(dev, "per");
+   if (IS_ERR(data->clk_per)) {
+   ret = PTR_ERR(data->clk_per);
+   dev_err(dev,
+   "Failed to get per clock, err=%d\n", ret);
+   return ret;
+   }
+
+   data->need_three_clks = true;
+   return ret;
+}
+
+static int imx_prepare_enable_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret = 0;
+
+   if (data->need_three_clks) {
+   ret = clk_prepare_enable(data->clk_ipg);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable ipg clk, err=%d\n",
+   ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(data->clk_ahb);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable ahb clk, err=%d\n",
+   ret);
+   clk_disable_unprepare(data->clk_ipg);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(data->clk_per);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable per clk, err=%d\n",
+   ret);
+   clk_disable_unprepare(data->clk_ahb);
+   clk_disable_unprepare(data->clk_ipg);
+   return ret;
+   }
+   } else {
+   ret = clk_prepare_enable(data->clk);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable clk, err=%d\n",
+   ret);
+   return ret;
+   }
+   }
+
+   return ret;
+}
+
+static void imx_disable_unprepare_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+
+   if (data->need_three_clks) {
+   clk_disable_unprepare(data->clk_per);
+   clk_disable_unprepare(data->clk_ahb);
+   clk_disable_unprepare(data->clk_ipg);
+   } else {
+   clk_disable_unprepare(data->clk);
+   }
+}
 
 static int ci_hdrc_imx_probe(struct platform_device *pdev)
 {
@@ -153,23 +255,18 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
 
+   platform_set_drvdata(pdev, data);
data->usbmisc_data = usbmisc_get_init_data(&pdev->dev);
if (IS_ERR(data->usbmisc_data))
return PTR_ERR(data->usbmisc_data);
 
-   data->clk = devm_clk_get(&pdev->dev, NULL);
-   if (IS_ERR(data->clk)) {
-   dev_err(&pdev->dev,
-   

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki  wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse  
> >> wrote:
> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> > and *not* using DT-specific code in places where we should be using 
> >> >> > the
> >> >> > generic APIs.
> >> >>
> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> here.
> >> >
> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >
> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> > work through that — while in DT, properties which reference GPIO pins
> >> > will have different contents. They'll be compatible at the driver
> >> > level, in the sense that there's a call to get a given GPIO given the
> >> > property name, but the subsystems *will* be doing different things
> >> > behind the scenes.
> >> >
> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> > then take stock of what we have left, and work out what, if anything,
> >> > still needs to be done.
> >>
> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> functions. Some are DT specific, but probably because those subsystems
> >> are new and DT only. In any case, I don't think these 1 line changes
> >> do anything to make doing conversions here harder.
> >>
> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> here is that big.
> >> >
> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> > is a note in the commit comment to that effect. That's different from
> >> > having not thought about it :)
> >>
> >> Considering at one point we did create a fwnode based API, we did
> >> think about it. Plus there was little input from ACPI folks as to
> >> whether the change was even useful for ACPI case.
> >
> > Well, sorry, but who was asking whom, specifically?
> 
> You and linux-acpi have been copied on v2 and later of the entire
> series I think.

Yes, but it wasn't like a direct request, say "We need your input, so can you
please have a look and BTW we want this in 4.4, so please do it ASAP".  In
which case I'd prioritize that before other things I needed to take care of.

> > The underlying problem is present in ACPI too and we don't really have a 
> > good
> > solution for it.  We might benefit from a common one if it existed.
> 
> The problem for DT is we don't generically know what are the
> dependencies at a core level. We could know some or most dependencies
> if phandles (links to other nodes) were typed, but they are not. If
> the core had this information, we could simply control the device
> creation to order probing. Instead, this information is encoded into
> the bindings and binding parsing resides in the subsystems. That
> parsing happens during probe of the client side and is done by the
> subsystems (for common bindings). Since we already do the parsing at
> this point, it is a convenient place to trigger the probe of the
> dependency. Is ACPI going to be similar in this regard?

It is similar in some ways.  For example, if a device's functionality depends
on an I2C resource (connection), the core doesn't know that at the device
creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

There is a _DEP object in ACPI that can be used by firmware to tell the OS
about those dependencies, but there's no way in the driver core to use that
information anyway today.

> Fundamentally, it is a question of probe devices when their
> dependencies are present or drivers ensure their dependencies are
> ready. IIRC, init systems went thru a similar debate for service
> dependencies.

The probe ordering is not the entire picture, though.

Even if you get the probe ordering right, the problem is going to show up in
multiple other places: system suspend/resume, runtime PM, system shutdown,
unbinding of drivers.  In all of those cases it is necessary to handle things
in a specific order if there is a dependency.

> >> In any case, we're talking about adding 1 line.
> >
> > But also about making the driver core slighly OF-centric.
> 
> How so? The one line is in DT binding parsing code in subsystems, not
>

Re: [PATCH 1/1] usb: chipidea: otg: don't wait vbus drops below BSV when starts host

[Peter Chen]

On Fri, Oct 16, 2015 at 01:53:20PM +0800, Li Jun wrote:
> Some HW design may use ID pin state to control vbus for otg port,
> so before host role start, the vbus is already turned on, in this
> case, we do not need wait vbus dropping below BSV.
> 

Yes, only gadget need to consider vbus.

> Signed-off-by: Li Jun 
> ---
>  drivers/usb/chipidea/otg.c |9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> index ad6c87a..3169c51 100644
> --- a/drivers/usb/chipidea/otg.c
> +++ b/drivers/usb/chipidea/otg.c
> @@ -77,9 +77,12 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
>   ci_role(ci)->name, ci->roles[role]->name);
>  
>   ci_role_stop(ci);
> - /* wait vbus lower than OTGSC_BSV */
> - hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> - CI_VBUS_STABLE_TIMEOUT_MS);
> +
> + if (role == CI_ROLE_GADGET)
> + /* wait vbus lower than OTGSC_BSV */
> + hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> + CI_VBUS_STABLE_TIMEOUT_MS);
> +
>   ci_role_start(ci, role);
>   }
>  }
> -- 
> 1.7.9.5
> 

-- 

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/2] USB: serial: cp210x: Implement 16-bit register access functions

[Johan Hovold]

On Mon, Oct 19, 2015 at 05:01:24PM -0500, Konstantin Shkolnyy wrote:
> Existing register access functions cp210x_get_config and cp210x_set_config
> are cumbersome to use. This change introduces new functions specifically
> for 16-bit registers that read and write simple u16 values.

There's a bit too much going on in both these patches. Remember, one
logical change per patch.

Also make sure to include the patch revision in the subject and bump it
(for the whole series) when resending.

> Signed-off-by: Konstantin Shkolnyy 
> ---
>  drivers/usb/serial/cp210x.c | 119 
> 
>  1 file changed, 88 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index eac7cca..5a7c15e 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -301,6 +301,77 @@ static struct usb_serial_driver * const serial_drivers[] 
> = {
>  #define CONTROL_WRITE_RTS0x0200
>  
>  /*
> + * Reads any 16-bit CP210X_ register (req).
> + */
> +static int cp210x_read_u16_reg(struct usb_serial *serial, u8 req, u16 *pval)
> +{
> + struct cp210x_serial_private *spriv = usb_get_serial_data(serial);
> + __le16 le16_value;
> + int result;
> +
> + result = usb_control_msg(serial->dev,
> + usb_rcvctrlpipe(serial->dev, 0),
> + req, REQTYPE_INTERFACE_TO_HOST, 0,
> + spriv->bInterfaceNumber, &le16_value, 2,
> + USB_CTRL_SET_TIMEOUT);

As Oliver already pointed out, you cannot use an automatic variable for
the data stage here.

> + if (result != 2) {
> + if (result > 0)
> + result = -EPROTO;
> + dev_err(&serial->dev->dev, "%s ifc %d req 0x%x err %d\n",
> + __func__, spriv->bInterfaceNumber, req, result);
> + return result;
> + }
> + *pval = le16_to_cpu(le16_value);
> + return 0;
> +}
> +
> +/*
> + * Writes any 16-bit CP210X_ register (req) whose value is passed
> + * entirely in the wValue field of the USB request.
> + */
> +static int cp210x_write_u16_reg(struct usb_serial *serial, u8 req, u16 val)
> +{
> + struct cp210x_serial_private *spriv = usb_get_serial_data(serial);
> + int result;
> +
> + result = usb_control_msg(serial->dev,
> + usb_sndctrlpipe(serial->dev, 0),
> + req, REQTYPE_HOST_TO_INTERFACE, val,
> + spriv->bInterfaceNumber, NULL, 0,
> + USB_CTRL_SET_TIMEOUT);
> + if (result < 0) {
> + dev_err(&serial->dev->dev, "%s ifc %d req 0x%x err %d\n",
> + __func__, spriv->bInterfaceNumber, req, result);
> + }
> + return result;
> +}
> +
> +/*
> + * Command-specific wrappers around USB access functions
> + */
> +static int cp210x_ifc_enable(struct usb_serial_port *port)
> +{
> + return cp210x_write_u16_reg(port->serial,
> + CP210X_IFC_ENABLE, UART_ENABLE);
> +}
> +
> +static int cp210x_ifc_disable(struct usb_serial_port *port)
> +{
> + return cp210x_write_u16_reg(port->serial,
> + CP210X_IFC_ENABLE, UART_DISABLE);
> +}

Why are these here? This is unrelated to adding the line_ctl helpers.

> +
> +static int cp210x_get_line_ctl(struct usb_serial_port *port, u16 *pctrl)
> +{
> + return cp210x_read_u16_reg(port->serial, CP210X_GET_LINE_CTL, pctrl);
> +}
> +
> +static int cp210x_set_line_ctl(struct usb_serial_port *port, u16 ctrl)
> +{
> + return cp210x_write_u16_reg(port->serial, CP210X_SET_LINE_CTL, ctrl);
> +}

Instead of adding the new helpers to read u16 as a prerequisite for
fixing the broken cp2108 support, just reuse the current config register
helpers for now (in order to keep the fixes minimal and potentially
backportable). Once the fixes are in place, feel free to clean up the
remaining register accesses.

> +
> +/*
>   * cp210x_get_config
>   * Reads from the CP210x configuration registers
>   * 'size' is specified in bytes.
> @@ -400,17 +471,6 @@ static int cp210x_set_config(struct usb_serial_port 
> *port, u8 request,
>  }
>  
>  /*
> - * cp210x_set_config_single
> - * Convenience function for calling cp210x_set_config on single data values
> - * without requiring an integer pointer
> - */
> -static inline int cp210x_set_config_single(struct usb_serial_port *port,
> - u8 request, unsigned int data)
> -{
> - return cp210x_set_config(port, request, &data, 2);
> -}
> -
> -/*
>   * cp210x_quantise_baudrate
>   * Quantises the baud rate as per AN205 Table 1
>   */
> @@ -456,12 +516,9 @@ static int cp210x_open(struct tty_struct *tty, struct 
> usb_serial_port *port)
>  {
>   int result;
>  
> - result = cp210x_set_config_single(port, CP210X_IFC_ENABLE,
> - UART_ENABLE);
> - if (result) {
> -  

Re: [PATCH 2/2] USB: serial: cp210x: Workaround for occasional cp2108 hangs.

[Johan Hovold]

On Mon, Oct 19, 2015 at 05:01:40PM -0500, Konstantin Shkolnyy wrote:
> This patch can only be applied after the patch titled
> "USB: serial: cp210x: Implement 16-bit register access functions"

No need to put this in the commit message, ordering is assumed to be
correct when you submit a series of patches.

> Work around 2 cp2108 bugs:
> 
> 1) cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
> However, SET_LINE_CTL functions properly. When the driver tries to modify
> the register, it reads it, modifies some bits and writes back. Because
> the read bytes were swapped, this often results in an invalid value to be
> written. In turn, this causes cp2108 respond with a stall. The stall
> sometimes doesn't clear properly and cp2108 starts responding to following
> valid commands also with stalls, effectively failing.
> 
> 2) Occasionally, writing data and immediately closing the port makes cp2108
> stop responding. The device had to be unplugged to clear the error.
> The failure is induced by shutting down the device while its Tx queue still
> has unsent data. This condition is avoided by issuing PURGE command from
> the close() callback.

Two distinct fixes need to go in separate patches.

You should end up with something like the following series

 - fix hang after close (purge)
 - refactor lcr handling
 - fix cp2108 lcr handling
 - more clean ups...

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: [PATCH v9 4/5] xhci: mediatek: support MTK xHCI host controller

[Mathias Nyman]

On 20.10.2015 09:29, chunfeng yun wrote:

hi,
On Mon, 2015-10-19 at 14:25 +0300, Mathias Nyman wrote:


So basically we are trying to use as many microframes as possible with as few 
packets
per microframe as possible.

Did I understand this correctly?

Yes, you are right.


How will devices react if they expect to get 16 packets every 16th microframe,
but they get one packet every microframe instead?

I think that the synchronous endpoint must specify its period by
bInterval, but can't specify how data should be transfered during the
period by the host, and it just only receives data passively. So the
device can receive data correctly in the case(bInterval is 5).

quote from usb3_r1.0 section4.4.8 Isochronous Transfers:
"The host can request data from the device or send data to the device at
any time during the service interval for a particular endpoint on that
device"



As I understand the 4.4.8 section it just means the device can't assume a fixed
time interval between transfers, meaning that the host can use the last 
microframe
in one esit and the first microframe in the next esit, but still only use 1 
microframe
per esit.

Section 8.12.6.1 describes how a 11 packet isoc transfer is allowed to be split
to 1 burst of 11 packets, 2 burst (8 + 3),  3 burst (4+4+3) 6 bursts 
(2+2+2+2+2+1) or
11 bursts of 1. These are however all within the same microframe. Splitting the
transfer into several microframes in a esit kind of makes the whole interval 
concept pointless.


It doesn't say that the packets should be transfered within the same
microframe (bus interval), as I understand it means service interval;

The direct prove resides in figure 8-56/8-57.

Term:
1. BI, bus interval, a 125 us period that establishes the internal
boundary of service interval, aka uframe;
2. SSI, Support Smart Isochronous;
3. DBI, Data in this Bus Interval is done;
4. NBI, Numbers of Bus Interval;

As the figure shows, the service interval = 8 BI, that host distribute 2
packets @1st uframe, keep U1/U2 state for the next 3uframe, then
transmit 4 packets @4th uframe, and the remaining 3 packet in the last
frame.

Please notice that this just is an example illustrated by spec, but we
can derive the conclusion that the distribution of packet in a service
interval is completely decided by host, and can split isoc transfers
across multiple uframes.


So it seems. You're right



PS: as you can see, MTK implementation of schedule algorithms is an
implementation of Smart Isochronous of which the smart side resides in
software.


Thanks for the clarification, I now understand how the implementation works

-Mathias  


--
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] On-demand device probing

[David Woodhouse]

On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> > 
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way
> > to
> > describe GPIO, and properties which reference GPIO pins are
> > intended to
> > work through that — while in DT, properties which reference GPIO
> > pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given
> > the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> 
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

I think that part is already being worked on, but...

> If ACPI already handles GPIOs internally, then I'm left wondering
> why GPIO descriptor stuff went down the fwnode route at all - it
> seems rather pointless in this case, 

ACPI already had a way for a given device to say that it uses certain
other GPIOs. But until we had device properties in ACPI, it could say
*what* it used them for. So sure, we could say that we used GPIO#15
from  controller and GPIOs #27 and #31 from  controller.
But there was no way to say that the former was the shotdown pin and
the latter was the reset pin.

While a GPIO property in DT will contain a phandle and basically be a
complete reference to find the pin you're after, the same property
represented in ACPI will just be an index into the resources that ACPI
could already refer to.

So referring to the example in Documentation/acpi/gpio-properties.txt:

  Name (_CRS, ResourceTemplate ()
  {
  GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
  "\\_SB.GPO0", 0, ResourceConsumer) {15}
  GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
  })

That part, ACPI already had. But..

  Name (_DSD, Package ()
  {
  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
  Package ()
  {
  Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
  Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
  }
  })

...this part is new, and allows us the full flexibility of device
properties. And the appropriate gpiod_get* function is supposed to
transparently work on either DT or ACPI.


-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 1/2] USB: serial: cp210x: Implement 16-bit register access functions

[Konstantin Shkolnyy]

On Tue, Oct 20, 2015 at 1:45 AM, Oliver Neukum  wrote:
> On Mon, 2015-10-19 at 17:01 -0500, Konstantin Shkolnyy wrote:
[...]
>> +static int cp210x_read_u16_reg(struct usb_serial *serial, u8 req, u16 *pval)
>> +{
>> + struct cp210x_serial_private *spriv = usb_get_serial_data(serial);
>> + __le16 le16_value;
>
> 1. If you already get passed a pointer to a buffer, why use another
> buffer?

Because I want to preserve the caller's value in the case of an error.
--
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 04/15] tcm_usb_gadget: Fix enabled attribute failure

[Andrzej Pietrasiewicz]

From: Nicholas Bellinger 

Fix up tcm_usbg_tpg_store_enable() return value to propagate
usbg_attach() failure up to user-space if no HDC is found.

Reported-by: Andrzej Pietrasiewicz 
Cc: Andrzej Pietrasiewicz 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Nicholas Bellinger 
[split unrelated changes into separate patches]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index dcc9b1a..cbba4b9 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1505,10 +1505,14 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
if (op > 1)
return -EINVAL;
 
-   if (op && tpg->gadget_connect)
+   if (op && tpg->gadget_connect) {
+   ret = -EINVAL;
goto out;
-   if (!op && !tpg->gadget_connect)
+   }
+   if (!op && !tpg->gadget_connect) {
+   ret = -EINVAL;
goto out;
+   }
 
if (op) {
ret = usbg_attach(tpg);
@@ -1518,8 +1522,10 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
usbg_detach(tpg);
}
tpg->gadget_connect = op;
-out:
+
return count;
+out:
+   return ret;
 }
 
 static ssize_t tcm_usbg_tpg_nexus_show(struct config_item *item, char *page)
-- 
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 02/15] tcm_usb_gadget: Don't strip off nexus WWPN prefix

[Andrzej Pietrasiewicz]

From: Nicholas Bellinger 

Avoid stripping off the 'naa.' I_T nexus prefix from configfs
attribute store input, so that user-space will get back what
it originaly wrote into ../usb_gadget/$WWPN/$TPGT/nexus.

Note the SCSI initiator WWPN is purely symbolic for UAS + BOT,
so it will not effect host side code.

Reported-by: Andrzej Pietrasiewicz 
Cc: Andrzej Pietrasiewicz 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Nicholas Bellinger 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 33833fe..d22e188 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1657,7 +1657,7 @@ static ssize_t tcm_usbg_tpg_nexus_store(struct 
config_item *item,
if (i_port[strlen(i_port) - 1] == '\n')
i_port[strlen(i_port) - 1] = '\0';
 
-   ret = tcm_usbg_make_nexus(tpg, &i_port[4]);
+   ret = tcm_usbg_make_nexus(tpg, &i_port[0]);
if (ret < 0)
return ret;
return count;
-- 
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 10/15] usb: gadget: f_tcm: convert to new function interface with backward compatibility

[Andrzej Pietrasiewicz]

Converting tcm to the new function interface requires converting
USB tcm's function code and its users.

This patch converts the f_tcm.c to the new function interface.

The file can be now compiled into a separate module usb_f_tcm.ko.

The old function interface is provided by means of preprocessor conditional
directives. After all users are converted, the old interface can be
removed.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/Kconfig |   3 +
 drivers/usb/gadget/function/Makefile   |   2 +
 drivers/usb/gadget/function/f_tcm.c| 288 -
 drivers/usb/gadget/function/tcm.h  |   2 +
 drivers/usb/gadget/function/u_tcm.h|  47 +
 drivers/usb/gadget/legacy/tcm_usb_gadget.c |   1 +
 6 files changed, 338 insertions(+), 5 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_tcm.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index bcf83c0..1e97d8e 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -199,6 +199,9 @@ config USB_F_HID
 config USB_F_PRINTER
tristate
 
+config USB_F_TCM
+   tristate
+
 choice
tristate "USB Gadget Drivers"
default USB_ETH
diff --git a/drivers/usb/gadget/function/Makefile 
b/drivers/usb/gadget/function/Makefile
index bd7def5..cb8c225 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -44,3 +44,5 @@ usb_f_hid-y   := f_hid.o
 obj-$(CONFIG_USB_F_HID)+= usb_f_hid.o
 usb_f_printer-y:= f_printer.o
 obj-$(CONFIG_USB_F_PRINTER)+= usb_f_printer.o
+usb_f_tcm-y:= f_tcm.o
+obj-$(CONFIG_USB_F_TCM)+= usb_f_tcm.o
diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index d1b602a..c4cb296 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -22,6 +22,21 @@
 #include 
 
 #include "tcm.h"
+#include "u_tcm.h"
+
+#ifndef USBF_TCM_INCLUDED
+
+#define TPG_INSTANCES  1
+
+struct tpg_instance {
+   struct usb_function_instance*func_inst;
+   struct usbg_tpg *tpg;
+};
+
+static struct tpg_instance tpg_instances[TPG_INSTANCES];
+
+static DEFINE_MUTEX(tpg_instances_lock);
+#endif
 
 static inline struct f_uas *to_f_uas(struct usb_function *f)
 {
@@ -1377,6 +1392,10 @@ static struct se_portal_group *usbg_make_tpg(
struct usbg_tpg *tpg;
unsigned long tpgt;
int ret;
+#ifndef USBF_TCM_INCLUDED
+   struct f_tcm_opts *opts;
+   unsigned i;
+#endif
 
if (strstr(name, "tpgt_") != name)
return ERR_PTR(-EINVAL);
@@ -1387,14 +1406,40 @@ static struct se_portal_group *usbg_make_tpg(
pr_err("gadgets, you can't do this here.\n");
return ERR_PTR(-EBUSY);
}
+#ifndef USBF_TCM_INCLUDED
+   ret = -ENODEV;
+   mutex_lock(&tpg_instances_lock);
+   for (i = 0; i < TPG_INSTANCES; ++i)
+   if (tpg_instances[i].func_inst && !tpg_instances[i].tpg)
+   break;
+   if (i == TPG_INSTANCES)
+   goto unlock_inst;
+
+   opts = container_of(tpg_instances[i].func_inst, struct f_tcm_opts,
+   func_inst);
+   mutex_lock(&opts->dep_lock);
+   if (!opts->ready)
+   goto unlock_dep;
+
+   if (opts->dependent && !try_module_get(opts->dependent))
+   goto unlock_dep;
+#endif
 
tpg = kzalloc(sizeof(struct usbg_tpg), GFP_KERNEL);
+   ret = -ENOMEM;
if (!tpg)
+#ifdef USBF_TCM_INCLUDED
return ERR_PTR(-ENOMEM);
+#else
+   goto unref_dep;
+#endif
mutex_init(&tpg->tpg_mutex);
atomic_set(&tpg->tpg_port_count, 0);
tpg->workqueue = alloc_workqueue("tcm_usb_gadget", 0, 1);
if (!tpg->workqueue) {
+#ifndef USBF_TCM_INCLUDED
+   goto free_tpg;
+#endif
kfree(tpg);
return NULL;
}
@@ -1408,12 +1453,35 @@ static struct se_portal_group *usbg_make_tpg(
 */
ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_SAS);
if (ret < 0) {
+#ifndef USBF_TCM_INCLUDED
+   goto free_workqueue;
+#endif
destroy_workqueue(tpg->workqueue);
kfree(tpg);
return NULL;
}
+#ifndef USBF_TCM_INCLUDED
+   tpg_instances[i].tpg = tpg;
+   tpg->fi = tpg_instances[i].func_inst;
+   mutex_unlock(&opts->dep_lock);
+   mutex_unlock(&tpg_instances_lock);
+#endif
the_only_tpg_I_currently_have = tpg;
return &tpg->se_tpg;
+#ifndef USBF_TCM_INCLUDED
+free_workqueue:
+   destroy_workqueue(tpg->workqueue);
+free_tpg:
+   kfree(tpg);
+unref_dep:
+   module_put(opts->dependent);
+unlock_dep:
+   mutex_unlock(&opts->dep_lock);
+unlock_inst:
+   mutex_unlock(&tpg_instances_lock);
+
+   return ERR_PTR(ret);
+#endif

[PATCH 00/15] Equivalent of tcm_usb_gadget with configfs

[Andrzej Pietrasiewicz]

Dear All,

This series adds support to tcm usb gadget for composing it with configfs.

@target-devel folks: You might be wondering why add configfs for something
which already supports configfs. In tcm_usb_gadget configfs has beeen
used for configuring the SCSI target part, but the usb gadget part
is considered a legacy gadget. A legacy gadget is a composite usb gadget
whose composition is defined statically at compilation time.
Composite gadgets can consist of a number of "functions" and configurations.
In legacy gadgets the selection is hardcoded in a dedicated kernel
module. But with configfs the selection can be made at runtime without
writing any kernel code. The conversion process started almost three
years ago.

The series aims at integrating configfs into tcm, the way it has been
done with 19 of 20 usb functions. In other words this concludes the
process of conversion to configfs in usb gadgets.

The series depends on the series from Chrisoph:
http://www.spinics.net/lists/target-devel/msg10730.html

@Nicholas: In order to use the series from Christoph (simplifying
configfs attributes) I rebased my series on top of your for-next,
which happens not to contain your patches which strip off nexus
WWPN prefix, fix nexus leak and fix enabled attribute failure.
I re-post them here. I have split one of them to separate
unrelated changes.

@Joel: I resend the patch which adds unlocked versions of
configfs_(un)depend_item(). The purpose of configfs_(un)depend_item()
is to allow other kernel subsystems to prohibit deletion of a config
item until they can live without it. This is exactly the case with
tcm usb gadget, but the other kernel subsystem happens to be another
subsystem in configfs: the user must create an instance of the tcm
function in usb_gadget subsystem in order to be able to create
a tpg in target subsystem. But once a tpg goes live its corresponding
tcm function must not be removed until the tpg is deleted.
Even though these are two distinct configfs subsystems the
configfs_(un)depend_item() will not work from a configfs callback.
That is why there is a need to provide the "unlocked" variant.

BACKWARD COMPATIBILITY
==

Please note that the old tcm_usb_gadget.ko is still available and works.

USING THE NEW "GADGET"
==

Please refer to this post:

http://www.spinics.net/lists/linux-usb/msg76388.html

for general information from Sebastian on how to use configfs-based
gadgets (*).

With configfs the procedure is as follows, compared to the information
mentioned above (*):

instead of mkdir functions/acm.ttyS1 do

mkdir functions/tcm.

e.g. mkdir functions/tcm.usb0.

In the tcm.usb0 directory there are no attributes, because all the
configuration is performed with the target subsystem in configfs.

Below is a script which creates a tcm gadget on a board with dwc3:

# mount -t configfs none /sys/kernel/config
# modprobe usb_f_tcm
# cd /sys/kernel/config/usb_gadget
# mkdir tcm
# cd tcm
# mkdir functions/tcm.0
# cd /sys/kernel/config/target/
# mkdir usb_gadget
# cd usb_gadget
# mkdir naa.0123456789abcdef
# cd naa.0123456789abcdef
# mkdir tpgt_1
# cd tpgt_1
# echo naa.01234567890abcdef > nexus
# echo 1 > enable
# cd /sys/kernel/config/usb_gadget/tcm
# mkdir configs/c.1
# ln -s functions/tcm.0 configs/c.1
# echo $VENDOR_ID > idVendor
# echo $PRODUCT_ID > idProduct
# echo 1240.dwc3 > UDC

TESTING THE FUNCTION


The most basic testing

device: run the script above

host: see the gadget enumerated

Andrzej Pietrasiewicz (11):
  usb: gadget: tcm: split string definitions into function and device
  usb: gadget: tcm: follow naming conventions
  usb: gadget: tcm: use strtobool for a boolean value
  usb: gadget: tcm: simplify attribute store function
  usb: gadget: tcm: factor out f_tcm
  usb: gadget: f_tcm: convert to new function interface with backward
compatibility
  usb: gadget: tcm: convert to use new function registration interface
  usb: gadget: f_tcm: remove compatibility layer
  usb: gadget: f_tcm: remove redundant singleton
  usb: gadget: f_tcm: use usb_gstrings_attach
  usb: gadget: f_tcm: add configfs support

Krzysztof Opasiak (1):
  fs: configfs: Add unlocked version of configfs_depend_item()

Nicholas Bellinger (3):
  tcm_usb_gadget: Don't strip off nexus WWPN prefix
  tcm_usb_gadget: Fix nexus leak
  tcm_usb_gadget: Fix enabled attribute failure

 Documentation/ABI/testing/configfs-usb-gadget-tcm |6 +
 drivers/usb/gadget/Kconfig|   17 +
 drivers/usb/gadget/function/Makefile  |2 +
 drivers/usb/gadget/function/f_tcm.c   | 2422 +
 drivers/usb/gadget/function/tcm.h |  132 ++
 drivers/usb/gadget/function/u_tcm.h   |   47 +
 drivers/usb/gadget/legacy/Kconfig |1 +
 drivers/usb/gadget/legacy/tcm_usb_gadget.c| 2182 +--
 drivers/usb/gadget/legacy/tcm_usb_gadget.h|  133 --
 fs/configfs

[PATCH 15/15] usb: gadget: f_tcm: add configfs support

[Andrzej Pietrasiewicz]

Allow using the tcm function as a component of a gadget composed with
ConfigFS.

Signed-off-by: Andrzej Pietrasiewicz 
---
 Documentation/ABI/testing/configfs-usb-gadget-tcm |  6 ++
 drivers/usb/gadget/Kconfig| 14 +
 drivers/usb/gadget/function/f_tcm.c   | 70 ++-
 3 files changed, 87 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-tcm

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-tcm 
b/Documentation/ABI/testing/configfs-usb-gadget-tcm
new file mode 100644
index 000..a29ed2d
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-tcm
@@ -0,0 +1,6 @@
+What:  /config/usb-gadget/gadget/functions/tcm.name
+Date:  Dec 2015
+KernelVersion: 4.5
+Description:
+   There are no attributes because all the configuration
+   is performed in the "target" subsystem of configfs.
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 1e97d8e..81bf660 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -454,6 +454,20 @@ config USB_CONFIGFS_F_PRINTER
  For more information, see Documentation/usb/gadget_printer.txt
  which includes sample code for accessing the device file.
 
+config USB_CONFIGFS_F_TCM
+   bool "USB Gadget Target Fabric"
+   depends on TARGET_CORE
+   depends on USB_CONFIGFS
+   select USB_LIBCOMPOSITE
+   select USB_F_TCM
+   help
+ This fabric is a USB gadget component. Two USB protocols are
+ supported that is BBB or BOT (Bulk Only Transport) and UAS
+ (USB Attached SCSI). BOT is advertised on alternative
+ interface 0 (primary) and UAS is on alternative interface 1.
+ Both protocols can work on USB2.0 and USB3.0.
+ UAS utilizes the USB 3.0 feature called streams support.
+
 source "drivers/usb/gadget/legacy/Kconfig"
 
 endchoice
diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index f957951..015d19c 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -23,6 +23,7 @@
 
 #include "tcm.h"
 #include "u_tcm.h"
+#include "configfs.h"
 
 #define TPG_INSTANCES  1
 
@@ -1408,8 +1409,15 @@ static struct se_portal_group *usbg_make_tpg(
if (!opts->ready)
goto unlock_dep;
 
-   if (opts->dependent && !try_module_get(opts->dependent))
-   goto unlock_dep;
+   if (opts->dependent) {
+   if (!try_module_get(opts->dependent))
+   goto unlock_dep;
+   } else {
+   ret = configfs_depend_item_unlocked(
+   &opts->func_inst.group.cg_item);
+   if (ret)
+   goto unlock_dep;
+   }
 
tpg = kzalloc(sizeof(struct usbg_tpg), GFP_KERNEL);
ret = -ENOMEM;
@@ -1443,7 +1451,11 @@ free_workqueue:
 free_tpg:
kfree(tpg);
 unref_dep:
-   module_put(opts->dependent);
+   if (opts->dependent)
+   module_put(opts->dependent);
+   else
+   configfs_undepend_item_unlocked(
+   &opts->func_inst.group.cg_item);
 unlock_dep:
mutex_unlock(&opts->dep_lock);
 unlock_inst:
@@ -1476,6 +1488,9 @@ static void usbg_drop_tpg(struct se_portal_group *se_tpg)
mutex_lock(&opts->dep_lock);
if (opts->dependent)
module_put(opts->dependent);
+   else
+   configfs_undepend_item_unlocked(
+   &opts->func_inst.group.cg_item);
mutex_unlock(&opts->dep_lock);
mutex_unlock(&tpg_instances_lock);
 
@@ -2199,6 +2214,28 @@ static int tcm_setup(struct usb_function *f,
return usbg_bot_setup(f, ctrl);
 }
 
+static inline struct f_tcm_opts *to_f_tcm_opts(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct f_tcm_opts,
+   func_inst.group);
+}
+
+static void tcm_attr_release(struct config_item *item)
+{
+   struct f_tcm_opts *opts = to_f_tcm_opts(item);
+
+   usb_put_function_instance(&opts->func_inst);
+}
+
+static struct configfs_item_operations tcm_item_ops = {
+   .release= tcm_attr_release,
+};
+
+static struct config_item_type tcm_func_type = {
+   .ct_item_ops= &tcm_item_ops,
+   .ct_owner   = THIS_MODULE,
+};
+
 static void tcm_free_inst(struct usb_function_instance *f)
 {
struct f_tcm_opts *opts;
@@ -2217,6 +2254,28 @@ static void tcm_free_inst(struct usb_function_instance 
*f)
kfree(opts);
 }
 
+static int tcm_register_callback(struct usb_function_instance *f)
+{
+   struct f_tcm_opts *opts = container_of(f, struct f_tcm_opts, func_inst);
+
+   mutex_lock(&opts->dep_lock);
+   opts->can_attach = true;
+   mutex_unlock(&opts->dep_lock);
+
+   return 0;
+}
+
+static void tcm_unregister_callback(struct usb_function_instance *f)
+{
+   s

[PATCH 01/15] fs: configfs: Add unlocked version of configfs_depend_item()

[Andrzej Pietrasiewicz]

From: Krzysztof Opasiak 

This change is necessary for the SCSI target usb gadget composed with
configfs. In this case configfs will be used for two different purposes:
to compose a usb gadget and to configure the target part. If an instance
of tcm function is created in $CONFIGFS_ROOT/usb_gadget//functions
a tpg can be created in $CONFIGFS_ROOT/target/usb_gadget//, but after
a tpg is created the tcm function must not be removed until its
corresponding tpg is gone. While the configfs_depend/undepend_item() are
meant exactly for creating this kind of dependencies, they are not suitable
if the other kernel subsystem happens to be another subsystem in configfs,
so this patch adds unlocked versions meant for configfs callbacks.

Signed-off-by: Krzysztof Opasiak 
[updated the commit log]
Signed-off-by: Andrzej Pietrasiewicz 
---
 fs/configfs/dir.c| 29 +
 include/linux/configfs.h |  9 +
 2 files changed, 38 insertions(+)

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index c81ce7f..1e1ae76 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1152,6 +1152,35 @@ void configfs_undepend_item(struct configfs_subsystem 
*subsys,
 }
 EXPORT_SYMBOL(configfs_undepend_item);
 
+int configfs_depend_item_unlocked(struct config_item *target)
+{
+   struct configfs_dirent *sd;
+   int ret = -ENOENT;
+
+   spin_lock(&configfs_dirent_lock);
+   BUG_ON(!target->ci_dentry);
+
+   sd = target->ci_dentry->d_fsdata;
+   if ((sd->s_type & CONFIGFS_DIR) &&
+   ((sd->s_type & CONFIGFS_USET_DROPPING) ||
+(sd->s_type & CONFIGFS_USET_CREATING)))
+   goto out_unlock_dirent_lock;
+
+   sd->s_dependent_count += 1;
+   ret = 0;
+
+out_unlock_dirent_lock:
+   spin_unlock(&configfs_dirent_lock);
+   return ret;
+}
+EXPORT_SYMBOL(configfs_depend_item_unlocked);
+
+void configfs_undepend_item_unlocked(struct config_item *target)
+{
+   configfs_undepend_item(NULL, target);
+}
+EXPORT_SYMBOL(configfs_undepend_item_unlocked);
+
 static int configfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t 
mode)
 {
int ret = 0;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index a8a335b..76b045d 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -202,4 +202,13 @@ void configfs_unregister_subsystem(struct 
configfs_subsystem *subsys);
 int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item 
*target);
 void configfs_undepend_item(struct configfs_subsystem *subsys, struct 
config_item *target);
 
+/*
+ * These functions can sleep and can alloc with GFP_KERNEL
+ * NOTE: These should be called only underneath configfs callbacks.
+ * WARNING: These cannot be called on newly created item
+ *(in make_group()/make_item callback)
+ */
+int configfs_depend_item_unlocked(struct config_item *target);
+void configfs_undepend_item_unlocked(struct config_item *target);
+
 #endif /* _CONFIGFS_H_ */
-- 
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 07/15] usb: gadget: tcm: use strtobool for a boolean value

[Andrzej Pietrasiewicz]

Simplify the function.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index a60ef8f..62b1217 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1496,14 +1496,12 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
 {
struct se_portal_group *se_tpg = to_tpg(item);
struct usbg_tpg  *tpg = container_of(se_tpg, struct usbg_tpg, se_tpg);
-   unsigned long op;
+   bool op;
ssize_t ret;
 
-   ret = kstrtoul(page, 0, &op);
-   if (ret < 0)
-   return -EINVAL;
-   if (op > 1)
-   return -EINVAL;
+   ret = strtobool(page, &op);
+   if (ret)
+   return ret;
 
if (op && tpg->gadget_connect) {
ret = -EINVAL;
-- 
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 08/15] usb: gadget: tcm: simplify attribute store function

[Andrzej Pietrasiewicz]

Simplify function code.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 62b1217..522acaf 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1503,27 +1503,19 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
if (ret)
return ret;
 
-   if (op && tpg->gadget_connect) {
-   ret = -EINVAL;
-   goto out;
-   }
-   if (!op && !tpg->gadget_connect) {
-   ret = -EINVAL;
-   goto out;
-   }
+   if ((op && tpg->gadget_connect) || (!op && !tpg->gadget_connect))
+   return -EINVAL;
 
-   if (op) {
+   if (op)
ret = usbg_attach(tpg);
-   if (ret)
-   goto out;
-   } else {
+   else
usbg_detach(tpg);
-   }
+   if (ret)
+   return ret;
+
tpg->gadget_connect = op;
 
return count;
-out:
-   return ret;
 }
 
 static ssize_t tcm_usbg_tpg_nexus_show(struct config_item *item, char *page)
-- 
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 06/15] usb: gadget: tcm: follow naming conventions

[Andrzej Pietrasiewicz]

Prepare for splitting tcm_usb_gadget into legacy gadget proper and f_tcm.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 556decf..a60ef8f 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -2045,7 +2045,7 @@ static void give_back_ep(struct usb_ep **pep)
ep->driver_data = NULL;
 }
 
-static int usbg_bind(struct usb_configuration *c, struct usb_function *f)
+static int tcm_bind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_uas*fu = to_f_uas(f);
struct usb_gadget   *gadget = c->cdev->gadget;
@@ -2118,7 +2118,7 @@ ep_fail:
return -ENOTSUPP;
 }
 
-static void usbg_unbind(struct usb_configuration *c, struct usb_function *f)
+static void tcm_unbind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_uas *fu = to_f_uas(f);
 
@@ -2132,7 +2132,7 @@ struct guas_setup_wq {
unsigned int alt;
 };
 
-static void usbg_delayed_set_alt(struct work_struct *wq)
+static void tcm_delayed_set_alt(struct work_struct *wq)
 {
struct guas_setup_wq *work = container_of(wq, struct guas_setup_wq,
work);
@@ -2153,7 +2153,7 @@ static void usbg_delayed_set_alt(struct work_struct *wq)
usb_composite_setup_continue(fu->function.config->cdev);
 }
 
-static int usbg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
+static int tcm_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
 {
struct f_uas *fu = to_f_uas(f);
 
@@ -2163,7 +2163,7 @@ static int usbg_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
work = kmalloc(sizeof(*work), GFP_ATOMIC);
if (!work)
return -ENOMEM;
-   INIT_WORK(&work->work, usbg_delayed_set_alt);
+   INIT_WORK(&work->work, tcm_delayed_set_alt);
work->fu = fu;
work->alt = alt;
schedule_work(&work->work);
@@ -2172,7 +2172,7 @@ static int usbg_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
return -EOPNOTSUPP;
 }
 
-static void usbg_disable(struct usb_function *f)
+static void tcm_disable(struct usb_function *f)
 {
struct f_uas *fu = to_f_uas(f);
 
@@ -2183,7 +2183,7 @@ static void usbg_disable(struct usb_function *f)
fu->flags = 0;
 }
 
-static int usbg_setup(struct usb_function *f,
+static int tcm_setup(struct usb_function *f,
const struct usb_ctrlrequest *ctrl)
 {
struct f_uas *fu = to_f_uas(f);
@@ -2194,7 +2194,7 @@ static int usbg_setup(struct usb_function *f,
return usbg_bot_setup(f, ctrl);
 }
 
-static int usbg_cfg_bind(struct usb_configuration *c)
+static int tcm_bind_config(struct usb_configuration *c)
 {
struct f_uas *fu;
int ret;
@@ -2203,11 +2203,11 @@ static int usbg_cfg_bind(struct usb_configuration *c)
if (!fu)
return -ENOMEM;
fu->function.name = "Target Function";
-   fu->function.bind = usbg_bind;
-   fu->function.unbind = usbg_unbind;
-   fu->function.set_alt = usbg_set_alt;
-   fu->function.setup = usbg_setup;
-   fu->function.disable = usbg_disable;
+   fu->function.bind = tcm_bind;
+   fu->function.unbind = tcm_unbind;
+   fu->function.set_alt = tcm_set_alt;
+   fu->function.setup = tcm_setup;
+   fu->function.disable = tcm_disable;
fu->function.strings = tcm_strings;
fu->tpg = the_only_tpg_I_currently_have;
 
@@ -2241,7 +2241,7 @@ static int usb_target_bind(struct usb_composite_dev *cdev)
usbg_us_strings[USB_G_STR_CONFIG].id;
 
ret = usb_add_config(cdev, &usbg_config_driver,
-   usbg_cfg_bind);
+   tcm_bind_config);
if (ret)
return ret;
usb_composite_overwrite_options(cdev, &coverwrite);
-- 
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 03/15] tcm_usb_gadget: Fix nexus leak

[Andrzej Pietrasiewicz]

From: Nicholas Bellinger 

This patch adds the missing tcm_usbg_drop_nexus() to properly
release tcm_usbg_nexus memory during typical ->fabric_drop_tpg()
callback shutdown.

Reported-by: Andrzej Pietrasiewicz 
Cc: Andrzej Pietrasiewicz 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Nicholas Bellinger 
[split unrelated changes into separate patches]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index d22e188..dcc9b1a 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1423,11 +1423,14 @@ static struct se_portal_group *usbg_make_tpg(
return &tpg->se_tpg;
 }
 
+static int tcm_usbg_drop_nexus(struct usbg_tpg *);
+
 static void usbg_drop_tpg(struct se_portal_group *se_tpg)
 {
struct usbg_tpg *tpg = container_of(se_tpg,
struct usbg_tpg, se_tpg);
 
+   tcm_usbg_drop_nexus(tpg);
core_tpg_deregister(se_tpg);
destroy_workqueue(tpg->workqueue);
kfree(tpg);
-- 
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 13/15] usb: gadget: f_tcm: remove redundant singleton

[Andrzej Pietrasiewicz]

The only instance is guaranteed with TPG_INSTANCES defined to 1.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c | 9 -
 drivers/usb/gadget/function/tcm.h   | 2 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index b92417b..356d8fd 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1377,8 +1377,6 @@ static int usbg_init_nodeacl(struct se_node_acl *se_nacl, 
const char *name)
return 0;
 }
 
-struct usbg_tpg *the_only_tpg_I_currently_have;
-
 static struct se_portal_group *usbg_make_tpg(
struct se_wwn *wwn,
struct config_group *group,
@@ -1396,11 +1394,6 @@ static struct se_portal_group *usbg_make_tpg(
return ERR_PTR(-EINVAL);
if (kstrtoul(name + 5, 0, &tpgt) || tpgt > UINT_MAX)
return ERR_PTR(-EINVAL);
-   if (the_only_tpg_I_currently_have) {
-   pr_err("Until the gadget framework can't handle multiple\n");
-   pr_err("gadgets, you can't do this here.\n");
-   return ERR_PTR(-EBUSY);
-   }
ret = -ENODEV;
mutex_lock(&tpg_instances_lock);
for (i = 0; i < TPG_INSTANCES; ++i)
@@ -1443,7 +1436,6 @@ static struct se_portal_group *usbg_make_tpg(
tpg->fi = tpg_instances[i].func_inst;
mutex_unlock(&opts->dep_lock);
mutex_unlock(&tpg_instances_lock);
-   the_only_tpg_I_currently_have = tpg;
return &tpg->se_tpg;
 
 free_workqueue:
@@ -1488,7 +1480,6 @@ static void usbg_drop_tpg(struct se_portal_group *se_tpg)
mutex_unlock(&tpg_instances_lock);
 
kfree(tpg);
-   the_only_tpg_I_currently_have = NULL;
 }
 
 static struct se_wwn *usbg_make_tport(
diff --git a/drivers/usb/gadget/function/tcm.h 
b/drivers/usb/gadget/function/tcm.h
index 0b8ff6d..b75c6f3 100644
--- a/drivers/usb/gadget/function/tcm.h
+++ b/drivers/usb/gadget/function/tcm.h
@@ -129,6 +129,4 @@ struct f_uas {
struct usb_request  *bot_req_out;
 };
 
-extern struct usbg_tpg *the_only_tpg_I_currently_have;
-
 #endif /* __TARGET_USB_GADGET_H__ */
-- 
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 14/15] usb: gadget: f_tcm: use usb_gstrings_attach

[Andrzej Pietrasiewicz]

Do not directly use file static strings definitions in instances of f_tcm.
Instead use usb_gstrings_attach.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index 356d8fd..f957951 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -2044,6 +2044,7 @@ static void give_back_ep(struct usb_ep **pep)
 static int tcm_bind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_uas*fu = to_f_uas(f);
+   struct usb_string   *us;
struct usb_gadget   *gadget = c->cdev->gadget;
struct usb_ep   *ep;
struct f_tcm_opts   *opts;
@@ -2058,16 +2059,12 @@ static int tcm_bind(struct usb_configuration *c, struct 
usb_function *f)
return -ENODEV;
}
mutex_unlock(&opts->dep_lock);
-
-   if (tcm_us_strings[0].id == 0) {
-   ret = usb_string_ids_tab(c->cdev, tcm_us_strings);
-   if (ret < 0)
-   return ret;
-
-   bot_intf_desc.iInterface = tcm_us_strings[USB_G_STR_INT_BBB].id;
-   uasp_intf_desc.iInterface =
-   tcm_us_strings[USB_G_STR_INT_UAS].id;
-   }
+   us = usb_gstrings_attach(c->cdev, tcm_strings,
+   ARRAY_SIZE(tcm_us_strings));
+   if (IS_ERR(us))
+   return PTR_ERR(us);
+   bot_intf_desc.iInterface = us[USB_G_STR_INT_BBB].id;
+   uasp_intf_desc.iInterface = us[USB_G_STR_INT_UAS].id;
 
iface = usb_interface_id(c, f);
if (iface < 0)
@@ -2325,7 +2322,6 @@ static struct usb_function *tcm_alloc(struct 
usb_function_instance *fi)
fu->function.set_alt = tcm_set_alt;
fu->function.setup = tcm_setup;
fu->function.disable = tcm_disable;
-   fu->function.strings = tcm_strings;
fu->function.free_func = tcm_free;
fu->tpg = tpg_instances[i].tpg;
mutex_unlock(&tpg_instances_lock);
-- 
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 11/15] usb: gadget: tcm: convert to use new function registration interface

[Andrzej Pietrasiewicz]

Convert the only user of old tcm function interface so that the old
interface can be removed.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/Kconfig  |  1 +
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 61 +-
 2 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/legacy/Kconfig 
b/drivers/usb/gadget/legacy/Kconfig
index 4d682ad..a23d1b9 100644
--- a/drivers/usb/gadget/legacy/Kconfig
+++ b/drivers/usb/gadget/legacy/Kconfig
@@ -250,6 +250,7 @@ config USB_GADGET_TARGET
tristate "USB Gadget Target Fabric Module"
depends on TARGET_CORE
select USB_LIBCOMPOSITE
+   select USB_F_TCM
help
  This fabric is an USB gadget. Two USB protocols are supported that is
  BBB or BOT (Bulk Only Transport) and UAS (USB Attached SCSI). BOT is
diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index f042df4..645800d 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -21,11 +21,9 @@
 #include 
 #include 
 
-USB_GADGET_COMPOSITE_OPTIONS();
+#include "u_tcm.h"
 
-/* #include to be removed when new function registration interface is used  */
-#define USBF_TCM_INCLUDED
-#include "../function/f_tcm.c"
+USB_GADGET_COMPOSITE_OPTIONS();
 
 #define UAS_VENDOR_ID  0x0525  /* NetChip */
 #define UAS_PRODUCT_ID 0xa4a5  /* Linux-USB File-backed Storage Gadget */
@@ -60,8 +58,31 @@ static struct usb_gadget_strings *usbg_strings[] = {
NULL,
 };
 
+static struct usb_function_instance *fi_tcm;
+static struct usb_function *f_tcm;
+
 static int guas_unbind(struct usb_composite_dev *cdev)
 {
+   if (!IS_ERR_OR_NULL(f_tcm))
+   usb_put_function(f_tcm);
+
+   return 0;
+}
+
+static int tcm_do_config(struct usb_configuration *c)
+{
+   int status;
+
+   f_tcm = usb_get_function(fi_tcm);
+   if (IS_ERR(f_tcm))
+   return PTR_ERR(f_tcm);
+
+   status = usb_add_function(c, f_tcm);
+   if (status < 0) {
+   usb_put_function(f_tcm);
+   return status;
+   }
+
return 0;
 }
 
@@ -71,6 +92,9 @@ static struct usb_configuration usbg_config_driver = {
.bmAttributes   = USB_CONFIG_ATT_SELFPOWER,
 };
 
+static int usbg_attach(struct usb_function_instance *f);
+static void usbg_detach(struct usb_function_instance *f);
+
 static int usb_target_bind(struct usb_composite_dev *cdev)
 {
int ret;
@@ -87,8 +111,7 @@ static int usb_target_bind(struct usb_composite_dev *cdev)
usbg_config_driver.iConfiguration =
usbg_us_strings[USB_G_STR_CONFIG].id;
 
-   ret = usb_add_config(cdev, &usbg_config_driver,
-   tcm_bind_config);
+   ret = usb_add_config(cdev, &usbg_config_driver, tcm_do_config);
if (ret)
return ret;
usb_composite_overwrite_options(cdev, &coverwrite);
@@ -104,25 +127,43 @@ static struct usb_composite_driver usbg_driver = {
.unbind = guas_unbind,
 };
 
-static int usbg_attach(struct usbg_tpg *tpg)
+static int usbg_attach(struct usb_function_instance *f)
 {
return usb_composite_probe(&usbg_driver);
 }
 
-static void usbg_detach(struct usbg_tpg *tpg)
+static void usbg_detach(struct usb_function_instance *f)
 {
usb_composite_unregister(&usbg_driver);
 }
 
 static int __init usb_target_gadget_init(void)
 {
-   return target_register_template(&usbg_ops);
+   struct f_tcm_opts *tcm_opts;
+
+   fi_tcm = usb_get_function_instance("tcm");
+   if (IS_ERR(fi_tcm))
+   return PTR_ERR(fi_tcm);
+
+   tcm_opts = container_of(fi_tcm, struct f_tcm_opts, func_inst);
+   mutex_lock(&tcm_opts->dep_lock);
+   tcm_opts->tcm_register_callback = usbg_attach;
+   tcm_opts->tcm_unregister_callback = usbg_detach;
+   tcm_opts->dependent = THIS_MODULE;
+   tcm_opts->can_attach = true;
+   mutex_unlock(&tcm_opts->dep_lock);
+
+   fi_tcm->set_inst_name(fi_tcm, "tcm-legacy");
+
+   return 0;
 }
 module_init(usb_target_gadget_init);
 
 static void __exit usb_target_gadget_exit(void)
 {
-   target_unregister_template(&usbg_ops);
+   if (!IS_ERR_OR_NULL(fi_tcm))
+   usb_put_function_instance(fi_tcm);
+
 }
 module_exit(usb_target_gadget_exit);
 
-- 
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 05/15] usb: gadget: tcm: split string definitions into function and device

[Andrzej Pietrasiewicz]

Prepare for factoring out f_tcm from a legacy gadget.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 25 +
 drivers/usb/gadget/legacy/tcm_usb_gadget.h |  3 +--
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index cbba4b9..556decf 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1990,13 +1990,13 @@ static struct usb_device_descriptor usbg_device_desc = {
.bNumConfigurations =   1,
 };
 
+#define USB_G_STR_CONFIG USB_GADGET_FIRST_AVAIL_IDX
+
 static struct usb_string   usbg_us_strings[] = {
[USB_GADGET_MANUFACTURER_IDX].s = "Target Manufactor",
[USB_GADGET_PRODUCT_IDX].s  = "Target Product",
[USB_GADGET_SERIAL_IDX].s   = "0001",
[USB_G_STR_CONFIG].s= "default config",
-   [USB_G_STR_INT_UAS].s   = "USB Attached SCSI",
-   [USB_G_STR_INT_BBB].s   = "Bulk Only Transport",
{ },
 };
 
@@ -2010,6 +2010,22 @@ static struct usb_gadget_strings *usbg_strings[] = {
NULL,
 };
 
+static struct usb_string   tcm_us_strings[] = {
+   [USB_G_STR_INT_UAS].s   = "USB Attached SCSI",
+   [USB_G_STR_INT_BBB].s   = "Bulk Only Transport",
+   { },
+};
+
+static struct usb_gadget_strings tcm_stringtab = {
+   .language = 0x0409,
+   .strings = tcm_us_strings,
+};
+
+static struct usb_gadget_strings *tcm_strings[] = {
+   &tcm_stringtab,
+   NULL,
+};
+
 static int guas_unbind(struct usb_composite_dev *cdev)
 {
return 0;
@@ -2192,10 +2208,11 @@ static int usbg_cfg_bind(struct usb_configuration *c)
fu->function.set_alt = usbg_set_alt;
fu->function.setup = usbg_setup;
fu->function.disable = usbg_disable;
+   fu->function.strings = tcm_strings;
fu->tpg = the_only_tpg_I_currently_have;
 
-   bot_intf_desc.iInterface = usbg_us_strings[USB_G_STR_INT_BBB].id;
-   uasp_intf_desc.iInterface = usbg_us_strings[USB_G_STR_INT_UAS].id;
+   bot_intf_desc.iInterface = tcm_us_strings[USB_G_STR_INT_BBB].id;
+   uasp_intf_desc.iInterface = tcm_us_strings[USB_G_STR_INT_UAS].id;
 
ret = usb_add_function(c, &fu->function);
if (ret)
diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.h 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.h
index 0b749e1..f1b69e2 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.h
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.h
@@ -16,8 +16,7 @@
 #define UASP_SS_EP_COMP_NUM_STREAMS (1 << UASP_SS_EP_COMP_LOG_STREAMS)
 
 enum {
-   USB_G_STR_CONFIG = USB_GADGET_FIRST_AVAIL_IDX,
-   USB_G_STR_INT_UAS,
+   USB_G_STR_INT_UAS = 0,
USB_G_STR_INT_BBB,
 };
 
-- 
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 12/15] usb: gadget: f_tcm: remove compatibility layer

[Andrzej Pietrasiewicz]

There are no old function interface users left.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c | 87 +++--
 1 file changed, 6 insertions(+), 81 deletions(-)

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index c4cb296..b92417b 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -24,8 +24,6 @@
 #include "tcm.h"
 #include "u_tcm.h"
 
-#ifndef USBF_TCM_INCLUDED
-
 #define TPG_INSTANCES  1
 
 struct tpg_instance {
@@ -36,7 +34,6 @@ struct tpg_instance {
 static struct tpg_instance tpg_instances[TPG_INSTANCES];
 
 static DEFINE_MUTEX(tpg_instances_lock);
-#endif
 
 static inline struct f_uas *to_f_uas(struct usb_function *f)
 {
@@ -1392,10 +1389,8 @@ static struct se_portal_group *usbg_make_tpg(
struct usbg_tpg *tpg;
unsigned long tpgt;
int ret;
-#ifndef USBF_TCM_INCLUDED
struct f_tcm_opts *opts;
unsigned i;
-#endif
 
if (strstr(name, "tpgt_") != name)
return ERR_PTR(-EINVAL);
@@ -1406,7 +1401,6 @@ static struct se_portal_group *usbg_make_tpg(
pr_err("gadgets, you can't do this here.\n");
return ERR_PTR(-EBUSY);
}
-#ifndef USBF_TCM_INCLUDED
ret = -ENODEV;
mutex_lock(&tpg_instances_lock);
for (i = 0; i < TPG_INSTANCES; ++i)
@@ -1423,26 +1417,16 @@ static struct se_portal_group *usbg_make_tpg(
 
if (opts->dependent && !try_module_get(opts->dependent))
goto unlock_dep;
-#endif
 
tpg = kzalloc(sizeof(struct usbg_tpg), GFP_KERNEL);
ret = -ENOMEM;
if (!tpg)
-#ifdef USBF_TCM_INCLUDED
-   return ERR_PTR(-ENOMEM);
-#else
goto unref_dep;
-#endif
mutex_init(&tpg->tpg_mutex);
atomic_set(&tpg->tpg_port_count, 0);
tpg->workqueue = alloc_workqueue("tcm_usb_gadget", 0, 1);
-   if (!tpg->workqueue) {
-#ifndef USBF_TCM_INCLUDED
+   if (!tpg->workqueue)
goto free_tpg;
-#endif
-   kfree(tpg);
-   return NULL;
-   }
 
tpg->tport = tport;
tpg->tport_tpgt = tpgt;
@@ -1452,23 +1436,16 @@ static struct se_portal_group *usbg_make_tpg(
 * pretend to be SAS..
 */
ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_SAS);
-   if (ret < 0) {
-#ifndef USBF_TCM_INCLUDED
+   if (ret < 0)
goto free_workqueue;
-#endif
-   destroy_workqueue(tpg->workqueue);
-   kfree(tpg);
-   return NULL;
-   }
-#ifndef USBF_TCM_INCLUDED
+
tpg_instances[i].tpg = tpg;
tpg->fi = tpg_instances[i].func_inst;
mutex_unlock(&opts->dep_lock);
mutex_unlock(&tpg_instances_lock);
-#endif
the_only_tpg_I_currently_have = tpg;
return &tpg->se_tpg;
-#ifndef USBF_TCM_INCLUDED
+
 free_workqueue:
destroy_workqueue(tpg->workqueue);
 free_tpg:
@@ -1481,7 +1458,6 @@ unlock_inst:
mutex_unlock(&tpg_instances_lock);
 
return ERR_PTR(ret);
-#endif
 }
 
 static int tcm_usbg_drop_nexus(struct usbg_tpg *);
@@ -1490,16 +1466,13 @@ static void usbg_drop_tpg(struct se_portal_group 
*se_tpg)
 {
struct usbg_tpg *tpg = container_of(se_tpg,
struct usbg_tpg, se_tpg);
-#ifndef USBF_TCM_INCLUDED
unsigned i;
struct f_tcm_opts *opts;
-#endif
 
tcm_usbg_drop_nexus(tpg);
core_tpg_deregister(se_tpg);
destroy_workqueue(tpg->workqueue);
 
-#ifndef USBF_TCM_INCLUDED
mutex_lock(&tpg_instances_lock);
for (i = 0; i < TPG_INSTANCES; ++i)
if (tpg_instances[i].tpg == tpg)
@@ -1513,7 +1486,7 @@ static void usbg_drop_tpg(struct se_portal_group *se_tpg)
module_put(opts->dependent);
mutex_unlock(&opts->dep_lock);
mutex_unlock(&tpg_instances_lock);
-#endif
+
kfree(tpg);
the_only_tpg_I_currently_have = NULL;
 }
@@ -2082,13 +2055,10 @@ static int tcm_bind(struct usb_configuration *c, struct 
usb_function *f)
struct f_uas*fu = to_f_uas(f);
struct usb_gadget   *gadget = c->cdev->gadget;
struct usb_ep   *ep;
-#ifndef USBF_TCM_INCLUDED
struct f_tcm_opts   *opts;
-#endif
int iface;
int ret;
 
-#ifndef USBF_TCM_INCLUDED
opts = container_of(f->fi, struct f_tcm_opts, func_inst);
 
mutex_lock(&opts->dep_lock);
@@ -2097,7 +2067,7 @@ static int tcm_bind(struct usb_configuration *c, struct 
usb_function *f)
return -ENODEV;
}
mutex_unlock(&opts->dep_lock);
-#endif
+
if (tcm_us_strings[0].id == 0) {
ret = usb_string_ids_tab(c->cdev, tcm_us_strings);
if (ret < 0)
@@ -2173,18 +2143,6 @@ ep_fail:
return -ENOTSUPP;
 }
 
-#ifdef USBF_TCM_INCLUDED
-
-static void tcm_old_

[PATCH 09/15] usb: gadget: tcm: factor out f_tcm

[Andrzej Pietrasiewicz]

Prepare for converting tcm to new function registration interface.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c| 2168 
 drivers/usb/gadget/function/tcm.h  |  132 ++
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2150 +--
 drivers/usb/gadget/legacy/tcm_usb_gadget.h |  132 --
 4 files changed, 2303 insertions(+), 2279 deletions(-)
 create mode 100644 drivers/usb/gadget/function/f_tcm.c
 create mode 100644 drivers/usb/gadget/function/tcm.h
 delete mode 100644 drivers/usb/gadget/legacy/tcm_usb_gadget.h

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
new file mode 100644
index 000..d1b602a
--- /dev/null
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -0,0 +1,2168 @@
+/* Target based USB-Gadget
+ *
+ * UAS protocol handling, target callbacks, configfs handling,
+ * BBB (USB Mass Storage Class Bulk-Only (BBB) and Transport protocol handling.
+ *
+ * Author: Sebastian Andrzej Siewior 
+ * License: GPLv2 as published by FSF.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tcm.h"
+
+static inline struct f_uas *to_f_uas(struct usb_function *f)
+{
+   return container_of(f, struct f_uas, function);
+}
+
+static void usbg_cmd_release(struct kref *);
+
+static inline void usbg_cleanup_cmd(struct usbg_cmd *cmd)
+{
+   kref_put(&cmd->ref, usbg_cmd_release);
+}
+
+/* Start bot.c code */
+
+static int bot_enqueue_cmd_cbw(struct f_uas *fu)
+{
+   int ret;
+
+   if (fu->flags & USBG_BOT_CMD_PEND)
+   return 0;
+
+   ret = usb_ep_queue(fu->ep_out, fu->cmd.req, GFP_ATOMIC);
+   if (!ret)
+   fu->flags |= USBG_BOT_CMD_PEND;
+   return ret;
+}
+
+static void bot_status_complete(struct usb_ep *ep, struct usb_request *req)
+{
+   struct usbg_cmd *cmd = req->context;
+   struct f_uas *fu = cmd->fu;
+
+   usbg_cleanup_cmd(cmd);
+   if (req->status < 0) {
+   pr_err("ERR %s(%d)\n", __func__, __LINE__);
+   return;
+   }
+
+   /* CSW completed, wait for next CBW */
+   bot_enqueue_cmd_cbw(fu);
+}
+
+static void bot_enqueue_sense_code(struct f_uas *fu, struct usbg_cmd *cmd)
+{
+   struct bulk_cs_wrap *csw = &fu->bot_status.csw;
+   int ret;
+   u8 *sense;
+   unsigned int csw_stat;
+
+   csw_stat = cmd->csw_code;
+
+   /*
+* We can't send SENSE as a response. So we take ASC & ASCQ from our
+* sense buffer and queue it and hope the host sends a REQUEST_SENSE
+* command where it learns why we failed.
+*/
+   sense = cmd->sense_iu.sense;
+
+   csw->Tag = cmd->bot_tag;
+   csw->Status = csw_stat;
+   fu->bot_status.req->context = cmd;
+   ret = usb_ep_queue(fu->ep_in, fu->bot_status.req, GFP_ATOMIC);
+   if (ret)
+   pr_err("%s(%d) ERR: %d\n", __func__, __LINE__, ret);
+}
+
+static void bot_err_compl(struct usb_ep *ep, struct usb_request *req)
+{
+   struct usbg_cmd *cmd = req->context;
+   struct f_uas *fu = cmd->fu;
+
+   if (req->status < 0)
+   pr_err("ERR %s(%d)\n", __func__, __LINE__);
+
+   if (cmd->data_len) {
+   if (cmd->data_len > ep->maxpacket) {
+   req->length = ep->maxpacket;
+   cmd->data_len -= ep->maxpacket;
+   } else {
+   req->length = cmd->data_len;
+   cmd->data_len = 0;
+   }
+
+   usb_ep_queue(ep, req, GFP_ATOMIC);
+   return;
+   }
+   bot_enqueue_sense_code(fu, cmd);
+}
+
+static void bot_send_bad_status(struct usbg_cmd *cmd)
+{
+   struct f_uas *fu = cmd->fu;
+   struct bulk_cs_wrap *csw = &fu->bot_status.csw;
+   struct usb_request *req;
+   struct usb_ep *ep;
+
+   csw->Residue = cpu_to_le32(cmd->data_len);
+
+   if (cmd->data_len) {
+   if (cmd->is_read) {
+   ep = fu->ep_in;
+   req = fu->bot_req_in;
+   } else {
+   ep = fu->ep_out;
+   req = fu->bot_req_out;
+   }
+
+   if (cmd->data_len > fu->ep_in->maxpacket) {
+   req->length = ep->maxpacket;
+   cmd->data_len -= ep->maxpacket;
+   } else {
+   req->length = cmd->data_len;
+   cmd->data_len = 0;
+   }
+   req->complete = bot_err_compl;
+   req->context = cmd;
+   req->buf = fu->cmd.buf;
+   usb_ep_queue(ep, req, GFP_KERNEL);
+   } else {
+   bot_enqueue_sense_code(fu, cmd);
+   }
+}
+
+static int bot_send_status(struct usbg_cmd *cmd, bool moved_data)
+{
+   struct f_uas *fu = cmd->fu;
+   struct bulk_

Re: [PATCH 00/15] Equivalent of tcm_usb_gadget with configfs

[Sebastian Andrzej Siewior]

On 10/20/2015 02:32 PM, Andrzej Pietrasiewicz wrote:
> Dear All,
> 
> This series adds support to tcm usb gadget for composing it with configfs.

oh great. With this you could have two tcm functions right? (that was
one of the limitations of the legacy gadget due to the API we had).

I will try to take a look on this sometime next week…

Sebastian
--
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 00/15] Equivalent of tcm_usb_gadget with configfs

[Andrzej Pietrasiewicz]

W dniu 20.10.2015 o 14:40, Sebastian Andrzej Siewior pisze:

On 10/20/2015 02:32 PM, Andrzej Pietrasiewicz wrote:

Dear All,

This series adds support to tcm usb gadget for composing it with configfs.


oh great. With this you could have two tcm functions right? (that was
one of the limitations of the legacy gadget due to the API we had).



Yes and no :O

I have prepared the series with more instances of tcm in mind, but
the number of instances is #defined as 1.

The original limitation I believe comes from the fact that the
tcm function was realized in a legacy tcm_usb_gadget and there
is no way to load a kernel module more than once. Now the usb tcm
function implementation is factored out into f_tcm.c proper.



I will try to take a look on this sometime next week…


Please do!

AP

--
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/2] USB: serial: cp210x: Implement 16-bit register access functions

[Konstantin Shkolnyy]

On Tue, Oct 20, 2015 at 2:45 AM, Johan Hovold  wrote:
[...]
> Instead of adding the new helpers to read u16 as a prerequisite for
> fixing the broken cp2108 support, just reuse the current config register
> helpers for now (in order to keep the fixes minimal and potentially
> backportable). Once the fixes are in place, feel free to clean up the
> remaining register accesses.

The current helpers take "port" as a parameter. You pointed out
previously that port shouldn't be used in probe(). That made me
implement new helpers cp210x_write_u16_reg and cp210x_read_u16_reg
that don't use port. Probe() now calls cp210x_activate_workarounds
which in turn calls these new helpers.

An alternative would be to call usb_control_msg from
cp210x_activate_workarounds, but I think it would make it look pretty
ugly.
--
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/2] USB: serial: cp210x: Implement 16-bit register access functions

[Johan Hovold]

On Tue, Oct 20, 2015 at 07:52:31AM -0500, Konstantin Shkolnyy wrote:
> On Tue, Oct 20, 2015 at 2:45 AM, Johan Hovold  wrote:
> [...]
> > Instead of adding the new helpers to read u16 as a prerequisite for
> > fixing the broken cp2108 support, just reuse the current config register
> > helpers for now (in order to keep the fixes minimal and potentially
> > backportable). Once the fixes are in place, feel free to clean up the
> > remaining register accesses.
> 
> The current helpers take "port" as a parameter. You pointed out
> previously that port shouldn't be used in probe(). That made me
> implement new helpers cp210x_write_u16_reg and cp210x_read_u16_reg
> that don't use port. Probe() now calls cp210x_activate_workarounds
> which in turn calls these new helpers.

Oh, that's right.

> An alternative would be to call usb_control_msg from
> cp210x_activate_workarounds, but I think it would make it look pretty
> ugly.

Or you move the quirk-detect (and private data allocation) to port_probe
instead (and remove startup/release). These devices have exactly one
port per interface, so you wouldn't introduce any redundancy.

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: [PATCH] usb: chipidea: set unique names to requested irqs

[Vladimir Zapolskiy]

On 20.10.2015 09:05, Peter Chen wrote:
> On Mon, Oct 19, 2015 at 07:00:26PM +0300, Vladimir Zapolskiy wrote:
>> This change allows to get a driver instance of usb controller, which
>> registers an irq, now the interrupt names are unique:
>>
>> # cat /proc/interrupts | grep ci_
>>  72:   0   0   0   0GIC  72  ci_hdrc.0
>>  75:2096   0   0   0GIC  75  ci_hdrc.1
>>
>> Signed-off-by: Vladimir Zapolskiy 
>> ---
>>  drivers/usb/chipidea/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
>> index 3feebf7..f2d2e5c 100644
>> --- a/drivers/usb/chipidea/core.c
>> +++ b/drivers/usb/chipidea/core.c
>> @@ -917,7 +917,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>>  
>>  platform_set_drvdata(pdev, ci);
>>  ret = devm_request_irq(dev, ci->irq, ci_irq, IRQF_SHARED,
>> -ci->platdata->name, ci);
>> +   dev_name(dev), ci);
>>  if (ret)
>>  goto stop;
>>  
>> -- 
>> 2.5.0
>>
> 
> The current code uses glue layer's device name, what's the problem
> for that?
> 
> root@imx6qpsabreauto:~# cat /proc/interrupts | grep usb
> 74:  0   GIC  74  2184200.usb
> 75:  3   GIC  75  2184000.usb
> 

Ok, then please ignore this change, I found it on an older kernel version.

--
With best wishes,
Vladimir
--
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] On-demand device probing

[Rob Herring]

On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki  wrote:
> On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki  
>> wrote:
>> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse  
>> >> wrote:
>> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> >> > But the point I'm making is that we are working towards *fixing* 
>> >> >> > that,
>> >> >> > and *not* using DT-specific code in places where we should be using 
>> >> >> > the
>> >> >> > generic APIs.
>> >> >>
>> >> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> >> me) that we don't want to have the subsystems having knowledge of how
>> >> >> they are bound to a specific firmware which is what you seem to imply
>> >> >> here.
>> >> >
>> >> > I don't know that there *is* a coherent plan here to address it all.
>> >> >
>> >> > Certainly, we *will* need subsystems to have firmware-specific
>> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> >> > describe GPIO, and properties which reference GPIO pins are intended to
>> >> > work through that — while in DT, properties which reference GPIO pins
>> >> > will have different contents. They'll be compatible at the driver
>> >> > level, in the sense that there's a call to get a given GPIO given the
>> >> > property name, but the subsystems *will* be doing different things
>> >> > behind the scenes.
>> >> >
>> >> > My plan, such as it is, is to go through the leaf-node drivers which
>> >> > almost definitely *should* be firmware-agnostic, and convert those. And
>> >> > then take stock of what we have left, and work out what, if anything,
>> >> > still needs to be done.
>> >>
>> >> Many cases are already agnostic in the drivers in terms of the *_get()
>> >> functions. Some are DT specific, but probably because those subsystems
>> >> are new and DT only. In any case, I don't think these 1 line changes
>> >> do anything to make doing conversions here harder.
>> >>
>> >> >> It seems like we're going to have to refactor these bits of code when
>> >> >> they get generalised anyway so I'm not sure that the additional cost
>> >> >> here is that big.
>> >> >
>> >> > That's an acceptable answer — "we're adding legacy code here but we
>> >> > know it's going to be refactored anyway". If that's true, all it takes
>> >> > is a note in the commit comment to that effect. That's different from
>> >> > having not thought about it :)
>> >>
>> >> Considering at one point we did create a fwnode based API, we did
>> >> think about it. Plus there was little input from ACPI folks as to
>> >> whether the change was even useful for ACPI case.
>> >
>> > Well, sorry, but who was asking whom, specifically?
>>
>> You and linux-acpi have been copied on v2 and later of the entire
>> series I think.
>
> Yes, but it wasn't like a direct request, say "We need your input, so can you
> please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> which case I'd prioritize that before other things I needed to take care of.

Fair enough. Can you please review and comment on v7 of the series? We
can discuss at KS as well.

>> > The underlying problem is present in ACPI too and we don't really have a 
>> > good
>> > solution for it.  We might benefit from a common one if it existed.
>>
>> The problem for DT is we don't generically know what are the
>> dependencies at a core level. We could know some or most dependencies
>> if phandles (links to other nodes) were typed, but they are not. If
>> the core had this information, we could simply control the device
>> creation to order probing. Instead, this information is encoded into
>> the bindings and binding parsing resides in the subsystems. That
>> parsing happens during probe of the client side and is done by the
>> subsystems (for common bindings). Since we already do the parsing at
>> this point, it is a convenient place to trigger the probe of the
>> dependency. Is ACPI going to be similar in this regard?
>
> It is similar in some ways.  For example, if a device's functionality depends
> on an I2C resource (connection), the core doesn't know that at the device
> creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

So you will need to create devices, defer their probing and then probe
on demand as well unless you have other ideas how you would do it.

> There is a _DEP object in ACPI that can be used by firmware to tell the OS
> about those dependencies, but there's no way in the driver core to use that
> information anyway today.

I would think that the equivalent function for ACPI to of_device_probe
could process these if they are generic and you can associate the
dependency to a struct device.

>> Fundamentally, it is a question of probe devices when their
>> dependencies are present or drivers ensure their dependencies are
>> ready. IIRC, init systems went thru a

Re: [PATCH 1/2] USB: serial: cp210x: Implement 16-bit register access functions

[Konstantin Shkolnyy]

On Tue, Oct 20, 2015 at 8:02 AM, Johan Hovold  wrote:
> On Tue, Oct 20, 2015 at 07:52:31AM -0500, Konstantin Shkolnyy wrote:
>> On Tue, Oct 20, 2015 at 2:45 AM, Johan Hovold  wrote:
>> [...]
>> > Instead of adding the new helpers to read u16 as a prerequisite for
>> > fixing the broken cp2108 support, just reuse the current config register
>> > helpers for now (in order to keep the fixes minimal and potentially
>> > backportable). Once the fixes are in place, feel free to clean up the
>> > remaining register accesses.
>>
>> The current helpers take "port" as a parameter. You pointed out
>> previously that port shouldn't be used in probe(). That made me
>> implement new helpers cp210x_write_u16_reg and cp210x_read_u16_reg
>> that don't use port. Probe() now calls cp210x_activate_workarounds
>> which in turn calls these new helpers.
>
> Oh, that's right.
>
>> An alternative would be to call usb_control_msg from
>> cp210x_activate_workarounds, but I think it would make it look pretty
>> ugly.
>
> Or you move the quirk-detect (and private data allocation) to port_probe
> instead (and remove startup/release). These devices have exactly one
> port per interface, so you wouldn't introduce any redundancy.

OK, how about this:
patch #1
- attach/release replaced with port_probe/port_release;
- changes in the code using the "private" data since it has moved from
serial to port;
- cp210x_activate_workarounds in the port_probe, using the current helpers;
- a new helper cp210x_get_line_ctl that calls the current helper and
swaps the bytes.
patch #2
- sending "purge" from close, using the current helper.

However, the Tx queue bug fixed by the "purge" doesn't have a
detection method. We only know that it exists in the same cp2108 that
has the "byte swap" bug. So the "purge" is activated by the same "byte
swap" flag and  patch #2 depends on patch #1. Also, there is no reason
to only apply one of the patches. Do you think we can merge these
patches?
--
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

Fwd: linux-image-4.3.0-rc5-amd64 fails to attach usb storage device

[Jos van Wolput]

 Forwarded Message 
Subject: linux-image-4.3.0-rc5-amd64 fails to attach usb storage device
Date: Tue, 20 Oct 2015 12:01:41 +0800
From: Jos van Wolput 
Reply-To: wol...@on.nl
To: Debian Bug Tracking System 

Package: linux-image-4.3.0-rc5-amd64
Version: 4.3~rc5-1~exp1
Severity: important

Dear Maintainer,

After upgrading linux-image-4.2.0-1-amd64 (4.2.3-2) from unstable to 
linux-image-4.3.0-rc5-amd64 from experimental my Verbatim usb flash drive
is detected but fails to attach.
Using kernel 4.2.3-2 this device is properly detected and attached.

Please see the attached kernel.log

-- System Information:
Debian Release: sid + experimental
Architecture: amd64 (x86_64)
Kernel: linux-image-4.3.0-rc5-amd64
Systemd: 227-2

Kind regards,
Jos v.Wolput




Oct 20 11:34:21 debian kernel: [  101.305777] usb-storage 2-2:1.0: USB Mass Storage device detected
Oct 20 11:34:21 debian kernel: [  101.306000] scsi host6: usb-storage 2-2:1.0
Oct 20 11:34:21 debian kernel: [  101.306240] usbcore: registered new interface driver usb-storage
Oct 20 11:34:21 debian kernel: [  101.335548] usbcore: registered new interface driver uas
Oct 20 11:34:22 debian kernel: [  102.838335] scsi 6:0:0:0: Direct-Access Verbatim   PQ: 0 ANSI: 4
Oct 20 11:34:22 debian kernel: [  102.838737] [ cut here ]
Oct 20 11:34:22 debian kernel: [  102.838755] WARNING: CPU: 0 PID: 100 at /build/linux-HFgDpK/linux-4.3~rc5/kernel/kmod.c:140 __request_module+0x1e9/0x290()
Oct 20 11:34:22 debian kernel: [  102.838759] Modules linked in: uas usb_storage xt_recent nf_log_ipv4 nf_log_common snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device xt_tcpudp ip6table_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_TCPMSS xt_LOG ipt_REJECT nf_reject_ipv4 iptable_mangle xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables binfmt_misc zram zsmalloc hid_generic usbhid hid arc4 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media rt2800pci rt2800mmio rt2800lib rt2x00pci rt2x00mmio joydev rt2x00lib eeprom_93cx6 mac80211 tg3 snd_hda_codec_realtek pcmcia kvm_amd cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ptp pps_core libphy kvm psmouse crc_ccitt snd_hda_intel rfkill pcspkr snd_hda_codec yenta_socket evdev snd_hda_core serio_raw pcmcia_rsrc snd_hwdep pcmcia_core snd_pcm_oss snd_mixer_oss k10temp snd_pcm ohci_pci sp5100_tco i2c_piix4 sr_mod ohci_hcd snd_timer ehci_pci cdrom snd ehci_hcd soundcore sg usbcore usb_common shpchp battery ene_ir rc_core wmi ac video button acpi_cpufreq processor loop parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod ahci libahci radeon libata i2c_algo_bit drm_kms_helper scsi_mod ttm drm thermal lz4 lz4_compress
Oct 20 11:34:22 debian kernel: [  102.838926] CPU: 0 PID: 100 Comm: kworker/u4:4 Not tainted 4.3.0-rc5-amd64 #1 Debian 4.3~rc5-1~exp1
Oct 20 11:34:22 debian kernel: [  102.838930] Hardware name: Acer TravelMate 4530 /Elgon   , BIOS V1.11 08/06/2008
Oct 20 11:34:22 debian kernel: [  102.838938] Workqueue: events_unbound async_run_entry_fn
Oct 20 11:34:22 debian kernel: [  102.838943]  817f5230 812c0349  8106ee11
Oct 20 11:34:22 debian kernel: [  102.838949]  a00de839 8800b8287d70 0001 88009cefa168
Oct 20 11:34:22 debian kernel: [  102.838954]   81081e99 88012d4c85c0 88012548bba0
Oct 20 11:34:22 debian kernel: [  102.838960] Call Trace:
Oct 20 11:34:22 debian kernel: [  102.838974]  [] ? dump_stack+0x40/0x57
Oct 20 11:34:22 debian kernel: [  102.838980]  [] ? warn_slowpath_common+0x81/0xb0
Oct 20 11:34:22 debian kernel: [  102.838989]  [] ? __request_module+0x1e9/0x290
Oct 20 11:34:22 debian kernel: [  102.838995]  [] ? mutex_lock+0xe/0x30
Oct 20 11:34:22 debian kernel: [  102.839004]  [] ? kernfs_activate+0x65/0xe0
Oct 20 11:34:22 debian kernel: [  102.839010]  [] ? kernfs_add_one+0x100/0x160
Oct 20 11:34:22 debian kernel: [  102.839048]  [] ? scsi_dh_lookup+0x29/0x40 [scsi_mod]
Oct 20 11:34:22 debian kernel: [  102.839067]  [] ? scsi_dh_add_device+0xca/0xf0 [scsi_mod]
Oct 20 11:34:22 debian kernel: [  102.839085]  [] ? scsi_sysfs_add_sdev+0xb8/0x280 [scsi_mod]
Oct 20 11:34:22 debian kernel: [  102.839101]  [] ? do_scan_async+0x116/0x160 [scsi_mod]
Oct 20 11:34:22 debian kernel: [  102.839107]  [] ? async_run_entry_fn+0x45/0x140
Oct 20 11:34:22 debian kernel: [  102.839113]  [] ? process_one_work+0x14a/0x3b0
Oct 20 11:34:22 debian kernel: [  102.839118]  [] ? worker_thread+0x4d/0x450
Oct 20 11:34:22 debian kernel: [  102.839124]  [] ? rescuer_thread+0x2e0/0x2e0
Oct 20 11:34:22 debian kernel: [  102.839130]  [] ? kthread+0xbd/0xe0
Oct 20 11:34:22 debian kernel: [  102.839136]  [] ? kthread_park+0x50/0x50
Oct 20 11:34:22 debian kernel: [  102.839143]  [] ? ret_from_fork+0x3f/0x7

Fwd: [Bug 106321] linux-kernel-4.3-rc5 fails to attach usb storage device

[Jos van Wolput]

 Forwarded Message 
Subject: [Bug 106321] linux-kernel-4.3-rc5 fails to attach usb storage device
Date: Tue, 20 Oct 2015 13:48:54 +
From: bugzilla-dae...@bugzilla.kernel.org
To: wol...@on.nl

https://bugzilla.kernel.org/show_bug.cgi?id=106321

--- Comment #1 from Greg Kroah-Hartman  ---
On Tue, Oct 20, 2015 at 06:25:29AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=106321

Bug ID: 106321
   Summary: linux-kernel-4.3-rc5 fails to attach usb storage
device


Please send to the linux-usb@vger.kernel.org mailing list.

--
You are receiving this mail because:
You reported the bug.



--
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] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Rob Herring wrote:

> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle 
> > things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing.

Devices are suspended in reverse order of _registration_.  Not of 
probing.

Furthermore, that applies only to devices that use synchronous suspend.  
Async suspend is becoming common, and there the only restrictions are 
parent-child relations plus whatever explicit requirements that drivers 
impose by calling device_pm_wait_for_dev().

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: Fwd: linux-image-4.3.0-rc5-amd64 fails to attach usb storage device

[Alan Stern]

On Tue, 20 Oct 2015, Jos van Wolput wrote:

>  Forwarded Message 
> Subject: linux-image-4.3.0-rc5-amd64 fails to attach usb storage device
> Date: Tue, 20 Oct 2015 12:01:41 +0800
> From: Jos van Wolput 
> Reply-To: wol...@on.nl
> To: Debian Bug Tracking System 
> 
> Package: linux-image-4.3.0-rc5-amd64
> Version: 4.3~rc5-1~exp1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading linux-image-4.2.0-1-amd64 (4.2.3-2) from unstable to 
> linux-image-4.3.0-rc5-amd64 from experimental my Verbatim usb flash drive
> is detected but fails to attach.
> Using kernel 4.2.3-2 this device is properly detected and attached.
> 
> Please see the attached kernel.log
> 
> -- System Information:
> Debian Release: sid + experimental
> Architecture: amd64 (x86_64)
> Kernel: linux-image-4.3.0-rc5-amd64
> Systemd: 227-2

This looks like a SCSI problem, not a USB problem.  Please post this to 
the linux-scsi mailing list.

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

Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Erwin Van de Velde]

Hi all,

Due to some hardware issues, I have to reset USB modems and a USB to
serial converter on some of my servers. What I noticed is that
/dev/ttyUSBXX devices are never reused: ttyUSB1 becomes ttyUSB3 e.g.
and so on. This looks fine, but we have to do it rather often, so
after a while we reach ttyUSB511 after which the system refuses to
create new ttyUSB devices (I guess this is a hard limit in the kernel
code).

This issue seems unsolvable with anything less than a reboot. Is there
a better way? Why are ttyUSB device numbers of devices that have
already disappeared not reused?

Tested on Debian 8 with 3.16 kernel.

Kind regards,
Erwin
--
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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Johan Hovold]

On Tue, Oct 20, 2015 at 05:20:23PM +0200, Erwin Van de Velde wrote:
> Hi all,
> 
> Due to some hardware issues, I have to reset USB modems and a USB to
> serial converter on some of my servers. What I noticed is that
> /dev/ttyUSBXX devices are never reused: ttyUSB1 becomes ttyUSB3 e.g.
> and so on. This looks fine, but we have to do it rather often, so
> after a while we reach ttyUSB511 after which the system refuses to
> create new ttyUSB devices (I guess this is a hard limit in the kernel
> code).

What do you mean by reset here? Do you disconnect and plug the device
back in?

> This issue seems unsolvable with anything less than a reboot. Is there
> a better way? Why are ttyUSB device numbers of devices that have
> already disappeared not reused?
> 
> Tested on Debian 8 with 3.16 kernel.

Please try a more recent kernel (e.g. 4.2). 3.16 is way too old and not
supported by the community.

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: [GIT PULL] On-demand device probing

[Mark Brown]

On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:

> Furthermore, that applies only to devices that use synchronous suspend.  
> Async suspend is becoming common, and there the only restrictions are 
> parent-child relations plus whatever explicit requirements that drivers 
> impose by calling device_pm_wait_for_dev().

Hrm, this is the first I'd noticed that feature though I see the initial
commit dates from January.  It looks like most of the users are PCs at
the minute but we should be using it more widely for embedded things,
there's definitely some cases I'm aware of where it will allow us to
remove some open coding.

It does seem like we want to be feeding dependency information we
discover for probing way into the suspend dependencies...


signature.asc
Description: PGP signature

Re: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Greg KH]

On Tue, Oct 20, 2015 at 05:20:23PM +0200, Erwin Van de Velde wrote:
> Hi all,
> 
> Due to some hardware issues, I have to reset USB modems and a USB to
> serial converter on some of my servers. What I noticed is that
> /dev/ttyUSBXX devices are never reused: ttyUSB1 becomes ttyUSB3 e.g.
> and so on. This looks fine, but we have to do it rather often, so
> after a while we reach ttyUSB511 after which the system refuses to
> create new ttyUSB devices (I guess this is a hard limit in the kernel
> code).
> 
> This issue seems unsolvable with anything less than a reboot. Is there
> a better way? Why are ttyUSB device numbers of devices that have
> already disappeared not reused?

Userspace still has the port open, so the number is not reused until
userspace closes the device node.  Fix your userspace programs to
properly listen to the hangup signal to know to release the device node
and you should be fine.

> Tested on Debian 8 with 3.16 kernel.

As Johan said, this is very old, please try a modern kernel.  If you are
stuck with Debian's kernel, please file a bug with them, there's nothing
we can do here.

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: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>  wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?
> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.
> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds OK to me.

Something like this.  I haven't put a lot of effort into it to change all
the places which return an -EPROBE_DEFER, and it also looks like we need
some helpers to report when we have only an device_node (or should that
be fwnode?)  See the commented out of_warn_deferred() in
drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
for resources should make debugging why things are getting deferred easier.

We could make driver_deferred_probe_report something that can be
deactivated again after the last deferred probe run, and provide the
user with a knob that they can turn it back on again.

I've tried this out on two of my platforms, including forcing
driver_deferred_probe_report to be enabled, and I get exactly one
deferred probe, so not a particularly good test.

The patch won't apply as-is to mainline for all files; it's based on my
tree which has some 360 additional patches (which seems to be about
normal for my tree now.)

 drivers/base/dd.c   | 29 +
 drivers/base/power/domain.c |  7 +--
 drivers/clk/clkdev.c|  9 -
 drivers/gpio/gpiolib-of.c   |  5 +
 drivers/gpu/drm/bridge/dw_hdmi.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
 drivers/gpu/drm/msm/dsi/dsi.c   |  2 +-
 drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
 drivers/of/irq.c|  5 -
 drivers/pci/host/pci-mvebu.c|  1 +
 drivers/pinctrl/core.c  |  5 +++--
 drivers/pinctrl/devicetree.c|  4 ++--
 drivers/regulator/core.c|  5 +++--
 include/linux/device.h  |  1 +
 16 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..bb12224f2901 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+   if (driver_deferred_probe_report) {
+   struct va_format vaf;
+   va_list ap;
+
+   va_start(ap, fmt);
+   vaf.fmt = fmt;
+   vaf.va = ≈
+
+   dev_warn(dev, "deferring probe: %pV", &vaf);
+   va_end(ap);
+   }
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
+
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
  *
@@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
driver_deferred_probe_trigger();
/* Sort as many dependencies as possible before exiting initcalls */
flush_workqueue(deferred_wq);
+
+   /* Now one final round, reporting any devices that remain deferred */
+   driver_deferred_probe_report = true;
+   driver_deferred_probe_trigger();
+   /* Sort as many dependenci

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Mark Brown wrote:

> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> 
> > Furthermore, that applies only to devices that use synchronous suspend.  
> > Async suspend is becoming common, and there the only restrictions are 
> > parent-child relations plus whatever explicit requirements that drivers 
> > impose by calling device_pm_wait_for_dev().
> 
> Hrm, this is the first I'd noticed that feature though I see the initial
> commit dates from January.

Async suspend and device_pm_wait_for_dev() were added in January 2010, 
not 2015!

>  It looks like most of the users are PCs at
> the minute but we should be using it more widely for embedded things,
> there's definitely some cases I'm aware of where it will allow us to
> remove some open coding.
> 
> It does seem like we want to be feeding dependency information we
> discover for probing way into the suspend dependencies...

Rafael has been thinking about a way to do this systematically.  
Nothing concrete has emerged yet.

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: Udoo support for chipidea

[Fabio Estevam]

Hi Peter,

On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen  wrote:

> Add linux-usb.
>
> Patryk, your problem is you may need to open 24M OSC for HUB 2514
> manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> but this clock is not controller's clock, controller's clock has
> already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> override it at board's dts file.
>
> You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> can't work, try to open IMX6QDL_CLK_CKO at one place to test.

What is the appropriate place to acquire and enable the USB hub clock?

This issue has appeared several times and it seems we don't have a
solution for this yet.

Any suggestions?
--
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/2] USB: serial: cp210x: Implement 16-bit register access functions

[Johan Hovold]

On Tue, Oct 20, 2015 at 09:19:05AM -0500, Konstantin Shkolnyy wrote:
> On Tue, Oct 20, 2015 at 8:02 AM, Johan Hovold  wrote:
> > On Tue, Oct 20, 2015 at 07:52:31AM -0500, Konstantin Shkolnyy wrote:
> >> On Tue, Oct 20, 2015 at 2:45 AM, Johan Hovold  wrote:
> >> [...]
> >> > Instead of adding the new helpers to read u16 as a prerequisite for
> >> > fixing the broken cp2108 support, just reuse the current config register
> >> > helpers for now (in order to keep the fixes minimal and potentially
> >> > backportable). Once the fixes are in place, feel free to clean up the
> >> > remaining register accesses.
> >>
> >> The current helpers take "port" as a parameter. You pointed out
> >> previously that port shouldn't be used in probe(). That made me
> >> implement new helpers cp210x_write_u16_reg and cp210x_read_u16_reg
> >> that don't use port. Probe() now calls cp210x_activate_workarounds
> >> which in turn calls these new helpers.
> >
> > Oh, that's right.
> >
> >> An alternative would be to call usb_control_msg from
> >> cp210x_activate_workarounds, but I think it would make it look pretty
> >> ugly.
> >
> > Or you move the quirk-detect (and private data allocation) to port_probe
> > instead (and remove startup/release). These devices have exactly one
> > port per interface, so you wouldn't introduce any redundancy.
> 
> OK, how about this:
> patch #1
> - attach/release replaced with port_probe/port_release;
> - changes in the code using the "private" data since it has moved from
> serial to port;
> - cp210x_activate_workarounds in the port_probe, using the current helpers;
> - a new helper cp210x_get_line_ctl that calls the current helper and
> swaps the bytes.
> patch #2
> - sending "purge" from close, using the current helper.
> 
> However, the Tx queue bug fixed by the "purge" doesn't have a
> detection method. We only know that it exists in the same cp2108 that
> has the "byte swap" bug. So the "purge" is activated by the same "byte
> swap" flag and  patch #2 depends on patch #1.

So you only see the hang after close with data in fifo on cp2108? Is
this something that might get fixed as well in later revisions?

But doing a purge as part of close should not be a problem on the other
products, right? I think doing this unconditionally would be best (just
like you eventually add tx_empty for all devices). No need to depend on
the broken-lcr-quirk.

> Also, there is no reason
> to only apply one of the patches. Do you think we can merge these
> patches?

No, again you want one logical change per patch.

I suggest you split it as follows

 - fix hang with non-empty tx fifo
 - use port data for private data
 - fix broken cp2108 lcr

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: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 20 October 2015 at 18:04, Alan Stern  wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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

[BUG] mfd: rtsx_usb data corruption with SDCX microsd

[Marcus Overhagen]

I tested again with a 4.2 kernel but the bug is still present and
happens more often. So far nobody has responded.
I don't know what to do, and whether it's related to usb, mmc or mfd.
Please advise.

When using the RTS5129 card reader (USB2 but internal to Samsung
NP7230U3E series 7 ultrabook) and a Samsung 128 GB SDXC microsd the
data that is read or written is always corrupted.
A 32 GB SDHC does not show data corruption with this card reader.

[root@goetterdaemmerung f3-5.0]# uname -a
Linux goetterdaemmerung 4.2.3-1-ARCH #1 SMP PREEMPT Sat Oct 3 18:52:50
CEST 2015 x86_64 GNU/Linux
[root@goetterdaemmerung f3-5.0]# ./f3read /mnt/dashcam1/
  SECTORS  ok/corrupted/changed/overwritten
Validating file 1.h2w ... 1752476/   279302/  9/  65365
Validating file 2.h2w ... 1755153/   164013/  7/ 177979
Validating file 3.h2w ... 1751003/   126213/ 16/ 219920
Validating file 4.h2w ...  123986/15442/  0/  12348^C
[root@goetterdaemmerung f3-5.0]#

many errors logged, but always the same:

[39143.853105] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
[39143.860019] mmcblk0: mmc0:59b4 0 119 GiB
[39143.862649]  mmcblk0: p1
[39144.654751] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39145.322333] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39161.533429] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39174.344246] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39174.961629] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39175.602352] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39176.229774] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39176.853664] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39177.468247] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39178.071814] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39178.672414] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39179.279727] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
[39179.890435] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900

regards
Marcus

-- Forwarded message --
From: Marcus Overhagen 
Date: Mon, Sep 28, 2015 at 9:42 PM
Subject: Fwd: Data corruption with RTS5129 card reader and 128 GB SDXC microsd
To: kernel list 
Cc: linux-...@vger.kernel.org, Lee Jones 


Can somebody help me with this issue? Linux is corrupting data when
using the SD card reader!

I already sent it to linux-mmc on September 11th, and on September
17th forwarded it to Roger Tseng (author of rtsx_usb) and Samuel Ortiz
(maintainer of MFD) but have received no response,

-- Forwarded message --
From: Marcus Overhagen 
Date: Fri, Sep 11, 2015 at 3:26 PM
Subject: Data corruption with RTS5129 card reader and 128 GB SDXC microsd
To: linux-...@vger.kernel.org


I have a data corruption problem with RTS5129 sd card reader and a
128GB Samsung EVO microsd.

This is not a fake card, its tested ok with H2testw in another windows machine.
The card also works when I put it in an external microSD=>USB card reader.

Previously I was using a 32 GB Sandisk Ultra microsd UHS-I without
noticing any issues.
With the 128GB card, playback of dashcam videos shows many broken
frames, but is ok when using external card reader.

A test with F3 software shows "overwritten" sectors, I think in this
case they indicate that the wrong sector is read.

Bus 003 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129
Card Reader Controller

[root@goetterdaemmerung marcus]# uname -a
Linux goetterdaemmerung 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17
08:52:28 CEST 2015 x86_64 GNU/Linux

[1.033568] xhci_hcd :00:14.0: xHCI Host Controller
[1.033575] xhci_hcd :00:14.0: new USB bus registered, assigned
bus number 3
[1.033673] xhci_hcd :00:14.0: hcc params 0x20007181 hci
version 0x100 quirks 0xb930
[1.033682] xhci_hcd :00:14.0: cache line size of 64 is not supported
[1.033931] hub 3-0:1.0: USB hub found

[1.393530] usb 3-3: new high-speed USB device number 2 using xhci_hcd
[1.451468] hub 1-1:1.0: USB hub found
[1.451580] hub 1-1:1.0: 6 ports detected
[1.464698] hub 2-1:1.0: USB hub found
[1.464847] hub 2-1:1.0: 6 ports detected
[1.572914] usbcore: registered new interface driver rtsx_usb

[67697.876276] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
[67697.876720] mmcblk0: mmc0:59b4 0 119 GiB
[67697.881189]  mmcblk0: p1

some errors are loggged during card access:

[68223.345521] mmcblk0: error -110 sendi

[PATCH] usb: gadget: composite: remove redundant bcdUSB setting in legacy

[Krzysztof Opasiak]

From: Igor Kotrasinski 

Since composite now overwrites bcdUSB for any gadget, remove
setting it in legacy gadgets. All legacy gadgets set 0x0200, the
same as the value additionally set by composite, so there is no
behaviour change.

Signed-off-by: Igor Kotrasinski 

Rebase onto current balbi/next

Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/legacy/acm_ms.c |2 +-
 drivers/usb/gadget/legacy/audio.c  |2 +-
 drivers/usb/gadget/legacy/cdc2.c   |2 +-
 drivers/usb/gadget/legacy/ether.c  |2 +-
 drivers/usb/gadget/legacy/g_ffs.c  |2 +-
 drivers/usb/gadget/legacy/gmidi.c  |2 +-
 drivers/usb/gadget/legacy/hid.c|2 +-
 drivers/usb/gadget/legacy/mass_storage.c   |2 +-
 drivers/usb/gadget/legacy/multi.c  |2 +-
 drivers/usb/gadget/legacy/ncm.c|2 +-
 drivers/usb/gadget/legacy/nokia.c  |2 +-
 drivers/usb/gadget/legacy/printer.c|2 +-
 drivers/usb/gadget/legacy/serial.c |2 +-
 drivers/usb/gadget/legacy/tcm_usb_gadget.c |2 +-
 drivers/usb/gadget/legacy/webcam.c |2 +-
 drivers/usb/gadget/legacy/zero.c   |2 +-
 16 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/gadget/legacy/acm_ms.c 
b/drivers/usb/gadget/legacy/acm_ms.c
index 4b158e2..c16089e 100644
--- a/drivers/usb/gadget/legacy/acm_ms.c
+++ b/drivers/usb/gadget/legacy/acm_ms.c
@@ -40,7 +40,7 @@ static struct usb_device_descriptor device_desc = {
.bLength =  sizeof device_desc,
.bDescriptorType =  USB_DT_DEVICE,
 
-   .bcdUSB =   cpu_to_le16(0x0200),
+   /* .bcdUSB = DYNAMIC */
 
.bDeviceClass = USB_CLASS_MISC /* 0xEF */,
.bDeviceSubClass =  2,
diff --git a/drivers/usb/gadget/legacy/audio.c 
b/drivers/usb/gadget/legacy/audio.c
index 685cf3b..5d7b3c6 100644
--- a/drivers/usb/gadget/legacy/audio.c
+++ b/drivers/usb/gadget/legacy/audio.c
@@ -123,7 +123,7 @@ static struct usb_device_descriptor device_desc = {
.bLength =  sizeof device_desc,
.bDescriptorType =  USB_DT_DEVICE,
 
-   .bcdUSB =   cpu_to_le16(0x200),
+   /* .bcdUSB = DYNAMIC */
 
 #ifdef CONFIG_GADGET_UAC1
.bDeviceClass = USB_CLASS_PER_INTERFACE,
diff --git a/drivers/usb/gadget/legacy/cdc2.c b/drivers/usb/gadget/legacy/cdc2.c
index ecd8c8d..51c0868 100644
--- a/drivers/usb/gadget/legacy/cdc2.c
+++ b/drivers/usb/gadget/legacy/cdc2.c
@@ -43,7 +43,7 @@ static struct usb_device_descriptor device_desc = {
.bLength =  sizeof device_desc,
.bDescriptorType =  USB_DT_DEVICE,
 
-   .bcdUSB =   cpu_to_le16(0x0200),
+   /* .bcdUSB = DYNAMIC */
 
.bDeviceClass = USB_CLASS_COMM,
.bDeviceSubClass =  0,
diff --git a/drivers/usb/gadget/legacy/ether.c 
b/drivers/usb/gadget/legacy/ether.c
index 31e9160..25a2c2e 100644
--- a/drivers/usb/gadget/legacy/ether.c
+++ b/drivers/usb/gadget/legacy/ether.c
@@ -151,7 +151,7 @@ static struct usb_device_descriptor device_desc = {
.bLength =  sizeof device_desc,
.bDescriptorType =  USB_DT_DEVICE,
 
-   .bcdUSB =   cpu_to_le16 (0x0200),
+   /* .bcdUSB = DYNAMIC */
 
.bDeviceClass = USB_CLASS_COMM,
.bDeviceSubClass =  0,
diff --git a/drivers/usb/gadget/legacy/g_ffs.c 
b/drivers/usb/gadget/legacy/g_ffs.c
index 320a81b..f85639e 100644
--- a/drivers/usb/gadget/legacy/g_ffs.c
+++ b/drivers/usb/gadget/legacy/g_ffs.c
@@ -69,7 +69,7 @@ static struct usb_device_descriptor gfs_dev_desc = {
.bLength= sizeof gfs_dev_desc,
.bDescriptorType= USB_DT_DEVICE,
 
-   .bcdUSB = cpu_to_le16(0x0200),
+   /* .bcdUSB = DYNAMIC */
.bDeviceClass   = USB_CLASS_PER_INTERFACE,
 
.idVendor   = cpu_to_le16(GFS_VENDOR_ID),
diff --git a/drivers/usb/gadget/legacy/gmidi.c 
b/drivers/usb/gadget/legacy/gmidi.c
index 8a18348..582f1db 100644
--- a/drivers/usb/gadget/legacy/gmidi.c
+++ b/drivers/usb/gadget/legacy/gmidi.c
@@ -86,7 +86,7 @@ MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
 static struct usb_device_descriptor device_desc = {
.bLength =  USB_DT_DEVICE_SIZE,
.bDescriptorType =  USB_DT_DEVICE,
-   .bcdUSB =   cpu_to_le16(0x0200),
+   /* .bcdUSB = DYNAMIC */
.bDeviceClass = USB_CLASS_PER_INTERFACE,
.idVendor = cpu_to_le16(DRIVER_VENDOR_NUM),
.idProduct =cpu_to_le16(DRIVER_PRODUCT_NUM),
diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c
index 7e5d2c4..a71a884 100644
--- a/drivers/usb/gadget/legacy/hid.c
+++ b/drivers/usb/gadget/legacy/hid.c
@@ -47,7 +47,7 @@ static struct usb_device_descriptor device_desc = {
.bLength =  sizeof device_desc,
 

Re: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Peter Stuge]

Greg KH wrote:
> Userspace still has the port open, so the number is not reused until
> userspace closes the device node.  Fix your userspace programs to
> properly listen to the hangup signal to know to release the device node
> and you should be fine.

There's still a bit of a race condition here, isn't there?

Is there any good way to deal with that?


//Peter
--
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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Greg K-H]

On October 20, 2015 9:38:52 AM PDT, Peter Stuge  wrote:
>Greg KH wrote:
>> Userspace still has the port open, so the number is not reused until
>> userspace closes the device node.  Fix your userspace programs to
>> properly listen to the hangup signal to know to release the device
>node
>> and you should be fine.
>
>There's still a bit of a race condition here, isn't there?
>
>Is there any good way to deal with that?

What race condition are you seeing here? 


--
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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Peter Stuge]

Greg K-H wrote:
> >> Userspace still has the port open, so the number is not reused until
> >> userspace closes the device node.  Fix your userspace programs to
> >> properly listen to the hangup signal to know to release the device
> >node
> >> and you should be fine.
> >
> >There's still a bit of a race condition here, isn't there?
> >
> >Is there any good way to deal with that?
> 
> What race condition are you seeing here?

USB cable is unplugged
 Process is sent SIGHUP
USB cable is quickly replugged
 Process closes port


//Peter
--
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] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> On 20 October 2015 at 18:04, Alan Stern  wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

But what Rafael is proposing is quite general; it would apply to _all_
dependencies as opposed to just those present in DT drivers or those 
affecting platform_devices.

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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Bin Liu]

Hi,

On Tue, Oct 20, 2015 at 11:57 AM, Peter Stuge  wrote:
> Greg K-H wrote:
>> >> Userspace still has the port open, so the number is not reused until
>> >> userspace closes the device node.  Fix your userspace programs to
>> >> properly listen to the hangup signal to know to release the device
>> >node
>> >> and you should be fine.
>> >
>> >There's still a bit of a race condition here, isn't there?
>> >
>> >Is there any good way to deal with that?
>>
>> What race condition are you seeing here?
>
> USB cable is unplugged

Assuming /dev/ttyUSB0 is opened by process ATM.

>  Process is sent SIGHUP
> USB cable is quickly replugged

/dev/ttyUSB0 is still open, so /dev/ttyUSB1 is created.

>  Process closes port

Process closes /dev/ttyUSB0.

Regards,
-Bin.

>
>
> //Peter
> --
> 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
--
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 01/15] fs: configfs: Add unlocked version of configfs_depend_item()

[Joel Becker]

On Tue, Oct 20, 2015 at 02:32:32PM +0200, Andrzej Pietrasiewicz wrote:
> From: Krzysztof Opasiak 
> 
> This change is necessary for the SCSI target usb gadget composed with
> configfs. In this case configfs will be used for two different purposes:
> to compose a usb gadget and to configure the target part. If an instance
> of tcm function is created in $CONFIGFS_ROOT/usb_gadget//functions
> a tpg can be created in $CONFIGFS_ROOT/target/usb_gadget//, but after
> a tpg is created the tcm function must not be removed until its
> corresponding tpg is gone. While the configfs_depend/undepend_item() are
> meant exactly for creating this kind of dependencies, they are not suitable
> if the other kernel subsystem happens to be another subsystem in configfs,
> so this patch adds unlocked versions meant for configfs callbacks.
> 
> Signed-off-by: Krzysztof Opasiak 
> [updated the commit log]
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  fs/configfs/dir.c| 29 +
>  include/linux/configfs.h |  9 +
>  2 files changed, 38 insertions(+)
> 
> diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
> index c81ce7f..1e1ae76 100644
> --- a/fs/configfs/dir.c
> +++ b/fs/configfs/dir.c
> @@ -1152,6 +1152,35 @@ void configfs_undepend_item(struct configfs_subsystem 
> *subsys,
>  }
>  EXPORT_SYMBOL(configfs_undepend_item);
>  
> +int configfs_depend_item_unlocked(struct config_item *target)
> +{
> + struct configfs_dirent *sd;
> + int ret = -ENOENT;
> +
> + spin_lock(&configfs_dirent_lock);
> + BUG_ON(!target->ci_dentry);
> +
> + sd = target->ci_dentry->d_fsdata;
> + if ((sd->s_type & CONFIGFS_DIR) &&
> + ((sd->s_type & CONFIGFS_USET_DROPPING) ||
> +  (sd->s_type & CONFIGFS_USET_CREATING)))
> + goto out_unlock_dirent_lock;
> +
> + sd->s_dependent_count += 1;
> + ret = 0;
> +
> +out_unlock_dirent_lock:
> + spin_unlock(&configfs_dirent_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL(configfs_depend_item_unlocked);

This version lacks configfs_depend_prep(); how do you guard against
parents being in the middle of removal?  It's not just this entry being
DROPPING, it's also parents.

I also worry about the lack of pinning the fs.  I think that might be
OK, because your source already has a hold on the fs, but I'm not 100%
sure.

Joel

-- 

"What does it say about a society's priorities when the time you
 spend in meetings on Monday is greater than the total number of
 hours you spent sleeping over the weekend?"
- Nat Friedman

http://www.jlbec.org/
jl...@evilplan.org
--
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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Peter Stuge]

Hello,

Bin Liu wrote:
> >> >There's still a bit of a race condition here, isn't there?
> >> >
> >> >Is there any good way to deal with that?
> >>
> >> What race condition are you seeing here?
> >
> > USB cable is unplugged
> 
> Assuming /dev/ttyUSB0 is opened by process ATM.
> 
> >  Process is sent SIGHUP
> > USB cable is quickly replugged
> 
> /dev/ttyUSB0 is still open, so /dev/ttyUSB1 is created.
> 
> >  Process closes port
> 
> Process closes /dev/ttyUSB0.

Right - this is the race condition I'm talking about.

I know that the kernel will reuse ttyUSB0 *next time* because then,
the process has closed it. My question is about dealing with the race
condition between replug and close on the first unplug-replug cycle.

The kernel could take the stance that it will not try to second-guess
the outside world, but another alternative is to defer the new device
until the old has been closed, or perhaps a timeout.


//Peter
--
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/2] USB: serial: cp210x: Implement 16-bit register access functions

[Konstantin Shkolnyy]

On Tue, Oct 20, 2015 at 11:22 AM, Johan Hovold  wrote:
> On Tue, Oct 20, 2015 at 09:19:05AM -0500, Konstantin Shkolnyy wrote:
>> On Tue, Oct 20, 2015 at 8:02 AM, Johan Hovold  wrote:
>> > On Tue, Oct 20, 2015 at 07:52:31AM -0500, Konstantin Shkolnyy wrote:
>> >> On Tue, Oct 20, 2015 at 2:45 AM, Johan Hovold  wrote:
>> >> [...]
>> >> > Instead of adding the new helpers to read u16 as a prerequisite for
>> >> > fixing the broken cp2108 support, just reuse the current config register
>> >> > helpers for now (in order to keep the fixes minimal and potentially
>> >> > backportable). Once the fixes are in place, feel free to clean up the
>> >> > remaining register accesses.
>> >>
>> >> The current helpers take "port" as a parameter. You pointed out
>> >> previously that port shouldn't be used in probe(). That made me
>> >> implement new helpers cp210x_write_u16_reg and cp210x_read_u16_reg
>> >> that don't use port. Probe() now calls cp210x_activate_workarounds
>> >> which in turn calls these new helpers.
>> >
>> > Oh, that's right.
>> >
>> >> An alternative would be to call usb_control_msg from
>> >> cp210x_activate_workarounds, but I think it would make it look pretty
>> >> ugly.
>> >
>> > Or you move the quirk-detect (and private data allocation) to port_probe
>> > instead (and remove startup/release). These devices have exactly one
>> > port per interface, so you wouldn't introduce any redundancy.
>>
>> OK, how about this:
>> patch #1
>> - attach/release replaced with port_probe/port_release;
>> - changes in the code using the "private" data since it has moved from
>> serial to port;
>> - cp210x_activate_workarounds in the port_probe, using the current helpers;
>> - a new helper cp210x_get_line_ctl that calls the current helper and
>> swaps the bytes.
>> patch #2
>> - sending "purge" from close, using the current helper.
>>
>> However, the Tx queue bug fixed by the "purge" doesn't have a
>> detection method. We only know that it exists in the same cp2108 that
>> has the "byte swap" bug. So the "purge" is activated by the same "byte
>> swap" flag and  patch #2 depends on patch #1.
>
> So you only see the hang after close with data in fifo on cp2108? Is
> this something that might get fixed as well in later revisions?
>
> But doing a purge as part of close should not be a problem on the other
> products, right? I think doing this unconditionally would be best (just
> like you eventually add tx_empty for all devices). No need to depend on
> the broken-lcr-quirk.

Theoretically it shouldn't be a problem, but since it hasn't been
there for other devices, not causing any complaints, I'm reluctant to
do this.

>> Also, there is no reason
>> to only apply one of the patches. Do you think we can merge these
>> patches?
>
> No, again you want one logical change per patch.
>
> I suggest you split it as follows
>
>  - fix hang with non-empty tx fifo
>  - use port data for private data
>  - fix broken cp2108 lcr

Yes, this looks OK for an "unconditional purge" option.
Otherwise it would be
- use port data for private data
- fix both bugs

Since the purge workaround is almost a one-liner, it won't noticeably
increase the diff, and nobody would ever want to apply just one
workaround of the 2 and continue to experience device hangs.
--
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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Alan Stern]

On Tue, 20 Oct 2015, Bin Liu wrote:

> Hi,
> 
> On Tue, Oct 20, 2015 at 11:57 AM, Peter Stuge  wrote:
> > Greg K-H wrote:
> >> >> Userspace still has the port open, so the number is not reused until
> >> >> userspace closes the device node.  Fix your userspace programs to
> >> >> properly listen to the hangup signal to know to release the device
> >> >node
> >> >> and you should be fine.
> >> >
> >> >There's still a bit of a race condition here, isn't there?
> >> >
> >> >Is there any good way to deal with that?

Yes, there is a race condition.  If the program closes the device node 
before the device is plugged in again, the ttyUSB number won't change; 
otherwise it will.  No, there is no good way to deal with this.

The good news is that it doesn't matter.  Provided the programs are 
written to release the device nodes properly, the numbers won't 
increase indefinitely the way Erwin described:

Program opens /dev/ttyUSB0
Device is unplugged
Device is plugged in again and is assigned to /dev/ttyUSB1
Program closes the ttyUSB0 device node

Program opens /dev/ttyUSB1
Device is unplugged
Device is plugged in again and is assigned to /dev/ttyUSB0
(which is now available)
Program closes the ttyUSB1 device node

Program opens /dev/ttyUSB0 ...

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: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

[Gregory CLEMENT]

Hi Felipe,
 
 On lun., oct. 05 2015, Felipe Balbi  wrote:


>> So after many tests on different devices, 200ms is enough for most of
>> them, but for one, 2000ms (2s) was needed!
>>
>> I see several option:
>> - adding a sysfs entry to setup the time
>> - adding a debugs entry entry
>> - adding configuration option in menuconfig
>> - using 2000ms and hopping it was enough for everyone
>>
>> My preference would go to the first option, what is your opinion?
>
> I'm not sure if either of them is good. man 2s is just too large. If the
> device isn't following the specification, I'm afraid that device needs
> to be fixed.
>
> I think the real issue here is the lack of a disconnect IRQ from AM335x
> devices. But here's something I've been meaning to test but never had
> time. If you look into AM335x address space, there's a bit in the
> wrapper which tells it to use the standard MUSB registers for IRQ,
> instead of the TI-specific thing. Can you see if we get a disconnect IRQ
> with that ?
>
> TRM is at [1], see page 2566. Basically, if you set bit 3 in register
> offset 0x1014, then it should use Mentor IRQ registers. If that works,
> quite a few problems will actually vanish :-p

So I tried it with the following patch:

-
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index c791ba5..c714500 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb)
 
/* Reset the musb */
dsps_writel(reg_base, wrp->control, (1 << wrp->reset));
+   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
 
musb->isr = dsps_interrupt;
 
@@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb)
if (session_restart || !glue->sw_babble_enabled) {
dev_info(musb->controller, "Restarting MUSB to recover from 
Babble\n");
dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
+   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
usleep_range(100, 200);
usb_phy_shutdown(musb->xceiv);
usleep_range(100, 200);


I am not very familiar with that driver but my understanding was that
the Mentor IRQ registeres are managed by the musb_interrupt() function
which is called from the dsps_interrupt() interrupt handler.

Am I right?

if it is the case then it didn't fix the issue I had.

I activated the following debug line:

[musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012"
[musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012"

But I didn't get any interrupt while disconnecting the cable without any
device connected on it (whereas I got an interrupt when I connected it).

Note that I applied this patch instead of the "usb: musb: dsps: handle
the otg_state_a_wait_vrise_timeout case", is what you had in mind ?

Gregory

>
> [1] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf
>
> -- 
> balbi

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/2] USB: serial: cp210x: Implement 16-bit register access functions

[Konstantin Shkolnyy]

On Tue, Oct 20, 2015 at 11:22 AM, Johan Hovold  wrote:
> On Tue, Oct 20, 2015 at 09:19:05AM -0500, Konstantin Shkolnyy wrote:
>> On Tue, Oct 20, 2015 at 8:02 AM, Johan Hovold  wrote:
>> > On Tue, Oct 20, 2015 at 07:52:31AM -0500, Konstantin Shkolnyy wrote:
>> >> On Tue, Oct 20, 2015 at 2:45 AM, Johan Hovold  wrote:
>> >> [...]
>> >> > Instead of adding the new helpers to read u16 as a prerequisite for
>> >> > fixing the broken cp2108 support, just reuse the current config register
>> >> > helpers for now (in order to keep the fixes minimal and potentially
>> >> > backportable). Once the fixes are in place, feel free to clean up the
>> >> > remaining register accesses.
>> >>
>> >> The current helpers take "port" as a parameter. You pointed out
>> >> previously that port shouldn't be used in probe(). That made me
>> >> implement new helpers cp210x_write_u16_reg and cp210x_read_u16_reg
>> >> that don't use port. Probe() now calls cp210x_activate_workarounds
>> >> which in turn calls these new helpers.
>> >
>> > Oh, that's right.
>> >
>> >> An alternative would be to call usb_control_msg from
>> >> cp210x_activate_workarounds, but I think it would make it look pretty
>> >> ugly.
>> >
>> > Or you move the quirk-detect (and private data allocation) to port_probe
>> > instead (and remove startup/release). These devices have exactly one
>> > port per interface, so you wouldn't introduce any redundancy.
>>
>> OK, how about this:
>> patch #1
>> - attach/release replaced with port_probe/port_release;
>> - changes in the code using the "private" data since it has moved from
>> serial to port;
>> - cp210x_activate_workarounds in the port_probe, using the current helpers;
>> - a new helper cp210x_get_line_ctl that calls the current helper and
>> swaps the bytes.
>> patch #2
>> - sending "purge" from close, using the current helper.
>>
>> However, the Tx queue bug fixed by the "purge" doesn't have a
>> detection method. We only know that it exists in the same cp2108 that
>> has the "byte swap" bug. So the "purge" is activated by the same "byte
>> swap" flag and  patch #2 depends on patch #1.
>
> So you only see the hang after close with data in fifo on cp2108? Is
> this something that might get fixed as well in later revisions?
>
> But doing a purge as part of close should not be a problem on the other
> products, right? I think doing this unconditionally would be best (just
> like you eventually add tx_empty for all devices). No need to depend on
> the broken-lcr-quirk.

Sorry, sent the previous message too quickly. I see your point now.
There is no way to know if the Tx fifo bug will be fixed together with
"swapped bytes". And then the failure will return. I guess we'll just
make it unconditional and I'll make the patches according to your
plan:

>  - fix hang with non-empty tx fifo
>  - use port data for private data
>  - fix broken cp2108 lcr
--
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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Krzysztof Opasiak]

On 10/20/2015 07:35 PM, Alan Stern wrote:

On Tue, 20 Oct 2015, Bin Liu wrote:


Hi,

On Tue, Oct 20, 2015 at 11:57 AM, Peter Stuge  wrote:

Greg K-H wrote:

Userspace still has the port open, so the number is not reused until
userspace closes the device node.  Fix your userspace programs to
properly listen to the hangup signal to know to release the device

node

and you should be fine.


There's still a bit of a race condition here, isn't there?

Is there any good way to deal with that?


Yes, there is a race condition.  If the program closes the device node
before the device is plugged in again, the ttyUSB number won't change;
otherwise it will.  No, there is no good way to deal with this.



Well, I see some option for a walk around for this. You may use device 
authorization. First of all you should set unauthorized as default 
policy for hcd to which you connect serial converter. Then on system 
boot,authorize your converter and run your userspace. When you get 
disconnected event you should close opened ttyUSB and then authorize 
newly connected converter (or wait until reset finishes and then 
authorize it). This should work as tty will be allocated after 
authorizing the device so ttyUSB0 should be always available for driver.


--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Peter Stuge]

Krzysztof Opasiak wrote:
>> There's still a bit of a race condition here, isn't there?
>>
>> Is there any good way to deal with that?
>>
>> Yes, there is a race condition.  If the program closes the device node
>> before the device is plugged in again, the ttyUSB number won't change;
>> otherwise it will.  No, there is no good way to deal with this.
>
> You may use device authorization.

I think that's a good way. Thanks Krzysztof!


//Peter
--
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] Fix data loss in cdc-acm

[Peter Hurley]

On 08/05/2015 01:36 PM, Peter Hurley wrote:
> On 07/22/2015 06:53 PM, Sven Brauch wrote:
>> On 23/07/15 00:12, Peter Hurley wrote:
>>> The premature unthrottle actually leads to the data loss but the throttling
>>> with a mere 2K left is _way too late_.
>> Ok, yes, I think so too.
>>
>>> 10ms is a _really_ long time for a cpu not to attend to a kworker.
> 
> I haven't forgotten about this problem and I still plan to look into why
> the long delay, particularly focusing on the scheduling latency from
> tty_flip_buffer_push() => flush_to_ldisc().

I made some changes wrt which CPU is scheduled for the flush_to_ldisc()
input worker, which should reduce the kworker latency. The changes are
on the tty-next branch of Greg's tty.git tree; please test at your earliest
convenience.


>>> 1. What are the termios settings of the tty receiving input? Is it 'raw'
>>>mode or typical terminal mode (icanon, echo, etc.) or something else?
>> In my test code, I open the tty like
>>   fd = open("/dev/ttyACM0", O_RDWR | O_NOCTTY | O_NONBLOCK);
>> I don't make any other changes to the default settings. To be honest,
>> I'm not sure in which mode it is operating then (I was assuming raw, but
>> I might be wrong?).

ECHO is on by default and the cdc-acm driver does not implement the
put_char() and flush_chars() tty driver methods, which made the problem
_way worse_, since every echoed char is sent as it's own URB.

Since echoing is performed by the input worker, this seems the likely
cause for the significant delay in ldisc processing.

Echo processing should probably be performed by a separate kworker rather
than by the input kworker.

Regards,
Peter Hurley

--
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] extcon: add MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/18/2014 12:58 AM, Sergei Shtylyov wrote:


MAX3355E chip integrates a charge pump and comparators to enable a system with
an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru the
ID signal from the USB OTG connector.  On some Renesas boards, this signal  is
just  fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
host and gadget USB controllers sharing the same USB bus; however,  we'd  like
to allow host or gadget drivers to be loaded depending on the cable type,
hence
the need for the MAX3355 extcon driver. The Vbus status signals are also wired
to GPIOs (however, we're not currently intested in them), the  OFFVBUS# signal
is controlled  by the host controllers, there's also the SHDN# signal wired to
GPIO, which should be high for normal operation.



Signed-off-by: Sergei Shtylyov 



---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.



  Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 ++
  drivers/extcon/Kconfig  |6
  drivers/extcon/Makefile |1
  drivers/extcon/extcon-max3355.c |  122

  4 files changed, 150 insertions(+)



Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip



Need manufactor information as following :
   -> Maxim MAX3355


Would be Maxim enough? Or perhaps I should use Maxim Integrated [Products]?


   You haven't replied to my questions.


+
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
GPIO pin
+  connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+  connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+usb-otg {
+compatible = "maxim,max3355";
+maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
+maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;



Kernel already supported the gpio helper function to get gpio from devicetree.
I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
include/linux/of_gpio.h.



gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;


OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
to insist on using this one...


   Moreover, it now says "gpios" isn't allowed for the new bindings. So I 
have to strongly disagree here...


[...]


+static irqreturn_t max3355_id_irq(int irq, void *dev_id)
+{
+struct max3355_data *data = dev_id;
+int id = gpio_get_value(data->id_gpio);
+
+extcon_set_cable_state(data->edev, "USB-HOST", !id);



You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
function
and then you would set the cable state according to gpio state and flag.


I'm sorry but I just don't see why I have to do it. This is not a generic
GPIO driver, and the polarities of the GPIOs are determined solely by the
MAX3355 specs.


   Again, got not reply...


[...]

+static int max3355_probe(struct platform_device *pdev)
+{
+struct device_node *np = pdev->dev.of_node;
+struct max3355_data *data;
+int gpio, irq, ret;
+
+data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
+GFP_KERNEL);
+if (!data)
+return -ENOMEM;
+
+data->edev = devm_extcon_dev_allocate(&pdev->dev, max3355_cable);
+if (IS_ERR(data->edev)) {
+dev_err(&pdev->dev, "failed to allocate extcon device\n");
+return PTR_ERR(data->edev);
+}
+data->edev->name = kstrdup(np->name, GFP_KERNEL);
+
+gpio = of_get_named_gpio(np, "maxim,id-gpio", 0);



Use of_get_gpio() or of_get_gpio_flags().


OK, I'll use the first one.


   No, I won't due to not being able to use "gpios" anymore.

[...]


+
+ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, max3355_id_irq,
+IRQF_TRIGGER_RISING |
+IRQF_TRIGGER_FALLING | IRQF_ONESHOT,



Is it right to add both RISING and FALLING trigger?


How else I'm supposed to know when the OTG ID signal goes low and high?


and need to add IRQF_NO_SUSPEND to wakeup from suspend state when interrupt
happen.


Hm, are you sure we want to wake up on plugging another kind of USB cable?


   No reply to that as well...

[...]

+static struct platform_driver max3355_driver = {
+.probe= max3355_probe,
+.driver= {
+.name= "extc

[PATCH 1/3] uwb: drp: Use setup_timer

[Muhammad Falak R Wani]

Use timer API function setup_timer instead of init_timer to
initialize a kernel timer.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/uwb/drp.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/uwb/drp.c b/drivers/uwb/drp.c
index 8fc1b78..38d0504 100644
--- a/drivers/uwb/drp.c
+++ b/drivers/uwb/drp.c
@@ -642,9 +642,7 @@ static void uwb_drp_handle_alien_drp(struct uwb_rc *rc, 
struct uwb_ie_drp *drp_i
}
 
INIT_LIST_HEAD(&cnflt->rc_node);
-   init_timer(&cnflt->timer);
-   cnflt->timer.function = uwb_cnflt_timer;
-   cnflt->timer.data = (unsigned long)cnflt;
+   setup_timer(&cnflt->timer, uwb_cnflt_timer, (unsigned long)cnflt);
 
cnflt->rc = rc;
INIT_WORK(&cnflt->cnflt_update_work, uwb_cnflt_update_work);
-- 
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 2/3] uwb: neh: Use setup_timer

[Muhammad Falak R Wani]

Use timer API function setup_timer instead of init_timer to
initialize the timer.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/uwb/neh.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/uwb/neh.c b/drivers/uwb/neh.c
index 8cb71bb..36b5cb6 100644
--- a/drivers/uwb/neh.c
+++ b/drivers/uwb/neh.c
@@ -223,9 +223,7 @@ struct uwb_rc_neh *uwb_rc_neh_add(struct uwb_rc *rc, struct 
uwb_rccb *cmd,
 
kref_init(&neh->kref);
INIT_LIST_HEAD(&neh->list_node);
-   init_timer(&neh->timer);
-   neh->timer.function = uwb_rc_neh_timer;
-   neh->timer.data = (unsigned long)neh;
+   setup_timer(&neh->timer, uwb_rc_neh_timer, (unsigned long)neh);
 
neh->rc = rc;
neh->evt_type = expected_type;
-- 
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] uwb: rsv: Use setup_timer

[Muhammad Falak R Wani]

Use timer API function setup_timer instead of init_timer to
initialize the timer.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/uwb/rsv.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/uwb/rsv.c b/drivers/uwb/rsv.c
index 536ad42..f5e2724 100644
--- a/drivers/uwb/rsv.c
+++ b/drivers/uwb/rsv.c
@@ -470,9 +470,7 @@ static struct uwb_rsv *uwb_rsv_alloc(struct uwb_rc *rc)
INIT_LIST_HEAD(&rsv->rc_node);
INIT_LIST_HEAD(&rsv->pal_node);
kref_init(&rsv->kref);
-   init_timer(&rsv->timer);
-   rsv->timer.function = uwb_rsv_timer;
-   rsv->timer.data = (unsigned long)rsv;
+   setup_timer(&rsv->timer, uwb_rsv_timer, (unsigned long)rsv);
 
rsv->rc = rc;
INIT_WORK(&rsv->handle_timeout_work, uwb_rsv_handle_timeout_work);
@@ -989,9 +987,8 @@ void uwb_rsv_init(struct uwb_rc *rc)
rc->bow.can_reserve_extra_mases = true;
rc->bow.total_expired = 0;
rc->bow.window = UWB_DRP_BACKOFF_WIN_MIN >> 1;
-   init_timer(&rc->bow.timer);
-   rc->bow.timer.function = uwb_rsv_backoff_win_timer;
-   rc->bow.timer.data = (unsigned long)&rc->bow;
+   setup_timer(&rc->bow.timer, uwb_rsv_backoff_win_timer,
+   (unsigned long)&rc->bow);
 
bitmap_complement(rc->uwb_dev.streams, rc->uwb_dev.streams, 
UWB_NUM_STREAMS);
 }
-- 
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

[GIT PULL] USB patches for v4.4 merge window

[Felipe Balbi]

Hi Greg,

Here's the large gadget pull request for v4.4. All patches have been
in next for a while and should be safe to apply.

Let me know if you want any changes to this pull request.

cheers

The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c:

  Linux 4.3-rc3 (2015-09-27 07:50:08 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v4.4

for you to fetch changes up to 81e9d14a53eb1abfbe6ac828a87a2deb4702b5f1:

  usb: gadget: net2280: restore ep_cfg after defect7374 workaround (2015-10-19 
09:25:53 -0500)


usb: patches for v4.4 merge window

This pull request is large with a total of 136 non-merge
commits. Because of its size, we will only describe the big things in
broad terms.

Many will be happy to know that dwc3 is now almost twice as fast after
some profiling and speed improvements. Also in dwc3, John Youn from
Synopsys added support for their new DWC USB3.1 IP Core and the HAPS
platform which can be used to validate it.

A series of patches from Robert Baldyga cleaned up uses of
ep->driver_data as a flag for "claimed endpoint" in favor of the new
ep->claimed flag.

Sudip Mukherjee fixed a ton of really old problems on the amd5536udc
driver. That should make a few people happy.

Heikki Krogerus worked on converting dwc3 to the unified device property
interface.

Together with these, there's a ton of non-critical fixes, typos and
stuff like that.

Signed-off-by: Felipe Balbi 


Alan Stern (1):
  usb: misc: usbtest: format the data pattern according to max packet size

Alexandre Belloni (1):
  usb: gadget: at91_udc: move at91_udc_data in at91_udc.h

Antti Seppälä (1):
  usb: dwc2: Use platform endianness when accessing registers

Bin Liu (2):
  usb: musb: set the controller speed based on the config setting
  usb: musb: dsps: control musb speed based on dts setting

Doug Anderson (1):
  usb: dwc2: host: Fix use after free w/ simultaneous irqs

Douglas Anderson (1):
  usb: dwc2: host: Protect PCGCTL with lock in dwc2_port_resume()

Felipe Balbi (12):
  usb: dwc3: gadget: move trace_dwc3_ep_queue()
  usb: dwc3: gadget: start requests as soon as they come
  usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued
  usb: dwc3: gadget: improve ep_queue's error reporting
  usb: gadget: mass_storage: allow for deeper queue lengths
  usb: dwc2: rename all s3c_* to dwc2_*
  usb: gadget: pch-udc: fix lock
  usb: dwc3: gadget: start transfer on XFER_COMPLETE
  usb: dwc3: gadget: use update transfer command
  usb: dwc3: gadget: use Update Transfer from Xfer In Progress
  usb: dwc3: gadget: remove unnecessary _irqsave()
  Revert "usb: dwc3: gadget: remove unnecessary _irqsave()"

Felipe F. Tonello (1):
  usb: gadget: f_midi: check for error on usb_ep_queue

Geliang Tang (1):
  usb: gadget: fix a trivial typo

Gregory Herrero (22):
  usb: dwc2: host: don't clear hprt0 status bits when exiting hibernation
  usb: dwc2: host: create a function to handle port_resume
  usb: dwc2: host: add flag to reflect bus state
  usb: dwc2: host: enter hibernation during bus suspend
  usb: dwc2: host: update hcd and lx_state during start/stop callbacks
  usb: dwc2: host: avoid resetting lx_state to L3 during disconnect
  usb: dwc2: host: ignore wakeup interrupt if hibernation supported
  usb: dwc2: host: resume only if bus is suspended
  usb: dwc2: host: reset frame number after suspend
  usb: dwc2: host: disconnect hcd prior stopping it
  usb: dwc2: host: disable interrupt during stop
  usb: dwc2: host: clear pending interrupts prior hibernation
  usb: dwc2: host: wait 3ms for controller stabilization
  usb: dwc2: host: correctly dump urb isochronous descriptors
  usb: dwc2: host: use correct frame number during qh init
  usb: dwc2: host: kill remaining urbs using -ECONNRESET status
  usb: dwc2: gadget: ensure lx_state corresponds to current state
  usb: dwc2: gadget: don't modify pullup state in host mode
  usb: dwc2: gadget: set op_state in vbus_session call
  usb: dwc2: gadget: abort core init if core_reset fails
  usb: dwc2: gadget: unmask idstschng interrupt only if controller supports 
it
  usb: dwc2: gadget: exit hibernation before power down

Hans de Goede (1):
  musb: sunxi: Make sunxi musb glue work without MUSB_PIO_ONLY

Heikki Krogerus (5):
  usb: common: of_usb_get_maximum_speed to usb_get_maximum_speed
  usb: dwc3: st: prepare the driver for generic usb_get_dr_mode function
  usb: common: of_usb_get_dr_mode to usb_get_dr_mode
  usb: dwc3: core: convert to unified device property interface
  usb: dwc3: pci: passing forward the ACPI companion

Igor Kotrasinski (1):
  usb: gadget: composite

Re: [GIT PULL] On-demand device probing

[Mark Brown]

On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:

> > https://lkml.org/lkml/2015/6/17/311

> But what Rafael is proposing is quite general; it would apply to _all_
> dependencies as opposed to just those present in DT drivers or those 
> affecting platform_devices.

We'll still need most of the DT bits that are there at the minute (the
ones strewn around the subsystems) AFAICT since it's at the point where
we parse the DT and work out what the dependencies are which we probably
want to do prior to getting the drivers up and will be different for
ACPI.  I think the level of DT dependency here looks a lot larger than
it actually is due to the fact that a lot of what's being modified is DT
parsing code.


signature.asc
Description: PGP signature

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki  wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki  
> >> wrote:
> >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse  
> >> >> wrote:
> >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> >> > But the point I'm making is that we are working towards *fixing* 
> >> >> >> > that,
> >> >> >> > and *not* using DT-specific code in places where we should be 
> >> >> >> > using the
> >> >> >> > generic APIs.
> >> >> >>
> >> >> >> What is the plan for fixing things here?  It's not obvious (at least 
> >> >> >> to
> >> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> >> here.
> >> >> >
> >> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >> >
> >> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> >> > describe GPIO, and properties which reference GPIO pins are intended 
> >> >> > to
> >> >> > work through that — while in DT, properties which reference GPIO pins
> >> >> > will have different contents. They'll be compatible at the driver
> >> >> > level, in the sense that there's a call to get a given GPIO given the
> >> >> > property name, but the subsystems *will* be doing different things
> >> >> > behind the scenes.
> >> >> >
> >> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> >> > almost definitely *should* be firmware-agnostic, and convert those. 
> >> >> > And
> >> >> > then take stock of what we have left, and work out what, if anything,
> >> >> > still needs to be done.
> >> >>
> >> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> >> functions. Some are DT specific, but probably because those subsystems
> >> >> are new and DT only. In any case, I don't think these 1 line changes
> >> >> do anything to make doing conversions here harder.
> >> >>
> >> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> >> here is that big.
> >> >> >
> >> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> >> > is a note in the commit comment to that effect. That's different from
> >> >> > having not thought about it :)
> >> >>
> >> >> Considering at one point we did create a fwnode based API, we did
> >> >> think about it. Plus there was little input from ACPI folks as to
> >> >> whether the change was even useful for ACPI case.
> >> >
> >> > Well, sorry, but who was asking whom, specifically?
> >>
> >> You and linux-acpi have been copied on v2 and later of the entire
> >> series I think.
> >
> > Yes, but it wasn't like a direct request, say "We need your input, so can 
> > you
> > please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> > which case I'd prioritize that before other things I needed to take care of.
> 
> Fair enough. Can you please review and comment on v7 of the series? We
> can discuss at KS as well.

I'll do that.

I'm in the middle of travel right now and speaking at a conference tomorrow,
so I may not be able to get to that for a couple of days, but will do my best
to do it as soon as I possibly can.

> >> > The underlying problem is present in ACPI too and we don't really have a 
> >> > good
> >> > solution for it.  We might benefit from a common one if it existed.
> >>
> >> The problem for DT is we don't generically know what are the
> >> dependencies at a core level. We could know some or most dependencies
> >> if phandles (links to other nodes) were typed, but they are not. If
> >> the core had this information, we could simply control the device
> >> creation to order probing. Instead, this information is encoded into
> >> the bindings and binding parsing resides in the subsystems. That
> >> parsing happens during probe of the client side and is done by the
> >> subsystems (for common bindings). Since we already do the parsing at
> >> this point, it is a convenient place to trigger the probe of the
> >> dependency. Is ACPI going to be similar in this regard?
> >
> > It is similar in some ways.  For example, if a device's functionality 
> > depends
> > on an I2C resource (connection), the core doesn't know that at the device
> > creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.
> 
> So you will need to create devices, defer their probing and then probe
> on demand as well unless you have other ideas how you would do it.

Right.

> > There is a _DEP object in ACPI t

Re: Overly conservative xHCI bandwidth estimation

[Steinar H. Gunderson]

On Mon, Sep 28, 2015 at 02:32:13PM +0200, Steinar H. Gunderson wrote:
> Just so that it doesn't get lost: I've reported issues with this specific
> device and LPM not too long ago. It's entirely possible that the device
> somehow is broken, although it works in Windows 7/8/10 and OS X, from what I
> know, and at least Windows 10 uses USB3 LPM.
> 
> Perhaps figuring out what's wrong with the ping timeouts would also fix this
> issue? I'm afraid I don't have any fancy USB analyzer equipment to debug
> with, though.
> 
> In any case, I'll reiterate my request to turn off LPM for a specific device,
> no matter whose fault these specific issues are. :-)

Is there anything else I can do to help fixing these issues? (U1/U2 timeouts
causing disconnects, and xHCI bandwidth estimation being off.) I've been
running with CONFIG_PM=n for a while now, but it is obviously not a good
place to be for a laptop.

/* Steinar */
-- 
Homepage: http://www.sesse.net/
--
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] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote:
> 
> --7fVr/IRGAG9sAW4J
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> 
> > > This iteration of the series would make this quite easy, as
> > > dependencies are calculated before probes are attempted:
> 
> > > https://lkml.org/lkml/2015/6/17/311
> 
> > But what Rafael is proposing is quite general; it would apply to _all_
> > dependencies as opposed to just those present in DT drivers or those=20
> > affecting platform_devices.
> 
> We'll still need most of the DT bits that are there at the minute (the
> ones strewn around the subsystems) AFAICT since it's at the point where
> we parse the DT and work out what the dependencies are which we probably
> want to do prior to getting the drivers up and will be different for
> ACPI.  I think the level of DT dependency here looks a lot larger than
> it actually is due to the fact that a lot of what's being modified is DT
> parsing code.

Right, something will have to register the dependency, or a "link" between
devices, with the core once we find out that the dependency is there.

Thanks,
Rafael

--
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: dwc2: host: Fix ahbcfg for rk3066

[Douglas Anderson]

The comment for ahbcfg for rk3066 parameters (also used for rk3288)
claimed that ahbcfg was INCR16, but it wasn't.  Since the bits weren't
shifted properly, the 0x7 ended up being masked and we ended up
programming 0x3 for the HBstLen.  Let's set it to INCR16 properly.

As per Wu Liang Feng at Rockchip this may increase transmission
efficiency.  I did blackbox tests with writing 0s to a USB-based SD
reader (forcefully capping CPU Freq to try to measure efficiency):
  cd /sys/devices/system/cpu/cpu0/cpufreq
  echo userspace > scaling_governor
  echo 126000 > scaling_setspeed
  for i in $(seq 10); do
dd if=/dev/zero of=/dev/sdb bs=1M count=750
  done

With the above tests I found that speeds went from ~15MB/s to ~18MB/s.
Note that most other tests I did (including reading from the same USB
reader) didn't show any difference in performance.

Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/platform.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5859b0f..e61d773 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -108,7 +108,8 @@ static const struct dwc2_core_params params_rk3066 = {
.host_ls_low_power_phy_clk  = -1,
.ts_dline   = -1,
.reload_ctl = -1,
-   .ahbcfg = 0x7, /* INCR16 */
+   .ahbcfg = GAHBCFG_HBSTLEN_INCR16 <<
+ GAHBCFG_HBSTLEN_SHIFT,
.uframe_sched   = -1,
.external_id_pin_ctl= -1,
.hibernation= -1,
-- 
2.6.0.rc2.230.g3dd15c0

--
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: Overly conservative xHCI bandwidth estimation

[Lu, Baolu]

I could spend some time on this issue a week later.
I'd like to check whether there is any bugs in the driver itself.
Otherwise, blacklist this specific device for LPM.

Thanks,
Baolu

On 10/21/2015 07:05 AM, Steinar H. Gunderson wrote:

On Mon, Sep 28, 2015 at 02:32:13PM +0200, Steinar H. Gunderson wrote:

Just so that it doesn't get lost: I've reported issues with this specific
device and LPM not too long ago. It's entirely possible that the device
somehow is broken, although it works in Windows 7/8/10 and OS X, from what I
know, and at least Windows 10 uses USB3 LPM.

Perhaps figuring out what's wrong with the ping timeouts would also fix this
issue? I'm afraid I don't have any fancy USB analyzer equipment to debug
with, though.

In any case, I'll reiterate my request to turn off LPM for a specific device,
no matter whose fault these specific issues are. :-)

Is there anything else I can do to help fixing these issues? (U1/U2 timeouts
causing disconnects, and xHCI bandwidth estimation being off.) I've been
running with CONFIG_PM=n for a while now, but it is obviously not a good
place to be for a laptop.

/* Steinar */


--
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

Fwd: [Bug 106321] linux-kernel-4.3-rc5 fails to attach usb storage device

[Jos van Wolput]

 Forwarded Message 
Subject: [Bug 106321] linux-kernel-4.3-rc5 fails to attach usb storage device
Date: Tue, 20 Oct 2015 13:48:54 +
From: bugzilla-dae...@bugzilla.kernel.org
To: wol...@on.nl

https://bugzilla.kernel.org/show_bug.cgi?id=106321

--- Comment #1 from Greg Kroah-Hartman  ---
On Tue, Oct 20, 2015 at 06:25:29AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=106321

Bug ID: 106321
   Summary: linux-kernel-4.3-rc5 fails to attach usb storage
device


Please send to the linux-usb@vger.kernel.org mailing list.

--
You are receiving this mail because:
You reported the bug.



--
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: Udoo support for chipidea

[Peter Chen]

On Tue, Oct 20, 2015 at 02:09:38PM -0200, Fabio Estevam wrote:
> Hi Peter,
> 
> On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen  wrote:
> 
> > Add linux-usb.
> >
> > Patryk, your problem is you may need to open 24M OSC for HUB 2514
> > manually, and you have used IMX6QDL_CLK_CKO for it in the design,
> > but this clock is not controller's clock, controller's clock has
> > already decided at SoC dts file (imx6qdl.dtsi), you don't need to
> > override it at board's dts file.
> >
> > You can try delete clock property at imx6qdl-udoo.dtsi, if it still
> > can't work, try to open IMX6QDL_CLK_CKO at one place to test.
> 
> What is the appropriate place to acquire and enable the USB hub clock?
> 
> This issue has appeared several times and it seems we don't have a
> solution for this yet.
> 
> Any suggestions?

Add Alan.

Hi Alan, we have several designs that the on-board HUB need to
be reset by gpio pin and its clock is also from the board or
the SoC. Any suggestions how to add these platform information
for HUB device?

-- 

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] extcon: add MAX3355 driver

[Chanwoo Choi]

Hi Sergei,

I think this patch is too much delay. I recommend you better to develop
this driver based on latest extcon-next branch[1].
[1] 
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next

Thanks,
Chanwoo Choi

On 2015년 10월 21일 03:20, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/18/2014 12:58 AM, Sergei Shtylyov wrote:
> 
 MAX3355E chip integrates a charge pump and comparators to enable a system 
 with
 an integrated USB OTG dual-role transceiver to function as a USB OTG 
 dual-role
 device. In addition to sensing/controlling Vbus, the chip also passes thru 
 the
 ID signal from the USB OTG connector.  On some Renesas boards, this signal 
  is
 just  fed into the SoC thru a GPIO pin -- there's no real OTG controller, 
 only
 host and gadget USB controllers sharing the same USB bus; however,  we'd  
 like
 to allow host or gadget drivers to be loaded depending on the cable type,
 hence
 the need for the MAX3355 extcon driver. The Vbus status signals are also 
 wired
 to GPIOs (however, we're not currently intested in them), the  OFFVBUS# 
 signal
 is controlled  by the host controllers, there's also the SHDN# signal 
 wired to
 GPIO, which should be high for normal operation.
>>
 Signed-off-by: Sergei Shtylyov 
>>
 ---
 The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>>
   Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 ++
   drivers/extcon/Kconfig  |6
   drivers/extcon/Makefile |1
   drivers/extcon/extcon-max3355.c |  122
 
   4 files changed, 150 insertions(+)
>>
 Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
 ===
 --- /dev/null
 +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
 @@ -0,0 +1,21 @@
 +MAX3355 USB OTG chip
>>
>>> Need manufactor information as following :
>>>-> Maxim MAX3355
>>
>> Would be Maxim enough? Or perhaps I should use Maxim Integrated 
>> [Products]?
> 
>You haven't replied to my questions.
> 
 +
 +
 +MAX3355 integrates a charge pump and comparators to enable a system with 
 an
 +integrated USB OTG dual-role transceiver to function as a USB OTG 
 dual-role
 +device.
 +
 +Required properties:
 +- compatible: should be "maxim,max3355";
 +- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
 GPIO pin
 +  connected to the MAX3355's SHDN# pin;
 +- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO 
 pin
 +  connected to the MAX3355's ID_OUT pin.
 +
 +Example (Koelsch board):
 +
 +usb-otg {
 +compatible = "maxim,max3355";
 +maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
 +maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
>>
>>> Kernel already supported the gpio helper function to get gpio from 
>>> devicetree.
>>> I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
>>> include/linux/of_gpio.h.
>>
>>> gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;
>>
>> OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
>> to insist on using this one...
> 
>Moreover, it now says "gpios" isn't allowed for the new bindings. So I 
> have to strongly disagree here...
> 
> [...]
> 
 +static irqreturn_t max3355_id_irq(int irq, void *dev_id)
 +{
 +struct max3355_data *data = dev_id;
 +int id = gpio_get_value(data->id_gpio);
 +
 +extcon_set_cable_state(data->edev, "USB-HOST", !id);
>>
>>> You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
>>> function
>>> and then you would set the cable state according to gpio state and flag.
>>
>> I'm sorry but I just don't see why I have to do it. This is not a generic
>> GPIO driver, and the polarities of the GPIOs are determined solely by the
>> MAX3355 specs.
> 
>Again, got not reply...
> 
>> [...]
 +static int max3355_probe(struct platform_device *pdev)
 +{
 +struct device_node *np = pdev->dev.of_node;
 +struct max3355_data *data;
 +int gpio, irq, ret;
 +
 +data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
 +GFP_KERNEL);
 +if (!data)
 +return -ENOMEM;
 +
 +data->edev = devm_extcon_dev_allocate(&pdev->dev, max3355_cable);
 +if (IS_ERR(data->edev)) {
 +dev_err(&pdev->dev, "failed to allocate extcon device\n");
 +return PTR_ERR(data->edev);
 +}
 +data->edev->name = kstrdup(np->name, GFP_KERNEL);
 +
 +gpio = of_get_named_gpio(np, "maxim,id-g

[PATCH 1/1] usb: chipidea: otg: gadget module load and unload support

[Peter Chen]

From: Li Jun 

This patch is to support load and unload gadget driver in full OTG mode.

Signed-off-by: Li Jun 
Signed-off-by: Peter Chen 
Cc: Jiada Wang 
(Peter: it fixes a bug that the unload/reload gadget driver can't work
 well at OTG FSM mode)
Cc:  #v4.0+
---
 drivers/usb/chipidea/udc.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index e19d8b8..67cfa04 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1755,6 +1755,22 @@ static int ci_udc_start(struct usb_gadget *gadget,
return retval;
 }
 
+static void ci_udc_stop_for_otg_fsm(struct ci_hdrc *ci)
+{
+   if (!ci_otg_is_fsm_mode(ci))
+   return;
+
+   mutex_lock(&ci->fsm.lock);
+   if (ci->fsm.otg->state == OTG_STATE_A_PERIPHERAL) {
+   ci->fsm.a_bidl_adis_tmout = 1;
+   ci_hdrc_otg_fsm_start(ci);
+   } else if (ci->fsm.otg->state == OTG_STATE_B_PERIPHERAL) {
+   ci->fsm.protocol = PROTO_UNDEF;
+   ci->fsm.otg->state = OTG_STATE_UNDEFINED;
+   }
+   mutex_unlock(&ci->fsm.lock);
+}
+
 /**
  * ci_udc_stop: unregister a gadget driver
  */
@@ -1779,6 +1795,7 @@ static int ci_udc_stop(struct usb_gadget *gadget)
ci->driver = NULL;
spin_unlock_irqrestore(&ci->lock, flags);
 
+   ci_udc_stop_for_otg_fsm(ci);
return 0;
 }
 
-- 
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: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
>> Hi Russell,
>>
>> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>>  wrote:
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

 Well, adding those reports would give you a changelog similar to the
 one in this series...
>>>
>>> I'm not sure about that, because what I was thinking of is adding
>>> a flag which would be set at late_initcall() time prior to running
>>> a final round of deferred device probing.
>>
>> Which round is the final round?
>> That's the one which didn't manage to bind any new devices to drivers,
>> which is something you only know _after_ the round has been run.
>>
>> So I think we need one extra round to handle this.
>>
>>> This flag would then be used in a deferred_warn() printk function
>>> which would normally be silent, but when this flag is set, it would
>>> print the reason for the deferral - and this would replace (or be
>>> added) to the subsystems and drivers which return -EPROBE_DEFER.
>>>
>>> That has the effect of hiding all the deferrals up until just before
>>> launching into userspace, which should then acomplish two things -
>>> firstly, getting rid of the rather useless deferred messages up to
>>> that point, and secondly printing the reason why the remaining
>>> deferrals are happening.
>>>
>>> That should be a small number of new lines plus a one-line change
>>> in subsystems and drivers.
>>
>> Apart from the extra round we probably can't get rid of, that sounds OK to 
>> me.
> 
> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
> 
> We could make driver_deferred_probe_report something that can be
> deactivated again after the last deferred probe run, and provide the
> user with a knob that they can turn it back on again.
> 
> I've tried this out on two of my platforms, including forcing
> driver_deferred_probe_report to be enabled, and I get exactly one
> deferred probe, so not a particularly good test.
> 
> The patch won't apply as-is to mainline for all files; it's based on my
> tree which has some 360 additional patches (which seems to be about
> normal for my tree now.)

I like the concept (I have been thinking along similar lines lately).
But I think this might make the console messages more confusing than
they are now.  The problem is that debug, warn, and error messages
come from a somewhat random set of locations at the moment.  Some
come from the driver probe routines and some come from the subsystems
that the probe routines call.  So the patch is suppressing some
messages, but not others.

One thing that seemed pretty obvious from the patches is that the
current probe routines are somewhat inconsistent in terms of messages,
and that there is room for a set of best practices for messaging.  That
is on my long term wish list, but I'm not sure I'll ever chase after
those windmills.

A couple of specific comments below.


> 
>  drivers/base/dd.c   | 29 +
>  drivers/base/power/domain.c |  7 +--
>  drivers/clk/clkdev.c|  9 -
>  drivers/gpio/gpiolib-of.c   |  5 +
>  drivers/gpu/drm/bridge/dw_hdmi.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
>  drivers/gpu/drm/msm/dsi/dsi.c   |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/of/irq.c|  5 -
>  drivers/pci/host/pci-mvebu.c|  1 +
>  drivers/pinctrl/core.c  |  5 +++--
>  drivers/pinctrl/devicetree.c|  4 ++--
>  drivers/regulator/core.c|  5 +++--
>  include/linux/device.h  |  1 +
>  16 files changed, 71 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..bb12224f2901 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
>   mutex_unlock(&deferred_probe_mutex);
>  }
>  
> +static bool driver_deferred_probe_report;
> +
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *

Re: [GIT PULL] On-demand device probing

[Jean-Francois Moine]

Sorry to enter this thread a bit late.

About the number of probe deferred messages, I proposed a simple patch to
reduce them:

https://lkml.org/lkml/2013/8/20/218

I was wondering how many messages this patch could save...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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