From: David Rivshin
If a fixed-link DT subnode is used, the phy_device was looked up so
that a PHY ID string could be constructed and passed to phy_connect().
This is not necessary, as the device_node can be passed directly to
of_phy_connect() instead. This reuses the same codepath as if the
phy-
From: David Rivshin
The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
and only one need be specified. Make this clear in the binding doc.
Also mark the phy_id property as deprecated, as phy-handle should be
used instead.
Signed-off-by: David Rivshin
---
Changes since v
From: David Rivshin
The phy-mode emac property was only being processed in the phy_id
or fixed-link cases. However if phy-handle was specified instead,
an error message would complain about the lack of phy_id or
fixed-link, and then jump past the of_get_phy_mode(). This would
result in the PHY mo
From: David Rivshin
If an emac node has a phy-handle property that points to something
which is not a phy, then a segmentation fault will occur when the
interface is brought up. This is because while phy_connect() will
return ERR_PTR() on failure, of_phy_connect() will return NULL.
The common err
From: David Rivshin
Commit 9e42f715264ff158478fa30eaed847f6e131366b ("drivers: net: cpsw: add
phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv
field. However, phy connections are per-slave, so the phy_node field should
be in cpsw_slave_data rather than cpsw_priv.
This wou
From: David Rivshin
This series fixes a number of related issues around using phy-handle
properties in cpsw emac nodes.
Patch 1 fixes a bug if more than one slave is used, and either
slave uses the phy-handle property in the devicetree.
Patch 2 fixes a NULL pointer dereference which can occur i
On Mon, 25 Apr 2016 22:12:20 +0300
Grygorii Strashko wrote:
> On 04/22/2016 06:45 PM, David Rivshin (Allworx) wrote:
> > On Fri, 22 Apr 2016 16:03:34 +0300
> > Grygorii Strashko wrote:
> >
> >> On 04/21/2016 09:26 PM, David Rivshin (Allworx) wrot
On Fri, 22 Apr 2016 16:03:34 +0300
Grygorii Strashko wrote:
> On 04/21/2016 09:26 PM, David Rivshin (Allworx) wrote:
> > From: David Rivshin
> >
> > The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> > and only one need be specified. However
From: David Rivshin
If a fixed-link DT subnode is used, the phy_device was looked up so
that a PHY ID string could be constructed and passed to phy_connect().
This is not necessary, as the device_node can be passed directly to
of_phy_connect() instead. This reuses the same codepath as if the
phy-
From: David Rivshin
The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
and only one need be specified. However if phy-handle was specified, an
error message would complain about the lack of phy_id or fixed-link.
Also, if phy-handle was specified and the subsequent of_phy_c
From: David Rivshin
Commit 9e42f715264ff158478fa30eaed847f6e131366b ("drivers: net: cpsw: add
phy-handle parsing") saved the "phy-handle" phandle into a new cpsw_priv
field. However, phy connections are per-slave, so the phy_node field should
be in cpsw_slave_data rather than cpsw_priv.
This wou
From: David Rivshin
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.
The third patch cleans up th
know.
For tonight, I guess I have no choice but to give up. I'll try again
tomorrow in hopes gmail becomes sane again.
On Wed, 20 Apr 2016 23:24:39 -0400
"David Rivshin (Allworx)" wrote:
> From: David Rivshin
>
> The first patch fixes a bug that makes dual_emac mode
From: David Rivshin
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.
The third patch cleans up th
On Tue, 19 Apr 2016 18:43:39 -0400 (EDT)
David Miller wrote:
> From: Grygorii Strashko
> Date: Tue, 19 Apr 2016 21:44:09 +0300
>
> > May be you can send revert + your patch 1 (only fix for this issue).
> >
> > Dave, Does that sound good to you?
>
> Sure.
OK, I will hopefully have that read
On Tue, 19 Apr 2016 18:44:41 +0300
Grygorii Strashko wrote:
> On 04/19/2016 06:01 PM, David Rivshin (Allworx) wrote:
> > On Tue, 19 Apr 2016 17:41:07 +0300
> > Grygorii Strashko wrote:
> >
> >> Hi,
> >>
> >> On 04/19/2016 04:56 PM, Andrew
On Tue, 19 Apr 2016 17:41:07 +0300
Grygorii Strashko wrote:
> Hi,
>
> On 04/19/2016 04:56 PM, Andrew Goodbody wrote:
> > Adding a 2nd PHY to cpsw results in a NULL pointer dereference
> > as below. Fix by maintaining a reference to each PHY node in slave
> > struct instead of a single reference
Hi Nikolaus,
I recently submitted a driver for the IS31FL32xx family of devices, so
this driver caught my eye. I have a few comments below.
On Mon, 18 Apr 2016 20:43:16 +0200
"H. Nikolaus Schaller" wrote:
> This is a driver for the Integrated Silicon Solution Inc. LED driver
> chips IS31FL3196
Jacek. And thanks also for your patience with all my
questions along the way.
>
> Thanks,
> Jacek Anaszewski
>
> On 03/08/2016 01:57 AM, David Rivshin (Allworx) wrote:
> > From: David Rivshin
> >
> > This series adds support for the ISSI IS31FL32xx family of I2C
From: David Rivshin
This adds a binding description for the is31fl3236/35/18/16 I2C LED
controllers.
Signed-off-by: David Rivshin
Acked-by: Rob Herring
---
Changes from v1:
- swapped node name and label in example
- added Rob's ack (given above fix) [1]
Changes from RFC:
- Removed max-bri
From: David Rivshin
Si-En Technology was acquired by ISSI in 2011, and it appears that
the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
Add the "si-en,sn3218" and "si-en,sn3216" compatible strings into the
IS31FL32XX driver as aliases for the issi equivalents, and update
bindi
From: David Rivshin
The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.
Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
This has been tested on the IS31FL3236 and IS31FL3216, on an AR
From: David Rivshin
ISSI is the stock ticker Integrated Silicon Solutions Inc.
Company website: http://www.issi.com
Signed-off-by: David Rivshin
Acked-by: Rob Herring
---
Changes from v1:
- added Rob's ack [1]
Changes from RFC:
none
[1] https://lkml.org/lkml/2016/3/4/961
Documentation/d
From: David Rivshin
This series adds support for the ISSI IS31FL32xx family of I2C LED
controllers. Since the IS31FL3218/3216 are actually the same devices as
the SN3218/3216, adds their compatible strings as aliases.
As requested, this series is based on the current linux-leds/for-next, minus
p
On Fri, 04 Mar 2016 16:38:01 +0100
Jacek Anaszewski wrote:
> On 03/04/2016 03:27 PM, David Rivshin (Allworx) wrote:
> > (Stefan, sorry for the duplicate, I just realized that I originally
> > replied only to you by accident).
> >
> > On Thu, 3 Mar 2016 19:13:03 +0
qually easy for me.
>
> Thanks,
> Jacek Anaszewski
>
> On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:
> > From: David Rivshin
> >
> > Si-En Technology was acquired by ISSI in 2011, and it appears that
> > the IS31FL3218/IS31FL3216 are just rebrand
On Fri, 4 Mar 2016 22:39:06 +0100
Jacek Anaszewski wrote:
> On 03/04/2016 08:02 PM, David Rivshin (Allworx) wrote:
> > On Fri, 04 Mar 2016 17:01:52 +0100
> > Jacek Anaszewski wrote:
> >
> >> On 03/04/2016 04:05 PM, David Rivshin (Allworx) wrote:
> >&
On Fri, 4 Mar 2016 22:14:27 +0100 (CET)
Stefan Wahren wrote:
> Hi David,
>
> > "David Rivshin (Allworx)" hat am 3. März 2016
> > um
> > 04:01 geschrieben:
> >
> >
> > From: David Rivshin
> >
> > Si-En Technology was acquired by
On Fri, 04 Mar 2016 17:01:52 +0100
Jacek Anaszewski wrote:
> On 03/04/2016 04:05 PM, David Rivshin (Allworx) wrote:
> > On Fri, 04 Mar 2016 08:54:02 +0100
> > Jacek Anaszewski wrote:
> >
> >> On 03/04/2016 01:45 AM, David Rivshin (Allworx) wrote:
> >&
On Fri, 04 Mar 2016 08:54:02 +0100
Jacek Anaszewski wrote:
> On 03/04/2016 01:45 AM, David Rivshin (Allworx) wrote:
> > On Thu, 03 Mar 2016 15:51:32 +0100
> > Jacek Anaszewski wrote:
> >
> >> Hi David,
> >>
> >> Thanks for the update. Two remar
(Stefan, sorry for the duplicate, I just realized that I originally
replied only to you by accident).
On Thu, 3 Mar 2016 19:13:03 +0100 (CET)
Stefan Wahren wrote:
> Hi David,
>
> i will test the driver on weekend. Some comments below
Great, thanks very much.
> > "Da
On Thu, 03 Mar 2016 15:51:32 +0100
Jacek Anaszewski wrote:
> Hi David,
>
> Thanks for the update. Two remarks in the code.
>
> On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:
> > From: David Rivshin
> >
> > The IS31FL32xx family of LED controll
On Thu, 3 Mar 2016 07:52:51 -0600
Rob Herring wrote:
> On Wed, Mar 2, 2016 at 3:35 PM, David Rivshin (Allworx)
> wrote:
> > From: David Rivshin
> >
> > The of_property_{read,count,match}_string* family of functions never
> > modify the struct device_node pointer
From: David Rivshin
This adds a binding description for the is31fl3236/35/18/16 I2C LED
controllers.
Signed-off-by: David Rivshin
---
Rob,
I went with the 1-based 'reg' property here. I inferred that that
would be your preference based on the previous thread [1]. Let me
know if that's not the
From: David Rivshin
The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.
Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
This has been tested on the IS31FL3236 and IS31FL3216, on an AR
From: David Rivshin
ISSI is the stock ticker Integrated Silicon Solutions Inc.
Company website: http://www.issi.com
Signed-off-by: David Rivshin
---
Changes from RFC:
none
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation
From: David Rivshin
Si-En Technology was acquired by ISSI in 2011, and it appears that
the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
As the IS31FL32XX driver already handles the *3218 devices, there
is no longer a need for the dedicated SN3218 driver.
Add the "sn,sn3218" an
From: David Rivshin
This series adds support for the ISSI IS31FL32xx family of I2C LED
controllers. Since the IS31FL3218 is actually the same device as the
SN3218, the dedicated leds-sn3218 driver is removed and the compatible
string is folded into this driver.
Changes from RFC [1]:
- Removed m
From: David Rivshin
The of_property_{read,count,match}_string* family of functions never
modify the struct device_node pointer that is passed in, so there is no
reason for it to be non-const. Equivalent functions for all other types
already take a 'const struct device_node *np'.
Signed-off-by: D
On Fri, 18 Dec 2015 21:01:57 +0100
Nicholas Mc Guire wrote:
> This is an API consolidation only. The use of kmalloc + memset to 0
> is equivalent to kzalloc.
>
> Signed-off-by: Nicholas Mc Guire
> ---
>
> Found by coccinelle script (relaxed version of
> scripts/coccinelle/api/alloc/kzalloc-sim
40 matches
Mail list logo
