On 8 June 2017 at 18:08, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> 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
Hi Greg,
do you mind i
From: Rafał Miłecki
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
---
V2: Update to use "led-triggers"
V3: Update to use "trigger-sources"
V5:
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
that weird 3/2 number.
It's a proof of concept, it was tested & will be submitted through ARM tree if
previous patches get accepted.
V3
From: Rafał Miłecki
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 generic and not influenced by
any
From: Rafał Miłecki
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 comes with alread
From: Rafał Miłecki
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 history of thi
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
that weird 3/2 number.
It's a proof of concept, it was tested & will be submitted through ARM tree if
previous patches get accepted.
V3
From: Rafał Miłecki
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
---
V2: Update to use "led-triggers"
V3: Update to use "trigger-sources"
-
From: Rafał Miłecki
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 generic and not influenced by
any
On 29 May 2017 at 21:52, Jacek Anaszewski wrote:
> On 05/29/2017 04:01 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> 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
>
From: Rafał Miłecki
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
---
V2: Update to use "led-triggers"
V3: Update to use "trigger-sources"
-
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
that weird 3/2 number.
It's a proof of concept, it was tested & will be submitted through ARM tree if
previous patches get accepted.
V3
From: Rafał Miłecki
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 generic and not influenced by
any
From: Rafał Miłecki
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 before someome
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
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 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 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/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
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 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 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
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
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
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
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
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
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
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"
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
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
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 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
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 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
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
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
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
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 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
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 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
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 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
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 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 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 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 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 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 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 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 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
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 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
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
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 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
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 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
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 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:
>
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
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
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,
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
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 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 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.
>> +
>
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 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.
>
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
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
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:
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:
>
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 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 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 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
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
;
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
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
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 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
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
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
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
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
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 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
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 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
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 = <
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
1 - 100 of 136 matches
Mail list logo
