RE: [PATCH] Add support for usbfs zerocopy.

[Alan Stern]

On Tue, 15 Dec 2015, David Laight wrote:

> > Good point.  So it seems that the try_module_get() / module_put()
> > solution is the only one.
> 
> That still isn't entirely correct.
> 
> Someone with more knowledge than either of us has needs to sort out
> how to handle this properly.
> 
> Before calling dma_free_coherent() you (and I) need to invalidate all
> the vma mappings that reference the memory - so that any accesses
> will call the vma_ops.fault() code which will return VM_FAULT_SIGBUS.
> Then you need to hold the module present until all the mappings are
> removed.

Don't the vma mappings get invalidated before the
vm_operations_struct's ->close method is called?  In other words, when
a process calls munmap() or exits?  The try_module_get() will hold the 
module present until the ->close method has been called for all the 
mappings.

> This ordering is more important if vm_iomap_memory() is used since
> iounmap() has to be called from the .remove() entry for the hardware.

Fortunately we're not concerned with iomem.

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

[Sergei Shtylyov]

On 12/15/2015 04:20 AM, Chanwoo Choi wrote:


Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators to

^^ ^^

enable a system with an integrated USB OTG dual-role transceiver to function
as  an 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
aren't currently interested in them),  the OFFVBUS# signal is controlled  by

^^ ^^

the host controllers, there's  also the SHDN# signal wired to a GPIO, it

^^

should be driven high for the  normal operation.

^^
As above '^' expression, you used the double space between words.
You should fix it.


   OK, since so many people seem to be offended by that, I'll fix it. 
Meanwhile, please comment on the patch itself.



Thanks,
Chanwoo Choi

[...]

MBR, Sergei

--
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: [PROBLEM] usb hub malformed packets causes null pointer dereference

[Alan Stern]

On Tue, 15 Dec 2015, Cornea, Alexandru wrote:

> Hello, 
>Apologies for the late response. 
>We tried the patch, and although the system does not crash anymore, 
> another issue occurs. 
> 
>Depending on platform (Gigabyte GXBT, Galileo board), the USB port that is 
> used for testing or all USB ports become blocked and cannot recognize new 
> devices. 
>Also, soft shutdown / reboot seems to hang.
> 
>The below trace gives more information:
> 
> [  240.304129] INFO: task kworker/3:2:93 blocked for more than 120 seconds.
> [  240.304173]   Tainted: GE   4.3.0with-patch #8
> [  240.304190] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  240.304212] kworker/3:2 D 88011e2d6980 093  2 
> 0x
> [  240.304241] Workqueue: usb_hub_wq hub_event
> [  240.304257]  8800c73bbb78 0046 88011931aa00 
> 8800c7107000
> [  240.304286]  8800c73bc000 8800c9bb6494 8800c7107000 
> 
> [  240.304315]  8800c9bb6498 8800c73bbb90 817ab963 
> 8800c9bb6490
> [  240.304344] Call Trace:
> [  240.304357]  [] schedule+0x33/0x80
> [  240.304373]  [] schedule_preempt_disabled+0xe/0x10
> [  240.304393]  [] __mutex_lock_slowpath+0x95/0x110
> [  240.304413]  [] mutex_lock+0x1f/0x2f
> [  240.304430]  [] device_release_driver+0x1b/0x30
> [  240.304448]  [] bus_remove_device+0x101/0x170
> [  240.304467]  [] device_del+0x139/0x260
> [  240.304485]  [] ? usb_remove_ep_devs+0x1f/0x30
> [  240.304504]  [] usb_disable_device+0xa6/0x280
> [  240.304522]  [] usb_disconnect+0x94/0x270
> [  240.304539]  [] hub_event+0x693/0x1420
> [  240.304557]  [] process_one_work+0x14e/0x3d0
> [  240.304575]  [] worker_thread+0x11a/0x470
> [  240.305058]  [] ? __schedule+0x358/0x910
> [  240.305527]  [] ? rescuer_thread+0x310/0x310
> [  240.305992]  [] kthread+0xd2/0xf0
> [  240.306450]  [] ? kthread_park+0x50/0x50
> [  240.306905]  [] ret_from_fork+0x3f/0x70
> [  240.307357]  [] ? kthread_park+0x50/0x50
> [  360.382912] INFO: task kworker/3:2:93 blocked for more than 120 seconds.
> // same output every 120s

I can't figure out the problem from this trace.  Were there any other 
tasks blocked like this one?

Please enable USB debugging (echo 'module usbcore =p' 
>/sys/kernel/debug/dynamic_debug/control), run the test again, and post 
the resulting dmesg log.

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 2/3] doc: dt-binding: generic onboard USB HUB

[Ulf Hansson]

On 9 December 2015 at 09:55, Arnd Bergmann  wrote:
> On Wednesday 09 December 2015 16:12:24 Peter Chen wrote:
>> On Tue, Dec 08, 2015 at 09:24:03PM -0600, Rob Herring wrote:
>> > On Tue, Dec 08, 2015 at 10:58:48AM +0100, Arnd Bergmann wrote:
>> > > On Tuesday 08 December 2015 10:50:49 Philipp Zabel wrote:
>> > > > This something we don't have to define ad-hoc. The hub hangs off an USB
>> > > > controller, right? The "Open Firmware recommended practice: USB"
>> > > > document already describes how to represent USB devices in a generic
>> > > > manner:
>> > > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
>> > > >
>> > > > Is there a reason not to reuse this?
>> > > >
>> > > > The usb hub node would be a child of the usb controller node, and it
>> > > > could use
>> > > > compatible = "usb,class9"; /* bDeviceClass 9 (Hub) */
>> > >
>> > > Good point, I had not thought of that when I looked at the patches.
>> > >
>> > > Yes, let's do this way. I don't know if we ever implemented the simple
>> > > patch to associate a USB device with a device_node, but if not, then
>> > > let's do it now for this driver. A lot of people have asked for it in
>> > > the past.
>> >
>> > Agreed. Also, some hubs have I2C buses as well, but I still think under
>> > the USB bus is the right place.
>> >
>> > However, one complication here is often (probably this case) these
>> > addtional signals need to be controlled before the device enumerates.
>> >
>>
>> Yes, I did not find a way to let the USB bus code handle it, so I had to
>> write a platform driver to do it
>
> Looping in Ulf, he solved the same problem for SDIO devices recently,
> and probably remembers the details best.
>

Thanks Arnd!

Yes, that was a kind of a long outstanding issue we have had for SDIO devices.

Several generic attempts was made to have a framework/library
available to support so called "power sequences" for exactly the same
reasons as above.
Others and myself failed to get those attempts accepted.

Instead, I invented a mmc subsystem specific DT based solution, the
"mmc-pwrseq".

DT documentation:
Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
Documentation/devicetree/bindings/mmc/mmc.txt

Long story short: The mmc host device may contain a phandle to a
mmc-pwrseq, which will describe the resources needed to power on/off
the SDIO card.

The code is available at:
drivers/mmc/core/pwrseq*

We didn't implement this as platform driver, but that was mostly
because I initially wanted things to be simple. Although, nothing
prevents us from converting to this as a follow up, which would make
the solution a bit less "hacky".

Kind regards
Uffe
--
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 v2] extcon: add Maxim MAX3355 driver

[Greg KH]

On Tue, Dec 15, 2015 at 02:24:56PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/15/2015 2:44 AM, Greg KH wrote:
> 
> >>Maxim  Integrated MAX3355E chip integrates a  charge pump and 
> >>comparators
> >>to
> >>enable a system with an integrated USB OTG dual-role transceiver to
> >>function
> >>as  an 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
> >>aren't currently interested in them),  the OFFVBUS# signal is controlled
> >>by
> >>the host controllers, there's  also the SHDN# signal wired to a GPIO, it
> >>should be driven high for the  normal operation.
> >
> >
> >As multiple people have said, fix the spacing here.
> 
> 
> You are the first to complain abou _this_ patch. If you don't have 
>  other
> issues with this driver in which case you should have trimmed the reply at
> this point), I'd like to keep my spacing as is. Thank you.
> >>>
> >>>Your previous version was not "extcon-usb-gpio: add enable pin
> >>>support"[1] which has now been re-written to be max3355 specific?
> >>
> >>No, the MAX3355 driver pre-dates that version. First there was a driver,
> >>then I tried to re-use the existing stuff (there was no extcon-usb-gpio at
> >>the time of writing my driver), then had to return to the separate driver
> >>idea...
> >>
> >>>"So
> >>>what" and "I'd like to keep my spacing as is" aren't valid reasons.
> >>>Fix it, then I'll look at the rest again.
> >>
> >>I'll consider doing that if you care to explain what's the problem with
> >>my spacing. TIA.
> >
> >You are mixing 2 and 1 spaces between words, don't do that.
> 
>Care to just explain why?

Because the rules of typography and grammer do not allow this.

Are you really arguing this?  If so, it's trivial for us to just ignore
your patches if you insist on this.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/15/2015 09:51 PM, Greg KH wrote:


Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators
to
enable a system with an integrated USB OTG dual-role transceiver to
function
as  an 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
aren't currently interested in them),  the OFFVBUS# signal is controlled
by
the host controllers, there's  also the SHDN# signal wired to a GPIO, it
should be driven high for the  normal operation.



As multiple people have said, fix the spacing here.



You are the first to complain abou _this_ patch. If you don't have other
issues with this driver in which case you should have trimmed the reply at
this point), I'd like to keep my spacing as is. Thank you.


Your previous version was not "extcon-usb-gpio: add enable pin
support"[1] which has now been re-written to be max3355 specific?


No, the MAX3355 driver pre-dates that version. First there was a driver,
then I tried to re-use the existing stuff (there was no extcon-usb-gpio at
the time of writing my driver), then had to return to the separate driver
idea...


"So
what" and "I'd like to keep my spacing as is" aren't valid reasons.
Fix it, then I'll look at the rest again.


I'll consider doing that if you care to explain what's the problem with
my spacing. TIA.


You are mixing 2 and 1 spaces between words, don't do that.


Care to just explain why?


Because the rules of typography and grammer do not allow this.


   Typography? Are you serious? The books are all printed using filled up 
lines with arbitrary spaces between words. Grammar, maybe.



Are you really arguing this?  If so, it's trivial for us to just ignore
your patches if you insist on this.


   I haven't had the opposite side's arguments so far, just "don't do it 
because we say so". Geert's mail was the first with such argument, and it 
didn't really seem a serious one, sorry.
   And please don't try to intimidate me with ignoring my patches. With 750+ 
merged patches I don't care that much...



greg k-h


MBR, Sergei

--
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: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[kbuild test robot]

Hi Yoshihiro,

[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.4-rc5 next-20151214]

url:
https://github.com/0day-ci/linux/commits/Yoshihiro-Shimoda/usb-gadget-renesas_usb3-add-support-for-Renesas-USB3-0-peripheral-controller/20151215-145706
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/bug.h:35:0,
from include/linux/bug.h:4,
from include/linux/thread_info.h:11,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/interrupt.h:8,
from drivers/usb/gadget/udc/renesas_usb3.c:13:
   drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_calc_ramarea':
>> drivers/usb/gadget/udc/renesas_usb3.c:1240:21: error: 'SZ_16K' undeclared 
>> (first use in this function)
 WARN_ON(ram_size > SZ_16K);
^
   include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
 int __ret_warn_on = !!(condition);\
^
   drivers/usb/gadget/udc/renesas_usb3.c:1240:21: note: each undeclared 
identifier is reported only once for each function it appears in
 WARN_ON(ram_size > SZ_16K);
^
   include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
 int __ret_warn_on = !!(condition);\
^
>> drivers/usb/gadget/udc/renesas_usb3.c:1242:18: error: 'SZ_1K' undeclared 
>> (first use in this function)
 if (ram_size <= SZ_1K)
 ^
>> drivers/usb/gadget/udc/renesas_usb3.c:1244:23: error: 'SZ_2K' undeclared 
>> (first use in this function)
 else if (ram_size <= SZ_2K)
  ^
>> drivers/usb/gadget/udc/renesas_usb3.c:1246:23: error: 'SZ_4K' undeclared 
>> (first use in this function)
 else if (ram_size <= SZ_4K)
  ^
>> drivers/usb/gadget/udc/renesas_usb3.c:1248:23: error: 'SZ_8K' undeclared 
>> (first use in this function)
 else if (ram_size <= SZ_8K)
  ^
   drivers/usb/gadget/udc/renesas_usb3.c: At top level:
>> drivers/usb/gadget/udc/renesas_usb3.c:1626:23: error: 'SZ_16K' undeclared 
>> here (not in a function)
 .ramsize_per_ramif = SZ_16K,
  ^
>> drivers/usb/gadget/udc/renesas_usb3.c:1628:22: error: 'SZ_4K' undeclared 
>> here (not in a function)
 .ramsize_per_pipe = SZ_4K,
 ^
   drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_calc_ramarea':
>> drivers/usb/gadget/udc/renesas_usb3.c:1252:1: warning: control reaches end 
>> of non-void function [-Wreturn-type]
}
^

vim +/SZ_16K +1240 drivers/usb/gadget/udc/renesas_usb3.c

  1234  val |= PN_MOD_EPNUM(usb_endpoint_num(desc));
  1235  usb3_write(usb3, val, USB3_PN_MOD);
  1236  }
  1237  
  1238  static u32 usb3_calc_ramarea(int ram_size)
  1239  {
> 1240  WARN_ON(ram_size > SZ_16K);
  1241  
> 1242  if (ram_size <= SZ_1K)
  1243  return PN_RAMMAP_RAMAREA_1KB;
> 1244  else if (ram_size <= SZ_2K)
  1245  return PN_RAMMAP_RAMAREA_2KB;
> 1246  else if (ram_size <= SZ_4K)
  1247  return PN_RAMMAP_RAMAREA_4KB;
> 1248  else if (ram_size <= SZ_8K)
  1249  return PN_RAMMAP_RAMAREA_8KB;
  1250  else
  1251  return PN_RAMMAP_RAMAREA_16KB;
> 1252  }
  1253  
  1254  static u32 usb3_calc_rammap_val(struct renesas_usb3_ep *usb3_ep,
  1255  const struct usb_endpoint_descriptor 
*desc)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Peter Chen]

On Mon, Dec 14, 2015 at 10:35:19AM +0100, Arnd Bergmann wrote:
> On Monday 14 December 2015 15:26:11 Peter Chen wrote:
> > Hi all,
> > 
> > There is a known issue that the USB code can't handle USB HUB's
> > external pins well, in that case, it may cause some onboard
> > USB HUBs can't work since their PHY's clock or reset pin needs to
> > operate.
> > 
> > The user reported this issue at below:
> > http://www.spinics.net/lists/linux-usb/msg131502.html
> > 
> > In this patch set, I add a generic onboard USB HUB driver to
> > handle this problem, the external signals will be configured
> > before usb controller's initialization, it much likes we did
> > it at board code before.
> > 
> > The user needs to add this generic hub node at dts to support it.
> > 
> > @The udoo users, help to test please.
> 
> I still think need to do this properly by representing the hub
> device as a USB device, using power sequencing code like MMC does.
> 
>   Arnd

