| Message ID | 20190313165526.28588-1-wsa+renesas@sang-engineering.com |
|---|---|
| Headers | show |
| Series | i2c: improve i2c_new_{device|dummy} | expand |
śr., 13 mar 2019 o 17:56 Wolfram Sang <wsa+renesas@sang-engineering.com> 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
> 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.
śr., 13 mar 2019 o 22:09 Wolfram Sang <wsa@the-dreams.de> 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-----
> 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.
śr., 13 mar 2019 o 22:19 Wolfram Sang <wsa@the-dreams.de> 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-----
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(-)