On Thu, 26 Sep 2019, Schmauss, Erik wrote:
-Original Message-
From: linux-acpi-ow...@vger.kernel.org
On Behalf Of Shevchenko, Andriy
Sent: Thursday, September 26, 2019 9:35 AM
To: Schmauss, Erik
Cc: Nikolaus Voss ; Rafael J. Wysocki
; Moore, Robert ; Len Brown
; Jacek Anaszewski
Hi Erik,
On Thu, 26 Sep 2019, Schmauss, Erik wrote:
-Original Message-
From: Nikolaus Voss
Sent: Thursday, September 12, 2019 1:08 AM
To: Shevchenko, Andriy ; Schmauss, Erik
; Rafael J. Wysocki ; Moore,
Robert
Cc: Len Brown ; Jacek Anaszewski
; Pavel Machek ; Dan Murphy
; linux-a
On Tue, 24 Sep 2019, Andy Shevchenko wrote:
On Mon, Sep 23, 2019 at 11:47:01AM +0200, Nikolaus Voss wrote:
For unloading an ACPI table, it is necessary to provide the
index of the table. The method intended for dynamically
loading or hotplug addition of tables, acpi_load_table(),
does not
On Tue, 24 Sep 2019, Shevchenko, Andriy wrote:
On Tue, Sep 24, 2019 at 03:07:34PM +0300, Shevchenko, Andriy wrote:
On Mon, Sep 23, 2019 at 11:47:01AM +0200, Nikolaus Voss wrote:
For unloading an ACPI table, it is necessary to provide the
index of the table. The method intended for dynamically
lear favorite,
but I'm tending to Rafael's solution my favorite being the API change.
Niko
-Original Message-
From: Nikolaus Voss
Sent: Monday, September 23, 2019 2:05 AM
To: Moore, Robert
Cc: Ferry Toth ; Shevchenko, Andriy ; Schmauss, Erik
; Rafael J. Wysocki ; Len Brown ;
loads")
Signed-off-by: Nikolaus Voss
---
drivers/acpi/acpi_configfs.c | 2 +-
drivers/acpi/acpica/tbxfload.c | 43 ++
include/acpi/acpixf.h | 6 +
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_configfs.c b/dr
On Thu, 19 Sep 2019, Rafael J. Wysocki wrote:
On Thursday, September 12, 2019 10:07:42 AM CEST Nikolaus Voss wrote:
For unloading an ACPI table, it is necessary to provide the
index of the table. The method intended for dynamically
loading or hotplug addition of tables, acpi_load_table
On Thu, 19 Sep 2019, Moore, Robert wrote:
-Original Message-
From: Nikolaus Voss [mailto:n...@vosn.de]
Sent: Wednesday, September 18, 2019 7:32 AM
To: Moore, Robert
Cc: Ferry Toth ; Shevchenko, Andriy ; Schmauss, Erik
; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski
; Pavel Machek
On Wed, 18 Sep 2019, Moore, Robert wrote:
-Original Message-
From: Nikolaus Voss [mailto:n...@vosn.de]
Sent: Monday, September 16, 2019 2:47 AM
To: Moore, Robert
Cc: Ferry Toth ; Shevchenko, Andriy ; Schmauss, Erik
; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski
; Pavel Machek
On Fri, 13 Sep 2019, Moore, Robert wrote:
-Original Message-
From: Ferry Toth [mailto:fnt...@gmail.com]
Sent: Friday, September 13, 2019 9:48 AM
To: Shevchenko, Andriy ; Moore, Robert
Cc: Nikolaus Voss ; Schmauss, Erik ; Rafael J. Wysocki
; Len Brown ; Jacek Anaszewski ; Pavel
Bob,
On Thu, 12 Sep 2019, Moore, Robert wrote:
The ability to unload an ACPI table (especially AML tables such as
SSDTs) is in the process of being deprecated in ACPICA -- since it is
also deprecated in the current ACPI specification. This is being done
because of the difficulty of deleting th
function of acpi_configfs.
Reported-by: Andy Shevchenko
Fixes: d06c47e3dd07f ("ACPI: configfs: Resolve objects on host-directed table
loads")
Signed-off-by: Nikolaus Voss
---
drivers/acpi/acpi_configfs.c | 2 +-
drivers/acpi/acpica/dbfileio.c | 2 +-
drivers/acpi/acpica/tbxf
On Fri, 6 Sep 2019, Shevchenko, Andriy wrote:
On Wed, Sep 04, 2019 at 09:20:03AM +0200, Nikolaus Voss wrote:
On Fri, 30 Aug 2019, Shevchenko, Andriy wrote:
On Fri, Aug 16, 2019 at 01:57:26PM +0200, Nikolaus Voss wrote:
On Wed, 14 Aug 2019, Schmauss, Erik wrote:
-Original Message
On Wed, 3 Jul 2019, Andrew F. Davis wrote:
On 7/2/19 6:12 AM, Nikolaus Voss wrote:
On Mon, 1 Jul 2019, Andrew F. Davis wrote:
On 7/1/19 11:35 AM, Nikolaus Voss wrote:
On Mon, 1 Jul 2019, Andrew F. Davis wrote:
On 7/1/19 9:42 AM, Nikolaus Voss wrote:
Replace enum tas572x_type with struct
On Wed, 3 Jul 2019, Greg Kroah-Hartman wrote:
On Fri, Jun 28, 2019 at 12:10:41PM +0200, Nikolaus Voss wrote:
On Fri, 28 Jun 2019, Heikki Krogerus wrote:
On Fri, Jun 28, 2019 at 11:01:08AM +0200, Nikolaus Voss wrote:
Portinfo bit field is 3 bits wide, not 2 bits. This led to
a wrong driver
On Mon, 1 Jul 2019, Andrew F. Davis wrote:
On 7/1/19 11:35 AM, Nikolaus Voss wrote:
On Mon, 1 Jul 2019, Andrew F. Davis wrote:
On 7/1/19 9:42 AM, Nikolaus Voss wrote:
Replace enum tas572x_type with struct tas5720_variant which aggregates
variant specific stuff and can be directly referenced
On Mon, 1 Jul 2019, Andrew F. Davis wrote:
On 7/1/19 9:42 AM, Nikolaus Voss wrote:
Replace enum tas572x_type with struct tas5720_variant which aggregates
variant specific stuff and can be directly referenced from an id table.
Signed-off-by: Nikolaus Voss
---
sound/soc/codecs/tas5720.c | 98
Add ACPI IDs for tas5720 and tas5722 and use device match API
to determine the variant.
Signed-off-by: Nikolaus Voss
---
sound/soc/codecs/tas5720.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index
Replace enum tas572x_type with struct tas5720_variant which aggregates
variant specific stuff and can be directly referenced from an id table.
Signed-off-by: Nikolaus Voss
---
sound/soc/codecs/tas5720.c | 98 +-
1 file changed, 33 insertions(+), 65 deletions
suggested by Mark Brown and Andrew F. Davis.
- don't integrate variant data into variant struct but reference it
(suggested by Andrew F. Davis).
Nikolaus Voss (2):
ASoC: tas5720.c: cleanup variant management
ASoC: tas5720.c: add ACPI enumeration support
sound/soc/codecs/tas5720.c
On Fri, 28 Jun 2019, Andrew F. Davis wrote:
On 6/28/19 8:34 AM, Nikolaus Voss wrote:
Add support for ACPI enumeration for tas5720 and tas5722.
Use device_match API to unify access to driver data for DT and ACPI.
Aggregate variant stuff into its own struct and directly reference
it in variant
On Fri, 28 Jun 2019, Mark Brown wrote:
On Fri, Jun 28, 2019 at 02:34:16PM +0200, Nikolaus Voss wrote:
Add support for ACPI enumeration for tas5720 and tas5722.
Use device_match API to unify access to driver data for DT and ACPI.
Aggregate variant stuff into its own struct and directly reference
Add support for ACPI enumeration for tas5720 and tas5722.
Use device_match API to unify access to driver data for DT and ACPI.
Aggregate variant stuff into its own struct and directly reference
it in variant data for i2c/of/acpi_device_id.
Signed-off-by: Nikolaus Voss
---
sound/soc/codecs
On Fri, 28 Jun 2019, Heikki Krogerus wrote:
On Fri, Jun 28, 2019 at 11:01:08AM +0200, Nikolaus Voss wrote:
Portinfo bit field is 3 bits wide, not 2 bits. This led to
a wrong driver configuration for some tps6598x configurations.
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery
controllers")
Signed-off-by: Nikolaus Voss
---
drivers/usb/typec/tps6598x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
ind
Portinfo bit field is 3 bits wide, not 2 bits. This led to
a wrong driver configuration for some tps6598x configurations.
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery
controllers")
Signed-off-by: Nikolaus Voss
---
drivers/usb/typec/tps6598x.c | 2
this enforces the constness
of the pointer to propagate to tps6598x_block_write(), so add
the const qualifier there to avoid the warning.
Signed-off-by: Nikolaus Voss
---
drivers/usb/typec/tps6598x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/typec/tps65
On Wed, 19 Jun 2019, Moore, Robert wrote:
-Original Message-
From: Nikolaus Voss [mailto:n...@vosn.de]
Sent: Wednesday, June 19, 2019 2:31 AM
To: Moore, Robert
Cc: Rafael J. Wysocki ; Rafael J. Wysocki
; Len Brown ; Schmauss, Erik
; Jacek Anaszewski
; Pavel Machek ; Dan Murphy
Hi Bob,
On Tue, 18 Jun 2019, Moore, Robert wrote:
-Original Message-
From: Moore, Robert
Sent: Tuesday, June 18, 2019 1:25 PM
To: 'Nikolaus Voss'
Cc: 'Rafael J. Wysocki' ; 'Rafael J. Wysocki'
; 'Len Brown' ; Schmauss, Erik
; 'Jac
On Mon, 17 Jun 2019, Moore, Robert wrote:
-Original Message-
From: Nikolaus Voss [mailto:n...@vosn.de]
Sent: Sunday, June 16, 2019 11:24 PM
To: Moore, Robert
Cc: Rafael J. Wysocki ; Rafael J. Wysocki
; Len Brown ; Schmauss, Erik
; Jacek Anaszewski
; Pavel Machek ; Dan Murphy
; Thierry
Bob,
On Fri, 14 Jun 2019, Moore, Robert wrote:
-Original Message-
From: Nikolaus Voss [mailto:n...@vosn.de]
Sent: Friday, June 14, 2019 2:26 AM
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki ; Len Brown ; Moore, Robert ; Schmauss, Erik
; Jacek Anaszewski ; Pavel Machek ; Dan Murphy
Hi Rafael,
On Fri, 14 Jun 2019, Rafael J. Wysocki wrote:
On Wed, Jun 12, 2019 at 10:36 AM Nikolaus Voss
wrote:
If an ACPI SSDT overlay is loaded after built-in tables
have been loaded e.g. via configfs or efivar_ssdt_load()
it is necessary to rewalk the namespace to resolve
references
ate. The firmware-node framework could be used
to unify both paths in a future patch.
To support leds-pwm driver, an additional method devm_fwnode_pwm_get()
which supports both ACPI and DT configuration is exported.
Signed-off-by: Nikolaus Voss
---
drivers/pwm/core.c | 113
{
Package () {"label", "alarm-led"},
Package () {"pwms", Package ()
{\_SB_.PCI0.PWM, 0, 60, 0}},
Package () {"linux,def
ries makes leds-pwm use the ACPI-enabled
PWM framework.
v2:
- fixes by Pavel Machek and Dan Murphy
Nikolaus Voss (3):
ACPI: Resolve objects on host-directed table loads
PWM framework: add support referencing PWMs from ACPI
leds-pwm.c: support ACPI via firmware-node framework
drivers/acpi/
load use the same method as efivar_ssdt_load().
Signed-off-by: Nikolaus Voss
---
drivers/acpi/acpi_configfs.c | 6 +-
drivers/acpi/acpica/tbxfload.c | 11 +++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
On Thu, 21 Feb 2019, Heikki Krogerus wrote:
On Wed, Feb 20, 2019 at 04:11:38PM +0100, Nikolaus Voss wrote:
From: Nikolaus Voss
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read
Hi Guenther,
On Wed, 20 Feb 2019, Guenter Roeck wrote:
On 2/20/19 7:11 AM, Nikolaus Voss wrote:
From: Nikolaus Voss
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes
Hi Greg,
On Wed, 20 Feb 2019, Greg Kroah-Hartman wrote:
On Wed, Feb 20, 2019 at 04:22:00PM +0100, Nikolaus Voss wrote:
v2: fix tps6598x_exec_cmd also
---
drivers/usb/typec/tps6598x.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/usb
On Wed, 20 Feb 2019, Greg Kroah-Hartman wrote:
On Wed, Feb 20, 2019 at 01:57:30PM +0100, Nikolaus Voss wrote:
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes
On Wed, 20 Feb 2019, Guenter Roeck wrote:
On 2/20/19 4:57 AM, Nikolaus Voss wrote:
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes) correctly also exists
with writes
From: Nikolaus Voss
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes) correctly also exists
with writes.
As workaround, this patch adds a block write function the same
On Wed, 20 Feb 2019, Heikki Krogerus wrote:
On Wed, Feb 20, 2019 at 04:14:23PM +0200, Heikki Krogerus wrote:
On Wed, Feb 20, 2019 at 02:38:47PM +0100, Nikolaus Voss wrote:
On Wed, 20 Feb 2019, Heikki Krogerus wrote:
On Wed, Feb 20, 2019 at 01:57:30PM +0100, Nikolaus Voss wrote:
Commit
On Wed, 20 Feb 2019, Heikki Krogerus wrote:
On Wed, Feb 20, 2019 at 01:57:30PM +0100, Nikolaus Voss wrote:
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes) correctly
a block read function.
Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately with
plain-I2C adapters")
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery
controllers")
Signed-off-by: Nikolaus Voss
---
v2: fix tps6598x_exec_cmd a
Hi,
On Wed, 20 Feb 2019, Heikki Krogerus wrote:
Hi,
On Mon, Sep 10, 2018 at 07:05:01AM +0200, Nikolaus Voss wrote:
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes
a block read function.
Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately with
plain-I2C adapters")
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery
controllers")
Signed-off-by: Nikolaus Voss
---
drivers/usb/t
Make platform data optional and add DT id table.
Switch to dynamically mapped GPIOs and IRQs if not provided
via platform data.
Signed-off-by: Nikolaus Voss
---
drivers/gpio/gpio-adp5588.c | 151
1 file changed, 68 insertions(+), 83 deletions(-)
diff --git
interrupts for both edges and to generate only one
interrupt per state change.
Thus it is possible to chain the gpio-keys driver for some GPIOs.
Signed-off-by: Nikolaus Voss
---
drivers/gpio/gpio-adp5588.c | 85 ++---
1 file changed, 32 insertions(+), 53 deletions
Hi Markus,
On Thu, 27 Aug 2015, Markus Pargmann wrote:
This allows to read/write up to 32 bytes of data and is to be prefered
if supported before the register read/write smbus support.
Signed-off-by: Markus Pargmann
---
drivers/base/regmap/regmap-i2c.c | 49
A/B rootfs partition scheme for interruptible firmware updates
(i.e. rootfsA/ rootfsB).
The partition label can be queried with the blkid command.
Signed-off-by: Nikolaus Voss
---
init/do_mounts.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/init
On Mon, 9 Jul 2018, Rafael J. Wysocki wrote:
On Wednesday, July 4, 2018 4:40:34 PM CEST Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 9:09 AM, Nikolaus Voss wrote:
When using ACPI with ACPI_DT_NAMESPACE_HID/ PRP0001 HID and referring to
of_device_id table "compatible" strings
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 9:09 AM, Nikolaus Voss wrote:
When using ACPI with ACPI_DT_NAMESPACE_HID/ PRP0001 HID and referring to
of_device_id table "compatible" strings in DSD, a pointer to the
corresponding DT table entry should be returned in
Andy Shevchenko
- removed syncing DT/I2C table names as Jonathan Cameron pointed out
this would be an ABI change
- converting from probe() to probe_new() is moved into a separate
patch (as suggested by Jonathan Cameron)
Nikolaus Voss (2):
IIO: st_accel_i2c.c: Simplify access to driver data
struct i2c_device_id argument of probe() is not used, so use probe_new()
instead.
Reviewed-by: Andy Shevchenko
Signed-off-by: Nikolaus Voss
---
drivers/iio/accel/st_accel_i2c.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers
Shevchenko
Signed-off-by: Nikolaus Voss
---
drivers/iio/accel/st_accel_i2c.c | 59 ++--
1 file changed, 25 insertions(+), 34 deletions(-)
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index 056dddb27236..d02298f0256c 100644
--- a
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 8:41 AM, Nikolaus Voss
wrote:
Use device_get_match_data API to simplify access to driver data.
Let acpi_device_id table entries point to the same driver data as
of_device_id table entries and uniquify access to driver data by
struct i2c_device_id argument of probe() is not used, so use probe_new()
instead.
Signed-off-by: Nikolaus Voss
---
drivers/iio/accel/st_accel_i2c.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index
: Nikolaus Voss
---
drivers/iio/accel/st_accel_i2c.c | 56 ++--
1 file changed, 24 insertions(+), 32 deletions(-)
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index 6bdec8c451e0..c6e08c834f11 100644
--- a/drivers/iio/accel/st_accel_i2c.c
meron pointed out
this would be an ABI change
- converting from probe() to probe_new() is moved into a separate
patch (as suggested by Jonathan Cameron)
Nikolaus Voss (2):
IIO: st_accel_i2c.c: Simplify access to driver data
IIO: st_accel_i2c.c: Use probe_new() instead of probe()
driver
On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
On Wed, Jul 4, 2018 at 2:31 PM, Nikolaus Voss
wrote:
On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
On Wed, Jul 4, 2018 at 1:46 PM, Nikolaus Voss
wrote:
[snip]
But this discussion isn't really related to your patch. I thi
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 9:09 AM, Nikolaus Voss
wrote:
Thanks for the patch, now I completely got it and agree on approach.
Few comments below.
When using ACPI with ACPI_DT_NAMESPACE_HID/ PRP0001 HID and referring to
of_device_id table "compa
On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
On Wed, Jul 4, 2018 at 1:46 PM, Nikolaus Voss
wrote:
[snip]
But this discussion isn't really related to your patch. I think is
correct but just said that (b) wasn't a justification to leave the I2C
table, points (a) and (c) are
Hi Javier,
On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
Hi Nikolaus,
On Wed, Jul 4, 2018 at 1:15 PM, Nikolaus Voss
wrote:
On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
[snip]
I think Nikolaus is correct, assuming that the driver can be used on
legacy
platforms that register
On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
Hi Andy,
On 07/04/2018 12:19 PM, Andy Shevchenko wrote:
Summon Javier to the discussion.
For my opinion he is an expert in this topic.
I wouldn't call myself an expert in anything to be honest :)
[snip]
The table is not used by the dri
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 1:17 PM, Nikolaus Voss
wrote:
On Wed, 4 Jul 2018, Sudeep Holla wrote:
On 04/07/18 10:32, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 6:37 AM, Srinath Mannam
wrote:
+1 on NACK for this and anything else that abuse PRP0001
When using ACPI with ACPI_DT_NAMESPACE_HID/ PRP0001 HID and referring to
of_device_id table "compatible" strings in DSD, a pointer to the
corresponding DT table entry should be returned instead of a null
pointer. An acpi_device_id match still takes precedence.
Signed-off-by: Nik
On Wed, 4 Jul 2018, Sudeep Holla wrote:
On 04/07/18 10:32, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 6:37 AM, Srinath Mannam
wrote:
Hi Sudeep, Andy,
Yes, This patch is to get of_device_id and then fetch data pointer.
To add ACPI support in multiple drivers which are device-tree based
and
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 12:09 PM, Nikolaus Voss
wrote:
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 9:37 AM, Nikolaus Voss
wrote:
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 9:06 AM, Nikolaus Voss
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 9:37 AM, Nikolaus Voss
wrote:
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 9:06 AM, Nikolaus Voss
wrote:
struct i2c_device_id argument of probe() is not used, so use probe_new()
instead.
This makes
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 8:41 AM, Nikolaus Voss
wrote:
Use device_get_match_data API to simplify access to driver data.
..._data()
But. You actually don't use it below.
It is used, see below.
Let acpi_device_id table entries point to the
On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Tue, Jul 3, 2018 at 9:06 AM, Nikolaus Voss
wrote:
struct i2c_device_id argument of probe() is not used, so use probe_new()
instead.
This makes...
MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
...this table obsolete IIUC. At least that's
On Mon, 2 Jul 2018, Andy Shevchenko wrote:
On Mon, Jul 2, 2018 at 9:41 AM, Nikolaus Voss
wrote:
On Fri, 29 Jun 2018, Andy Shevchenko wrote:
I'm not sure I understand how ->probe_new() is supposed to work
against i2c_id_table, but I don't care for legacy platform data
anyway.
struct i2c_device_id argument of probe() is not used, so use probe_new()
instead.
Signed-off-by: Nikolaus Voss
---
drivers/iio/accel/st_accel_i2c.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index
Use device_get_match_data API to simplify access to driver data.
Let acpi_device_id table entries point to the same driver data as
of_device_id table entries and uniquify access to driver data by using
device_get_match_data API.
Signed-off-by: Nikolaus Voss
---
drivers/iio/accel/st_accel_i2c.c
nto a separate
patch (as suggested by Jonathan Cameron)
Nikolaus Voss (2):
IIO: st_accel_i2c.c: Simplify access to driver data
IIO: st_accel_i2c.c: Use probe_new() instead of probe()
drivers/iio/accel/st_accel_i2c.c | 26 ++
1 file changed, 10 insertions(+), 16 dele
On Sat, 30 Jun 2018, Jonathan Cameron wrote:
On Fri, 29 Jun 2018 10:45:54 +0200
Nikolaus Voss wrote:
I2C device ID table strings should really match the DT compatible
strings (without the manufacturer prefix) to avoid confusion. This is
especially reasonable when using ACPI PRP0001 HID /DT
On Sat, 30 Jun 2018, Jonathan Cameron wrote:
On Fri, 29 Jun 2018 10:10:10 +0200
Nikolaus Voss wrote:
Currently, the driver bails out if not explicitly referred to in
DT or ACPI tables. This prevents fallback mechanisms from coming
into effect, e.g. I2C device ID table match via DT or ACPI
On Fri, 29 Jun 2018, Andy Shevchenko wrote:
I'm not sure I understand how ->probe_new() is supposed to work
against i2c_id_table, but I don't care for legacy platform data
anyway.
What I would like to point to is device_get_match_data() API which
should simplify / unify the case how you get dri
manufacturer prefix stripped off) by the ACPI
layer and thus as i2c_board_info->type by the I2C layer.
Signed-off-by: Nikolaus Voss
---
drivers/iio/accel/st_accel.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/accel/st_accel.
as a corresponding
DT entry. As far as I can see, the old I2C table strings aren't used
in mainline, so renaming them should be safe.
Nikolaus Voss (3):
IIO: st_accel_i2c.c: Use fallback if DT/ACPI enum failed
IIO: st_sensors_i2c.c: Don't print error on failed ACPI match
IIO: st_a
If there is a ACPI node for a i2c device but HID/CID doesn't match, there
could still be a ACPI_DT_NAMESPACE_HID / PRP0001 HID entry which is
matched against the i2c device ID table, so don't print an error
message.
Signed-off-by: Nikolaus Voss
---
drivers/iio/common/st_sensors/st_sen
-off-by: Nikolaus Voss
---
drivers/iio/accel/st_accel_i2c.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index 6bdec8c451e0..e360da407027 100644
--- a/drivers/iio/accel/st_accel_i2c.c
Hi Thierry,
On Thu, 25 Sep 2014, Thierry Reding wrote:
Please Cc the linux-...@vger.kernel.org mailing list for PWM-related
patches in the future.
ok, I ran get_maintainer.pl on an old kernel...
Also a couple more comments:
In the patch description: "pwm frequency" should be "PWM frequency"
the calculation more efficient.
Signed-off-by: Nikolaus Voss
---
drivers/pwm/pwm-atmel.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 6e700a5..ff17b5d 100644
--- a/drivers/pwm/pwm-atmel.c
The old driver used con_id clock entries. Convert to use dev_id
for clock lookup via standard method.
Signed-off-by: Nikolaus Voss
---
arch/arm/mach-at91/at91rm9200.c |1 +
arch/arm/mach-at91/at91sam9260.c |1 +
arch/arm/mach-at91/at91sam9261.c |1 +
arch/arm/mach-at91/at91sam9263
Signed-off-by: Nikolaus Voss
---
arch/arm/mach-at91/include/mach/at91_twi.h | 68 --
drivers/i2c/busses/Makefile|1 -
drivers/i2c/busses/i2c-at91.c | 314
3 files changed, 383 deletions(-)
delete mode 100644 arch/arm/mach-at91
)
Signed-off-by: Nikolaus Voss
Reviewed-by: Felipe Balbi
Tested-by: Hubert Feurstein
v12: - corrected wrong id_entry on sam9261 twi gpio pdev
v11: - fix for flags persistency suggested by Carsten Behling
- calc_twi_clock fix for sam9261 by Ludovic Desroches
v10: - applied fix for RXRDY
The G45 datasheets explicitly states that setting the open drain property
on peripheral function gpios is not allowed. (How about other A91 chips?)
Signed-off-by: Nikolaus Voss
---
arch/arm/mach-at91/at91sam9g45_devices.c |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach
does not rely on more than one repeated start.
Changes since v11:
- corrected wrong id_entry on sam9261 twi gpio pdev
Nikolaus Voss (4):
drivers/i2c/busses/i2c-at91.c: remove old polling driver
Replace clk_lookup.con_id with clk_lookup.dev_id entries for twi clk
drivers/i2c/busses/i2c-at91.c
The old driver used con_id clock entries. Convert to use dev_id
for clock lookup via standard method.
Signed-off-by: Nikolaus Voss
---
arch/arm/mach-at91/at91rm9200.c |1 +
arch/arm/mach-at91/at91sam9260.c |1 +
arch/arm/mach-at91/at91sam9261.c |1 +
arch/arm/mach-at91/at91sam9263
does not rely on more than one repeated start.
Changes since v10:
- fix for flags persistency suggested and tested by Carsten Behling
- clk_lookup.dev_id entries for at91sam9x5
- calc_twi_clock fix for sam9261 by Ludovic Desroches
Nikolaus Voss (4):
drivers/i2c/busses/i2c-at91.c: remove old
)
Signed-off-by: Nikolaus Voss
Reviewed-by: Felipe Balbi
Tested-by: Hubert Feurstein
v11: - fix for flags persistency suggested by Carsten Behling
- calc_twi_clock fix for sam9261 by Ludovic Desroches
v10: - applied fix for RXRDY overrun bug submitted by Hubert Feurstein
- applied fix
Signed-off-by: Nikolaus Voss
---
arch/arm/mach-at91/include/mach/at91_twi.h | 68 --
drivers/i2c/busses/Makefile|1 -
drivers/i2c/busses/i2c-at91.c | 314
3 files changed, 383 deletions(-)
delete mode 100644 arch/arm/mach-at91
The G45 datasheets explicitly states that setting the open drain property
on peripheral function gpios is not allowed. (How about other A91 chips?)
Signed-off-by: Nikolaus Voss
---
arch/arm/mach-at91/at91sam9g45_devices.c |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach
95 matches
Mail list logo