I will try to have a patch set for general onboard USB 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

[PATCH v3 4/9] phy: ti-pipe3: move mem resource initialization to a separate function

[Kishon Vijay Abraham I]

No functional change. Moved mem resource initialization done in
probe to a separate function as part of cleaning up
ti_pipe3_probe.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-ti-pipe3.c |   52 
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 3154da0..1991efd 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -418,14 +418,42 @@ static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_pll_base(struct ti_pipe3 *phy)
+{
+   struct resource *res;
+   const struct of_device_id *match;
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
+   struct platform_device *pdev = to_platform_device(dev);
+
+   if (of_device_is_compatible(node, "ti,phy-pipe3-pcie"))
+   return 0;
+
+   match = of_match_device(ti_pipe3_id_table, dev);
+   if (!match)
+   return -EINVAL;
+
+   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
+   if (!phy->dpll_map) {
+   dev_err(dev, "no DPLL data\n");
+   return -EINVAL;
+   }
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "pll_ctrl");
+   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(phy->pll_ctrl_base))
+   return PTR_ERR(phy->pll_ctrl_base);
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
struct phy *generic_phy;
struct phy_provider *phy_provider;
-   struct resource *res;
struct device_node *node = pdev->dev.of_node;
-   const struct of_device_id *match;
struct device *dev = >dev;
int ret;
 
@@ -435,23 +463,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
phy->dev= dev;
 
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   match = of_match_device(ti_pipe3_id_table, dev);
-   if (!match)
-   return -EINVAL;
-
-   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
-   if (!phy->dpll_map) {
-   dev_err(dev, "no DPLL data\n");
-   return -EINVAL;
-   }
-
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(phy->pll_ctrl_base))
-   return PTR_ERR(phy->pll_ctrl_base);
-   }
+   ret = ti_pipe3_get_pll_base(phy);
+   if (ret)
+   return ret;
 
ret = ti_pipe3_get_sysctrl(phy);
if (ret)
-- 
1.7.9.5

--
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 v3 2/9] phy: ti-pipe3: move clk initialization to a separate function

[Kishon Vijay Abraham I]

No functional change. Moved clock initialization done in probe to a
separate function as part of cleaning up ti_pipe3_probe.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-ti-pipe3.c |  127 +---
 1 file changed, 72 insertions(+), 55 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index c511105..3379a4d 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -308,48 +308,11 @@ static const struct phy_ops ops = {
 
 static const struct of_device_id ti_pipe3_id_table[];
 
-static int ti_pipe3_probe(struct platform_device *pdev)
+static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
 {
-   struct ti_pipe3 *phy;
-   struct phy *generic_phy;
-   struct phy_provider *phy_provider;
-   struct resource *res;
-   struct device_node *node = pdev->dev.of_node;
-   struct device_node *control_node;
-   struct platform_device *control_pdev;
-   const struct of_device_id *match;
struct clk *clk;
-   struct device *dev = >dev;
-
-   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
-   if (!phy)
-   return -ENOMEM;
-
-   phy->dev= dev;
-
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   match = of_match_device(ti_pipe3_id_table, dev);
-   if (!match)
-   return -EINVAL;
-
-   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
-   if (!phy->dpll_map) {
-   dev_err(dev, "no DPLL data\n");
-   return -EINVAL;
-   }
-
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(phy->pll_ctrl_base))
-   return PTR_ERR(phy->pll_ctrl_base);
-
-   phy->sys_clk = devm_clk_get(dev, "sysclk");
-   if (IS_ERR(phy->sys_clk)) {
-   dev_err(dev, "unable to get sysclk\n");
-   return -EINVAL;
-   }
-   }
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
 
phy->refclk = devm_clk_get(dev, "refclk");
if (IS_ERR(phy->refclk)) {
@@ -369,25 +332,17 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
} else {
phy->wkupclk = ERR_PTR(-ENODEV);
-   phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
-   "syscon-pllreset");
-   if (IS_ERR(phy->dpll_reset_syscon)) {
-   dev_info(dev,
-"can't get syscon-pllreset, sata dpll won't 
idle\n");
-   phy->dpll_reset_syscon = NULL;
-   } else {
-   if (of_property_read_u32_index(node,
-  "syscon-pllreset", 1,
-  >dpll_reset_reg)) {
-   dev_err(dev,
-   "couldn't get pllreset reg. offset\n");
-   return -EINVAL;
-   }
+   }
+
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   phy->sys_clk = devm_clk_get(dev, "sysclk");
+   if (IS_ERR(phy->sys_clk)) {
+   dev_err(dev, "unable to get sysclk\n");
+   return -EINVAL;
}
}
 
if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-
clk = devm_clk_get(dev, "dpll_ref");
if (IS_ERR(clk)) {
dev_err(dev, "unable to get dpll ref clk\n");
@@ -418,6 +373,68 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy->div_clk = ERR_PTR(-ENODEV);
}
 
+   return 0;
+}
+
+static int ti_pipe3_probe(struct platform_device *pdev)
+{
+   struct ti_pipe3 *phy;
+   struct phy *generic_phy;
+   struct phy_provider *phy_provider;
+   struct resource *res;
+   struct device_node *node = pdev->dev.of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+   const struct of_device_id *match;
+   struct device *dev = >dev;
+   int ret;
+
+   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+   if (!phy)
+   return -ENOMEM;
+
+   phy->dev= dev;
+
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   match = of_match_device(ti_pipe3_id_table, dev);
+   if (!match)
+   return -EINVAL;
+
+   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
+   if (!phy->dpll_map) {
+   

[PATCH v3 3/9] phy: ti-pipe3: move sysctrl initialization to a separate function

[Kishon Vijay Abraham I]

No functional change. Moved sysctrl initialization done in probe to a
separate function as part of cleaning up ti_pipe3_probe.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-ti-pipe3.c |   78 +---
 1 file changed, 45 insertions(+), 33 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 3379a4d..3154da0 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -376,6 +376,48 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
+{
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+
+   control_node = of_parse_phandle(node, "ctrl-module", 0);
+   if (!control_node) {
+   dev_err(dev, "Failed to get control device phandle\n");
+   return -EINVAL;
+   }
+
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(dev, "Failed to get control device\n");
+   return -EINVAL;
+   }
+
+   phy->control_dev = _pdev->dev;
+
+   if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
+   phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
+   "syscon-pllreset");
+   if (IS_ERR(phy->dpll_reset_syscon)) {
+   dev_info(dev,
+"can't get syscon-pllreset, sata dpll won't 
idle\n");
+   phy->dpll_reset_syscon = NULL;
+   } else {
+   if (of_property_read_u32_index(node,
+  "syscon-pllreset", 1,
+  >dpll_reset_reg)) {
+   dev_err(dev,
+   "couldn't get pllreset reg. offset\n");
+   return -EINVAL;
+   }
+   }
+   }
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
@@ -383,8 +425,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct phy_provider *phy_provider;
struct resource *res;
struct device_node *node = pdev->dev.of_node;
-   struct device_node *control_node;
-   struct platform_device *control_pdev;
const struct of_device_id *match;
struct device *dev = >dev;
int ret;
@@ -413,42 +453,14 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return PTR_ERR(phy->pll_ctrl_base);
}
 
-   if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
-   phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
-   "syscon-pllreset");
-   if (IS_ERR(phy->dpll_reset_syscon)) {
-   dev_info(dev,
-"can't get syscon-pllreset, sata dpll won't 
idle\n");
-   phy->dpll_reset_syscon = NULL;
-   } else {
-   if (of_property_read_u32_index(node,
-  "syscon-pllreset", 1,
-  >dpll_reset_reg)) {
-   dev_err(dev,
-   "couldn't get pllreset reg. offset\n");
-   return -EINVAL;
-   }
-   }
-   }
+   ret = ti_pipe3_get_sysctrl(phy);
+   if (ret)
+   return ret;
 
ret = ti_pipe3_get_clk(phy);
if (ret)
return ret;
 
-   control_node = of_parse_phandle(node, "ctrl-module", 0);
-   if (!control_node) {
-   dev_err(dev, "Failed to get control device phandle\n");
-   return -EINVAL;
-   }
-
-   control_pdev = of_find_device_by_node(control_node);
-   if (!control_pdev) {
-   dev_err(dev, "Failed to get control device\n");
-   return -EINVAL;
-   }
-
-   phy->control_dev = _pdev->dev;
-
omap_control_phy_power(phy->control_dev, 0);
 
platform_set_drvdata(pdev, phy);
-- 
1.7.9.5

--
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 v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Kishon Vijay Abraham I]

Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: tisyscon@1c24 {
+   compatible = "syscon";
+   reg = <0x1c24 0x0024>;
+   };
};
 
cm_core_aon: cm_core_aon@5000 {
-- 
1.7.9.5

--
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] Add support for usbfs zerocopy.

[David Laight]

From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 14 December 2015 17:59
> On Mon, 14 Dec 2015, David Laight wrote:
> 
> > From: Alan Stern
> > > Sent: 14 December 2015 15:28
> > ...
> > > I thought of something else, a more serious problem.  According to the
> > > man page for munmap(2), closing the file descriptor does not unmap the
> > > region.  Therefore we need to explicitly make sure that the usbcore
> > > module cannot be unloaded while any memory mappings exist, by calling
> > > try_module_get(THIS_MODULE) when a mapping is created and
> > > module_put(THIS_MODULE) when a mapping is removed.
> >
> > Are you sure this is a problem?
> 
> I haven't actually tried to provoke a crash, if that's what you're
> asking.  Apart from that, yes, I'm sure this is a problem.

There are certainly potential issues with both remap_pfn_range()
and vm_iomap_memory().

> > It is more likely that either:
> > 1) the mmap() holds a reference to the physical pages - so they don't
> >   get freed even though the driver frees its reference to the memory.
> 
> The problem has nothing to do with the pages being freed.
> 
> > 2) when the driver frees the memory the user-space page tables are
> >   invalidated - so the next access generates EFAULT.
> 
> I'm not sure what you're getting at here.  The page tables are
> invalidated when the user program calls munmap (or exits), and the
> driver frees the memory when that happens.
> 
> > Not that I've done the experiment (or tried to read the code).
> >
> > If you need to monitor the mapping, you need to allow for partial unmaps.
> 
> That's not the problem either -- although I don't know how we should
> handle partial unmaps.  Can we disallow them?
> 
> The problem is that the user can map the memory, then close the file
> descriptor, then rmmod the usbcore module, then unmap the memory
> region.  When the unmap occurs, the memory subsystem will try to
> dereference the usbdev_vm_ops structure -- which has been unloaded
> along with the rest of usbcore.  This will cause an oops.

I was thinking that some side effect of dma_free_coherent() would
find the user mapping for the pages, force unmap them and invalidate
the user PTE (although the address range would have to remain reserved).
Maybe that is wishful thinking.

Similarly for iounmap().

> In theory we could prevent this problem by unmapping the memory when
> the file descriptor is closed.  But doing so would violate the
> guarantee in the munmap(2) documentation.

That doesn't help.
The mapping is inherited by fork() but you only see the last close().
So the close() need not be in the context of the process that has
the pages mapped.

David

--
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 v3 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Kishon Vijay Abraham I]

Deprecate using phy-omap-control driver to power on/off the PHY,
and use *syscon* framework to do the same. This handles
powering on/off the PHY for the USB2 PHYs used in various TI SoCs.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
 drivers/phy/phy-omap-usb2.c  |   94 ++
 include/linux/phy/omap_usb.h |   23 ++
 3 files changed, 107 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 49e5b0c..a3b3945 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -31,6 +31,8 @@ OMAP USB2 PHY
 
 Required properties:
  - compatible: Should be "ti,omap-usb2"
+  Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
+  in DRA7x
  - reg : Address and length of the register set for the device.
  - #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
@@ -40,10 +42,14 @@ Required properties:
* "wkupclk" - wakeup clock.
* "refclk" - reference clock (optional).
 
-Optional properties:
+Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
the PHY.
 
+Recommended properies:
+- syscon-phy-power : phandle/offset pair. Phandle to the system control
+  module and the register offset to power on/off the PHY.
+
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb2phy@4a0ad080 {
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index c79633e..c9c04ff 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #define USB2PHY_DISCON_BYP_LATCH (1 << 31)
@@ -97,22 +99,40 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb_power_off(struct phy *x)
+static int omap_usb_phy_power(struct omap_usb *phy, int on)
 {
-   struct omap_usb *phy = phy_get_drvdata(x);
+   u32 val;
+   int ret;
 
-   omap_control_phy_power(phy->control_dev, 0);
+   if (phy->syscon_phy_power) {
+   if (on)
+   val = phy->power_on;
+   else
+   val = phy->power_off;
+
+   ret = regmap_update_bits(phy->syscon_phy_power, phy->power_reg,
+phy->mask, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, on);
+   }
 
return 0;
 }
 
-static int omap_usb_power_on(struct phy *x)
+static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 1);
+   return omap_usb_phy_power(phy, false);
+}
 
-   return 0;
+static int omap_usb_power_on(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+
+   return omap_usb_phy_power(phy, true);
 }
 
 static int omap_usb_init(struct phy *x)
