Re: [PATCH] dt-bindings: i2c: eeprom: Add Renesas R1EX24128
2017-11-27 19:05 GMT+01:00 Wolfram Sang : > Bartosz, > >> Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 +- > > I just noticed this file is missing in the AT24 entry in MAINTAINERS. I > wanted to prepare a patch for that but then I was wondering if the name > "eeprom.txt" is really suitable? I have doubts. Would "at24.txt" be a > better name maybe? Rob? > > Kind regards, > >Wolfram > Yes, it definitely should be called at24.txt - especially that we have the legacy eeprom module in drivers/misc/eeprom/eeprom.c which has nothing to do with the bindings in eeprom.txt. Acked-in-advance-by: Bartosz Golaszewski Thanks, Bartosz
Re: [PATCH v2 5/5] dt-bindings: at24: add bindings for Rohm BR24T01
2018-01-30 11:44 GMT+01:00 Wolfram Sang : > On Mon, Jan 29, 2018 at 04:45:48PM +0100, Ulrich Hecht wrote: >> Both manufacturer and name variant. >> >> Signed-off-by: Ulrich Hecht > > Reviewed-by: Wolfram Sang > Acked-by: Bartosz Golaszewski
Re: [PATCH v2 5/5] dt-bindings: at24: add bindings for Rohm BR24T01
2018-02-05 7:07 GMT+01:00 Rob Herring : > On Mon, Jan 29, 2018 at 04:45:48PM +0100, Ulrich Hecht wrote: >> Both manufacturer and name variant. >> >> Signed-off-by: Ulrich Hecht >> --- >> Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++ >> 1 file changed, 2 insertions(+) > > Reviewed-by: Rob Herring > >> >> diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt >> b/Documentation/devicetree/bindings/eeprom/at24.txt >> index 1812c84..dd29937 100644 >> --- a/Documentation/devicetree/bindings/eeprom/at24.txt >> +++ b/Documentation/devicetree/bindings/eeprom/at24.txt >> @@ -40,6 +40,7 @@ Required properties: >> "microchip", >> "ramtron", >> "renesas", >> +"rohm", > > This is going to comflict with a patch sorting these IIRC. So they > should go thru the same tree. > >> "nxp", >> "st", >> >> @@ -47,6 +48,7 @@ Required properties: >> variants of the above. Known such exceptions are listed >> below: >> >> "renesas,r1ex24002" - the fallback is "atmel,24c02" >> +"rohm,br24t01" - the fallback is "atmel,24c01" >> >>- reg: The I2C address of the EEPROM. >> >> -- >> 2.7.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html AT24 patches go through Wolfram's tree, but since he already sent his PR for 4.16, I can pick them up for 4.17 (except for Peter's sorting patch which should go in after 4.16-rc1). Thanks, Bartosz
Re: [PATCH v2 5/5] dt-bindings: at24: add bindings for Rohm BR24T01
2018-01-29 16:45 GMT+01:00 Ulrich Hecht : > Both manufacturer and name variant. > > Signed-off-by: Ulrich Hecht > --- > Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt > b/Documentation/devicetree/bindings/eeprom/at24.txt > index 1812c84..dd29937 100644 > --- a/Documentation/devicetree/bindings/eeprom/at24.txt > +++ b/Documentation/devicetree/bindings/eeprom/at24.txt > @@ -40,6 +40,7 @@ Required properties: > "microchip", > "ramtron", > "renesas", > +"rohm", > "nxp", > "st", > > @@ -47,6 +48,7 @@ Required properties: > variants of the above. Known such exceptions are listed > below: > > "renesas,r1ex24002" - the fallback is "atmel,24c02" > +"rohm,br24t01" - the fallback is "atmel,24c01" > >- reg: The I2C address of the EEPROM. > > -- > 2.7.4 > Applied to for-next, thanks. Bart
Re: [PATCH] Documentation: gpio: driver: fix wire name for I2C
czw., 17 sty 2019 o 11:24 Geert Uytterhoeven napisał(a): > > On Thu, Jan 17, 2019 at 11:14 AM Wolfram Sang > wrote: > > Typo: the data line is called "SDA" not "SCA". > > > > Signed-off-by: Wolfram Sang > > Reviewed-by: Geert Uytterhoeven > Applied to for-next, thanks! Bart
Re: [PATCH] gpio: pca953x: Add wake-up support
wt., 12 lut 2019 o 15:17 Geert Uytterhoeven
napisał(a):
>
> Implement the irq_set_wake() method in the (optional) irq_chip of the
> GPIO expander, and propagate wake-up settings to the upstream interrupt
> controller. This allows GPIOs connected to a PCA953X GPIO expander to
> serve as wake-up sources.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Tested with a PCA9654 and gpio-keys on an R-Car Ebisu-4D board.
> ---
> drivers/gpio/gpio-pca953x.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index de52f63863dbe59b..8dfb8e326b9d12ca 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -151,6 +151,7 @@ struct pca953x_chip {
> u8 irq_trig_raise[MAX_BANK];
> u8 irq_trig_fall[MAX_BANK];
> struct irq_chip irq_chip;
> + unsigned int irq_parent;
> #endif
>
> struct i2c_client *client;
> @@ -513,6 +514,24 @@ static void pca953x_irq_unmask(struct irq_data *d)
> chip->irq_mask[d->hwirq / BANK_SZ] |= 1 << (d->hwirq % BANK_SZ);
> }
>
> +static int pca953x_irq_set_wake(struct irq_data *d, unsigned int on)
> +{
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> + struct pca953x_chip *chip = gpiochip_get_data(gc);
> + int error = 0;
> +
> + if (chip->irq_parent) {
> + error = irq_set_irq_wake(chip->irq_parent, on);
> + if (error) {
> + dev_dbg(&chip->client->dev,
> + "irq %u doesn't support irq_set_wake\n",
> + chip->irq_parent);
> + chip->irq_parent = 0;
> + }
> + }
> + return error;
> +}
> +
> static void pca953x_irq_bus_lock(struct irq_data *d)
> {
> struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> @@ -732,6 +751,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
> irq_chip->name = dev_name(&chip->client->dev);
> irq_chip->irq_mask = pca953x_irq_mask;
> irq_chip->irq_unmask = pca953x_irq_unmask;
> + irq_chip->irq_set_wake = pca953x_irq_set_wake;
Is it possible to assign this callback conditionally depending on
client->irq and avoid the if (chip->irq_parent) in
pca953x_irq_set_wake()?
Bart
> irq_chip->irq_bus_lock = pca953x_irq_bus_lock;
> irq_chip->irq_bus_sync_unlock = pca953x_irq_bus_sync_unlock;
> irq_chip->irq_set_type = pca953x_irq_set_type;
> @@ -747,6 +767,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
> }
>
> gpiochip_set_nested_irqchip(&chip->gpio_chip, irq_chip, client->irq);
> + chip->irq_parent = client->irq;
>
> return 0;
> }
> --
> 2.17.1
>
Re: Requesting false output GPIO as IRQ
wt., 26 lut 2019 o 11:01 Geert Uytterhoeven napisał(a):
>
> Hi Linus, Bartosz,
>
> If request_irq() is called on an otherwise unused GPIO that was
> incorrectly configured for output by the firmware, this fails with:
>
> gpio gpiochip2: (e6052000.gpio): gpiochip_lock_as_irq: tried to
> flag a GPIO set as output for IRQ
> gpio gpiochip2: (e6052000.gpio): unable to lock HW IRQ 22 for IRQ
> genirq: Failed to request resources for 0-0020 (irq 142) on
> irqchip e6052000.gpio
>
> This happens since commit ad817297418539b8 ("gpio: rcar: Implement
> .get_direction() callback"), as the (default) input state is changed to
> output by reading the hardware state. Without that callback, the code
> just continues.
>
> While I strongly agree the firmware should be fixed not to configure
> random GPIOs as outputs, shouldn't Linux just override this, if the GPIO
> is not marked in use (has not been requested)?
>
> What is your opinion on this?
> Thanks!
>
I think you're right about overriding this, because it's not only the
firmware that can change the configuration. Let's imagine user-space
that sets a GPIO, then releases it - it now stays configured as
output. We should probably force input in this case and maybe just
hint it with a pr_debug()?
Bart
Re: [PATCH v7 0/3] i2c: improve i2c_new_{device|dummy}
śr., 13 mar 2019 o 17:56 Wolfram Sang napisał(a): > > I recently remembered this old series because I needed to add a dummy to the > DA9063 driver, so I had a look at it. I am somewhat sorry for the long delay, > yet the overload of patches is something I am not really responsible for :/ > > However, the series v6 from December 2017 was mostly OK. I decided to fix the > things I noticed right away, only minor stuff: > > * instead of '__' prefix for the new functions, I added an 'errptr' suffix. > '__' indicates internal use, mostly unlocked flavors. However, these > functions > could be exported somewhen and then it makes sense to have a more > descriptive > name. This also removes the inconsistency that the devm_* variant returned > an > errptr while the non-devm variant returned NULL. Now, the name makes it > clear. > > * some minor issues/typos in the kernel doc sections > > This series does not include converting 'i2c_new_secondary_device' which I > plan > to convert (including all users) to use errptr only. And maybe the same for > 'i2c_new_probed_device', I am not sure about it yet. > > I added a new user of this series, since at24 has changed a bit since back > then. > Patch 3 is only for testing. First, this series needs to be applied. > > Tested on a Renesas Lager board (R-Car Gen2). > > If the feedback is positive, then I plan to create an immutable branch for the > at24- and MFD-trees after next rc1, so stuff can be based on top of it. > > Looking forward to comments, > >Wolfram > > > Heiner Kallweit (2): > i2c: core: improve return value handling of i2c_new_device and > i2c_new_dummy > i2c: core: add device-managed version of i2c_new_dummy > > Wolfram Sang (1): > mfd: da9063: occupy second I2C address, too > > Documentation/driver-model/devres.txt | 3 + > drivers/i2c/i2c-core-base.c | 114 > ++ > drivers/mfd/da9063-i2c.c | 2 + > include/linux/i2c.h | 3 + > 4 files changed, 109 insertions(+), 13 deletions(-) > > -- > 2.11.0 > Wasn't there a patch using this new managed variant in at24 as well? Bart
Re: [PATCH v7 0/3] i2c: improve i2c_new_{device|dummy}
śr., 13 mar 2019 o 22:09 Wolfram Sang napisał(a): > > > > Wasn't there a patch using this new managed variant in at24 as well? > > My Lager board has no EEPROM, so I skipped that. I was more interested > in the core parts for now. > No problem. Once you'll have these in your tree, could you provide me with an immutable branch and I'll try to dig it out for at24 for v5.2? Bart > -BEGIN PGP SIGNATURE- > > iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAlyJcYAACgkQFA3kzBSg > KbbMeRAAlwHEaXAk4DZcUCvVIUiuz0j9wcNNZXpwpZJsF0+1DAOJ6LpGYRlA4HSM > RpHMTuuiM1rtgoYrW1cp90KalfqCUBYC0+lAT/yE8CWXRCOYMHUfyhDiArDHj0Sy > xSsIsj2dDP6FqzyGSKf//Hqfs4HXAm8kooApELrX7cQaMmarIBqf1avbtF5egR2M > e3jIf21KG6TUhqNw4rpUmj6NOb50XomVKBOgZzTZwPQVdI5YQMxhM0vKX7ck7GYF > RyNXP3gAdg3GqCHFy4Ot46begqMUqLwbU7Bl/D9gmJWw1Jawl5V/GA3x7p9/81g2 > iii9XLIGzZemIRnETN/XdUwuWRZiIg1WKFZFO7xCsg9VXs1Pa3EuNWLLVU2ytrrZ > YNKzQFazbucsqVnbmFPjsmkggDynRz7g8mvjIzgBATcthbAiyMyDu660ivzUrv/2 > LG4jl3chGqkvYww6YaA6plJCtXas1rMLLwuqV7gaBQy6ZcoZu2WuJ2tPnz2xiKBo > m7HSJeK0KfEK7IYvnKDgpMnhsHgKw+RtkngErH4l9DXbH3jJHNFQA4UOVKAnY5fF > v1BlYCcPMBqegwjDlVHeed7IRx2L2uFHh8QXOHxP2f1R1/BOvTA6L2vcaLTu261U > Mcftv6MvhsDGdZ4aP4UPJDbNaIIcKzt54KCpIKV62mnxMq+B9ok= > =2v3C > -END PGP SIGNATURE-
Re: [PATCH v7 0/3] i2c: improve i2c_new_{device|dummy}
śr., 13 mar 2019 o 22:19 Wolfram Sang napisał(a): > > > > No problem. Once you'll have these in your tree, could you provide me > > with an immutable branch and I'll try to dig it out for at24 for v5.2? > > Quoting my cover letter ;) > > === > > If the feedback is positive, then I plan to create an immutable branch for the > at24- and MFD-trees after next rc1, so stuff can be based on top of it. > Point taken. Thanks! Bart > -BEGIN PGP SIGNATURE- > > iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAlyJc+oACgkQFA3kzBSg > KbaZNw//QKa58jcJaRbJYvmnw3QOtzrIrRK4TI9l6dVM6nb9gtcDtS1oJM6qvE9s > PthN6nNOBj9+TOepD34gTgnfal+QhafC23SjziETrfAE/N57seKttJZW+P2JOKhW > LLIkYIU8tmC68PLOxNTLbk8yG63n8z2527ICzF1Jp06v4RDP2FMntMRvaD5d5M48 > mJMrNCR9nzX52bk5lXu1zw4Tdh4vj3IwRFa2uUUA+dS7EYt82cRT6pq8BiGk/Svg > NaySKqXjiNDHG8EQLUuQF7e30LWo+D+JCqxG0E+ir1rINlw9dJkzQSA49UmMbwn0 > jwwCFoM15ugVDAohdI64Pj5FiNGMl5zt2Fw3Ude0G+n5SN1BKRG2v947OvCJtYra > Yd3PBT7CfubqfZHK4cF9SqGTsavHBYACIzOCjHCAnZDsrNEANCFuDcFUla94WQsa > USMBw/BnEI6rpPlCgUA5n0NrcGResj3g9GJXxD7x0JKSjKyBXBeApZUx4tEWa2m8 > tc+JAHJ136BFDI7zaRgi2LDqFBvYwZpvJt0ttc9uA1B3u3UecG2QHBjp6XdTc7qM > aDhXSYTxBXP6fJeFI3cf4aIwN9HqsWNwJDnG3I+/9ODiwvtG7IQFjxXJ+dSGSrlw > 0sAWsPg3mavtEVjSYBLuUDZAchHGTULpjf/38iTx2D6BmmtX3S4= > =Rd2y > -END PGP SIGNATURE-
Re: [PATCH] dt-bindings: at24: add Renesas R1EX24016
śr., 20 mar 2019 o 11:33 Geert Uytterhoeven napisał(a): > > Document the compatible value for the Renesas R1EX24128ASAS0A two-wire > serial interface EEPROM, so it can be used in DTS files without causing > checkpatch warnings. > > This is a 2 KiB EEPROM. The first 1 KiB can always be written, the > second 1 KiB cannot be written if the write-protect line is asserted. > > Signed-off-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/eeprom/at24.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt > b/Documentation/devicetree/bindings/eeprom/at24.txt > index 0e456bbc121399b7..22aead844d0f58d6 100644 > --- a/Documentation/devicetree/bindings/eeprom/at24.txt > +++ b/Documentation/devicetree/bindings/eeprom/at24.txt > @@ -50,6 +50,7 @@ Required properties: > > "nxp,se97b" - the fallback is "atmel,24c02", > "renesas,r1ex24002" - the fallback is "atmel,24c02" > +"renesas,r1ex24016" - the fallback is "atmel,24c16" > "renesas,r1ex24128" - the fallback is "atmel,24c128" > "rohm,br24t01" - the fallback is "atmel,24c01" > > -- > 2.17.1 > Applied, thanks! Bart
Re: [PATCH] gpio: pca953x: Add support for CAT9554
śr., 20 mar 2019 o 11:36 Geert Uytterhoeven
napisał(a):
>
> The ON Semiconductor CAT9554 is a variant of the PCA953x GPIO expander,
> with 8 GPIOs and interrupt functionality.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 +
> drivers/gpio/gpio-pca953x.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index fb144e2b65226601..8678df2a5713a9af 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -30,6 +30,7 @@ Required properties:
> ti,tca6424
> ti,tca9539
> ti,tca9554
> + onnn,cat9554
> onnn,pca9654
> exar,xra1202
> - gpio-controller: if used as gpio expander.
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index 7e76830b33682aa3..88c94d155e218535 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -1167,6 +1167,7 @@ static const struct of_device_id pca953x_dt_ids[] = {
> { .compatible = "ti,tca6416", .data = OF_953X(16, PCA_INT), },
> { .compatible = "ti,tca6424", .data = OF_953X(24, PCA_INT), },
>
> + { .compatible = "onnn,cat9554", .data = OF_953X( 8, PCA_INT), },
> { .compatible = "onnn,pca9654", .data = OF_953X( 8, PCA_INT), },
>
> { .compatible = "exar,xra1202", .data = OF_953X( 8, 0), },
> --
> 2.17.1
>
Hi Geert,
I'm seeing that historically we always would split the patches adding
the new compatible to the DT bindings and the actual support
implementation into separate commits. Could you do the same here?
Thanks,
Bart
Re: [PATCH v2 1/2] dt-bindings: gpio: pca953x: Document onnn,cat9554
czw., 21 mar 2019 o 10:21 Geert Uytterhoeven napisał(a): > > The ON Semiconductor CAT9554 is a variant of the PCA953x GPIO expander, > with 8 GPIOs and interrupt functionality. > > Signed-off-by: Geert Uytterhoeven > --- > v2: > - Split DT binding doc and driver update in separate patches. > --- > Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > index fb144e2b65226601..8678df2a5713a9af 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > @@ -30,6 +30,7 @@ Required properties: > ti,tca6424 > ti,tca9539 > ti,tca9554 > + onnn,cat9554 > onnn,pca9654 > exar,xra1202 > - gpio-controller: if used as gpio expander. > -- > 2.17.1 > Both applied to for-next. Thanks, Bart
Re: [PATCH v8 2/3] i2c: core: add device-managed version of i2c_new_dummy
czw., 16 maj 2019 o 23:13 Wolfram Sang
napisał(a):
>
> From: Heiner Kallweit
>
> i2c_new_dummy is typically called from the probe function of the
> driver for the primary i2c client. It requires calls to
> i2c_unregister_device in the error path of the probe function and
> in the remove function.
> This can be simplified by introducing a device-managed version.
>
> Note the changed error case return value type: i2c_new_dummy returns
> NULL whilst devm_i2c_new_dummy_device returns an ERR_PTR.
>
> Signed-off-by: Heiner Kallweit
> [wsa: rename new functions and fix minor kdoc issues]
> Signed-off-by: Wolfram Sang
> ---
> Documentation/driver-model/devres.txt | 3 ++
> drivers/i2c/i2c-core-base.c | 44 +++
> include/linux/i2c.h | 3 ++
> 3 files changed, 50 insertions(+)
>
> diff --git a/Documentation/driver-model/devres.txt
> b/Documentation/driver-model/devres.txt
> index 4a461359..69c7fa7f616c 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -271,6 +271,9 @@ GPIO
>devm_gpio_request_one()
>devm_gpio_free()
>
> +I2C
> + devm_i2c_new_dummy_device()
> +
> IIO
>devm_iio_device_alloc()
>devm_iio_device_free()
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 9c38dde73366..d389d4fb0623 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -929,6 +929,50 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter
> *adapter, u16 address)
> }
> EXPORT_SYMBOL_GPL(i2c_new_dummy);
>
> +struct i2c_dummy_devres {
> + struct i2c_client *client;
> +};
> +
> +static void devm_i2c_release_dummy(struct device *dev, void *res)
> +{
> + struct i2c_dummy_devres *this = res;
> +
> + i2c_unregister_device(this->client);
> +}
> +
> +/**
> + * devm_i2c_new_dummy_device - return a new i2c device bound to a dummy
> driver
> + * @dev: device the managed resource is bound to
> + * @adapter: the adapter managing the device
> + * @address: seven bit address to be used
> + * Context: can sleep
> + *
> + * This is the device-managed version of @i2c_new_dummy_device. It returns
> the
> + * new i2c client or an ERR_PTR in case of an error.
> + */
> +struct i2c_client *devm_i2c_new_dummy_device(struct device *dev,
> +struct i2c_adapter *adapter,
> +u16 address)
> +{
> + struct i2c_dummy_devres *dr;
> + struct i2c_client *client;
> +
> + dr = devres_alloc(devm_i2c_release_dummy, sizeof(*dr), GFP_KERNEL);
> + if (!dr)
> + return ERR_PTR(-ENOMEM);
> +
> + client = i2c_new_dummy_device(adapter, address);
> + if (IS_ERR(client)) {
> + devres_free(dr);
> + } else {
> + dr->client = client;
> + devres_add(dev, dr);
> + }
> +
> + return client;
> +}
> +EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
> +
> /**
> * i2c_new_secondary_device - Helper to get the instantiated secondary
> address
> * and create the associated device
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index be27062f8ed1..6c4db54714f6 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -469,6 +469,9 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter
> *, unsigned short addr);
> extern struct i2c_client *
> i2c_new_dummy(struct i2c_adapter *adap, u16 address);
>
> +extern struct i2c_client *
> +devm_i2c_new_dummy_device(struct device *dev, struct i2c_adapter *adap, u16
> address);
> +
> extern struct i2c_client *
> i2c_new_secondary_device(struct i2c_client *client,
> const char *name,
> --
> 2.19.1
>
Reviewed-by: Bartosz Golaszewski
Re: [PATCH v8 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy
ext: can sleep
> + *
> + * This deprecated function has the same functionality as
> @i2c_new_dummy_device,
> + * it just returns NULL instead of an ERR_PTR in case of an error for
> + * compatibility with current I2C API. It will be removed once all users are
> + * converted.
> + *
> + * This returns the new i2c client, which should be saved for later use with
> + * i2c_unregister_device(); or NULL to indicate an error.
> + */
> +struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
> +{
> + struct i2c_client *ret;
> +
> + ret = i2c_new_dummy_device(adapter, address);
> + return IS_ERR(ret) ? NULL : ret;
> }
> EXPORT_SYMBOL_GPL(i2c_new_dummy);
>
> @@ -1000,9 +1048,9 @@ i2c_sysfs_new_device(struct device *dev, struct
> device_attribute *attr,
> info.flags |= I2C_CLIENT_SLAVE;
> }
>
> - client = i2c_new_device(adap, &info);
> - if (!client)
> - return -EINVAL;
> + client = i2c_new_client_device(adap, &info);
> + if (IS_ERR(client))
> + return PTR_ERR(client);
>
> /* Keep track of the added device */
> mutex_lock(&adap->userspace_clients_lock);
> --
> 2.19.1
>
Reviewed-by: Bartosz Golaszewski
Re: [PATCH v8 3/3] mfd: da9063: occupy second I2C address, too
czw., 16 maj 2019 o 23:13 Wolfram Sang napisał(a): > > Even though we don't use it yet, we should mark the second I2C address > this device is listening to as used. > > Not yet for upstream until all dependencies are merged! > > Signed-off-by: Wolfram Sang > --- > drivers/mfd/da9063-i2c.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c > index 455de74c0dd2..2133b09f6e7a 100644 > --- a/drivers/mfd/da9063-i2c.c > +++ b/drivers/mfd/da9063-i2c.c > @@ -221,6 +221,8 @@ static int da9063_i2c_probe(struct i2c_client *i2c, > return ret; > } > > + devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter, i2c->addr + 1); > + > return da9063_device_init(da9063, i2c->irq); > } > > -- > 2.19.1 > Reviewed-by: Bartosz Golaszewski
Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
2018-08-30 11:16 GMT+02:00 Daniel Lezcano : > > [Added Arnd Bergmann, Bartosz Golaszewski and Mark Brown] > > On 30/08/2018 10:48, Geert Uytterhoeven wrote: >> Hi Daniel, > > [ ... ] > >>> Yeah, I got this point. But it is the meaning of your sentence: "... >>> which causes issues with complex dependencies.". >>> >>> It is ambiguous *what* causes the issues. >>> >>> Did you meant an attempt was done to support EPROBE_DEFER with >>> *_OF_DECLARE but caused too much issues with the complex dependencies? >>> >>> Or the current situation is causing too much issues with the complex >>> dependencies? >>> >>> (I know the latter is true, it is about the meaning of the sentence). >> >> I meant the latter. >> >> AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE. >> IMHO it would be pointless, as it would be much easier to just switch to real >> platform drivers. > > May be, may be not. > > From your point of view, the change is simple because it touches only a > single driver. > > From my point of view, the change implies a split in the approach while > I'm trying to unify the drivers little by little and there are hundred > of them. > > It is not the first time we face this situation and Bartosz Golaszewski > has a similar problem [1]. > Hi, thanks for Cc'in me on that. This was my latest proposal for early platform drivers: https://lkml.org/lkml/2018/5/11/488 I still intend on continuing this work, I just don't have the time right now. Best regards, Bartosz Golaszewski > We have all the frameworks we need to solve this properly but I would > like something we can propagate to all drivers (OF and !OF) so we end up > with unified code. > > It is time we clearly state the dependency issues and we find a proper > way to solve it. > > > > > [1] https://lkml.org/lkml/2018/4/26/657 > > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | > <http://www.linaro.org/linaro-blog/> Blog >
Re: [PATCH 01/14] gpio: pca953x: Deduplicate the bank_size
niedz., 2 gru 2018 o 20:36 Marek Vasut napisał(a):
>
> The bank_size = fls(...) code was duplicated in the driver 5 times,
> pull it into separate function.
>
Shouldn't it be bank_shift in the commit message?
Bart
> Signed-off-by: Marek Vasut
> Cc: Linus Walleij
> Cc: Bartosz Golaszewski
> ---
> drivers/gpio/gpio-pca953x.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index 023a32cfac42..31e3b1b52330 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -159,11 +159,16 @@ struct pca953x_chip {
> int (*read_regs)(struct pca953x_chip *, int, u8 *);
> };
>
> +static int pca953x_bank_shift(struct pca953x_chip *chip)
> +{
> + return fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> +}
> +
> static int pca953x_read_single(struct pca953x_chip *chip, int reg, u32 *val,
> int off)
> {
> int ret;
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int offset = off / BANK_SZ;
>
> ret = i2c_smbus_read_byte_data(chip->client,
> @@ -182,7 +187,7 @@ static int pca953x_write_single(struct pca953x_chip
> *chip, int reg, u32 val,
> int off)
> {
> int ret;
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int offset = off / BANK_SZ;
>
> ret = i2c_smbus_write_byte_data(chip->client,
> @@ -221,7 +226,7 @@ static int pca957x_write_regs_16(struct pca953x_chip
> *chip, int reg, u8 *val)
>
> static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
> {
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
>
> @@ -265,7 +270,7 @@ static int pca953x_read_regs_16(struct pca953x_chip
> *chip, int reg, u8 *val)
>
> static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
> {
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
>
> @@ -402,13 +407,12 @@ static void pca953x_gpio_set_multiple(struct gpio_chip
> *gc,
> unsigned long *mask, unsigned long
> *bits)
> {
> struct pca953x_chip *chip = gpiochip_get_data(gc);
> + int bank_shift = pca953x_bank_shift(chip);
> unsigned int bank_mask, bank_val;
> - int bank_shift, bank;
> + int bank;
> u8 reg_val[MAX_BANK];
> int ret;
>
> - bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> -
> mutex_lock(&chip->i2c_lock);
> memcpy(reg_val, chip->reg_output, NBANK(chip));
> for (bank = 0; bank < NBANK(chip); bank++) {
> --
> 2.18.0
>
Re: [PATCH 02/14] gpio: pca953x: Fix AI overflow on PCAL6524
niedz., 2 gru 2018 o 20:36 Marek Vasut napisał(a): > > The PCAL_PINCTRL_MASK is too large. The extended register block on > PCAL6524, which is the largest chip with this block, has the block > limited to address range 0x40..0x7f. This is because the bit 7 in > the command register is used for the Address Increment functionality. > > Trim the mask to 0x60 to match the datasheet and to prevent accidental > overwrite of the AI bit. > > Signed-off-by: Marek Vasut > Cc: Linus Walleij > Cc: Bartosz Golaszewski > --- > drivers/gpio/gpio-pca953x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c > index 31e3b1b52330..4e9c79ca69c5 100644 > --- a/drivers/gpio/gpio-pca953x.c > +++ b/drivers/gpio/gpio-pca953x.c > @@ -58,7 +58,7 @@ > #define PCA_GPIO_MASK 0x00FF > > #define PCAL_GPIO_MASK 0x1f > -#define PCAL_PINCTRL_MASK 0xe0 > +#define PCAL_PINCTRL_MASK 0x60 > > #define PCA_INT 0x0100 > #define PCA_PCAL 0x0200 > -- > 2.18.0 > Reviewed-by: Bartosz Golaszewski
Re: [PATCH 0/2] gpio: em: Miscellaneous probe cleanups
pon., 27 maj 2019 o 14:40 Geert Uytterhoeven
napisał(a):
>
> Hi Linus, Bartosz,
>
> This small series contains two cleanups for the GPIO driver for the
> venerable Renesas EMMA Mobile EV2 SoC.
>
> These are compile-tested only, due to lack of hardware.
>
> Thanks!
>
> Geert Uytterhoeven (2):
> gpio: em: Remove error messages on out-of-memory conditions
> gpio: em: Return early on error in em_gio_probe()
>
> drivers/gpio/gpio-em.c | 30 +-
> 1 file changed, 9 insertions(+), 21 deletions(-)
>
> --
> 2.17.1
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Hi Geert,
applied both and also sent a follow-up that makes this driver use the
managed variant of gpiochip_add_data().
Bart
Re: [PATCH] i2c: add newly exported functions to the header, too
pon., 24 cze 2019 o 19:04 Wolfram Sang
napisał(a):
>
> Nobody (including me) noticed that these functions were exported but not
> added to the header :/
>
> Fixes: 7159dbdae3c5 ("i2c: core: improve return value handling of
> i2c_new_device and i2c_new_dummy")
> Signed-off-by: Wolfram Sang
> ---
> drivers/i2c/i2c-core-base.c | 5 ++---
> include/linux/i2c.h | 6 ++
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 9e43508d4567..4ef44fa7e36b 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -721,7 +721,7 @@ static int i2c_dev_irq_from_resources(const struct
> resource *resources,
> * This returns the new i2c client, which may be saved for later use with
> * i2c_unregister_device(); or an ERR_PTR to describe the error.
> */
> -static struct i2c_client *
> +struct i2c_client *
> i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const
> *info)
> {
> struct i2c_client *client;
> @@ -887,8 +887,7 @@ static struct i2c_driver dummy_driver = {
> * This returns the new i2c client, which should be saved for later use with
> * i2c_unregister_device(); or an ERR_PTR to describe the error.
> */
> -static struct i2c_client *
> -i2c_new_dummy_device(struct i2c_adapter *adapter, u16 address)
> +struct i2c_client *i2c_new_dummy_device(struct i2c_adapter *adapter, u16
> address)
> {
> struct i2c_board_info info = {
> I2C_BOARD_INFO("dummy", address),
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 1308126fc384..79f0d4fd5036 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -436,6 +436,9 @@ struct i2c_board_info {
> extern struct i2c_client *
> i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info);
>
> +extern struct i2c_client *
> +i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const
> *info);
> +
> /* If you don't know the exact address of an I2C device, use this variant
> * instead, which can probe for device presence in a list of possible
> * addresses. The "probe" callback function is optional. If it is provided,
> @@ -457,6 +460,9 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter
> *, unsigned short addr);
> extern struct i2c_client *
> i2c_new_dummy(struct i2c_adapter *adap, u16 address);
>
> +extern struct i2c_client *
> +i2c_new_dummy_device(struct i2c_adapter *adapter, u16 address);
> +
> extern struct i2c_client *
> devm_i2c_new_dummy_device(struct device *dev, struct i2c_adapter *adap, u16
> address);
>
> --
> 2.19.1
>
Ha! How about that? :)
Reviewed-by: Bartosz Golaszewski
Re: [PATCH] dt-bindings: gpio: rcar: Add DT binding for r8a774b1
pon., 23 wrz 2019 o 15:28 Biju Das napisał(a): > > Document Renesas' RZ/G2N (R8A774B1) GPIO blocks compatibility within the > relevant dt-bindings. > > Signed-off-by: Biju Das > --- > Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt > b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt > index f3f2c46..41e5fed 100644 > --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt > +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt > @@ -8,6 +8,7 @@ Required Properties: > - "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO > controller. > - "renesas,gpio-r8a77470": for R8A77470 (RZ/G1C) compatible GPIO > controller. > - "renesas,gpio-r8a774a1": for R8A774A1 (RZ/G2M) compatible GPIO > controller. > +- "renesas,gpio-r8a774b1": for R8A774B1 (RZ/G2N) compatible GPIO > controller. > - "renesas,gpio-r8a774c0": for R8A774C0 (RZ/G2E) compatible GPIO > controller. > - "renesas,gpio-r8a7778": for R8A7778 (R-Car M1) compatible GPIO > controller. > - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO > controller. > -- > 2.7.4 > Patch applied, thanks! Bart
