Hi Mathias,
On 17 October 2016 at 22:30, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> 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 doe
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 usbp
From: Rafał Miłecki
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 handle kernel NU
On 6 December 2016 at 18:26, Pavel Machek wrote:
> On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote:
>> On Thu, 1 Dec 2016 17:56:07 +0100
>> Rafał Miłecki wrote:
>>
>> > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote:
>> > > Be
On 8 December 2016 at 09:40, Jacek Anaszewski wrote:
> On 12/06/2016 06:29 PM, Rafał Miłecki wrote:
>>
>> On 6 December 2016 at 18:26, Pavel Machek wrote:
>>>
>>> On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote:
>>>>
>>>> On
From: Rafał Miłecki
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
---
This patch is based on top of commit 52e847dc431 ("DT: leds: Improve examples
by adding some context"
From: Rafał Miłecki
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
---
drivers/usb/core/ledtrig-usbport.c | 54
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
---
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 insertion(+)
diff --git a/arch/arm/boot/dts/bcm47
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
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
On 21 November 2016 at 16:31, Mathias Nyman
wrote:
> On 21.11.2016 09:57, Rafał Miłecki wrote:
>>
>> Hi Mathias,
>>
>> On 17 October 2016 at 22:30, Rafał Miłecki wrote:
>>>
>>> From: Rafał Miłecki
>>>
>>> Broadcom's Northstar
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
---
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
previous patches get accepted.
---
arch/ar
From: Rafał Miłecki
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
---
V2: Update to use "led-triggers"
---
drivers/usb/co
From: Rafał Miłecki
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
---
V2: Replace "usb-ports" with "led-tri
On 20 January 2017 at 23:35, Jacek Anaszewski
wrote:
> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> Some LEDs can be related to particular devices described in DT. This
>> property allows specifying such relations. E.g. USB LED should usu
On 21 January 2017 at 22:42, Jacek Anaszewski
wrote:
> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
>> On 20 January 2017 at 23:35, Jacek Anaszewski
>> wrote:
>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki
>>>>
>
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
Some LEDs can be related to particular devices described in DT. This
property allows specifying such
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
Some LEDs can be related to particular devices described
From: Rafał Miłecki
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 trigger gets its documentation
On 9 September 2016 at 11:34, Peter Chen wrote:
> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the selected USB po
On 9 September 2016 at 13:05, Greg KH 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
>> >
>> > This commit adds a new trigger responsible for turn
On 15 September 2016 at 14:56, Pavel Machek wrote:
> On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote:
>> On 9 September 2016 at 13:05, Greg KH wrote:
>> > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote:
>> >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Raf
From: Rafał Miłecki
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 trigger gets its documentation
From: Rafał Miłecki
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
---
drivers/usb/host/bcma-hcd.c | 80
From: Rafał Miłecki
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 connecting USB devic
From: Rafał Miłecki
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 connecting USB devic
On 17 October 2016 at 23:10, Hauke Mehrtens wrote:
> On 10/17/2016 10:30 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> Broadcom's Northstar XHCI controllers seem to need a special start
>> procedure to work correctly. There isn't any official document
e cases in the future (e.g. add XHCI support).
Signed-off-by: Rafał Miłecki
---
drivers/usb/host/bcma-hcd.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index 291aaa2..dea12e9 100644
--- a/d
ling XHCI)
in the future.
Signed-off-by: Rafał Miłecki
---
drivers/usb/host/bcma-hcd.c | 59 ++---
1 file changed, 39 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index dea12e9..963e2d0 100644
-
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
---
drivers/usb/host/bcma-hcd.c | 19
mp;
generic-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-platfo
gt;;
usb-ports = "1", "1", "1";
};
Signed-off-by: Rafał Miłecki
---
drivers/leds/trigger/ledtrig-usbport.c | 72 ++
1 file changed, 72 insertions(+)
diff --git a/drivers/leds/trigger/ledtrig-usbport.c
b/drivers/leds/tr
This allows platforms using e.g. "generic-ohci" to reference HCD using
recently introduced providers mechanism
Signed-off-by: Rafał Miłecki
---
drivers/usb/host/ohci-platform.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb
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
---
drivers/usb/core/Makefile| 1 +
drivers/usb/core
On 13 July 2016 at 06:51, Peter Chen 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 numbering of
>> USB
Probing function was using &dev->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
---
driver
On 13 July 2016 at 10:02, Peter Chen wrote:
> On Wed, Jul 13, 2016 at 07:21:09AM +0200, Rafał Miłecki wrote:
>> On 13 July 2016 at 06:51, Peter Chen wrote:
>> > On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote:
>> >> I was working on an "usbport
;
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 p
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
---
drivers/usb/core/Makefile | 1 +
drivers/usb/core/hcd.c
ci USB_HCD_SHARED>;
usb-ports = "1", "1", "1";
};
Signed-off-by: Rafał Miłecki
---
drivers/leds/trigger/ledtrig-usbport.c | 72 ++
1 file changed, 72 insertions(+)
diff --git a/drivers/leds/trigger/ledtrig-usbport.c
b/drivers
On 13 July 2016 at 15:20, Felipe Balbi wrote:
> Rafał Miłecki writes:
>> Hi again,
>>
>> This is my second try of getting HCD providers into usb subsystem.
>>
>> During discussion of V1 I realized there are about 26 drivers adding a
>> single HCD and al
On 13 July 2016 at 15:50, Felipe Balbi wrote:
> Rafał Miłecki writes:
>> On 13 July 2016 at 15:20, Felipe Balbi wrote:
>>> Rafał Miłecki writes:
>>>> Hi again,
>>>>
>>>> This is my second try of getting HCD providers into usb subsystem.
On 13 July 2016 at 16:48, Jacek Anaszewski 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 {
>> gpios = <&gpio
On 14 July 2016 at 16:11, Alan Stern wrote:
> On Wed, 13 Jul 2016, Rafał Miłecki wrote:
>
>> Probing function was using &dev->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
On 14 July 2016 at 11:48, Peter Chen wrote:
> On Wed, Jul 13, 2016 at 04:40:53PM +0200, Rafał Miłecki wrote:
>> On 13 July 2016 at 15:50, Felipe Balbi wrote:
>> > Rafał Miłecki writes:
>> >> On 13 July 2016 at 15:20, Felipe Balbi
>> >> wrote:
>
Probing function was using &dev->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
Acked-by:
Probing function was using &dev->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
---
driver
On 15 July 2016 at 04:28, Peter Chen wrote:
> On Thu, Jul 14, 2016 at 05:52:43PM +0200, Rafał Miłecki wrote:
>> On 14 July 2016 at 11:48, Peter Chen wrote:
>> > On Wed, Jul 13, 2016 at 04:40:53PM +0200, Rafał Miłecki wrote:
>> >> Thanks for your effort and looking
On 15 July 2016 at 08:22, Peter Chen 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 change any usb codes.
>
ay to specify USB ports from user space. This may change in a future.
Signed-off-by: Rafał Miłecki
---
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 pretty simple solution of
On 18 July 2016 at 04:31, Peter Chen 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
>> + given LED.
>> +
>
On 18 July 2016 at 07:40, Peter Chen wrote:
> On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
>> On 18 July 2016 at 04:31, Peter Chen wrote:
>> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>> >> +
>> >> +usbport trigg
On 18 July 2016 at 07:53, Peter Chen wrote:
> On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
>> On 18 July 2016 at 07:40, Peter Chen wrote:
>> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
>> >> On 18 July 2016 at 04:31, Peter Ch
On 20 July 2016 at 03:02, Rob Herring 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 routers
>> that have
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 wrote:
> On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
>> On 20 July 2016 at 03:02, Rob Herring wrote:
>> > On Fri, Jul 15,
From: Rafał Miłecki
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 Northstar (ARM) devices were using other
On 12 August 2016 at 11:46, Kishon Vijay Abraham I wrote:
> On Friday 12 August 2016 03:58 AM, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> Northstar is a family of SoCs used in home routers. They have USB 2.0
>> and 3.0 controllers with PHYs that need to be pr
On 29 July 2016 at 09:09, Rafał Miłecki 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 wrote:
>> On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
>
From: Rafał Miłecki
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 trigger gets its documentation
On 24 August 2016 at 11:21, Greg KH wrote:
> On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the specified USB port. This ca
On 24 August 2016 at 11:22, Greg KH 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)
>> +{
>> + struct led_classdev *led
On 24 August 2016 at 12:49, Matthias Brugger wrote:
> On 24/08/16 00:03, Rafał Miłecki wrote:
>>
>> From: Rafał Miłecki
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the specified USB port. This can can u
From: Rafał Miłecki
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 trigger gets its documentation
On 24 August 2016 at 20:48, Bjørn Mork wrote:
> Rafał Miłecki 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
>> Documentation/ABI, but it seems none of triggers have
On 24 August 2016 at 23:04, Greg KH wrote:
> On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote:
>> On 24 August 2016 at 11:22, Greg KH wrote:
>> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
>> >> +static ssize_t ports_s
From: Rafał Miłecki
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 trigger gets its documentation
On 25 August 2016 at 10:03, Jacek Anaszewski wrote:
> On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
>>
>> From: Rafał Miłecki
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the specified USB port. This c
On 25 August 2016 at 10:03, Jacek Anaszewski wrote:
> On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
>>
>> From: Rafał Miłecki
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the specified USB port. This c
On 25 August 2016 at 14:49, Greg KH 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 *usbport_data;
>> + int err;
>> +
>&
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 observed_ports
>>> #1-1
>>>
>>>
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 solution needs re
On 29 August 2016 at 10:41, Pavel Machek wrote:
> On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
>> On 29 August 2016 at 10:05, Pavel Machek wrote:
>> >> >2) Having "ports" subdir with RW files, one per each existing physical
>> >> >port
>
On 30 August 2016 at 14:05, Greg KH wrote:
> On Fri, Aug 26, 2016 at 05:38:05PM +0200, Rafał Miłecki wrote:
>> On 25 August 2016 at 14:49, Greg KH wrote:
>> > On Thu, Aug 25, 2016 at 10:03:52AM +0200, Rafał Miłecki wrote:
>> >> +static void usbport_trig_activate
On 30 August 2016 at 22:54, Alan Stern 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 (/sys/class/leds/foo/) can be controller w
On 31 August 2016 at 20:23, Alan Stern 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 ("[PATCH] LED:
>> >> add L
On 31 August 2016 at 21:00, Rafał Miłecki wrote:
> On 31 August 2016 at 20:23, Alan Stern wrote:
>> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
>>> Not really as it won't cover some pretty common use cases. Many home
>>> routers have few USB ports (2-5)
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 separated list. This scheme is co
Thanks to switching to devm_gpiod_get:
1) We don't have to pass fwnode pointer
2) We can request initial GPIO value at getting call
This was successfully tested on Netgear R6250 (BCM4708).
Signed-off-by: Rafał Miłecki
---
drivers/usb/host/bcma-hcd.c | 6 ++
1 file changed, 2 inser
On 23 March 2016 at 14:52, Lu Baolu wrote:
> On 03/23/2016 07:37 PM, Rafał Miłecki wrote:
>> Thanks to switching to devm_gpiod_get:
>> 1) We don't have to pass fwnode pointer
>> 2) We can request initial GPIO value at getting call
>> This was successfully
On 24 March 2016 at 01:02, Lu Baolu wrote:
> On 03/23/2016 11:18 PM, Rafał Miłecki wrote:
>> On 23 March 2016 at 14:52, Lu Baolu wrote:
>>> On 03/23/2016 07:37 PM, Rafał Miłecki wrote:
>>>> Thanks to switching to devm_gpiod_get:
>>>> 1) We don't hav
On 24 March 2016 at 14:58, Sergei Shtylyov
wrote:
> On 03/24/2016 08:37 AM, Rafał Miłecki wrote:
>
>>>>>> Thanks to switching to devm_gpiod_get:
>>>>>> 1) We don't have to pass fwnode pointer
>>>>>> 2) We can request initial
On 24 March 2016 at 15:31, Sergei Shtylyov
wrote:
> On 03/24/2016 05:26 PM, Rafał Miłecki wrote:
>>>>>>>> Thanks to switching to devm_gpiod_get:
>>>>>>>> 1) We don't have to pass fwnode pointer
>>>>>>>> 2) We can req
Northstar is a family of SoCs used in home routers. They have USB 2.0
and 3.0 controllers with PHYs that need to be properly initialized.
This driver provides PHY init support in a generic way and can be bound
with XHCI controller driver.
Signed-off-by: Rafał Miłecki
---
.../devicetree/bindings
On 29 March 2016 at 03:46, Florian Fainelli wrote:
> CC: bcm-kernel-feedback-list, Jon
>
> Le 28/03/2016 14:59, Rafał Miłecki a écrit :
>> +static inline struct bcm_ns_usb3 *phy_to_usb3(struct usb_phy *phy)
>> +{
>> + return container_of(phy, struct bcm_ns_usb3,
On 30 March 2016 at 12:13, Felipe Balbi wrote:
> Rafał Miłecki writes:
>> Northstar is a family of SoCs used in home routers. They have USB 2.0
>> and 3.0 controllers with PHYs that need to be properly initialized.
>> This driver provides PHY init support in a generic
On 30 March 2016 at 12:55, Felipe Balbi wrote:
> Rafał Miłecki writes:
>> [ text/plain ]
>> On 30 March 2016 at 12:13, Felipe Balbi wrote:
>>> Rafał Miłecki writes:
>>>> Northstar is a family of SoCs used in home routers. They have USB 2.0
>>>&g
On 1 April 2016 at 14:00, Rafał Miłecki wrote:
> Northstar is a family of SoCs used in home routers. They have USB 2.0
> and 3.0 controllers with PHYs that need to be properly initialized.
> This driver provides PHY init support in a generic way and can be bound
> with an EHCI contr
On 5 April 2016 at 21:34, Jon Mason wrote:
> On Wed, Mar 30, 2016 at 5:32 PM, Jon Mason wrote:
>> On Tue, Mar 29, 2016 at 10:01 AM, Rafał Miłecki wrote:
>>> Northstar is a family of SoCs used in home routers. They have USB 2.0
>>> and 3.0 controllers with PH
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 eh
Hi and thanks for your review!
On 13 April 2016 at 15:54, Kishon Vijay Abraham I wrote:
> On Monday 11 April 2016 03:13 PM, Rafał Miłecki wrote:
>> +Example:
>> + usb2-phy {
>> + compatible = "brcm,ns-usb2-phy";
>> + reg = <
On 13 April 2016 at 17:25, Alan Stern 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
>>
>> Some of debugging lines contain
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 o
On 15 April 2016 at 17:33, Alan Stern 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) CONFIG_MIPS=y, CONFIG_BCM47XX=y
>> 2) CONF
On 16 April 2016 at 17:13, Alan Stern 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 is pretty intere
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
wrote:
On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
On 20 January 2017 at 23:35, Jacek Anaszewski
wrote:
On 01/20/2017 10: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:
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
wrote:
On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
On 20
nect' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1541:15: error: expected declaration
specifiers or '...' before string constant
Add linux/phy.h to bgmac.c
Signed-off-by: Russell King
Acked-by: Rafał Miłecki
--
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
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
wrote:
On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
On 20
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
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
2013/9/19 Russell King - ARM Linux :
> This email is only being sent to the mailing lists in question, not to
> anyone personally. The list of individuals is far to great to do that.
> I'm hoping no mailing lists reject the patches based on the number of
> recipients.
Huh, I think it was enough t
1 - 100 of 136 matches
Mail list logo