@@ -147,21 +167,38 @@ static const struct phy_ops ops = {
 static const struct usb_phy_data omap_usb2_data = {
.label = "omap_usb2",
.flags = OMAP_USB2_HAS_START_SRP | OMAP_USB2_HAS_SET_VBUS,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
 };
 
 static const struct usb_phy_data omap5_usb2_data = {
.label = "omap5_usb2",
.flags = 0,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
 };
 
 static const struct usb_phy_data dra7x_usb2_data = {
.label = "dra7x_usb2",
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
+};
+
+static const struct usb_phy_data dra7x_usb2_phy2_data = {
+   .label = "dra7x_usb2_phy2",
+   .flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+   .mask = OMAP_USB2_PHY_PD,
+   .power_off = OMAP_USB2_PHY_PD,
 };
 
 static const struct usb_phy_data am437x_usb2_data = {
.label = "am437x_usb2",
.flags =  0,
+   .mask = AM437X_USB2_PHY_PD | AM437X_USB2_OTG_PD |
+   AM437X_USB2_OTGVDET_EN | AM437X_USB2_OTGSESSEND_EN,
+   .power_on = AM437X_USB2_OTGVDET_EN | AM437X_USB2_OTGSESSEND_EN,
+   .power_off = AM437X_USB2_PHY_PD | AM437X_USB2_OTG_PD,
 };
 
 static const struct of_device_id omap_usb2_id_table[] = {
@@ -178,6 +215,10 @@ static const struct of_device_id omap_usb2_id_table[] = {
.data = _usb2_data,
},
{
+   .compatible = "ti,dra7x-usb2-phy2",
+   .data = _usb2_phy2_data,
+   },
+   {
.compatible = "ti,am437x-usb2",
.data = _usb2_data,
},
@@ -219,6 +260,9 @@ static int omap_usb2_probe(struct 

[PATCH v3 8/9] phy: omap-usb2: use omap_usb_power_off to power off the PHY during probe

[Kishon Vijay Abraham I]

No functional change. Previously omap_control_phy_power() was used to power
off the PHY during probe. But once phy-omap-usb2 driver is adapted to
use syscon, omap_control_phy_power() cannot be used. Hence used
omap_usb_power_off to power off the PHY.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Roger Quadros 
---
 drivers/phy/phy-omap-usb2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 0fe8058..c79633e 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -241,7 +241,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy->control_dev = _pdev->dev;
-   omap_control_phy_power(phy->control_dev, 0);
 
otg->set_host   = omap_usb_set_host;
otg->set_peripheral = omap_usb_set_peripheral;
@@ -261,6 +260,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy_set_drvdata(generic_phy, phy);
+   omap_usb_power_off(generic_phy);
 
phy_provider = devm_of_phy_provider_register(phy->dev,
of_phy_simple_xlate);
-- 
1.7.9.5

--
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 v3 1/9] phy: ti-pipe3: introduce local struct device* in probe

[Kishon Vijay Abraham I]

No functional change. Introduce local struct device pointer in
probe and replace using >dev/phy->dev with the local
device pointer. This is in preparation to split ti_pipe3_probe
and add separate functions for getting mem resource, getting
sysctrl and getting clocks.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-ti-pipe3.c |   54 ++--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 93bc112..c511105 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -319,40 +319,41 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct platform_device *control_pdev;
const struct of_device_id *match;
struct clk *clk;
+   struct device *dev = >dev;
 
-   phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   phy->dev= >dev;
+   phy->dev= dev;
 
if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   match = of_match_device(ti_pipe3_id_table, >dev);
+   match = of_match_device(ti_pipe3_id_table, dev);
if (!match)
return -EINVAL;
 
phy->dpll_map = (struct pipe3_dpll_map *)match->data;
if (!phy->dpll_map) {
-   dev_err(>dev, "no DPLL data\n");
+   dev_err(dev, "no DPLL data\n");
return -EINVAL;
}
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
   "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(>dev, res);
+   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
if (IS_ERR(phy->pll_ctrl_base))
return PTR_ERR(phy->pll_ctrl_base);
 
-   phy->sys_clk = devm_clk_get(phy->dev, "sysclk");
+   phy->sys_clk = devm_clk_get(dev, "sysclk");
if (IS_ERR(phy->sys_clk)) {
-   dev_err(>dev, "unable to get sysclk\n");
+   dev_err(dev, "unable to get sysclk\n");
return -EINVAL;
}
}
 
-   phy->refclk = devm_clk_get(phy->dev, "refclk");
+   phy->refclk = devm_clk_get(dev, "refclk");
if (IS_ERR(phy->refclk)) {
-   dev_err(>dev, "unable to get refclk\n");
+   dev_err(dev, "unable to get refclk\n");
/* older DTBs have missing refclk in SATA PHY
 * so don't bail out in case of SATA PHY.
 */
@@ -361,9 +362,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
 
if (!of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
-   phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
+   phy->wkupclk = devm_clk_get(dev, "wkupclk");
if (IS_ERR(phy->wkupclk)) {
-   dev_err(>dev, "unable to get wkupclk\n");
+   dev_err(dev, "unable to get wkupclk\n");
return PTR_ERR(phy->wkupclk);
}
} else {
@@ -371,14 +372,14 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
"syscon-pllreset");
if (IS_ERR(phy->dpll_reset_syscon)) {
-   dev_info(>dev,
+   dev_info(dev,
 "can't get syscon-pllreset, sata dpll won't 
idle\n");
phy->dpll_reset_syscon = NULL;
} else {
if (of_property_read_u32_index(node,
   "syscon-pllreset", 1,
   >dpll_reset_reg)) {
-   dev_err(>dev,
+   dev_err(dev,
"couldn't get pllreset reg. offset\n");
return -EINVAL;
}
@@ -387,30 +388,30 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
 
-   clk = devm_clk_get(phy->dev, "dpll_ref");
+   clk = devm_clk_get(dev, "dpll_ref");
if (IS_ERR(clk)) {
-   dev_err(>dev, "unable to get dpll ref clk\n");
+   dev_err(dev, "unable to get dpll ref clk\n");
return PTR_ERR(clk);
}
clk_set_rate(clk, 15);
 
-   clk = devm_clk_get(phy->dev, "dpll_ref_m2");
+   clk = devm_clk_get(dev, 

[PATCH v3 4/4] ARM: dts: : Use "syscon-phy-power" instead of "ctrl-module"

[Kishon Vijay Abraham I]

Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA and USB PHY node. Also remove the unused control
module dt nodes.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am4372.dtsi |   16 ++--
 arch/arm/boot/dts/dra7.dtsi   |   34 --
 arch/arm/boot/dts/omap5.dtsi  |   26 +++---
 3 files changed, 9 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..f42d4a4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -853,18 +853,6 @@
status = "disabled";
};
 
-   am43xx_control_usb2phy1: control-phy@44e10620 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10620 0x4>;
-   reg-names = "power";
-   };
-
-   am43xx_control_usb2phy2: control-phy@0x44e10628 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10628 0x4>;
-   reg-names = "power";
-   };
-
ocp2scp0: ocp2scp@483a8000 {
compatible = "ti,am437x-ocp2scp", "ti,omap-ocp2scp";
#address-cells = <1>;
@@ -875,7 +863,7 @@
usb2_phy1: phy@483a8000 {
compatible = "ti,am437x-usb2";
reg = <0x483a8000 0x8000>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x620>;
clocks = <_phy0_always_on_clk32k>,
 <_otg_ss0_refclk960m>;
clock-names = "wkupclk", "refclk";
@@ -894,7 +882,7 @@
usb2_phy2: phy@483e8000 {
compatible = "ti,am437x-usb2";
reg = <0x483e8000 0x8000>;
-   ctrl-module = <_control_usb2phy2>;
+   syscon-phy-power = <_conf 0x628>;
clocks = <_phy1_always_on_clk32k>,
 <_otg_ss1_refclk960m>;
clock-names = "wkupclk", "refclk";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 41545f9..8ce37e4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1170,14 +1170,6 @@
status = "disabled";
};
 
-   omap_control_sata: control-phy@4a002374 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002374 0x4>;
-   reg-names = "power";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -1192,7 +1184,7 @@
  <0x4A096400 0x64>, /* phy_tx */
  <0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-   ctrl-module = <_control_sata>;
+   syscon-phy-power = <_conf 0x374>;
clocks = <_clkin1>, <_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <_conf 0x3fc>;
@@ -1260,24 +1252,6 @@
clocks = <_32k_ck>;
};
 
-   omap_control_usb2phy1: control-phy@4a002300 {
-   compatible = "ti,control-phy-usb2";
-   reg = <0x4a002300 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb3phy1: control-phy@4a002370 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002370 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb2phy2: control-phy@0x4a002e74 {
-   compatible = "ti,control-phy-usb2-dra7";
-   reg = <0x4a002e74 0x4>;
-   reg-names = "power";
-   };
-
/* OCP2SCP1 */
ocp2scp@4a08 {
compatible = "ti,omap-ocp2scp";
@@ -1290,7 +1264,7 @@
usb2_phy1: phy@4a084000 {
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x400>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x300>;
clocks = 

[PATCH v3 3/4] ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2

[Kishon Vijay Abraham I]

The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, use the new compatible
string "ti,dra7x-usb2-phy2" for the second instance of USB2 PHY.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 156d735..41545f9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1299,7 +1299,8 @@
};
 
usb2_phy2: phy@4a085000 {
-   compatible = "ti,omap-usb2";
+   compatible = "ti,dra7x-usb2-phy2",
+"ti,omap-usb2";
reg = <0x4a085000 0x400>;
ctrl-module = <_control_usb2phy2>;
clocks = <_phy2_always_on_clk32k>,
-- 
1.7.9.5

--
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 v3 2/4] ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node

[Kishon Vijay Abraham I]

Add "syscon-phy-power" property and "syscon-pcs" property which can
be used to perform the control module initializations and remove
the deprecated "ctrl-module" property from PCIe PHY dt nodes.

Phandle to "sysclk" clock node is also added to the PCIe PHY node
since some of the syscon initializations is based on system clock
frequency.

Since "omap_control_pcie1phy" and "omap_control_pcie2phy" devicetree
nodes are no longer used, remove it.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |   33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e38f63f..156d735 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1204,16 +1204,18 @@
reg = <0x4a094000 0x80>, /* phy_rx */
  <0x4a094400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie1phy>;
+   syscon-phy-power = <_conf_pcie 0x1c>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy1_32khz>,
 <_pciephy1_clk>,
 <_pciephy1_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
};
 
@@ -1222,16 +1224,18 @@
reg = <0x4a095000 0x80>, /* phy_rx */
  <0x4a095400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie2phy>;
+   syscon-phy-power = <_conf_pcie 0x20>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy2_32khz>,
 <_pciephy2_clk>,
 <_pciephy2_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
status = "disabled";
};
@@ -1247,23 +1251,6 @@
ti,hwmods = "sata";
};
 
-   omap_control_pcie1phy: control-phy@0x4a003c40 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
-   omap_control_pcie2phy: control-pcie@0x4a003c44 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   status = "disabled";
-   };
-
rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
-- 
1.7.9.5

--
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 v3 0/4] ARM: dts: use syscon property instead of ctrl-module

[Kishon Vijay Abraham I]

This series is basically to deprecate using ctrl-module property and use
corresponding syscon properties to program the control module registers.

Changes from v2:
No changes.

Changes from v1:
*) Squashed the patches that replaces "ctrl-module" with
   "syscon-phy-power"
*) Added "syscon-phy-power" for SATA dt node in OMAP5 which was missed
   earlier
*) removed _ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module"
   in USB node_. It will be done later.

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

This series should be merged only after [2]

[2] -> http://www.spinics.net/lists/kernel/msg2144510.html

Logs with SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025205/
DRA7 EVM  : http://pastebin.ubuntu.com/14025212/
AM43XX EVM: http://pastebin.ubuntu.com/14025222/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025228/

Logs without SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025233/
DRA7 EVM  : http://pastebin.ubuntu.com/14025238/
AM43XX EVM: http://pastebin.ubuntu.com/14025329/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025248/

The config I used: http://pastebin.ubuntu.com/14025336/

Kishon Vijay Abraham I (4):
  ARM: dts: dra7: Add dt node for the sycon pcie
  ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY
node
  ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2
PHY2
  ARM: dts: : Use "syscon-phy-power" instead of
"ctrl-module"

 arch/arm/boot/dts/am4372.dtsi |   16 ++---
 arch/arm/boot/dts/dra7.dtsi   |   75 -
 arch/arm/boot/dts/omap5.dtsi  |   26 ++
 3 files changed, 26 insertions(+), 91 deletions(-)

-- 
1.7.9.5

--
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 v3 6/9] phy: ti-pipe3: use *syscon* framework API to power on/off the PHY

[Kishon Vijay Abraham I]

Deprecate using phy-omap-control driver to power on/off the PHY and
use *syscon* framework to do the same.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |   10 ++-
 drivers/phy/phy-ti-pipe3.c   |   90 ++
 2 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 9cf9446..e06f980 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -77,8 +77,6 @@ Required properties:
* "div-clk" - apll clock
 
 Optional properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
-   the PHY.
  - id: If there are multiple instance of the same type, in order to
differentiate between each instance "id" can be used (e.g., multi-lane PCIe
PHY). If "id" is not provided, it is set to default value of '1'.
@@ -86,6 +84,14 @@ Optional properties:
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
 
+Deprecated properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+   the PHY.
+
+Recommended properies:
+ - syscon-phy-power : phandle/offset pair. Phandle to the system control
+   module and the register offset to power on/off the PHY.
+
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb3phy@4a084400 {
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0ce4194..bc03625 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -56,6 +56,15 @@
 
 #define SATA_PLL_SOFT_RESETBIT(18)
 
+#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK  0x003FC000
+#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
+
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK 0xFFC0
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT22
+
+#define PIPE3_PHY_TX_RX_POWERON0x3
+#define PIPE3_PHY_TX_RX_POWEROFF   0x0
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -86,8 +95,10 @@ struct ti_pipe3 {
struct clk  *refclk;
struct clk  *div_clk;
struct pipe3_dpll_map   *dpll_map;
+   struct regmap   *phy_power_syscon; /* ctrl. reg. acces */
struct regmap   *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
+   unsigned intpower_reg; /* power reg. index within syscon */
boolsata_refclk_enabled;
 };
 
@@ -144,18 +155,53 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 *phy);
 
 static int ti_pipe3_power_off(struct phy *x)
 {
+   u32 val;
+   int ret;
struct ti_pipe3 *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 0);
+   if (phy->phy_power_syscon) {
+   val = PIPE3_PHY_TX_RX_POWEROFF <<
+   PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+
+   ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, 0);
+   }
 
return 0;
 }
 
 static int ti_pipe3_power_on(struct phy *x)
 {
+   u32 val;
+   u32 mask;
+   int ret;
+   unsigned long rate;
struct ti_pipe3 *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 1);
+   if (phy->phy_power_syscon) {
+   rate = clk_get_rate(phy->sys_clk);
+   if (!rate) {
+   dev_err(phy->dev, "Invalid clock rate\n");
+   return -EINVAL;
+   }
+   rate = rate / 100;
+   mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
+ OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
+   val = PIPE3_PHY_TX_RX_POWERON <<
+   PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+   val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+
+   ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+mask, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, 1);
+   }
 
return 0;
 }
@@ -334,7 +380,8 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
phy->wkupclk = ERR_PTR(-ENODEV);
}
 
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie") ||
+   phy->phy_power_syscon) {

[PATCH v3 7/9] phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY

[Kishon Vijay Abraham I]

Deprecate using phy-omap-control driver to set PCS value of the PHY
and start using *syscon* API to do the same.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
 drivers/phy/phy-ti-pipe3.c   |   34 +-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index e06f980..49e5b0c 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -83,6 +83,8 @@ Optional properties:
  - syscon-pllreset: Handle to system control region that contains the
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
+ - syscon-pcs : phandle/offset pair. Phandle to the system control module and 
the
+   register offset to write the PCS delay value.
 
 Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index bc03625..684d467 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -65,6 +65,9 @@
 #define PIPE3_PHY_TX_RX_POWERON0x3
 #define PIPE3_PHY_TX_RX_POWEROFF   0x0
 
+#define PCIE_PCS_MASK  0xFF
+#define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -96,9 +99,11 @@ struct ti_pipe3 {
struct clk  *div_clk;
struct pipe3_dpll_map   *dpll_map;
struct regmap   *phy_power_syscon; /* ctrl. reg. acces */
+   struct regmap   *pcs_syscon; /* ctrl. reg. acces */
struct regmap   *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
unsigned intpower_reg; /* power reg. index within syscon */
+   unsigned intpcie_pcs_reg; /* pcs reg. index in syscon */
boolsata_refclk_enabled;
 };
 
