On Tue, 31 Jul 2018 08:35:26 +0200
"H. Nikolaus Schaller" wrote:
> > Am 31.07.2018 um 00:56 schrieb David Rivshin :
> >
> > On Sun, 29 Jul 2018 20:19:08 +0200
> > "H. Nikolaus Schaller" wrote:
> >
> >> Hi,
> >>
>
timer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> >>>> [0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error
> >>>> -22
> >>>>
> >>>> the probe function has to wait until omap_dm_timer_probe() in
> >>>>
ork to pass this clock to the dmtimer driver.
>
> Adam, David, can you check if this solves the issue reported at [1] ?
Thanks! Works on my AM335x board.
Patches 1 and 4:
Tested-by: David Rivshin
If I might suggest also:
Fixes: df54bfc5502a ("clk: ti: am33xx: add clkctrl clock data&qu
On Mon, 16 Jul 2018 10:37:20 +0200
Pavel Machek wrote:
> On Mon 2018-07-16 00:57:40, Tony Lindgren wrote:
> > * Pavel Machek [180716 07:16]:
> > >
> > > When all the drivers are built-in, timers are not ready and probing
> > > fails. Fix that with -EPROBE_DEFFER.
> > >
> > > Signed-off-by: P
On Fri, 6 Apr 2018 14:49:22 +0100
Daniel Thompson wrote:
> On 06/04/18 14:25, Daniel Thompson wrote:
> > On Thu, Apr 05, 2018 at 04:09:16PM -0400, David Rivshin wrote:
> >> From: David Rivshin
> >>
> >> NUMREGBYTES (which is used as the size for gdb_
From: David Rivshin
NUMREGBYTES (which is used as the size for gdb_regs[]) is incorrectly based
on DBG_MAX_REG_NUM instead of GDB_MAX_REGS. DBG_MAX_REG_NUM is the number
of total registers, while GDB_MAX_REGS is the number of 'unsigned longs'
it takes to serialize those registers
From: David Rivshin
omap_gpio_debounce() does not validate that the requested debounce
is within a range it can handle. Instead it lets the register value
wrap silently, and always returns success.
This can lead to all sorts of unexpected behavior, such as gpio_keys
asking for a too-long
7 Mar 2017 19:42:35 -0400
David Rivshin wrote:
> On Fri, 17 Mar 2017 16:43:56 -0500
> Grygorii Strashko wrote:
>
> > On 03/17/2017 03:50 PM, David Rivshin wrote:
> > > On Fri, 17 Mar 2017 13:54:28 -0500
> > > Grygorii Strashko wrote:
> > >
>
On Fri, 17 Mar 2017 19:06:47 -0500
Grygorii Strashko wrote:
> CC: Tero
Gentle ping. Any thoughts on this? Is there anything I should
investigate, or other information you'd like me to provide?
> On 03/17/2017 06:14 PM, David Rivshin wrote:
> > On Fri, 17 Mar 2017 14:43:02 -
From: David Rivshin
The gpio-matrix-keypad driver normally sets inactive columns as inputs
while scanning. This does not work for all hardware, which may require
the inactive columns to be actively driven in order to overcome any
pull-ups/downs on the columns.
Signed-off-by: David Rivshin
On Fri, 17 Mar 2017 16:43:56 -0500
Grygorii Strashko wrote:
> On 03/17/2017 03:50 PM, David Rivshin wrote:
> > On Fri, 17 Mar 2017 13:54:28 -0500
> > Grygorii Strashko wrote:
> >
> >> On 03/17/2017 12:54 PM, David Rivshin wrote:
> >>> Hi Grygorii
On Fri, 17 Mar 2017 14:43:02 -0500
Grygorii Strashko wrote:
> On 03/16/2017 07:57 PM, David Rivshin wrote:
> > From: David Rivshin
> >
> > omap2_set_gpio_debounce() assumes the debounce clock runs at 32768Hz,
> > leading to 31us granularity. In reality the debounce c
On Fri, 17 Mar 2017 13:54:28 -0500
Grygorii Strashko wrote:
> On 03/17/2017 12:54 PM, David Rivshin wrote:
> > Hi Grygorii,
> >
> > On Fri, 17 Mar 2017 11:45:56 -0500
> > Grygorii Strashko wrote:
> >
> >> On 03/16/2017 07:57 PM, David
Hi Grygorii,
On Fri, 17 Mar 2017 11:45:56 -0500
Grygorii Strashko wrote:
> On 03/16/2017 07:57 PM, David Rivshin wrote:
> > From: David Rivshin
> >
> > omap_gpio_debounce() does not validate that the requested debounce
> > is within a range it can handle. Instead
From: David Rivshin
This series fixes a couple of issues in the gpio-omap set_debounce logic.
Patches based ontop of v4.11-rc1, but apply cleanly to linux-gpio/fixes
and linux-next.
Tested on a (custom) AM335x board via gpio-keys.
(Apologies if anyone received this series twice, it seemed to
From: David Rivshin
omap2_set_gpio_debounce() assumes the debounce clock runs at 32768Hz,
leading to 31us granularity. In reality the debounce clock (which
is provided by other modules) could be at different rate, leading to
an incorrect computation of the number of debounce clock cycles for
From: David Rivshin
omap_gpio_debounce() does not validate that the requested debounce
is within a range it can handle. Instead it lets the register value
wrap silently, and always returns success.
This can lead to all sorts of unexpected behavior, such as gpio_keys
asking for a too-long
On Sat, 10 Sep 2016 15:48:28 +0200
Neil Armstrong wrote:
> Le 10/09/2016 05:17, Matthijs van Duin a écrit :
> > On Mon, Sep 05, 2016 at 11:16:38AM +0200, H. Nikolaus Schaller wrote:
> >> This helps to get 100% intensity closer to "always on".
> >>
> >> It compensates for an effect of dmtimer wh
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
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
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
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 t
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
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
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 t
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
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
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:
- Remove
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 equ
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
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
Document
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
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
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
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
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,s
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
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'.
Sig
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
58 matches
Mail list logo
