Re: [PATCH V5 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

On 8 June 2017 at 18:08, Rafał Miłecki <zaj...@gmail.com> wrote: > From: Rafał Miłecki <ra...@milecki.pl> > > This uses DT info to read relation description of LEDs and USB ports. If > DT has properly described LEDs, trigger will know when to turn them on. > > Si

[PATCH V5 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

From: Rafał Miłecki <ra...@milecki.pl> This uses DT info to read relation description of LEDs and USB ports. If DT has properly described LEDs, trigger will know when to turn them on. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- V2: Update to use "led-triggers" V3:

[EXAMPLE V5 3/2] ARM: BCM53573: Specify ports for USB LED for Tenda AC9

From: Rafał Miłecki <ra...@milecki.pl> Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- This patch *should not* be applied. It's only an EXAMPLE and that's why it uses that weird 3/2 number. It's a proof of concept, it was tested & will be submitted through ARM tree if prev

[PATCH V5 1/2] dt-bindings: leds: document new trigger-sources property

From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to a specific device(s) described in the DT. This property allows specifying such relations. E.g. USB LED should usually be used to indicate some USB port(s) state. Please note this binding is designed to be g

[PATCH V5 0/2] usb: introduce "trigger-sources" DT property for usbport trigger

From: Rafał Miłecki <ra...@milecki.pl> This version of my patchset (V5) differs by renaming #source-cells to the #trigger-source-cells and documenting it in the leds/common.txt. I'd epxect both patches to go through Greg's usb.git if accepted. For a reference (and before someome

[PATCH V4 0/2] usb: introduce "trigger-sources" DT property for usbport trigger

From: Rafał Miłecki <ra...@milecki.pl> This patchset (V4) differs by only a tiny fix in 1/2 changing property used in the DT example. I'd epxect both patches to go through Greg's usb.git if accepted. For a reference (and before someome comes with already rejected solution) see below h

[EXAMPLE V4 3/2] ARM: BCM53573: Specify ports for USB LED for Tenda AC9

From: Rafał Miłecki <ra...@milecki.pl> Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- This patch *should not* be applied. It's only an EXAMPLE and that's why it uses that weird 3/2 number. It's a proof of concept, it was tested & will be submitted through ARM tree if prev

[PATCH V4 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

From: Rafał Miłecki <ra...@milecki.pl> This uses DT info to read relation description of LEDs and USB ports. If DT has properly described LEDs, trigger will know when to turn them on. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- V2: Update to use "led-triggers" V3:

[PATCH V4 1/2] dt-bindings: leds: document new trigger-sources property

From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to a specific device(s) described in the DT. This property allows specifying such relations. E.g. USB LED should usually be used to indicate some USB port(s) state. Please note this binding is designed to be g

Re: [PATCH V3 1/2] dt-bindings: leds: document new trigger-sources property

On 29 May 2017 at 21:52, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: > On 05/29/2017 04:01 PM, Rafał Miłecki wrote: >> From: Rafał Miłecki <ra...@milecki.pl> >> >> Some LEDs can be related to a specific device(s) described in the DT. >> This propert

[PATCH V3 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

From: Rafał Miłecki <ra...@milecki.pl> This uses DT info to read relation description of LEDs and USB ports. If DT has properly described LEDs, trigger will know when to turn them on. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- V2: Update to use "led-triggers" V3:

[EXAMPLE V3 3/2] ARM: BCM53573: Specify ports for USB LED for Tenda AC9

From: Rafał Miłecki <ra...@milecki.pl> Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- This patch *should not* be applied. It's only an EXAMPLE and that's why it uses that weird 3/2 number. It's a proof of concept, it was tested & will be submitted through ARM tree if prev

[PATCH V3 1/2] dt-bindings: leds: document new trigger-sources property

From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to a specific device(s) described in the DT. This property allows specifying such relations. E.g. USB LED should usually be used to indicate some USB port(s) state. Please note this binding is designed to be g

[PATCH V3 0/2] usb: introduce "trigger-sources" DT property for usbport trigger

From: Rafał Miłecki <ra...@milecki.pl> Hi, This is another try of adding relation between LEDs and devices to the DT (and usbport). I followed discussions in all old threads and came with this V3. I'd epxect both patches to go through Greg's usb.git if accepted. For a reference (and

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 02/02/2017 09:44 PM, Jacek Anaszewski wrote: On 02/01/2017 10:55 PM, Rafał Miłecki wrote: On 02/01/2017 10:26 PM, Jacek Anaszewski wrote: On 02/01/2017 04:56 PM, Rafał Miłecki wrote: On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: On 01/31/2017 05:11 PM, Rafał Miłecki wrote: Thanks a lot

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 02/01/2017 10:26 PM, Jacek Anaszewski wrote: On 02/01/2017 04:56 PM, Rafał Miłecki wrote: On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: On 01/31/2017 05:11 PM, Rafał Miłecki wrote: Thanks a lot Jacek for this explanation (and sorry but I needed a bit of time to think about this). I can

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: On 01/31/2017 05:11 PM, Rafał Miłecki wrote: On 01/25/2017 10:04 PM, Jacek Anaszewski wrote: On 01/25/2017 10:03 AM, Rafał Miłecki wrote: On 21 January 2017 at 22:42, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: On 01/21/2017 05

Re: [PATCH 4.10-rc3 05/13] net: bgmac: fix build errors when linux/phy*.h is removed from net/dsa.h

-off-by: Russell King <rmk+ker...@armlinux.org.uk> Acked-by: Rafał Miłecki <ra...@milecki.pl> -- 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 1/2] dt-bindings: leds: document new led-triggers property

On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: On 01/31/2017 05:11 PM, Rafał Miłecki wrote: On 01/25/2017 10:04 PM, Jacek Anaszewski wrote: On 01/25/2017 10:03 AM, Rafał Miłecki wrote: On 21 January 2017 at 22:42, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: On 01/21/2017 05

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:04 PM, Jacek Anaszewski wrote: On 01/25/2017 10:03 AM, Rafał Miłecki wrote: On 21 January 2017 at 22:42, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: On 01/21/2017 05:24 PM, Rafał Miłecki wrote: On 20 January 2017 at 23:35, Jacek Anaszewski <jacek.anaszew...@

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/23/2017 09:51 PM, Jacek Anaszewski wrote: On 01/23/2017 05:45 PM, Rob Herring wrote: On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote: Hi Rafał, On 01/20/2017 10:56 PM, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to part

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/23/2017 05:45 PM, Rob Herring wrote: On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote: Hi Rafał, On 01/20/2017 10:56 PM, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to particular devices described in DT. This property

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 21 January 2017 at 22:42, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: > On 01/21/2017 05:24 PM, Rafał Miłecki wrote: >> On 20 January 2017 at 23:35, Jacek Anaszewski >> <jacek.anaszew...@gmail.com> wrote: >>> On 01/20/2017 10:56 PM, Rafał Miłecki

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 20 January 2017 at 23:35, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: > On 01/20/2017 10:56 PM, Rafał Miłecki wrote: >> From: Rafał Miłecki <ra...@milecki.pl> >> >> Some LEDs can be related to particular devices described in DT. This >> propert

[PATCH V2 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

From: Rafał Miłecki <ra...@milecki.pl> This adds support for using description of relation between LEDs and USB ports from device tree. If DT has properly described LEDs, trigger will know when to turn them on. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- V2: Update to use &

[PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to particular devices described in DT. This property allows specifying such relations. E.g. USB LED should usually be used to indicate some USB port(s) state. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- V2:

[EXAMPLE V2 3/2] ARM: BCM53573: Specify ports for USB LED for Tenda AC9

From: Rafał Miłecki <ra...@milecki.pl> Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- This patch *should not* be applied. It's only an EXAMPLE and that's why it uses weird 3/2 number. It's a proof of concept, it was tested & will be submitted through ARM tree if prev

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

On 21 November 2016 at 16:31, Mathias Nyman <mathias.ny...@linux.intel.com> wrote: > On 21.11.2016 09:57, Rafał Miłecki wrote: >> >> Hi Mathias, >> >> On 17 October 2016 at 22:30, Rafał Miłecki <zaj...@gmail.com> wrote: >>> >>> From: Rafa

Re: [PATCH 1/2] dt-bindings: leds: document new usb-ports property

On 01/03/2017 09:52 PM, Rob Herring wrote: On Thu, Dec 29, 2016 at 02:03:04PM +0100, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to particular USB ports (common case for home routers). This property allows describing such a relation. Sign

[EXAMPLE 3/2] ARM: BCM53573: Specify ports for USB LED for Tenda AC9

From: Rafał Miłecki <ra...@milecki.pl> Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- This patch was tested & works as expected. It's marked as EXAMPLE just because it should go through ARM tree. --- arch/arm/boot/dts/bcm47189-tenda-ac9.dts | 1 + 1 file changed, 1 insertio

[PATCH 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

From: Rafał Miłecki <ra...@milecki.pl> This adds support for using description of relation between LEDs and USB ports from device tree. If device has a properly described LEDs, trigger will know when to turn them on. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- drivers/usb/

[PATCH 1/2] dt-bindings: leds: document new usb-ports property

From: Rafał Miłecki <ra...@milecki.pl> Some LEDs can be related to particular USB ports (common case for home routers). This property allows describing such a relation. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- This patch is based on top of commit 52e847dc431 ("

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On 8 December 2016 at 09:40, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: > On 12/06/2016 06:29 PM, Rafał Miłecki wrote: >> >> On 6 December 2016 at 18:26, Pavel Machek <pa...@ucw.cz> wrote: >>> >>> On Fri 2016-12-02 09:48:18, Ralph Sennhauser

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On 6 December 2016 at 18:26, Pavel Machek <pa...@ucw.cz> wrote: > On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote: >> On Thu, 1 Dec 2016 17:56:07 +0100 >> Rafał Miłecki <ra...@milecki.pl> wrote: >> >> > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote: &

[PATCH FIX] usb: core: usbport: Use proper LED API to fix potential crash

From: Rafał Miłecki <ra...@milecki.pl> Calling brightness_set manually isn't safe as some LED drivers don't implement this callback. The best idea is to just use a proper helper which will fallback to the brightness_set_blocking callback if needed. This fixes: [ 1461.761528] Unable to

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On 12/01/2016 03:28 PM, Ralph Sennhauser wrote: Below the oops with your debug patch applied. (...) root@wrt1900acs:/# cd sys/class/leds/pca963x\:shelby\:white\:usb2/ root@wrt1900acs:/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:shelby:white:usb2# echo

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

Hi Mathias, On 17 October 2016 at 22:30, Rafał Miłecki <zaj...@gmail.com> wrote: > From: Rafał Miłecki <ra...@milecki.pl> > > Broadcom's Northstar XHCI controllers seem to need a special start > procedure to work correctly. There isn't any official documentatio

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

On 17 October 2016 at 23:10, Hauke Mehrtens <ha...@hauke-m.de> wrote: > On 10/17/2016 10:30 PM, Rafał Miłecki wrote: >> From: Rafał Miłecki <ra...@milecki.pl> >> >> Broadcom's Northstar XHCI controllers seem to need a special start >> procedure to w

[PATCH V2] usb: xhci: add support for performing fake doorbell

From: Rafał Miłecki <ra...@milecki.pl> Broadcom's Northstar XHCI controllers seem to need a special start procedure to work correctly. There isn't any official documentation of this, the problem is that controller doesn't detect any connected devices with default setup. Moreover connecti

[PATCH] usb: xhci: add support for performing fake doorbell

From: Rafał Miłecki <ra...@milecki.pl> Broadcom's Northstar XHCI controllers seem to need a special start procedure to work correctly. There isn't any official documentation on this, the problem is that controller doesn't detect any connected devices with default setup. Moreover connecti

[PATCH] USB: bcma: drop Northstar PHY 2.0 initialization code

From: Rafał Miłecki <ra...@milecki.pl> This driver should initialize controller only, PHY initialization should be handled by separated PHY driver. We already have phy-bcm-ns-usb2 in place so let it makes its duty. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- drivers/usb/hos

[PATCH V6] usb: core: Introduce a USB port LED trigger

From: Rafał Miłecki <ra...@milecki.pl> This commit adds a new trigger responsible for turning on LED when USB device gets connected to the selected USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigge

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

On 15 September 2016 at 14:56, Pavel Machek <pa...@ucw.cz> wrote: > On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: >> On 9 September 2016 at 13:05, Greg KH <gre...@linuxfoundation.org> wrote: >> > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: >&

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

On 9 September 2016 at 13:05, Greg KH <gre...@linuxfoundation.org> wrote: > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: >> > From: Rafał Miłecki <ra...@milecki.pl> >> > >>

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

On 9 September 2016 at 11:34, Peter Chen <hzpeterc...@gmail.com> wrote: > On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: >> From: Rafał Miłecki <ra...@milecki.pl> >> >> This commit adds a new trigger responsible for turning on LED when USB >>

[PATCH V5] leds: trigger: Introduce a USB port trigger

From: Rafał Miłecki <ra...@milecki.pl> This commit adds a new trigger responsible for turning on LED when USB device gets connected to the selected USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigge

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 4 September 2016 at 02:24, Alan Stern wrote: > On Sat, 3 Sep 2016, Jacek Anaszewski wrote: > >> >> The remaining issue is the sysfs interface design for defining and >> >> presenting multiple USB ports. I'm still in favour of a single >> >> attribute with space

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 31 August 2016 at 21:00, Rafał Miłecki <zaj...@gmail.com> wrote: > On 31 August 2016 at 20:23, Alan Stern <st...@rowland.harvard.edu> wrote: >> On Tue, 30 Aug 2016, Rafał Miłecki wrote: >>> Not really as it won't cover some pretty common use cases. Many home >&

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 31 August 2016 at 20:23, Alan Stern <st...@rowland.harvard.edu> wrote: > On Tue, 30 Aug 2016, Rafał Miłecki wrote: > >> >> As you quite often need more complex LED management, there are >> >> triggers that were introduced in 2006 by c3bc9956ec52f ("[

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 30 August 2016 at 22:54, Alan Stern <st...@rowland.harvard.edu> wrote: > On Tue, 30 Aug 2016, Rafał Miłecki wrote: > >> Please take a look at Documentation to get some idea of LED triggers: >> Documentation/leds/leds-class.txt >> >> Basically a LED (/sy

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 30 August 2016 at 14:05, Greg KH <gre...@linuxfoundation.org> wrote: > On Fri, Aug 26, 2016 at 05:38:05PM +0200, Rafał Miłecki wrote: >> On 25 August 2016 at 14:49, Greg KH <gre...@linuxfoundation.org> wrote: >> > On Thu, Aug 25, 2016 at 10:03:52AM +0200, Rafał Mił

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 29 August 2016 at 10:41, Pavel Machek <pa...@ucw.cz> wrote: > On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote: >> On 29 August 2016 at 10:05, Pavel Machek <pa...@ucw.cz> wrote: >> >> >2) Having "ports" subdir with RW files, one per each existing phy

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 29 August 2016 at 10:05, Pavel Machek wrote: >> >2) Having "ports" subdir with RW files, one per each existing physical port >> >In this situation we don't need "new_port" or "remove_port". If we >> >want port to be observable we just do: >> >echo 1 > 1-1 >> >Implementing this

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 25 August 2016 at 20:48, Jacek Anaszewski wrote: > On 08/25/2016 04:30 PM, Alan Stern wrote: >> >> On Thu, 25 Aug 2016, Jacek Anaszewski wrote: >> >>> I'd see it as follows: >>> >>> #cat available_ports >>> #1-1 1-2 2-1 >>> >>> #echo "1-1" > new_port >>> >>> #cat

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 25 August 2016 at 14:49, Greg KH <gre...@linuxfoundation.org> wrote: > On Thu, Aug 25, 2016 at 10:03:52AM +0200, Rafał Miłecki wrote: >> +static void usbport_trig_activate(struct led_classdev *led_cdev) >> +{ >> + struct usbport_trig_data *usb

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 25 August 2016 at 10:03, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: > On 08/24/2016 07:52 PM, Rafał Miłecki wrote: >> >> From: Rafał Miłecki <ra...@milecki.pl> >> >> This commit adds a new trigger responsible for turning on LED when USB >> de

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 25 August 2016 at 10:03, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: > On 08/24/2016 07:52 PM, Rafał Miłecki wrote: >> >> From: Rafał Miłecki <ra...@milecki.pl> >> >> This commit adds a new trigger responsible for turning on LED when USB >> de

[PATCH V4] leds: trigger: Introduce an USB port trigger

From: Rafał Miłecki <ra...@milecki.pl> This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigge

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On 24 August 2016 at 23:04, Greg KH <gre...@linuxfoundation.org> wrote: > On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote: >> On 24 August 2016 at 11:22, Greg KH <gre...@linuxfoundation.org> wrote: >> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafa

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 24 August 2016 at 20:48, Bjørn Mork <bj...@mork.no> wrote: > Rafał Miłecki <zaj...@gmail.com> writes: > >> The last big missing thing is Documentation update (this is why I'm >> sending RFC). Greg pointed out we should have some entries in >> Documentatio

[PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

From: Rafał Miłecki <ra...@milecki.pl> This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigge

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On 24 August 2016 at 12:49, Matthias Brugger <mbrug...@suse.com> wrote: > On 24/08/16 00:03, Rafał Miłecki wrote: >> >> From: Rafał Miłecki <ra...@milecki.pl> >> >> This commit adds a new trigger responsible for turning on LED when USB >> device gets

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On 24 August 2016 at 11:22, Greg KH <gre...@linuxfoundation.org> wrote: > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote: >> +static ssize_t ports_show(struct device *dev, struct device_attribute *attr, >> + char *buf) >> +{ &

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On 24 August 2016 at 11:21, Greg KH <gre...@linuxfoundation.org> wrote: > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote: >> From: Rafał Miłecki <ra...@milecki.pl> >> >> This commit adds a new trigger responsible for turning on LED when USB >>

[PATCH V3] leds: trigger: Introduce an USB port trigger

From: Rafał Miłecki <ra...@milecki.pl> This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigge

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

On 29 July 2016 at 09:09, Rafał Miłecki <zaj...@gmail.com> wrote: > HI Rob, > > I got problems following your objections, so it took me some time to > go back to this. > > On 21 July 2016 at 22:42, Rob Herring <r...@kernel.org> wrote: >> On Wed, Jul 20, 201

Re: [PATCH V4] phy: bcm-ns-usb3: new driver for USB 3.0 PHY on Northstar

On 12 August 2016 at 11:46, Kishon Vijay Abraham I <kis...@ti.com> wrote: > On Friday 12 August 2016 03:58 AM, Rafał Miłecki wrote: >> From: Rafał Miłecki <ra...@milecki.pl> >> >> Northstar is a family of SoCs used in home routers. They have USB 2.0 >>

[PATCH] USB: bcma: support old USB 2.0 controller on Northstar devices

From: Rafał Miłecki <ra...@milecki.pl> Currently bcma-hcd driver handles 3 different bcma cores: 1) BCMA_CORE_USB20_HOST (0x819) 2) BCMA_CORE_NS_USB20 (0x504) 3) BCMA_CORE_NS_USB30 (0x505) The first one was introduced years ago and so far was used on MIPS devices only. All Northsta

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

HI Rob, I got problems following your objections, so it took me some time to go back to this. On 21 July 2016 at 22:42, Rob Herring <r...@kernel.org> wrote: > On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote: >> On 20 July 2016 at 03:02, Rob Herring <r...

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

On 20 July 2016 at 03:02, Rob Herring <r...@kernel.org> wrote: > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote: >> This commit adds a new trigger that can turn on LED when USB device gets >> connected to the USB port. This can be useful for various home rou

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

On 18 July 2016 at 07:53, Peter Chen <hzpeterc...@gmail.com> wrote: > On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote: >> On 18 July 2016 at 07:40, Peter Chen <hzpeterc...@gmail.com> wrote: >> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłeck

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

On 18 July 2016 at 07:40, Peter Chen <hzpeterc...@gmail.com> wrote: > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote: >> On 18 July 2016 at 04:31, Peter Chen <hzpeterc...@gmail.com> wrote: >> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

On 18 July 2016 at 04:31, Peter Chen <hzpeterc...@gmail.com> wrote: > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote: >> + >> +usbport trigger: >> +- usb-ports : List of USB ports that usbport should observed for turning on >> a >> +

[PATCH V2] leds: trigger: Introduce an USB port trigger

to specify USB ports from user space. This may change in a future. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- V2: The first version got support for specifying list of USB ports from user space only. There was a (big try &) discussion on adding DT support. It led to a pre

Re: [PATCH V2 0/1] usb: add HCD providers

On 15 July 2016 at 08:22, Peter Chen <hzpeterc...@gmail.com> wrote: > On Fri, Jul 15, 2016 at 07:48:11AM +0200, Rafał Miłecki wrote: >> >> > Below I supply another thought, please check if it is feasible. >> >> > In below design, you don't need to ch

Re: [PATCH V2 0/1] usb: add HCD providers

On 15 July 2016 at 04:28, Peter Chen <hzpeterc...@gmail.com> wrote: > On Thu, Jul 14, 2016 at 05:52:43PM +0200, Rafał Miłecki wrote: >> On 14 July 2016 at 11:48, Peter Chen <hzpeterc...@gmail.com> wrote: >> > On Wed, Jul 13, 2016 at 04:40:53PM +0200, Rafał Miłeck

[PATCH] usb: ohci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki <zaj...@

[PATCH V2] usb: ehci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki <zaj...@gmail.c

Re: [PATCH V2 0/1] usb: add HCD providers

On 14 July 2016 at 11:48, Peter Chen <hzpeterc...@gmail.com> wrote: > On Wed, Jul 13, 2016 at 04:40:53PM +0200, Rafał Miłecki wrote: >> On 13 July 2016 at 15:50, Felipe Balbi <felipe.ba...@linux.intel.com> wrote: >> > Rafał Miłecki <zaj...@gmail.com> writes: &g

Re: [PATCH] usb: ehci-platform: use helper variables in probe function

On 14 July 2016 at 16:11, Alan Stern <st...@rowland.harvard.edu> wrote: > On Wed, 13 Jul 2016, Rafał Miłecki wrote: > >> Probing function was using >dev and dev->dev.of_node over 20 times >> so I believe it made sense to use helper variables for both of them. >

Re: [PATCH V2 PROOF OF CONCEPT 2/1] trigger: ledtrig-usbport: read initial state from DT

On 13 July 2016 at 16:48, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: > On 07/13/2016 02:42 PM, Rafał Miłecki wrote: >> >> This allows specifying USB ports that should be observed by a trigger >> right after activating it. Example: >> >> usb {

Re: [PATCH V2 0/1] usb: add HCD providers

On 13 July 2016 at 15:50, Felipe Balbi <felipe.ba...@linux.intel.com> wrote: > Rafał Miłecki <zaj...@gmail.com> writes: >> On 13 July 2016 at 15:20, Felipe Balbi <felipe.ba...@linux.intel.com> wrote: >>> Rafał Miłecki <zaj...@gmail.com> writes: >

Re: [PATCH V2 0/1] usb: add HCD providers

On 13 July 2016 at 15:20, Felipe Balbi <felipe.ba...@linux.intel.com> wrote: > Rafał Miłecki <zaj...@gmail.com> writes: >> Hi again, >> >> This is my second try of getting HCD providers into usb subsystem. >> >> During discussion of V1 I realized ther

[PATCH V2 PROOF OF CONCEPT 2/1] trigger: ledtrig-usbport: read initial state from DT

ts = "1", "1", "1"; }; Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/leds/trigger/ledtrig-usbport.c | 72 ++ 1 file changed, 72 insertions(+) diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trig

[PATCH V2 0/1] usb: add HCD providers

; compatible = "generic-xhci"; reg = <0x3000 0x1000>; interrupts = ; }; The last (second) patch is not supposed to be applied, it's used only as a proof and example of how providers can be used. Rafał Miłecki (1): usb: core: add support for HCD provid

[PATCH V2 1/1] usb: core: add support for HCD providers

When working with Device Tree we may need to reference controllers (their nodes) and query for HCDs. This is useful for getting some runtime info about host controllers like e.g. assigned bus number. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/usb/core/Makefile

Re: [PATCH 0/2] usb: add HCD providers

On 13 July 2016 at 10:02, Peter Chen <hzpeterc...@gmail.com> wrote: > On Wed, Jul 13, 2016 at 07:21:09AM +0200, Rafał Miłecki wrote: >> On 13 July 2016 at 06:51, Peter Chen <hzpeterc...@gmail.com> wrote: >> > On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłe

[PATCH] usb: ehci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki <zaj...@

Re: [PATCH 0/2] usb: add HCD providers

On 13 July 2016 at 06:51, Peter Chen <hzpeterc...@gmail.com> wrote: > On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote: >> I was working on an "usbport" LED trigger driver and specifying its >> default state in DT. I realized I can't really determine n

[PATCH 2/2] ohci-platform: register HCD provider

This allows platforms using e.g. "generic-ohci" to reference HCD using recently introduced providers mechanism Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/usb/host/ohci-platform.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/usb/host/o

[PATCH 1/2] usb: core: add support for HCD providers

When working with Device Tree we may need to reference controllers (their nodes) and query for HCDs. This is useful for getting some runtime info about host controllers like e.g. assigned bus number. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/usb/core/Makefile| 1 + d

[PATCH PROOF OF CONCEPT 3/2] trigger: ledtrig-usbport: read initial state from DT

This allows specifying USB ports that should be observed by a trigger right after activating it. Example: usb { gpios = < 0 GPIO_ACTIVE_HIGH>; linux,default-trigger = "usbport"; usb-controllers = <>, <>, <>; usb-ports = "

[PATCH 0/2] usb: add HCD providers

c-xhci. The last (third) patch is not supposed to be applied, it's used only as a proof and example of how providers can be used. If there is anything wrong with this idea/implementation, please let me know. Rafał Miłecki (2): usb: core: add support for HCD providers ohci-platform: register HC

[PATCH] USB: bcma: initialize Northstar USB 3.0 controller

It's a rather simple controller, we just need to make sure USB is powered (using GPIO pin) and reset bus core. Once this is done it's safe to register XHCI controller and let it init PHY and do its magic. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/usb/host/bcma-hcd.

Re: Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

On 16 April 2016 at 17:13, Alan Stern <st...@rowland.harvard.edu> wrote: > On Fri, 15 Apr 2016, Rafał Miłecki wrote: > >> > What happens if you plug a USB-1.1 device (such as a mouse or keyboard) >> > into your single-port system? >> >> Now, this

Re: Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

On 15 April 2016 at 17:33, Alan Stern <st...@rowland.harvard.edu> wrote: > On Fri, 15 Apr 2016, Rafał Miłecki wrote: > >> Hello >> >> >> I'm seeing some problems with EHCI stability on two families of >> Broadcom devices: >> 1) CO

Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

Hello I'm seeing some problems with EHCI stability on two families of Broadcom devices: 1) CONFIG_MIPS=y, CONFIG_BCM47XX=y 2) CONFIG_ARM=y, CONFIG_ARCH_BCM_5301X=y both of them use bcma-hcd driver which registers "ehci-platform" device. An interesting note is that this stability problem occurs

Re: ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)

On 13 April 2016 at 17:25, Alan Stern <st...@rowland.harvard.edu> wrote: > On Wed, 13 Apr 2016, Rafał Miłecki wrote: >> I'm trying to debug some EHCI issue so I enabled debugging by adding >> ccflags-y := -DDEBUG >> to the drivers/usb/host/Makefile >> >>

Re: [PATCH V3] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar

Hi and thanks for your review! On 13 April 2016 at 15:54, Kishon Vijay Abraham I <kis...@ti.com> wrote: > On Monday 11 April 2016 03:13 PM, Rafał Miłecki wrote: >> +Example: >> + usb2-phy { >> + compatible = "brcm,ns-usb2-phy"; >

ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)

Hi, I'm trying to debug some EHCI issue so I enabled debugging by adding ccflags-y := -DDEBUG to the drivers/usb/host/Makefile Some of debugging lines contain random memory, e.g.: ehci-platform ehci-platform.0: .|��`|���5P5@�3�.��*�.|��o It's caused by dbg_status, dbg_cmd and dbg_port calling

  1   2   >