@@ -275,7 +280,16 @@ static int ti_pipe3_init(struct phy *x)
 * 18-1804.
 */
if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
-   omap_control_pcie_pcs(phy->control_dev, 0x96);
+   if (phy->pcs_syscon) {
+   val = 0x96 << OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT;
+   ret = regmap_update_bits(phy->pcs_syscon,
+phy->pcie_pcs_reg,
+PCIE_PCS_MASK, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_pcie_pcs(phy->control_dev, 0x96);
+   }
return 0;
}
 
@@ -461,6 +475,24 @@ static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
phy->control_dev = _pdev->dev;
}
 
+   if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   phy->pcs_syscon = syscon_regmap_lookup_by_phandle(node,
+ "syscon-pcs");
+   if (IS_ERR(phy->pcs_syscon)) {
+   dev_dbg(dev,
+   "can't get syscon-pcs, using omap control\n");
+   phy->pcs_syscon = NULL;
+   } else {
+   if (of_property_read_u32_index(node,
+  "syscon-pcs", 1,
+  >pcie_pcs_reg)) {
+   dev_err(dev,
+   "couldn't get pcie pcs reg. offset\n");
+   return -EINVAL;
+   }
+   }
+   }
+
if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
"syscon-pllreset");
-- 
1.7.9.5

--
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 v3 5/9] phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe

[Kishon Vijay Abraham I]

No functional change. Previously omap_control_phy_power() was used to power
off the PHY during probe. But once PIPE3 driver is adapted to use syscon,
omap_control_phy_power() cannot be used. Hence used ti_pipe3_power_off
to power off the PHY.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Roger Quadros 
---
 drivers/phy/phy-ti-pipe3.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 1991efd..0ce4194 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -475,8 +475,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   omap_control_phy_power(phy->control_dev, 0);
-
platform_set_drvdata(pdev, phy);
pm_runtime_enable(dev);
 
@@ -495,6 +493,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return PTR_ERR(generic_phy);
 
phy_set_drvdata(generic_phy, phy);
+
+   ti_pipe3_power_off(generic_phy);
+
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
-- 
1.7.9.5

--
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 v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Kishon Vijay Abraham I]

This series is basically to deprecate using phy-omap-control and use
syscon APIs to program the control module registers.

Changes from v2:
No changes.

Changes from v1:
*) cleanup ti_pipe3_probe in multiple steps
*) other minor cleanups

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

The patches have been pushed to
git://git.ti.com/linux-phy/linux-phy.git syscon

[1] -> https://lkml.org/lkml/2015/6/23/189

All the testing was done both before applying the dt patches and after
applying the dt patches (dt patches will be posted shortly).

Logs with SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025205/
DRA7 EVM  : http://pastebin.ubuntu.com/14025212/
AM43XX EVM: http://pastebin.ubuntu.com/14025222/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025228/

Logs without SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025233/
DRA7 EVM  : http://pastebin.ubuntu.com/14025238/
AM43XX EVM: http://pastebin.ubuntu.com/14025329/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025248/

The config I used: http://pastebin.ubuntu.com/14025336/

Kishon Vijay Abraham I (9):
  phy: ti-pipe3: introduce local struct device* in probe
  phy: ti-pipe3: move clk initialization to a separate function
  phy: ti-pipe3: move sysctrl initialization to a separate function
  phy: ti-pipe3: move mem resource initialization to a separate
function
  phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during
probe
  phy: ti-pipe3: use *syscon* framework API to power on/off the PHY
  phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY
  phy: omap-usb2: use omap_usb_power_off to power off the PHY during
probe
  phy: omap-usb2: use *syscon* framework API to power on/off the PHY

 Documentation/devicetree/bindings/phy/ti-phy.txt |   20 +-
 drivers/phy/phy-omap-usb2.c  |   96 +--
 drivers/phy/phy-ti-pipe3.c   |  304 --
 include/linux/phy/omap_usb.h |   23 ++
 4 files changed, 340 insertions(+), 103 deletions(-)

-- 
1.7.9.5

--
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: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[Arnd Bergmann]

On Tuesday 15 December 2015 15:54:32 Yoshihiro Shimoda wrote:
> R-Car H3 has USB3.0 peripheral controllers. This controller's has the
> following features:
>  - Supports super, high and full speed
>  - Contains 30 pipes for bulk or interrupt transfer
>  - Contains dedicated DMA controller
> 
> This driver doesn't support the dedicated DMAC for now.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  This patch is based on the latest Felipe's usb.git / testing/next branch.
>  (commit id = e9284de9fae69f1d5e57a4817bfc36dc5f3adf71)

Looks good overall, I've found a few small details:

>  .../devicetree/bindings/usb/renesas_usb3.txt   |   23 +
>  drivers/usb/gadget/udc/Kconfig |   11 +
>  drivers/usb/gadget/udc/Makefile|1 +
>  drivers/usb/gadget/udc/renesas_usb3.c  | 1720 
> 
>  drivers/usb/gadget/udc/renesas_usb3.h  |  284 

The header file is only used by one .c file, so just merge it all into that
file.

> +Required properties:
> +  - compatible: Must contain one of the following:
> + - "renesas,usb3-peri-r8a7795"
> +  - reg: Base address and length of the register for the USB3.0 Peripheral
> +  - interrupts: Interrupt specifier for the USB3.0 Peripheral
> +  - clocks: A list of phandle + clock specifier pairs

The clock specifier contains the phandle, please rephrase the last line

> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> new file mode 100644
> index 000..f302c89
> --- /dev/null
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -0,0 +1,1720 @@
> +/*
> + * Renesas USB3.0 Peripheral driver (USB gadget)
> + *
> + * Copyright (C) 2015  Renesas Electronics Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

As the 0-say bot found, this needs #include 

> +static int renesas_usb3_ep_queue(struct usb_ep *_ep, struct usb_request 
> *_req,
> +  gfp_t gfp_flags);
> +static void usb3_start_pipen(struct renesas_usb3_ep *usb3_ep,
> +  struct renesas_usb3_request *usb3_req);

Can you try to reorder the functions so you don't need forward declarations?

> +static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
> +{
> + iowrite32(data, usb3->reg + offs);
> +}
> +
> +static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
> +{
> + return ioread32(usb3->reg + offs);
> +}

I think using readl() is more common than ioread32() if the driver cannot
use IORESOURCE_IO but only IORESOURCE_MEM.

On ARM, the two are the same, but on some architectures ioread32 is more
expensive, so using the former is preferred.

> + for (i = 0; i < USB3_WAIT_NS; i++) {
> + if ((usb3_read(usb3, reg) & mask) == expected)
> + return 0;
> + ndelay(1);
> + }

ndelay(1) is unusual, maybe use cpu_relax() instead, or document why
you call ndelay()?

> +static void usb3_init_phy(struct renesas_usb3 *usb3)
> +{
> +}

If the function is empty, don't add or call it, it's easy to add if you
need it later.

> +static struct platform_driver renesas_usb3_driver = {
> + .remove =   __exit_p(renesas_usb3_remove),
> + .driver = {
> + .name = (char *)udc_name,
> + .of_match_table = of_match_ptr(usb3_of_match),
> + },
> +};
> +module_platform_driver_probe(renesas_usb3_driver, renesas_usb3_probe);

module_platform_driver_probe() won't work if you get into deferred probing,
I'd suggest using module_platform_driver() and not marking the remove
function as __exit

> +struct renesas_usb3;
> +struct renesas_usb3_request {
> + struct usb_request  req;
> + struct list_headqueue;
> +};

There is already a list_head in struct usb_request. Could you use that?
(I don't know, just asking because this looks odd)

> +#define USB3_EP_NAME_SIZE8
> +struct renesas_usb3_ep {
> + struct usb_ep ep;
> + struct renesas_usb3 *usb3;
> + int num;
> + char ep_name[USB3_EP_NAME_SIZE];
> + struct list_head queue;
> + u32 rammap_val;
> + bool dir_in;
> + bool halt;
> + bool wedge;
> + bool started;
> +};
> +
> +struct renesas_usb3_priv {
> + int ramsize_per_ramif;  /* unit = bytes */
> + int num_ramif;
> + int ramsize_per_pipe;   /* unit = bytes */
> + unsigned workaround_for_vbus:1; /* if 1, don't check vbus signal */
> +};

You use 'bool' in one structure, and bit fields in the other.
Maybe pick one of the two styles consistently.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Kishon Vijay Abraham I]

Hi Arnd,

On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
>> This series is basically to deprecate using phy-omap-control and use
>> syscon APIs to program the control module registers.
>>
>> Changes from v2:
>> No changes.
>>
>> Changes from v1:
>> *) cleanup ti_pipe3_probe in multiple steps
>> *) other minor cleanups
>>
>> Changes from [1] in PHY patches include
>> *) cleanup ti_pipe3_probe
>> *) have mask, power_on and power_off values in usb_phy_data for
>>omap-usb2 phy
>>
>> The patches have been pushed to
>> git://git.ti.com/linux-phy/linux-phy.git syscon
>>
>> [1] -> https://lkml.org/lkml/2015/6/23/189
>>
>> All the testing was done both before applying the dt patches and after
>> applying the dt patches (dt patches will be posted shortly).
>>
> 
> Can you explain here what the conversion is good for? Why do you
> prefer the syscon mapping over a high-level driver in this case?

phy-omap-control driver was added when there was no proper
infrastructure for doing control module initializations. The
phy-omap-control driver is not an 'actual' PHY driver and it
was just a hack to do PHY related control module initializations.
phy-omap-control is also getting unmanageable with the number of
platforms each having number of modules (like USB, SATA, PCIe),
using the same driver for control module initializations.

Now with SYSCON framework being added to the kernel, phy-omap-control
shouldn't be needed and it also provides a uniform API across all the
modules to program the control module.

Thanks
Kishon
--
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 v2] extcon: add Maxim MAX3355 driver

[Geert Uytterhoeven]

Hi Sergei,

On Tue, Dec 15, 2015 at 12:54 PM, Sergei Shtylyov
 wrote:
> On 12/15/2015 2:28 PM, Geert Uytterhoeven wrote:
 You are mixing 2 and 1 spaces between words, don't do that.
>>>
>>> Care to just explain why?
>>
>> It makes the text difficult to read.
>
>Are you serious? :-)

Yes. No accidentally forgotten smileys on my side.

Spasiba! Da svidanja...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] usb: chipidea: otg: use usb autosuspend to suspend bus for HNP

[Li Jun]

Directly manipulate the controller regsiter to suspend the usb bus
for HNP is not the proper way, this should be done through the usbcore
by usb autosuspend. So to start HNP, autosuspend support should be
added for OTG devices interface driver if it's not enabled.

Signed-off-by: Li Jun 
---
 drivers/usb/chipidea/otg_fsm.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 00ab59d..ba90dc6 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -485,20 +485,30 @@ static void ci_otg_loc_conn(struct otg_fsm *fsm, int on)
 
 /*
  * Generate SOF by host.
- * This is controlled through suspend/resume the port.
  * In host mode, controller will automatically send SOF.
  * Suspend will block the data on the port.
+ *
+ * This is controlled through usbcore by usb autosuspend,
+ * so the usb device class driver need support autosuspend,
+ * otherwise the bus suspend will not happen.
  */
 static void ci_otg_loc_sof(struct otg_fsm *fsm, int on)
 {
-   struct ci_hdrc  *ci = container_of(fsm, struct ci_hdrc, fsm);
+   struct usb_device *udev;
 
-   if (on)
-   hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_FPR,
-   PORTSC_FPR);
-   else
-   hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_SUSP,
-   PORTSC_SUSP);
+   if (!fsm->otg->host)
+   return;
+
+   udev = usb_hub_find_child(fsm->otg->host->root_hub, 1);
+   if (!udev)
+   return;
+
+   if (on) {
+   usb_disable_autosuspend(udev);
+   } else {
+   pm_runtime_set_autosuspend_delay(>dev, 0);
+   usb_enable_autosuspend(udev);
+   }
 }
 
 /*
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] usb: chipidea: host: set host to be null after hcd is freed

[Li Jun]

Set ci->hcd and ci->otg.host to be null in host_stop since the
hcd already freed.

Signed-off-by: Li Jun 
---
 drivers/usb/chipidea/host.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 3d24304..053bac9 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -190,6 +190,8 @@ static void host_stop(struct ci_hdrc *ci)
(ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON))
regulator_disable(ci->platdata->reg_vbus);
}
+   ci->hcd = NULL;
+   ci->otg.host = NULL;
 }
 
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Fabio Estevam]

On Tue, Dec 15, 2015 at 4:28 AM, Peter Chen  wrote:

> Thanks, Fabio.
>
> I am afraid I forget to set gpio as output, would you please apply
> below patch against my original ones:

Same error happens with these changes applied.

Here are more details: if I run a pure 4.3.2 then I do see the USB
stick to get detected if I boot it with the USB stick connected to
Udoo board:

[2.170178] usb 1-1.1: new high-speed USB device number 3 using ci_hdrc
[2.305840] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[2.314803] scsi host1: usb-storage 1-1.1:1.0
[2.400283] usb 1-1.3: new high-speed USB device number 4 using ci_hdrc
[3.327925] scsi 1:0:0:0: Direct-Access General  USB Flash Disk   1.0  P2
[3.347070] sd 1:0:0:0: [sda] 7831552 512-byte logical blocks: (4.01 GB/3.73)
[3.356181] sd 1:0:0:0: [sda] Write Protect is off
[3.362550] sd 1:0:0:0: [sda] No Caching mode page found
[3.367899] sd 1:0:0:0: [sda] Assuming drive cache: write through
[3.387401]  sda: sda1
[3.400238] sd 1:0:0:0: [sda] Attached SCSI removable disk
[4.931847] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow contx
[4.941414] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[4.961400] Sending DHCP requests ., OK
[5.380247] IP-Config: Got DHCP answer from 10.29.244.251, my address is 10.1
[5.390461] IP-Config: Complete:
[5.393731]  device=eth0, hwaddr=00:c0:08:88:0c:b5, ipaddr=10.29.244.61,4
[5.404074]  host=10.29.244.61, domain=am.freescale.net, nis-domain=(non)
[5.411362]  bootserver=0.0.0.0, rootserver=10.29.244.24, rootpath= 0
[5.423964] ALSA device list:
[5.426969]   No soundcards found.
[5.469374] VFS: Mounted root (nfs filesystem) readonly on device 0:14.
[5.478119] devtmpfs: mounted
[5.482376] Freeing unused kernel memory: 456K (c0a7e000 - c0af)
starting pid 160, tty '': '/etc/rc.d/rcS'
Mounting /proc and /sys
Starting the hotplug events dispatcher udevd
Synthesizing initial hotplug even[6.085842] udevd (173): /proc/173/oom_adj .

,but the system hangs here.

If I boot it with the USB stick disconnected, then the system boots
until the prompt, but the insertion of the USB stick is never detected
afterwards.

With your patch applied, the error message (usb 1-1: device descriptor
read/64, error -7) is shown with USB stick connected or disconnected
during boot.
--
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: storage: add "no SYNCHRONIZE CACHE" quirk

[Oliver Neukum]

On Thu, 2015-12-03 at 13:36 -0500, Alan Stern wrote:
> This is an old problem, but it was never resolved and it still affects
> people (Bugzilla #89511).  In short, there are USB-(S)ATA bridges that
> claim to be write-back but don't support the SYNCHRONIZE CACHE
> command.  
> This causes errors when filesystems try to flush data out to the disk.

OK, maybe this is a stupid idea, but could we test the command as we
enumerate the slave and store the result?

Regards
Oliver


--
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 v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Arnd Bergmann]

On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
> This series is basically to deprecate using phy-omap-control and use
> syscon APIs to program the control module registers.
> 
> Changes from v2:
> No changes.
> 
> Changes from v1:
> *) cleanup ti_pipe3_probe in multiple steps
> *) other minor cleanups
> 
> Changes from [1] in PHY patches include
> *) cleanup ti_pipe3_probe
> *) have mask, power_on and power_off values in usb_phy_data for
>omap-usb2 phy
> 
> The patches have been pushed to
> git://git.ti.com/linux-phy/linux-phy.git syscon
> 
> [1] -> https://lkml.org/lkml/2015/6/23/189
> 
> All the testing was done both before applying the dt patches and after
> applying the dt patches (dt patches will be posted shortly).
> 

Can you explain here what the conversion is good for? Why do you
prefer the syscon mapping over a high-level driver in this case?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled

[Oliver Neukum]

On Tue, 2015-12-08 at 15:33 +0100, Peter Wu wrote:
> Can you have a look? I guess that reset_resume needs different
> treatment, but don't know how to do it properly as suspend is not
> called
> before system reset (because the device is apparently already in
> suspended state).
> 
> I think that this new issue can be addressed in a different patch,
> this
> patch solves a more severe lockup. Opinions?

We do not know in advance whether resume() or reset_resume()
will be called after S3. A driver must be ready for both.


Regards
Oliver




--
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 v3 2/3] usb: renesas_usbhs: add fallback compatibility strings

[Geert Uytterhoeven]

On Tue, Dec 15, 2015 at 7:41 AM, Simon Horman  wrote:
>> >diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
>> >b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
>> >index a14c0bb561d5..c55cf77006d0 100644
>> >--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
>> >+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
>> >@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver
>> >
>> >  Required properties:
>> >- compatible: Must contain one of the following:
>>
>>Really?
>
> Would "...one or more of the following" help?

+1

>> >+
>> > - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
>> > - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
>> > - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
>> > - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
>> >+- "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
>> >+- "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
>> >+
>> >+When compatible with the generic version, nodes must list the
>> >+SoC-specific version corresponding to the platform first followed
>> >+by the generic version.
>> >+
>>
>>This kinda contradicts the above claim.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/15/2015 2:44 AM, Greg KH wrote:


Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators
to
enable a system with an integrated USB OTG dual-role transceiver to
function
as  an 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
aren't currently interested in them),  the OFFVBUS# signal is controlled
by
the host controllers, there's  also the SHDN# signal wired to a GPIO, it
should be driven high for the  normal operation.



As multiple people have said, fix the spacing here.



You are the first to complain abou _this_ patch. If you don't have other
issues with this driver in which case you should have trimmed the reply at
this point), I'd like to keep my spacing as is. Thank you.


Your previous version was not "extcon-usb-gpio: add enable pin
support"[1] which has now been re-written to be max3355 specific?


No, the MAX3355 driver pre-dates that version. First there was a driver,
then I tried to re-use the existing stuff (there was no extcon-usb-gpio at
the time of writing my driver), then had to return to the separate driver
idea...


"So
what" and "I'd like to keep my spacing as is" aren't valid reasons.
Fix it, then I'll look at the rest again.


I'll consider doing that if you care to explain what's the problem with
my spacing. TIA.


You are mixing 2 and 1 spaces between words, don't do that.


   Care to just explain why?

MBR, Sergei

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

[Geert Uytterhoeven]

Hi Sergei,

On Tue, Dec 15, 2015 at 12:24 PM, Sergei Shtylyov
 wrote:
 "So
 what" and "I'd like to keep my spacing as is" aren't valid reasons.
 Fix it, then I'll look at the rest again.
>>>
>>>
>>> I'll consider doing that if you care to explain what's the problem
>>> with
>>> my spacing. TIA.
>>
>>
>> You are mixing 2 and 1 spaces between words, don't do that.
>
>Care to just explain why?

It makes the text difficult to read.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] usb: renesas_usbhs: add fallback compatibility strings

[Sergei Shtylyov]

Hello.

On 12/15/2015 9:41 AM, Simon Horman wrote:


Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 
---
v3
* Moved documentation of SoC names to a separate patch
* Use correct fallback compatibility string in example

v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
   a single compatibility string for all of R-Car.
---
  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +-
  drivers/usb/renesas_usbhs/common.c  |  9 +
  2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index a14c0bb561d5..c55cf77006d0 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver

  Required properties:
- compatible: Must contain one of the following:


Really?


Would "...one or more of the following" help?


   It would, of course.


+
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
+   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first followed
+   by the generic version.
+


This kinda contradicts the above claim.

[...]


MBR, Sergei

--
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 v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Arnd Bergmann]

On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote:
> Hi Arnd,
> 
> On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
> > On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
> >> This series is basically to deprecate using phy-omap-control and use
> >> syscon APIs to program the control module registers.
> >>
> >> Changes from v2:
> >> No changes.
> >>
> >> Changes from v1:
> >> *) cleanup ti_pipe3_probe in multiple steps
> >> *) other minor cleanups
> >>
> >> Changes from [1] in PHY patches include
> >> *) cleanup ti_pipe3_probe
> >> *) have mask, power_on and power_off values in usb_phy_data for
> >>omap-usb2 phy
> >>
> >> The patches have been pushed to
> >> git://git.ti.com/linux-phy/linux-phy.git syscon
> >>
> >> [1] -> https://lkml.org/lkml/2015/6/23/189
> >>
> >> All the testing was done both before applying the dt patches and after
> >> applying the dt patches (dt patches will be posted shortly).
> >>
> > 
> > Can you explain here what the conversion is good for? Why do you
> > prefer the syscon mapping over a high-level driver in this case?
> 
> phy-omap-control driver was added when there was no proper
> infrastructure for doing control module initializations. The
> phy-omap-control driver is not an 'actual' PHY driver and it
> was just a hack to do PHY related control module initializations.
> phy-omap-control is also getting unmanageable with the number of
> platforms each having number of modules (like USB, SATA, PCIe),
> using the same driver for control module initializations.
> 
> Now with SYSCON framework being added to the kernel, phy-omap-control
> shouldn't be needed and it also provides a uniform API across all the
> modules to program the control module.

Ok, so the "phy-control" devices were really just a few registers of
a system controller device that does a lot of other things as well, right?

Can you put your description above into the cover-letter for the series,
and the merge commit?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/15/2015 2:28 PM, Geert Uytterhoeven wrote:


"So
what" and "I'd like to keep my spacing as is" aren't valid reasons.
Fix it, then I'll look at the rest again.



 I'll consider doing that if you care to explain what's the problem
with
my spacing. TIA.



You are mixing 2 and 1 spaces between words, don't do that.


Care to just explain why?


It makes the text difficult to read.


   Are you serious? :-)

[...]

MBR, Sergei

--
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] Revert "usb: chipidea: usbmisc_imx: delete clock information"

[Maciej S. Szmigiero]

Hi Peter,

On 16.09.2015 05:05, Peter Chen wrote:
>> On Mon, Sep 14, 2015 at 11:32 PM, Fabio Estevam 
>> wrote:
>>
>>> This did not help.
>>>
>>> It is getting late here, so I will be able to try more things tomorrow.
>>
>> I was able to fix it. Your initial patch had a missing 'return 0' in
>> imx_prepare_enable_clks(), causing:
>>
>> clk_disable_unprepare(data->clk_ahb);
>> clk_disable_unprepare(data->clk_ipg);
>>
>> to always be called.
>>
>> Doing like this on top of your original patch:
>>
>> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
>> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
>> @@ -212,6 +212,8 @@ static int imx_prepare_enable_clks(struct device *dev)
>> }
>> }
>>
>> +   return 0;
>> +
>>  err2:
>> clk_disable_unprepare(data->clk_ahb);
>>  err1:
>>
>> , fixes the crash.
>>
>> Would you like to split your patch into dts and usb parts and then resend it
>> formally?
>>
> 
> I have sent out the patches, one suggestion is you may need to add phandle
> for phy, you can use generic-phy, without clock information.
> 
> Peter

Can we now use this change for repairing the USB support on UDOO board?

This seems to work fine if not 100% correct:
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -122,7 +122,10 @@
pinctrl-names = "default";
pinctrl-0 = <_usbh>;
vbus-supply = <_usb_h1_vbus>;
-   clocks = < 201>;
+   clocks = < IMX6QDL_CLK_USBOH3>,
+< IMX6QDL_CLK_USBOH3>,
+< 201>;
+   clock-names = "ipg", "ahb", "per";
status = "okay";
 };
 
Best regards,
Maciej Szmigiero

--
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: [PROBLEM] usb hub malformed packets causes null pointer dereference

[Alan Stern]

On Tue, 15 Dec 2015, Alan Stern wrote:

> On Tue, 15 Dec 2015, Cornea, Alexandru wrote:
> 
> > Hello, 
> > Apologies for the late response. 
> > We tried the patch, and although the system does not crash anymore, another 
> > issue occurs.  
> > Depending on platform (Gigabyte GXBT, Galileo board), the USB port that is 
> > used for testing or all USB ports become blocked and cannot recognize new 
> > devices.  Also, soft shutdown / reboot seems to hang. 
> 
> 
> I can't figure out the problem from this trace.  Were there any other 
> tasks blocked like this one?
> 
> Please enable USB debugging (echo 'module usbcore =p' 
> > /sys/kernel/debug/dynamic_debug/control), run the test again, and post 
> the resulting dmesg log.

Never mind, I found the mistake.  An updated patch is below.

Alan Stern



Index: usb-4.3/drivers/usb/core/hub.c
===
--- usb-4.3.orig/drivers/usb/core/hub.c
+++ usb-4.3/drivers/usb/core/hub.c
@@ -1031,10 +1031,20 @@ static void hub_activate(struct usb_hub
unsigned delay;
 
/* Continue a partial initialization */
-   if (type == HUB_INIT2)
-   goto init2;
-   if (type == HUB_INIT3)
+   if (type == HUB_INIT2 || type == HUB_INIT3) {
+   device_lock(hub->intfdev);
+
+   /* Was the hub disconnected while we were waiting? */
+   if (hub->disconnected) {
+   device_unlock(hub->intfdev);
+   kref_put(>kref, hub_release);
+   return;
+   }
+   if (type == HUB_INIT2)
+   goto init2;
goto init3;
+   }
+   kref_get(>kref);
 
/* The superspeed hub except for root hub has to use Hub Depth
 * value as an offset into the route string to locate the bits
@@ -1232,6 +1242,7 @@ static void hub_activate(struct usb_hub
queue_delayed_work(system_power_efficient_wq,
>init_work,
msecs_to_jiffies(delay));
+   device_unlock(hub->intfdev);
return; /* Continues at init3: below */
} else {
msleep(delay);
@@ -1253,6 +1264,11 @@ static void hub_activate(struct usb_hub
/* Allow autosuspend if it was suppressed */
if (type <= HUB_INIT3)
usb_autopm_put_interface_async(to_usb_interface(hub->intfdev));
+
+   if (type == HUB_INIT2 || type == HUB_INIT3)
+   device_unlock(hub->intfdev);
+
+   kref_put(>kref, hub_release);
 }
 
 /* Implement the continuations for the delays above */

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

poweroff-issue with dwc2 on Felipe's testing/next branch

[Heiko Stübner]

Hi,

it seems the recent dwc2 additions to the testing/next branch [0] caused
some interesting issue for me.

Setting is a regular 4.4-rc3/4 (only with some display-stuff added), and the
testing/next branch merged in.

If I attach a single usb device everything still works fine, but once it
is connected through a hub, like the following:

root@localhost:~# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
|__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 
480M
|__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M

I get strange results when powering off the device with the usb device
still attached.

On regular 4.4-rc3
root@localhost:~# poweroff
...
reboot: Power down
~20sec delay before actual poweroff
[that delay is only present with a usb hub in between, probably due to the
big number of interrupts it creates]


With testing/next the device cannot poweroff anymore and instead I get
[   40.117160] reboot: Power down
[   68.031372] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[systemd-shutdow:1]
[   68.046575] Modules linked in:
[   68.053084] irq event stamp: 1654975
[   68.060091] hardirqs last  enabled at (1654974): [] 
__irq_svc+0x5c/0x78
[   68.074935] hardirqs last disabled at (1654975): [] 
__irq_svc+0x48/0x78
[   68.089666] softirqs last  enabled at (1654846): [] 
__do_softirq+0x358/0x49c
[   68.105261] softirqs last disabled at (1654847): [] 
irq_exit+0x94/0xd4
[   68.120027] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ #2761
[   68.133507] Hardware name: Rockchip (Device Tree)
[   68.142690] task: ee900d40 ti: ee902000 task.ti: ee902000
[   68.153237] PC is at rcu_lockdep_current_cpu_online+0x6c/0x90
[   68.164438] LR is at rcu_read_lock_held+0x38/0x58
[   68.173683] pc : []lr : []psr: 00010113
[   68.173683] sp : ee903be8  ip : ee903bf8  fp : ee903bf4
[   68.195300] r10: c0b884f8  r9 :   r8 : c0b884f8
[   68.205429] r7 : bccc  r6 : eed7f680  r5 : 0001  r4 : ee955800
[   68.217938] r3 : ee902028  r2 : 000f  r1 : c0b1891c  r0 : 0001
[   68.230482] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   68.244141] Control: 10c5387d  Table: 2dae806a  DAC: 0051
[   68.255283] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ #2761
[   68.268720] Hardware name: Rockchip (Device Tree)
[   68.278165] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   68.293198] [] (show_stack) from [] 
(dump_stack+0x84/0xb8)
[   68.307285] [] (dump_stack) from [] (show_regs+0x1c/0x20)
[   68.321205] [] (show_regs) from [] 
(watchdog_timer_fn+0x1c8/0x250)
[   68.336579] [] (watchdog_timer_fn) from [] 
(__hrtimer_run_queues+0x2cc/0x55c)
[   68.353819] [] (__hrtimer_run_queues) from [] 
(hrtimer_interrupt+0xac/0x1f8)
[   68.370795] [] (hrtimer_interrupt) from [] 
(arch_timer_handler_phys+0x38/0x48)
[   68.388044] [] (arch_timer_handler_phys) from [] 
(handle_percpu_devid_irq+0x15c/0x314)
[   68.406687] [] (handle_percpu_devid_irq) from [] 
(generic_handle_irq+0x28/0x38)
[   68.424177] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x9c/0xc4)
[   68.440945] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x58/0x80)
[   68.457054] [] (gic_handle_irq) from [] 
(__irq_svc+0x58/0x78)
[   68.471405] Exception stack(0xee903b98 to 0xee903be0)
[   68.481288] 3b80:   
0001 c0b1891c
[   68.497074] 3ba0: 000f ee902028 ee955800 0001 eed7f680 bccc 
c0b884f8 
[   68.512875] 3bc0: c0b884f8 ee903bf4 ee903bf8 ee903be8 c0094d00 c0095e98 
00010113 
[   68.528713] [] (__irq_svc) from [] 
(rcu_lockdep_current_cpu_online+0x6c/0x90)
[   68.545915] [] (rcu_lockdep_current_cpu_online) from [] 
(rcu_read_lock_held+0x38/0x58)
[   68.564535] [] (rcu_read_lock_held) from [] 
(run_rebalance_domains+0x114/0x3e4)
[   68.582013] [] (run_rebalance_domains) from [] 
(__do_softirq+0x1d8/0x49c)
[   68.598529] [] (__do_softirq) from [] 
(irq_exit+0x94/0xd4)
[   68.612591] [] (irq_exit) from [] 
(__handle_domain_irq+0xa0/0xc4)
[   68.808119] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x58/0x80)
[   69.004792] [] (gic_handle_irq) from [] 
(__irq_svc+0x58/0x78)
[   69.203767] Exception stack(0xee903d20 to 0xee903d68)
[   69.402232] 3d20: 0001 0010 c134e8f8 ee900d40  60010013 
ee26a834 
[   69.608139] 3d40:    ee903db4 0002 ee903d70 
ee9012a8 c007f4bc
[   69.811985] 3d60: 80010013 
[   70.007318] [] (__irq_svc) from [] 
(lock_acquire+0x190/0x218)
[   70.212947] [] (lock_acquire) from [] 
(mutex_lock_nested+0x78/0x41c)
[   70.419796] [] (mutex_lock_nested) from [] 
(regmap_lock_mutex+0x1c/0x20)
[   

Re: poweroff-issue with dwc2 on Felipe's testing/next branch

[John Youn]

On 12/15/2015 3:49 PM, Heiko Stübner wrote:
> Hi,
> 
> it seems the recent dwc2 additions to the testing/next branch [0] caused
> some interesting issue for me.
> 
> Setting is a regular 4.4-rc3/4 (only with some display-stuff added), and the
> testing/next branch merged in.
> 
> If I attach a single usb device everything still works fine, but once it
> is connected through a hub, like the following:
> 
> root@localhost:~# lsusb -t
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
> |__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
> Driver=smsc95xx, 480M
> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
> 
> I get strange results when powering off the device with the usb device
> still attached.
> 
> On regular 4.4-rc3
> root@localhost:~# poweroff
> ...
> reboot: Power down
> ~20sec delay before actual poweroff
> [that delay is only present with a usb hub in between, probably due to the
> big number of interrupts it creates]
> 
> 
> With testing/next the device cannot poweroff anymore and instead I get
> [   40.117160] reboot: Power down
> [   68.031372] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> [systemd-shutdow:1]
> [   68.046575] Modules linked in:
> [   68.053084] irq event stamp: 1654975
> [   68.060091] hardirqs last  enabled at (1654974): [] 
> __irq_svc+0x5c/0x78
> [   68.074935] hardirqs last disabled at (1654975): [] 
> __irq_svc+0x48/0x78
> [   68.089666] softirqs last  enabled at (1654846): [] 
> __do_softirq+0x358/0x49c
> [   68.105261] softirqs last disabled at (1654847): [] 
> irq_exit+0x94/0xd4
> [   68.120027] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ 
> #2761
> [   68.133507] Hardware name: Rockchip (Device Tree)
> [   68.142690] task: ee900d40 ti: ee902000 task.ti: ee902000
> [   68.153237] PC is at rcu_lockdep_current_cpu_online+0x6c/0x90
> [   68.164438] LR is at rcu_read_lock_held+0x38/0x58
> [   68.173683] pc : []lr : []psr: 00010113
> [   68.173683] sp : ee903be8  ip : ee903bf8  fp : ee903bf4
> [   68.195300] r10: c0b884f8  r9 :   r8 : c0b884f8
> [   68.205429] r7 : bccc  r6 : eed7f680  r5 : 0001  r4 : ee955800
> [   68.217938] r3 : ee902028  r2 : 000f  r1 : c0b1891c  r0 : 0001
> [   68.230482] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [   68.244141] Control: 10c5387d  Table: 2dae806a  DAC: 0051
> [   68.255283] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-rc4+ 
> #2761
> [   68.268720] Hardware name: Rockchip (Device Tree)
> [   68.278165] [] (unwind_backtrace) from [] 
> (show_stack+0x20/0x24)
> [   68.293198] [] (show_stack) from [] 
> (dump_stack+0x84/0xb8)
> [   68.307285] [] (dump_stack) from [] 
> (show_regs+0x1c/0x20)
> [   68.321205] [] (show_regs) from [] 
> (watchdog_timer_fn+0x1c8/0x250)
> [   68.336579] [] (watchdog_timer_fn) from [] 
> (__hrtimer_run_queues+0x2cc/0x55c)
> [   68.353819] [] (__hrtimer_run_queues) from [] 
> (hrtimer_interrupt+0xac/0x1f8)
> [   68.370795] [] (hrtimer_interrupt) from [] 
> (arch_timer_handler_phys+0x38/0x48)
> [   68.388044] [] (arch_timer_handler_phys) from [] 
> (handle_percpu_devid_irq+0x15c/0x314)
> [   68.406687] [] (handle_percpu_devid_irq) from [] 
> (generic_handle_irq+0x28/0x38)
> [   68.424177] [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x9c/0xc4)
> [   68.440945] [] (__handle_domain_irq) from [] 
> (gic_handle_irq+0x58/0x80)
> [   68.457054] [] (gic_handle_irq) from [] 
> (__irq_svc+0x58/0x78)
> [   68.471405] Exception stack(0xee903b98 to 0xee903be0)
> [   68.481288] 3b80:   
> 0001 c0b1891c
> [   68.497074] 3ba0: 000f ee902028 ee955800 0001 eed7f680 bccc 
> c0b884f8 
> [   68.512875] 3bc0: c0b884f8 ee903bf4 ee903bf8 ee903be8 c0094d00 c0095e98 
> 00010113 
> [   68.528713] [] (__irq_svc) from [] 
> (rcu_lockdep_current_cpu_online+0x6c/0x90)
> [   68.545915] [] (rcu_lockdep_current_cpu_online) from 
> [] (rcu_read_lock_held+0x38/0x58)
> [   68.564535] [] (rcu_read_lock_held) from [] 
> (run_rebalance_domains+0x114/0x3e4)
> [   68.582013] [] (run_rebalance_domains) from [] 
> (__do_softirq+0x1d8/0x49c)
> [   68.598529] [] (__do_softirq) from [] 
> (irq_exit+0x94/0xd4)
> [   68.612591] [] (irq_exit) from [] 
> (__handle_domain_irq+0xa0/0xc4)
> [   68.808119] [] (__handle_domain_irq) from [] 
> (gic_handle_irq+0x58/0x80)
> [   69.004792] [] (gic_handle_irq) from [] 
> (__irq_svc+0x58/0x78)
> [   69.203767] Exception stack(0xee903d20 to 0xee903d68)
> [   69.402232] 3d20: 0001 0010 c134e8f8 ee900d40  60010013 
> ee26a834 
> [   69.608139] 3d40:    ee903db4 0002 ee903d70 
> 

[PATCH v4 0/3] usb: renesas_usbhs: More compat strings

[Simon Horman]

Hi,

this short series adds generic, and soc-specific r8a7792 and r8a7793 compat
strings to the Renesas USBHS driver. The intention is to provide a complete
set of compat strings for known R-Car SoCs.

Changes since v3:
* State that one or more compat string should be used

Changes since v2:
* Split documentation of SoC names into separate patch
* Use correct fallback compatibility string in example

Changes since v1:
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
a single compatibility string for all of R-Car.

Simon Horman (3):
  usb: renesas_usbhs: add SoC names to compatibility string
documentation
  usb: renesas_usbhs: add fallback compatibility strings
  usb: renesas_usbhs: add device tree support for r8a779[23]

 .../devicetree/bindings/usb/renesas_usbhs.txt  | 22 --
 drivers/usb/renesas_usbhs/common.c |  9 +
 2 files changed, 25 insertions(+), 6 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/3] usb: renesas_usbhs: add fallback compatibility strings

[Simon Horman]

Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 
Acked-by: Kuninori Morimoto 
---
v4
* State that one or more compat string should be used

v3
* Moved documentation of SoC names to a separate patch
* Use correct fallback compatibility string in example

v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
  a single compatibility string for all of R-Car.
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 12 ++--
 drivers/usb/renesas_usbhs/common.c  |  9 +
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index a14c0bb561d5..45d9ae13ffa3 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -1,11 +1,19 @@
 Renesas Electronics USBHS driver
 
 Required properties:
-  - compatible: Must contain one of the following:
+  - compatible: Must contain one or more of the following:
+
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
+   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first followed
+   by the generic version.
+
   - reg: Base address and length of the register for the USBHS
   - interrupts: Interrupt specifier for the USBHS
   - clocks: A list of phandle + clock specifier pairs
@@ -22,7 +30,7 @@ Optional properties:
 
 Example:
usbhs: usb@e659 {
-   compatible = "renesas,usbhs-r8a7790";
+   compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7790_CLK_HSUSB>;
diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..db9a17bd8997 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+   {
+   .compatible = "renesas,rcar-gen2-usbhs",
+   .data = (void *)USBHS_TYPE_RCAR_GEN2,
+   },
+   {
+   /* Gen3 is compatible with Gen2 */
+   .compatible = "renesas,rcar-gen3-usbhs",
+   .data = (void *)USBHS_TYPE_RCAR_GEN2,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, usbhs_of_match);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/3] usb: renesas_usbhs: add device tree support for r8a779[23]

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

Signed-off-by: Simon Horman 
Acked-by: Rob Herring 
Acked-by: Kuninori Morimoto 
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 45d9ae13ffa3..b6040563e51a 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -5,6 +5,8 @@ Required properties:
 
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
+   - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
+   - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
- "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/3] usb: renesas_usbhs: add SoC names to compatibility string documentation

[Simon Horman]

This extends the documentation of compatibility strings a little to
include the SoC names.

Signed-off-by: Simon Horman 
Acked-by: Kuninori Morimoto 

---
v3
* Split into separate patch
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 7d48f63db44e..a14c0bb561d5 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,10 @@ Renesas Electronics USBHS driver
 
 Required properties:
   - compatible: Must contain one of the following:
-   - "renesas,usbhs-r8a7790"
-   - "renesas,usbhs-r8a7791"
-   - "renesas,usbhs-r8a7794"
-   - "renesas,usbhs-r8a7795"
+   - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
+   - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
+   - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
+   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
   - reg: Base address and length of the register for the USBHS
   - interrupts: Interrupt specifier for the USBHS
   - clocks: A list of phandle + clock specifier pairs
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[Yoshihiro Shimoda]

Hi Arnd,

Thank you very much for your review!

> From: Arnd Bergmann
> Sent: Tuesday, December 15, 2015 6:30 PM
> 
> On Tuesday 15 December 2015 15:54:32 Yoshihiro Shimoda wrote:
> > R-Car H3 has USB3.0 peripheral controllers. This controller's has the
> > following features:
> >  - Supports super, high and full speed
> >  - Contains 30 pipes for bulk or interrupt transfer
> >  - Contains dedicated DMA controller
> >
> > This driver doesn't support the dedicated DMAC for now.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  This patch is based on the latest Felipe's usb.git / testing/next branch.
> >  (commit id = e9284de9fae69f1d5e57a4817bfc36dc5f3adf71)
> 
> Looks good overall, I've found a few small details:
> 
> >  .../devicetree/bindings/usb/renesas_usb3.txt   |   23 +
> >  drivers/usb/gadget/udc/Kconfig |   11 +
> >  drivers/usb/gadget/udc/Makefile|1 +
> >  drivers/usb/gadget/udc/renesas_usb3.c  | 1720 
> > 
> >  drivers/usb/gadget/udc/renesas_usb3.h  |  284 
> 
> The header file is only used by one .c file, so just merge it all into that
> file.

I got it. I will merge the header file to the c file.

> > +Required properties:
> > +  - compatible: Must contain one of the following:
> > +   - "renesas,usb3-peri-r8a7795"
> > +  - reg: Base address and length of the register for the USB3.0 Peripheral
> > +  - interrupts: Interrupt specifier for the USB3.0 Peripheral
> > +  - clocks: A list of phandle + clock specifier pairs
> 
> The clock specifier contains the phandle, please rephrase the last line

I will revise it as the following:
 - clocks: clock phandle and specifier pair

> > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > b/drivers/usb/gadget/udc/renesas_usb3.c
> > new file mode 100644
> > index 000..f302c89
> > --- /dev/null
> > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
< snip >
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> As the 0-say bot found, this needs #include 

Thank you for the detail. I will add it here.

> > +static int renesas_usb3_ep_queue(struct usb_ep *_ep, struct usb_request 
> > *_req,
> > +gfp_t gfp_flags);
> > +static void usb3_start_pipen(struct renesas_usb3_ep *usb3_ep,
> > +struct renesas_usb3_request *usb3_req);
> 
> Can you try to reorder the functions so you don't need forward declarations?

Thank you for the point. I could reorder the functions.

> > +static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
> > +{
> > +   iowrite32(data, usb3->reg + offs);
> > +}
> > +
> > +static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
> > +{
> > +   return ioread32(usb3->reg + offs);
> > +}
> 
> I think using readl() is more common than ioread32() if the driver cannot
> use IORESOURCE_IO but only IORESOURCE_MEM.
> 
> On ARM, the two are the same, but on some architectures ioread32 is more
> expensive, so using the former is preferred.

I will use {read,write}l() instead of io{read,write}32().
Also I will change io{read,write}32_rep() functions too.

> > +   for (i = 0; i < USB3_WAIT_NS; i++) {
> > +   if ((usb3_read(usb3, reg) & mask) == expected)
> > +   return 0;
> > +   ndelay(1);
> > +   }
> 
> ndelay(1) is unusual, maybe use cpu_relax() instead, or document why
> you call ndelay()?

Thank you for the point. udelay(1) is enough in this function.
So, I will fix it.

> > +static void usb3_init_phy(struct renesas_usb3 *usb3)
> > +{
> > +}
> 
> If the function is empty, don't add or call it, it's easy to add if you
> need it later.

Thank you for the point. I will remove it.

> > +static struct platform_driver renesas_usb3_driver = {
> > +   .remove =   __exit_p(renesas_usb3_remove),
> > +   .driver = {
> > +   .name = (char *)udc_name,
> > +   .of_match_table = of_match_ptr(usb3_of_match),
> > +   },
> > +};
> > +module_platform_driver_probe(renesas_usb3_driver, renesas_usb3_probe);
> 
> module_platform_driver_probe() won't work if you get into deferred probing,
> I'd suggest using module_platform_driver() and not marking the remove
> function as __exit

Thank you for your suggestion. I will use module_platform_driver().

> > +struct renesas_usb3;
> > +struct renesas_usb3_request {
> > +   struct usb_request  req;
> > +   struct list_headqueue;
> > +};
> 
> There is already a list_head in struct usb_request. Could you use that?
> (I don't know, just asking because this looks odd)

The list_head in strcut usb_request is used by a gadget driver 
(drivers/usb/gadget/function/*.c).
So, a udc driver (e.g. drivers/usb/gadget/udc/*.c) cannot use it.

> > +#define USB3_EP_NAME_SIZE  8
> > +struct renesas_usb3_ep {
> > +   struct usb_ep ep;
> > +   struct renesas_usb3 *usb3;

RE: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[Yoshihiro Shimoda]

Hi Arnd again,

> From: Yoshihiro Shimoda
> Sent: Wednesday, December 16, 2015 10:43 AM
< snip >
> > > +static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
> > > +{
> > > + iowrite32(data, usb3->reg + offs);
> > > +}
> > > +
> > > +static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
> > > +{
> > > + return ioread32(usb3->reg + offs);
> > > +}
> >
> > I think using readl() is more common than ioread32() if the driver cannot
> > use IORESOURCE_IO but only IORESOURCE_MEM.
> >
> > On ARM, the two are the same, but on some architectures ioread32 is more
> > expensive, so using the former is preferred.
> 
> I will use {read,write}l() instead of io{read,write}32().
> Also I will change io{read,write}32_rep() functions too.

Oops. If I used {read,write}sl() instead of io{read,write}32_rep(),
build error happened in x86 environment.

  CC [M]  drivers/usb/gadget/udc/renesas_usb3.o
./drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_write_pipe':
./drivers/usb/gadget/udc/renesas_usb3.c:879:3: error: implicit declaration of 
function 'writesl' [-Werror=implicit-function-declaration]
   writesl(usb3->reg + fifo_reg, buf, len / 4);
   ^
./drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_read_pipe':
./drivers/usb/gadget/udc/renesas_usb3.c:923:3: error: implicit declaration of 
function 'readsl' [-Werror=implicit-function-declaration]
   readsl(usb3->reg + fifo_reg, buf, len / 4);

So, I will keep to use io{read,write}32(_rep) functions.

Best regards,
Yoshihiro Shimoda

--
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 v2] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[Yoshihiro Shimoda]

R-Car H3 has USB3.0 peripheral controllers. This controller's has the
following features:
 - Supports super, high and full speed
 - Contains 30 pipes for bulk or interrupt transfer
 - Contains dedicated DMA controller

This driver doesn't support the dedicated DMAC for now.

Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the latest Felipe's usb.git / testing/next branch.
 (commit id = e9284de9fae69f1d5e57a4817bfc36dc5f3adf71)

 Changes from v1:
  - fix build error in i386 environment if COMPILE_TEST=y
  - merge the header file code into the .c file
  - revise the device tree document about "clocks"
  - remove prototype declarations
  - use udelay(1) instead of ndelay(1) in usb3_wait()
  - remove empty function "usb3_init_phy()"
  - use module_platform_driver()
  - remove bit fields member in some structures

 .../devicetree/bindings/usb/renesas_usb3.txt   |   23 +
 drivers/usb/gadget/udc/Kconfig |   11 +
 drivers/usb/gadget/udc/Makefile|1 +
 drivers/usb/gadget/udc/renesas_usb3.c  | 1975 
 4 files changed, 2010 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/renesas_usb3.txt
 create mode 100644 drivers/usb/gadget/udc/renesas_usb3.c

diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
new file mode 100644
index 000..71bee11
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -0,0 +1,23 @@
+Renesas Electronics USB3.0 Peripheral driver
+
+Required properties:
+  - compatible: Must contain one of the following:
+   - "renesas,usb3-peri-r8a7795"
+  - reg: Base address and length of the register for the USB3.0 Peripheral
+  - interrupts: Interrupt specifier for the USB3.0 Peripheral
+  - clocks: clock phandle and specifier pair
+
+Example:
+   usb3_peri0: usb@ee02 {
+   compatible = "renesas,usb3-peri-r8a7795";
+   reg = <0 0xee02 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   };
+
+   usb3_peri1: usb@ee06 {
+   compatible = "renesas,usb3-peri-r8a7795";
+   reg = <0 0xee06 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 327>;
+   };
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index cdbff54..753c29b 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -174,6 +174,17 @@ config USB_RENESAS_USBHS_UDC
   dynamically linked module called "renesas_usbhs" and force all
   gadget drivers to also be dynamically linked.
 
+config USB_RENESAS_USB3
+   tristate 'Renesas USB3.0 Peripheral controller'
+   depends on ARCH_SHMOBILE || COMPILE_TEST
+   help
+  Renesas USB3.0 Peripheral controller is a USB peripheral controller
+  that supports super, high, and full speed USB 3.0 data transfers.
+
+  Say "y" to link the driver statically, or "m" to build a
+  dynamically linked module called "renesas_usb3" and force all
+  gadget drivers to also be dynamically linked.
+
 config USB_PXA27X
tristate "PXA 27x"
help
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index fba2049..dfee534 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -19,6 +19,7 @@ fsl_usb2_udc-y:= fsl_udc_core.o
 fsl_usb2_udc-$(CONFIG_ARCH_MXC)+= fsl_mxc_udc.o
 obj-$(CONFIG_USB_M66592)   += m66592-udc.o
 obj-$(CONFIG_USB_R8A66597) += r8a66597-udc.o
+obj-$(CONFIG_USB_RENESAS_USB3) += renesas_usb3.o
 obj-$(CONFIG_USB_FSL_QE)   += fsl_qe_udc.o
 obj-$(CONFIG_USB_S3C_HSUDC)+= s3c-hsudc.o
 obj-$(CONFIG_USB_LPC32XX)  += lpc32xx_udc.o
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
new file mode 100644
index 000..38f02bc
--- /dev/null
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -0,0 +1,1975 @@
+/*
+ * Renesas USB3.0 Peripheral driver (USB gadget)
+ *
+ * Copyright (C) 2015  Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register definitions */
+#define USB3_AXI_INT_STA   0x008
+#define USB3_AXI_INT_ENA   0x00c
+#define USB3_DMA_INT_STA   0x010
+#define USB3_DMA_INT_ENA   0x014
+#define USB3_USB_COM_CON   0x200
+#define USB3_USB20_CON 0x204
+#define USB3_USB30_CON 0x208
+#define USB3_USB_STA   0x210
+#define USB3_DRD_CON   0x218
+#define USB3_USB_INT_STA_1 0x220
+#define 

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Peter Chen]

On Tue, Dec 15, 2015 at 09:32:18AM -0200, Fabio Estevam wrote:
> On Tue, Dec 15, 2015 at 4:28 AM, Peter Chen  wrote:
> 
> > Thanks, Fabio.
> >
> > I am afraid I forget to set gpio as output, would you please apply
> > below patch against my original ones:
> 
> Same error happens with these changes applied.
> 
> Here are more details: if I run a pure 4.3.2 then I do see the USB
> stick to get detected if I boot it with the USB stick connected to
> Udoo board:
> 
> [2.170178] usb 1-1.1: new high-speed USB device number 3 using ci_hdrc
> [2.305840] usb-storage 1-1.1:1.0: USB Mass Storage device detected
> [2.314803] scsi host1: usb-storage 1-1.1:1.0
> [2.400283] usb 1-1.3: new high-speed USB device number 4 using ci_hdrc
> [3.327925] scsi 1:0:0:0: Direct-Access General  USB Flash Disk   1.0  
> P2
> [3.347070] sd 1:0:0:0: [sda] 7831552 512-byte logical blocks: (4.01 
> GB/3.73)
> [3.356181] sd 1:0:0:0: [sda] Write Protect is off
> [3.362550] sd 1:0:0:0: [sda] No Caching mode page found
> [3.367899] sd 1:0:0:0: [sda] Assuming drive cache: write through
> [3.387401]  sda: sda1
> [3.400238] sd 1:0:0:0: [sda] Attached SCSI removable disk
> [4.931847] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow 
> contx
> [4.941414] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [4.961400] Sending DHCP requests ., OK
> [5.380247] IP-Config: Got DHCP answer from 10.29.244.251, my address is 
> 10.1
> [5.390461] IP-Config: Complete:
> [5.393731]  device=eth0, hwaddr=00:c0:08:88:0c:b5, 
> ipaddr=10.29.244.61,4
> [5.404074]  host=10.29.244.61, domain=am.freescale.net, 
> nis-domain=(non)
> [5.411362]  bootserver=0.0.0.0, rootserver=10.29.244.24, rootpath=
>  0
> [5.423964] ALSA device list:
> [5.426969]   No soundcards found.
> [5.469374] VFS: Mounted root (nfs filesystem) readonly on device 0:14.
> [5.478119] devtmpfs: mounted
> [5.482376] Freeing unused kernel memory: 456K (c0a7e000 - c0af)
> starting pid 160, tty '': '/etc/rc.d/rcS'
> Mounting /proc and /sys
> Starting the hotplug events dispatcher udevd
> Synthesizing initial hotplug even[6.085842] udevd (173): 
> /proc/173/oom_adj .
> 
> ,but the system hangs here.
> 
> If I boot it with the USB stick disconnected, then the system boots
> until the prompt, but the insertion of the USB stick is never detected
> afterwards.
> 

Thanks, Fabio, but I am curious how things like that? The USBOH3 clock
is not opened, the usb driver will hang when it tries to access
registers. If this clock is always on, then, why the system will
hang later?

> With your patch applied, the error message (usb 1-1: device descriptor
> read/64, error -7) is shown with USB stick connected or disconnected
> during boot.

Would you help to check again the clock is IMX6QDL_CLK_CKO and the reset
pin is GPIO7 bit 12? If they are, check below two things please:
- The clock is opened (You can check if through clock tree)
- The gpio is high (phy_addr is 0x20b4000, the bit is 12)

If they are correct, try to toggle gpio manually to see if it can work.

-- 

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 v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Kishon Vijay Abraham I]

Hi,

On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote:
>> Hi Arnd,
>>
>> On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
>>> On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
 This series is basically to deprecate using phy-omap-control and use
 syscon APIs to program the control module registers.

 Changes from v2:
 No changes.

 Changes from v1:
 *) cleanup ti_pipe3_probe in multiple steps
 *) other minor cleanups

 Changes from [1] in PHY patches include
 *) cleanup ti_pipe3_probe
 *) have mask, power_on and power_off values in usb_phy_data for
omap-usb2 phy

 The patches have been pushed to
 git://git.ti.com/linux-phy/linux-phy.git syscon

 [1] -> https://lkml.org/lkml/2015/6/23/189

 All the testing was done both before applying the dt patches and after
 applying the dt patches (dt patches will be posted shortly).

>>>
>>> Can you explain here what the conversion is good for? Why do you
>>> prefer the syscon mapping over a high-level driver in this case?
>>
>> phy-omap-control driver was added when there was no proper
>> infrastructure for doing control module initializations. The
>> phy-omap-control driver is not an 'actual' PHY driver and it
>> was just a hack to do PHY related control module initializations.
>> phy-omap-control is also getting unmanageable with the number of
>> platforms each having number of modules (like USB, SATA, PCIe),
>> using the same driver for control module initializations.
>>
>> Now with SYSCON framework being added to the kernel, phy-omap-control
>> shouldn't be needed and it also provides a uniform API across all the
>> modules to program the control module.
> 
> Ok, so the "phy-control" devices were really just a few registers of
> a system controller device that does a lot of other things as well, right?

right.
> 
> Can you put your description above into the cover-letter for the series,
> and the merge commit?

Sure.

Thanks
Kishon
--
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 v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Sergei Shtylyov]

Hello.

On 12/15/2015 12:39 PM, Kishon Vijay Abraham I wrote:


Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I 
---
  arch/arm/boot/dts/dra7.dtsi |5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: tisyscon@1c24 {


   Please use the generic node names as the ePAPR standard says.

[...]

MBR, Sergei

--
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: [PROBLEM] usb hub malformed packets causes null pointer dereference

[Cornea, Alexandru]

Hello, 
   Apologies for the late response. 
   We tried the patch, and although the system does not crash anymore, another 
issue occurs. 

   Depending on platform (Gigabyte GXBT, Galileo board), the USB port that is 
used for testing or all USB ports become blocked and cannot recognize new 
devices. 
   Also, soft shutdown / reboot seems to hang.

   The below trace gives more information:

[  240.304129] INFO: task kworker/3:2:93 blocked for more than 120 seconds.
[  240.304173]   Tainted: GE   4.3.0with-patch #8
[  240.304190] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  240.304212] kworker/3:2 D 88011e2d6980 093  2 0x
[  240.304241] Workqueue: usb_hub_wq hub_event
[  240.304257]  8800c73bbb78 0046 88011931aa00 
8800c7107000
[  240.304286]  8800c73bc000 8800c9bb6494 8800c7107000 

[  240.304315]  8800c9bb6498 8800c73bbb90 817ab963 
8800c9bb6490
[  240.304344] Call Trace:
[  240.304357]  [] schedule+0x33/0x80
[  240.304373]  [] schedule_preempt_disabled+0xe/0x10
[  240.304393]  [] __mutex_lock_slowpath+0x95/0x110
[  240.304413]  [] mutex_lock+0x1f/0x2f
[  240.304430]  [] device_release_driver+0x1b/0x30
[  240.304448]  [] bus_remove_device+0x101/0x170
[  240.304467]  [] device_del+0x139/0x260
[  240.304485]  [] ? usb_remove_ep_devs+0x1f/0x30
[  240.304504]  [] usb_disable_device+0xa6/0x280
[  240.304522]  [] usb_disconnect+0x94/0x270
[  240.304539]  [] hub_event+0x693/0x1420
[  240.304557]  [] process_one_work+0x14e/0x3d0
[  240.304575]  [] worker_thread+0x11a/0x470
[  240.305058]  [] ? __schedule+0x358/0x910
[  240.305527]  [] ? rescuer_thread+0x310/0x310
[  240.305992]  [] kthread+0xd2/0xf0
[  240.306450]  [] ? kthread_park+0x50/0x50
[  240.306905]  [] ret_from_fork+0x3f/0x70
[  240.307357]  [] ? kthread_park+0x50/0x50
[  360.382912] INFO: task kworker/3:2:93 blocked for more than 120 seconds.
// same output every 120s

Regards,
   /Alex

-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu] 
Sent: Thursday, November 12, 2015 6:59 PM
To: Cornea, Alexandru 
Cc: linux-usb@vger.kernel.org; Maxim, Costel ; Moraru, 
Cristina 
Subject: Re: [PROBLEM] usb hub malformed packets causes null pointer dereference

On Tue, 10 Nov 2015, Cornea, Alexandru wrote:

> Hello,
>  
> We observed a kernel panic due to a null pointer dereference in the USB 
> stack while sending malformed USB hub packets.

This is an interesting bug.  Not least because it has nothing to do with the 
malformed packets -- it was triggered when the USB device was disconnected 
while the initialization procedure was still running.

> Testing was done on a Galileo board, using kernel version 4.1.8 (image 
> built with Yocto project).
> 
> Output of /proc/version: Linux version 4.1.8-yocto-standard 
> (REDACTED) (gcc version 5.2.0 (GCC) ) #1 PREEMPT Fri Oct 30 15:05:46 
> EET 2015
> 
> Please see full call trace at the end of the mail and reproduction steps.
> 
> Running in debug mode, part of the call trace is displayed, along with:
> <6, <6,  (null): activate --> -19
> which links to drivers/usb/core/hub.c:1239 , function hub_activate (init3). 
> This shows that hub->intfdev is null.
> 
> 1240  init3:
> 1241 hub->quiescing = 0;
> 1242 
> 1243 status = usb_submit_urb(hub->urb, GFP_NOIO);
> 1244 if (status < 0)
> 1245 dev_err(hub->intfdev, "activate --> %d\n", status);
> 
> If you need additional info, please let us know.

Please try the patch below and let us know if it fixes the problem.

Alan Stern



Index: usb-4.3/drivers/usb/core/hub.c
===
--- usb-4.3.orig/drivers/usb/core/hub.c
+++ usb-4.3/drivers/usb/core/hub.c
@@ -1031,10 +1031,20 @@ static void hub_activate(struct usb_hub
unsigned delay;
 
/* Continue a partial initialization */
-   if (type == HUB_INIT2)
-   goto init2;
-   if (type == HUB_INIT3)
+   if (type == HUB_INIT2 || type == HUB_INIT3) {
+   device_lock(hub->intfdev);
+
+   /* Was the hub disconnected while we were waiting? */
+   if (hub->disconnected) {
+   device_unlock(hub->intfdev);
+   kref_put(>kref, hub_release);
+   return;
+   }
+   if (type == HUB_INIT2)
+   goto init2;
goto init3;
+   }
+   kref_get(>kref);
 
/* The superspeed hub except for root hub has to use Hub Depth
 * value as an offset into the route string to locate the bits @@ 
-1232,6 +1242,7 @@ static void hub_activate(struct usb_hub
queue_delayed_work(system_power_efficient_wq,
>init_work,
 

Re: [PATCH 2/3] doc: dt-binding: generic onboard USB HUB

[Peter Chen]

On Tue, Dec 15, 2015 at 09:21:09PM +0100, Ulf Hansson wrote:
> On 9 December 2015 at 09:55, Arnd Bergmann  wrote:
> > On Wednesday 09 December 2015 16:12:24 Peter Chen wrote:
> >> On Tue, Dec 08, 2015 at 09:24:03PM -0600, Rob Herring wrote:
> >> > On Tue, Dec 08, 2015 at 10:58:48AM +0100, Arnd Bergmann wrote:
> >> > > On Tuesday 08 December 2015 10:50:49 Philipp Zabel wrote:
> >> > > > This something we don't have to define ad-hoc. The hub hangs off an 
> >> > > > USB
> >> > > > controller, right? The "Open Firmware recommended practice: USB"
> >> > > > document already describes how to represent USB devices in a generic
> >> > > > manner:
> >> > > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> >> > > >
> >> > > > Is there a reason not to reuse this?
> >> > > >
> >> > > > The usb hub node would be a child of the usb controller node, and it
> >> > > > could use
> >> > > > compatible = "usb,class9"; /* bDeviceClass 9 (Hub) */
> >> > >
> >> > > Good point, I had not thought of that when I looked at the patches.
> >> > >
> >> > > Yes, let's do this way. I don't know if we ever implemented the simple
> >> > > patch to associate a USB device with a device_node, but if not, then
> >> > > let's do it now for this driver. A lot of people have asked for it in
> >> > > the past.
> >> >
> >> > Agreed. Also, some hubs have I2C buses as well, but I still think under
> >> > the USB bus is the right place.
> >> >
> >> > However, one complication here is often (probably this case) these
> >> > addtional signals need to be controlled before the device enumerates.
> >> >
> >>
> >> Yes, I did not find a way to let the USB bus code handle it, so I had to
> >> write a platform driver to do it
> >
> > Looping in Ulf, he solved the same problem for SDIO devices recently,
> > and probably remembers the details best.
> >
> 
> Thanks Arnd!
> 
> Yes, that was a kind of a long outstanding issue we have had for SDIO devices.
> 
> Several generic attempts was made to have a framework/library
> available to support so called "power sequences" for exactly the same
> reasons as above.
> Others and myself failed to get those attempts accepted.
> 
> Instead, I invented a mmc subsystem specific DT based solution, the
> "mmc-pwrseq".
> 
> DT documentation:
> Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> Documentation/devicetree/bindings/mmc/mmc.txt
> 
> Long story short: The mmc host device may contain a phandle to a
> mmc-pwrseq, which will describe the resources needed to power on/off
> the SDIO card.
> 
> The code is available at:
> drivers/mmc/core/pwrseq*
> 
> We didn't implement this as platform driver, but that was mostly
> because I initially wanted things to be simple. Although, nothing
> prevents us from converting to this as a follow up, which would make
> the solution a bit less "hacky".
> 

Thanks for your information, Ulf.

-- 

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] Revert "usb: chipidea: usbmisc_imx: delete clock information"

[Peter Chen]

On Tue, Dec 15, 2015 at 09:19:39PM +0100, Maciej S. Szmigiero wrote:
> Hi Peter,
> 
> On 16.09.2015 05:05, Peter Chen wrote:
> >> On Mon, Sep 14, 2015 at 11:32 PM, Fabio Estevam 
> >> wrote:
> >>
> >>> This did not help.
> >>>
> >>> It is getting late here, so I will be able to try more things tomorrow.
> >>
> >> I was able to fix it. Your initial patch had a missing 'return 0' in
> >> imx_prepare_enable_clks(), causing:
> >>
> >> clk_disable_unprepare(data->clk_ahb);
> >> clk_disable_unprepare(data->clk_ipg);
> >>
> >> to always be called.
> >>
> >> Doing like this on top of your original patch:
> >>
> >> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> >> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> >> @@ -212,6 +212,8 @@ static int imx_prepare_enable_clks(struct device *dev)
> >> }
> >> }
> >>
> >> +   return 0;
> >> +
> >>  err2:
> >> clk_disable_unprepare(data->clk_ahb);
> >>  err1:
> >>
> >> , fixes the crash.
> >>
> >> Would you like to split your patch into dts and usb parts and then resend 
> >> it
> >> formally?
> >>
> > 
> > I have sent out the patches, one suggestion is you may need to add phandle
> > for phy, you can use generic-phy, without clock information.
> > 
> > Peter
> 
> Can we now use this change for repairing the USB support on UDOO board?
> 
> This seems to work fine if not 100% correct:
> --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> @@ -122,7 +122,10 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_usbh>;
>   vbus-supply = <_usb_h1_vbus>;
> - clocks = < 201>;
> + clocks = < IMX6QDL_CLK_USBOH3>,
> +  < IMX6QDL_CLK_USBOH3>,
> +  < 201>;
> + clock-names = "ipg", "ahb", "per";
>   status = "okay";
>  };
>  
> Best regards,
> Maciej Szmigiero
> 

I think it can work, but it is just a workaround. I am working
on a general solution for onboard USB device, the UDOO board
can be its user.

-- 

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 v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Tony Lindgren]

* Kishon Vijay Abraham I  [151215 04:47]:
> On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
> >>>
> >>> Can you explain here what the conversion is good for? Why do you
> >>> prefer the syscon mapping over a high-level driver in this case?
> >>
> >> phy-omap-control driver was added when there was no proper
> >> infrastructure for doing control module initializations. The
> >> phy-omap-control driver is not an 'actual' PHY driver and it
> >> was just a hack to do PHY related control module initializations.
> >> phy-omap-control is also getting unmanageable with the number of
> >> platforms each having number of modules (like USB, SATA, PCIe),
> >> using the same driver for control module initializations.
> >>
> >> Now with SYSCON framework being added to the kernel, phy-omap-control
> >> shouldn't be needed and it also provides a uniform API across all the
> >> modules to program the control module.
> > 
> > Ok, so the "phy-control" devices were really just a few registers of
> > a system controller device that does a lot of other things as well, right?
> 
> right.
> > 
> > Can you put your description above into the cover-letter for the series,
> > and the merge commit?

Just to confirm.. Seems like this series keeps USB working and the dts
changes can be done later after the driver changes have been merged?

Regards,

Tony
--
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] Add support for usbfs zerocopy.

[David Laight]

From: Alan Stern
> Sent: 15 December 2015 15:13
...
> > I was thinking that some side effect of dma_free_coherent() would
> > find the user mapping for the pages, force unmap them and invalidate
> > the user PTE (although the address range would have to remain reserved).
> > Maybe that is wishful thinking.
> 
> It is.  dma_free_coherent() does nothing but remove the DMA mapping and
> deallocate the memory.  It doesn't touch any user page mappings.
> 
> > Similarly for iounmap().
> >
> > > In theory we could prevent this problem by unmapping the memory when
> > > the file descriptor is closed.  But doing so would violate the
> > > guarantee in the munmap(2) documentation.
> >
> > That doesn't help.
> > The mapping is inherited by fork() but you only see the last close().
> > So the close() need not be in the context of the process that has
> > the pages mapped.
> 
> Good point.  So it seems that the try_module_get() / module_put()
> solution is the only one.

That still isn't entirely correct.

Someone with more knowledge than either of us has needs to sort out
how to handle this properly.

Before calling dma_free_coherent() you (and I) need to invalidate all
the vma mappings that reference the memory - so that any accesses
will call the vma_ops.fault() code which will return VM_FAULT_SIGBUS.
Then you need to hold the module present until all the mappings are
removed.

This ordering is more important if vm_iomap_memory() is used since
iounmap() has to be called from the .remove() entry for the hardware.

David


--
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] Add support for usbfs zerocopy.

[Alan Stern]

On Tue, 15 Dec 2015, David Laight wrote:

> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> > Sent: 14 December 2015 17:59
> > On Mon, 14 Dec 2015, David Laight wrote:
> > 
> > > From: Alan Stern
> > > > Sent: 14 December 2015 15:28
> > > ...
> > > > I thought of something else, a more serious problem.  According to the
> > > > man page for munmap(2), closing the file descriptor does not unmap the
> > > > region.  Therefore we need to explicitly make sure that the usbcore
> > > > module cannot be unloaded while any memory mappings exist, by calling
> > > > try_module_get(THIS_MODULE) when a mapping is created and
> > > > module_put(THIS_MODULE) when a mapping is removed.
> > >
> > > Are you sure this is a problem?
> > 
> > I haven't actually tried to provoke a crash, if that's what you're
> > asking.  Apart from that, yes, I'm sure this is a problem.
> 
> There are certainly potential issues with both remap_pfn_range()
> and vm_iomap_memory().

What are you thinking of?

> > > It is more likely that either:
> > > 1) the mmap() holds a reference to the physical pages - so they don't
> > >   get freed even though the driver frees its reference to the memory.
> > 
> > The problem has nothing to do with the pages being freed.
> > 
> > > 2) when the driver frees the memory the user-space page tables are
> > >   invalidated - so the next access generates EFAULT.
> > 
> > I'm not sure what you're getting at here.  The page tables are
> > invalidated when the user program calls munmap (or exits), and the
> > driver frees the memory when that happens.
> > 
> > > Not that I've done the experiment (or tried to read the code).
> > >
> > > If you need to monitor the mapping, you need to allow for partial unmaps.
> > 
> > That's not the problem either -- although I don't know how we should
> > handle partial unmaps.  Can we disallow them?
> > 
> > The problem is that the user can map the memory, then close the file
> > descriptor, then rmmod the usbcore module, then unmap the memory
> > region.  When the unmap occurs, the memory subsystem will try to
> > dereference the usbdev_vm_ops structure -- which has been unloaded
> > along with the rest of usbcore.  This will cause an oops.
> 
> I was thinking that some side effect of dma_free_coherent() would
> find the user mapping for the pages, force unmap them and invalidate
> the user PTE (although the address range would have to remain reserved).
> Maybe that is wishful thinking.

It is.  dma_free_coherent() does nothing but remove the DMA mapping and 
deallocate the memory.  It doesn't touch any user page mappings.

> Similarly for iounmap().
> 
> > In theory we could prevent this problem by unmapping the memory when
> > the file descriptor is closed.  But doing so would violate the
> > guarantee in the munmap(2) documentation.
> 
> That doesn't help.
> The mapping is inherited by fork() but you only see the last close().
> So the close() need not be in the context of the process that has
> the pages mapped.

Good point.  So it seems that the try_module_get() / module_put() 
solution is the only one.

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: storage: add "no SYNCHRONIZE CACHE" quirk

[Alan Stern]

On Tue, 15 Dec 2015, Oliver Neukum wrote:

> On Thu, 2015-12-03 at 13:36 -0500, Alan Stern wrote:
> > This is an old problem, but it was never resolved and it still affects
> > people (Bugzilla #89511).  In short, there are USB-(S)ATA bridges that
> > claim to be write-back but don't support the SYNCHRONIZE CACHE
> > command.  
> > This causes errors when filesystems try to flush data out to the disk.
> 
> OK, maybe this is a stupid idea, but could we test the command as we
> enumerate the slave and store the result?

Maybe, although doing so within usb-storage would be kind of difficult
-- that driver is set up to forward requests from the SCSI layer, not
to generate requests of its own.  Besides, usb-storage doesn't know 
anything about write-back vs. write-through; only sd does.  I suppose 
sd could perform that test.

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