Re: [PATCH] i2c: mux: Remove class argument from i2c_mux_add_adapter()
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
>
> Signed-off-by: Heiner Kallweit
Applied to for-next (meaning for 6.10), thanks!
signature.asc
Description: PGP signature
Re: [PATCH v2] drm/arm/comeda: don't use confusing 'timeout' variable name
> I will change the subject line to s/comeda/komeda/ when merging it. Oh, thank you! signature.asc Description: PGP signature
[PATCH v2] drm/arm/comeda: don't use confusing 'timeout' variable name
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_timeout() causing patterns like:
timeout = wait_for_completion_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Check the return value directly to drop
'timeout' which also fixes its wrong type.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 2c661f28410e..9bec59cf9c06 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -294,7 +294,6 @@ komeda_crtc_flush_and_wait_for_flip_done(struct komeda_crtc
*kcrtc,
struct komeda_dev *mdev = kcrtc->master->mdev;
struct completion *flip_done;
struct completion temp;
- int timeout;
/* if caller doesn't send a flip_done, use a private flip_done */
if (input_flip_done) {
@@ -308,8 +307,7 @@ komeda_crtc_flush_and_wait_for_flip_done(struct komeda_crtc
*kcrtc,
mdev->funcs->flush(mdev, kcrtc->master->id, 0);
/* wait the flip take affect.*/
- timeout = wait_for_completion_timeout(flip_done, HZ);
- if (timeout == 0) {
+ if (wait_for_completion_timeout(flip_done, HZ) == 0) {
DRM_ERROR("wait pipe%d flip done timeout\n", kcrtc->master->id);
if (!input_flip_done) {
unsigned long flags;
--
2.43.0
Re: [PATCH] i2c: mux: Remove class argument from i2c_mux_add_adapter()
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
>
> Signed-off-by: Heiner Kallweit
For the record, I will apply this patch once Andi sends me his pull
request because there is a dependency in there.
signature.asc
Description: PGP signature
Re: [PATCH 1/1] drm: arm: display: komeda: komeda_crtc: use 'time_left' variable with wait_for_completion_timeout()
> > /* wait the flip take affect.*/
> > - timeout = wait_for_completion_timeout(flip_done, HZ);
> > - if (timeout == 0) {
> > + time_left = wait_for_completion_timeout(flip_done, HZ);
> > + if (time_left == 0) {
>
> Honestly, if the name of the variable is confusing I would get rid of it
> completely. Can you
> send a patch that removes the timeout variable and here just does:
>
> if (wait_for_completion_timeout(flip_done, HZ) == 0) {
Can do. I think, though, that using 'time_left' is still easier to
understand. However, this code block is simple enough and it is your
driver, so I'll send v2 later.
signature.asc
Description: PGP signature
[PATCH 1/1] drm: arm: display: komeda: komeda_crtc: use 'time_left' variable with wait_for_completion_timeout()
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_timeout() causing patterns like:
timeout = wait_for_completion_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Fix to the proper variable type 'unsigned long' while here.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 2c661f28410e..c867acb737d6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -294,7 +294,7 @@ komeda_crtc_flush_and_wait_for_flip_done(struct komeda_crtc
*kcrtc,
struct komeda_dev *mdev = kcrtc->master->mdev;
struct completion *flip_done;
struct completion temp;
- int timeout;
+ unsigned long time_left;
/* if caller doesn't send a flip_done, use a private flip_done */
if (input_flip_done) {
@@ -308,8 +308,8 @@ komeda_crtc_flush_and_wait_for_flip_done(struct komeda_crtc
*kcrtc,
mdev->funcs->flush(mdev, kcrtc->master->id, 0);
/* wait the flip take affect.*/
- timeout = wait_for_completion_timeout(flip_done, HZ);
- if (timeout == 0) {
+ time_left = wait_for_completion_timeout(flip_done, HZ);
+ if (time_left == 0) {
DRM_ERROR("wait pipe%d flip done timeout\n", kcrtc->master->id);
if (!input_flip_done) {
unsigned long flags;
--
2.43.0
[PATCH 1/1] ALSA: aoa: soundbus: i2sbus: pcm: use 'time_left' variable with wait_for_completion_timeout()
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_timeout() causing patterns like:
timeout = wait_for_completion_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Fix to the proper variable type 'unsigned long' while here.
Signed-off-by: Wolfram Sang
---
sound/aoa/soundbus/i2sbus/pcm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/aoa/soundbus/i2sbus/pcm.c b/sound/aoa/soundbus/i2sbus/pcm.c
index 07df5cc0f2d7..98b812ffbde6 100644
--- a/sound/aoa/soundbus/i2sbus/pcm.c
+++ b/sound/aoa/soundbus/i2sbus/pcm.c
@@ -255,24 +255,24 @@ static void i2sbus_wait_for_stop(struct i2sbus_dev
*i2sdev,
{
unsigned long flags;
DECLARE_COMPLETION_ONSTACK(done);
- long timeout;
+ unsigned long time_left;
spin_lock_irqsave(>low_lock, flags);
if (pi->dbdma_ring.stopping) {
pi->stop_completion =
spin_unlock_irqrestore(>low_lock, flags);
- timeout = wait_for_completion_timeout(, HZ);
+ time_left = wait_for_completion_timeout(, HZ);
spin_lock_irqsave(>low_lock, flags);
pi->stop_completion = NULL;
- if (timeout == 0) {
+ if (time_left == 0) {
/* timeout expired, stop dbdma forcefully */
printk(KERN_ERR "i2sbus_wait_for_stop: timed out\n");
/* make sure RUN, PAUSE and S0 bits are cleared */
out_le32(>dbdma->control, (RUN | PAUSE | 1) << 16);
pi->dbdma_ring.stopping = 0;
- timeout = 10;
+ time_left = 10;
while (in_le32(>dbdma->status) & ACTIVE) {
- if (--timeout <= 0)
+ if (--time_left <= 0)
break;
udelay(1);
}
--
2.43.0
Re: [RFC PATCH-for-9.1 3/4] hw/i2c: Convert to spec v7 terminology (automatically)
Hi Philippe, > One of the biggest change from I2C spec v6 -> v7 is: > > • Updated the terms "master/slave" to "controller/target" > > Since it follows the inclusive terminology from the "Conscious > Language in your Open Source Projects" guidelines [*], replace > the I2C terminology. ... > Inspired-by: Wolfram Sang Cool, I am glad that I could inspire you to do this for QEMU. Good luck with the series, Wolfram signature.asc Description: PGP signature
Re: [PATCH 14/64] i2c: cpm: reword according to newest specification
> > out_8(>i2c_reg->i2mod, 0x00); > > - out_8(>i2c_reg->i2com, I2COM_MASTER); /* Master mode */ > > + out_8(>i2c_reg->i2com, I2COM_MASTER); /* Host mode */ > > I2COM_MASTER might be coming from the datasheet. Maybe we can just drop the comment? The value we write is pretty self-explaining. signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hi Easwar, > Sorry, got excited. :) There were drivers I'd been part of that I specifically > wanted to fixup, but then the scope grew to other users of algobit. Well, you got some positive feedback, so that is good. > > It is true that I changed quite some controller drivers within the i2c > > realm. I did this to gain experience. As you also noticed quite some > > questions came up. We need to agree on answers first. And once we are > > happy with the answers we found, then IMO we can go outside of the i2c > > realm and send patches to other subsystems referencing agreed > > precedence. I intentionally did not go outside i2c yet. Since your > > patches are already there, you probably want to foster them until they > > are ready for inclusion. > > Sorry, I don't quite follow what you mean by foster in this context. Are > you asking me to hold off on merging the series, or to follow through on > getting it merged? I think they are your patches, so this is up to you to decide. With "foster", I meant you keep working on them until everyone is happy. I haven't looked at the drivers you modify. I can't tell if they can be converted right away or if they use a lot of I2C API calls, so that it makes sense to wait until the core is converted. I trust you to decide this. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hello Easwar, On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > with more appropriate terms. Inspired by and following on to Wolfram's > series to fix drivers/i2c/[1], fix the terminology for users of the > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > in the specification. I really appreciate that you want to assist in this task to improve the I2C core. I do. I am afraid, however, that you took the second step before the first one, though. As I mentioned in my original cover letter, this is not only about renaming but also improving the I2C API (splitting up header files...). So, drivers are not a priority right now. They can be better fixed once the core is ready. It is true that I changed quite some controller drivers within the i2c realm. I did this to gain experience. As you also noticed quite some questions came up. We need to agree on answers first. And once we are happy with the answers we found, then IMO we can go outside of the i2c realm and send patches to other subsystems referencing agreed precedence. I intentionally did not go outside i2c yet. Since your patches are already there, you probably want to foster them until they are ready for inclusion. Yet, regarding further patches, my suggestion is to wait until the core is ready. That might take a while, though. However, there is enough to discuss until the core is ready. So, your collaboration there is highly appreciated! > The last patch updating the .master_xfer method to .xfer depends on > patch 1 of Wolfram's series below, but the series is otherwise > independent. It may make sense for the last patch to go in with Please drop the last patch from this series. It will nicely remove the dependency. Also, like above, I first want to gain experience with i2c before going to other subsystems. That was intended. All the best and happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hi Easwar, > Sorry, got excited. :) There were drivers I'd been part of that I specifically > wanted to fixup, but then the scope grew to other users of algobit. Well, you got some positive feedback, so that is good. > > It is true that I changed quite some controller drivers within the i2c > > realm. I did this to gain experience. As you also noticed quite some > > questions came up. We need to agree on answers first. And once we are > > happy with the answers we found, then IMO we can go outside of the i2c > > realm and send patches to other subsystems referencing agreed > > precedence. I intentionally did not go outside i2c yet. Since your > > patches are already there, you probably want to foster them until they > > are ready for inclusion. > > Sorry, I don't quite follow what you mean by foster in this context. Are > you asking me to hold off on merging the series, or to follow through on > getting it merged? I think they are your patches, so this is up to you to decide. With "foster", I meant you keep working on them until everyone is happy. I haven't looked at the drivers you modify. I can't tell if they can be converted right away or if they use a lot of I2C API calls, so that it makes sense to wait until the core is converted. I trust you to decide this. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hi Easwar, > Sorry, got excited. :) There were drivers I'd been part of that I specifically > wanted to fixup, but then the scope grew to other users of algobit. Well, you got some positive feedback, so that is good. > > It is true that I changed quite some controller drivers within the i2c > > realm. I did this to gain experience. As you also noticed quite some > > questions came up. We need to agree on answers first. And once we are > > happy with the answers we found, then IMO we can go outside of the i2c > > realm and send patches to other subsystems referencing agreed > > precedence. I intentionally did not go outside i2c yet. Since your > > patches are already there, you probably want to foster them until they > > are ready for inclusion. > > Sorry, I don't quite follow what you mean by foster in this context. Are > you asking me to hold off on merging the series, or to follow through on > getting it merged? I think they are your patches, so this is up to you to decide. With "foster", I meant you keep working on them until everyone is happy. I haven't looked at the drivers you modify. I can't tell if they can be converted right away or if they use a lot of I2C API calls, so that it makes sense to wait until the core is converted. I trust you to decide this. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hi Easwar, > Sorry, got excited. :) There were drivers I'd been part of that I specifically > wanted to fixup, but then the scope grew to other users of algobit. Well, you got some positive feedback, so that is good. > > It is true that I changed quite some controller drivers within the i2c > > realm. I did this to gain experience. As you also noticed quite some > > questions came up. We need to agree on answers first. And once we are > > happy with the answers we found, then IMO we can go outside of the i2c > > realm and send patches to other subsystems referencing agreed > > precedence. I intentionally did not go outside i2c yet. Since your > > patches are already there, you probably want to foster them until they > > are ready for inclusion. > > Sorry, I don't quite follow what you mean by foster in this context. Are > you asking me to hold off on merging the series, or to follow through on > getting it merged? I think they are your patches, so this is up to you to decide. With "foster", I meant you keep working on them until everyone is happy. I haven't looked at the drivers you modify. I can't tell if they can be converted right away or if they use a lot of I2C API calls, so that it makes sense to wait until the core is converted. I trust you to decide this. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hello Easwar, On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > with more appropriate terms. Inspired by and following on to Wolfram's > series to fix drivers/i2c/[1], fix the terminology for users of the > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > in the specification. I really appreciate that you want to assist in this task to improve the I2C core. I do. I am afraid, however, that you took the second step before the first one, though. As I mentioned in my original cover letter, this is not only about renaming but also improving the I2C API (splitting up header files...). So, drivers are not a priority right now. They can be better fixed once the core is ready. It is true that I changed quite some controller drivers within the i2c realm. I did this to gain experience. As you also noticed quite some questions came up. We need to agree on answers first. And once we are happy with the answers we found, then IMO we can go outside of the i2c realm and send patches to other subsystems referencing agreed precedence. I intentionally did not go outside i2c yet. Since your patches are already there, you probably want to foster them until they are ready for inclusion. Yet, regarding further patches, my suggestion is to wait until the core is ready. That might take a while, though. However, there is enough to discuss until the core is ready. So, your collaboration there is highly appreciated! > The last patch updating the .master_xfer method to .xfer depends on > patch 1 of Wolfram's series below, but the series is otherwise > independent. It may make sense for the last patch to go in with Please drop the last patch from this series. It will nicely remove the dependency. Also, like above, I first want to gain experience with i2c before going to other subsystems. That was intended. All the best and happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hello Easwar, On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > with more appropriate terms. Inspired by and following on to Wolfram's > series to fix drivers/i2c/[1], fix the terminology for users of the > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > in the specification. I really appreciate that you want to assist in this task to improve the I2C core. I do. I am afraid, however, that you took the second step before the first one, though. As I mentioned in my original cover letter, this is not only about renaming but also improving the I2C API (splitting up header files...). So, drivers are not a priority right now. They can be better fixed once the core is ready. It is true that I changed quite some controller drivers within the i2c realm. I did this to gain experience. As you also noticed quite some questions came up. We need to agree on answers first. And once we are happy with the answers we found, then IMO we can go outside of the i2c realm and send patches to other subsystems referencing agreed precedence. I intentionally did not go outside i2c yet. Since your patches are already there, you probably want to foster them until they are ready for inclusion. Yet, regarding further patches, my suggestion is to wait until the core is ready. That might take a while, though. However, there is enough to discuss until the core is ready. So, your collaboration there is highly appreciated! > The last patch updating the .master_xfer method to .xfer depends on > patch 1 of Wolfram's series below, but the series is otherwise > independent. It may make sense for the last patch to go in with Please drop the last patch from this series. It will nicely remove the dependency. Also, like above, I first want to gain experience with i2c before going to other subsystems. That was intended. All the best and happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hello Easwar, On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > with more appropriate terms. Inspired by and following on to Wolfram's > series to fix drivers/i2c/[1], fix the terminology for users of the > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > in the specification. I really appreciate that you want to assist in this task to improve the I2C core. I do. I am afraid, however, that you took the second step before the first one, though. As I mentioned in my original cover letter, this is not only about renaming but also improving the I2C API (splitting up header files...). So, drivers are not a priority right now. They can be better fixed once the core is ready. It is true that I changed quite some controller drivers within the i2c realm. I did this to gain experience. As you also noticed quite some questions came up. We need to agree on answers first. And once we are happy with the answers we found, then IMO we can go outside of the i2c realm and send patches to other subsystems referencing agreed precedence. I intentionally did not go outside i2c yet. Since your patches are already there, you probably want to foster them until they are ready for inclusion. Yet, regarding further patches, my suggestion is to wait until the core is ready. That might take a while, though. However, there is enough to discuss until the core is ready. So, your collaboration there is highly appreciated! > The last patch updating the .master_xfer method to .xfer depends on > patch 1 of Wolfram's series below, but the series is otherwise > independent. It may make sense for the last patch to go in with Please drop the last patch from this series. It will nicely remove the dependency. Also, like above, I first want to gain experience with i2c before going to other subsystems. That was intended. All the best and happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH 00/64] i2c: reword i2c_algorithm according to newest specification
Hi Andi, hi everyone, thank you for reviewing and waiting. I had a small personal hiatus over Easter but now I am back. This series needs another cycle, so no need to hurry. I will address some of the review comments but not all. The conversion (and API improvements) are some bigger tasks, so inconsistencies inbetween can't be avoided AFAICS. I'll keep you updated. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH 00/64] i2c: reword i2c_algorithm according to newest specification
Hi Andi, hi everyone, thank you for reviewing and waiting. I had a small personal hiatus over Easter but now I am back. This series needs another cycle, so no need to hurry. I will address some of the review comments but not all. The conversion (and API improvements) are some bigger tasks, so inconsistencies inbetween can't be avoided AFAICS. I'll keep you updated. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> Kind of odd though to change function names but not parameter names of > those very same functions. Ouch, this is definitely a valid point. Seems like this series will need a respin after all. Will wait for further comments, though. Thanks! signature.asc Description: PGP signature
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> Acked-by: Nicolas Ferre # for at91 > Probably file names themselves will need some care, in a second time. Totally true. I am aware of that. But one step after the other... signature.asc Description: PGP signature
[PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C
v7, SMBus 3.2, I3C specifications and replace "master/slave" with more
appropriate terms. For some drivers, this means no more conversions are
needed. For the others more work needs to be done but this will be
performed incrementally along with API changes/improvements. All these
changes here are simple search/replace results.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-amd-mp2-plat.c | 2 +-
drivers/i2c/busses/i2c-at91-master.c | 2 +-
drivers/i2c/busses/i2c-at91-slave.c| 8
drivers/i2c/busses/i2c-axxia.c | 10 +-
drivers/i2c/busses/i2c-cros-ec-tunnel.c| 2 +-
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/i2c/busses/i2c-designware-slave.c | 8
drivers/i2c/busses/i2c-diolan-u2c.c| 2 +-
drivers/i2c/busses/i2c-exynos5.c | 4 ++--
drivers/i2c/busses/i2c-gxp.c | 12 ++--
drivers/i2c/busses/i2c-hisi.c | 4 ++--
drivers/i2c/busses/i2c-img-scb.c | 2 +-
drivers/i2c/busses/i2c-imx.c | 12 ++--
drivers/i2c/busses/i2c-jz4780.c| 2 +-
drivers/i2c/busses/i2c-kempld.c| 2 +-
drivers/i2c/busses/i2c-meson.c | 4 ++--
drivers/i2c/busses/i2c-mlxbf.c | 8
drivers/i2c/busses/i2c-mt65xx.c| 2 +-
drivers/i2c/busses/i2c-mxs.c | 2 +-
drivers/i2c/busses/i2c-nomadik.c | 2 +-
drivers/i2c/busses/i2c-npcm7xx.c | 12 ++--
drivers/i2c/busses/i2c-nvidia-gpu.c| 4 ++--
drivers/i2c/busses/i2c-ocores.c| 8
drivers/i2c/busses/i2c-octeon-platdrv.c| 2 +-
drivers/i2c/busses/i2c-omap.c | 4 ++--
drivers/i2c/busses/i2c-opal.c | 4 ++--
drivers/i2c/busses/i2c-pasemi-core.c | 2 +-
drivers/i2c/busses/i2c-pnx.c | 2 +-
drivers/i2c/busses/i2c-pxa.c | 12 ++--
drivers/i2c/busses/i2c-qcom-cci.c | 2 +-
drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
drivers/i2c/busses/i2c-robotfuzz-osif.c| 2 +-
drivers/i2c/busses/i2c-rzv2m.c | 8
drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
drivers/i2c/busses/i2c-stm32f7.c | 14 +++---
drivers/i2c/busses/i2c-tegra-bpmp.c| 4 ++--
drivers/i2c/busses/i2c-tegra.c | 4 ++--
drivers/i2c/busses/i2c-thunderx-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-virtio.c| 2 +-
drivers/i2c/busses/i2c-wmt.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
41 files changed, 95 insertions(+), 95 deletions(-)
diff --git a/drivers/i2c/busses/i2c-amd-mp2-plat.c
b/drivers/i2c/busses/i2c-amd-mp2-plat.c
index 112fe2bc5662..eb47de29ec90 100644
--- a/drivers/i2c/busses/i2c-amd-mp2-plat.c
+++ b/drivers/i2c/busses/i2c-amd-mp2-plat.c
@@ -179,7 +179,7 @@ static u32 i2c_amd_func(struct i2c_adapter *a)
}
static const struct i2c_algorithm i2c_amd_algorithm = {
- .master_xfer = i2c_amd_xfer,
+ .xfer = i2c_amd_xfer,
.functionality = i2c_amd_func,
};
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index d311981d3e60..56223eee7755 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -739,7 +739,7 @@ static u32 at91_twi_func(struct i2c_adapter *adapter)
}
static const struct i2c_algorithm at91_twi_algorithm = {
- .master_xfer= at91_twi_xfer,
+ .xfer = at91_twi_xfer,
.functionality = at91_twi_func,
};
diff --git a/drivers/i2c/busses/i2c-at91-slave.c
b/drivers/i2c/busses/i2c-at91-slave.c
index d6eeea5166c0..00234bf776ab 100644
--- a/drivers/i2c/busses/i2c-at91-slave.c
+++ b/drivers/i2c/busses/i2c-at91-slave.c
@@ -62,7 +62,7 @@ static irqreturn_t atmel_twi_interrupt_slave(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static int at91_reg_slave(struct i2c_client *slave)
+static int at91_reg_target(struct i2c_client *slave)
{
struct at91_twi_dev *dev = i2c_get_adapdata(slave->adapter);
@@ -86,7 +86,7 @@ static int at91_reg_slave(struct i2c_client *slave)
return 0;
}
-static int at91_unreg_slave(struct i2c_client *slave)
+static int at91_unreg_target(struct i2c_client *slave)
{
struct at91_twi_dev *dev = i2c_get_adapdata(slave->adapter);
@@ -111,8 +111,8 @@ static u32 at91_twi_func(struct i2c_adapter *adapter)
}
static const struct i2c_algorithm at91_twi_algorithm_slave = {
- .reg_slave = at91_reg_slave,
- .unreg_slave= at91_unreg_slave,
+ .reg_target = at91_reg_target,
+ .unreg_target = at91_unreg_target,
.functionality = at91_twi_func,
};
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index a66f7f67b3b8..19545a44dbc9 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/dr
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> Kind of odd though to change function names but not parameter names of > those very same functions. Ouch, this is definitely a valid point. Seems like this series will need a respin after all. Will wait for further comments, though. Thanks! signature.asc Description: PGP signature
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> > static const struct i2c_algorithm at91_twi_algorithm = {
> > - .master_xfer= at91_twi_xfer,
> > + .xfer = at91_twi_xfer,
>
> Seems you made this by a script, can you check the indentations afterwards?
Yes, I noticed as well. But other (not converted) drivers have issues
there as well, so this will be a seperate patch.
Thanks!
signature.asc
Description: PGP signature
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> Acked-by: Nicolas Ferre # for at91 > Probably file names themselves will need some care, in a second time. Totally true. I am aware of that. But one step after the other... signature.asc Description: PGP signature
[PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C
v7, SMBus 3.2, I3C specifications and replace "master/slave" with more
appropriate terms. For some drivers, this means no more conversions are
needed. For the others more work needs to be done but this will be
performed incrementally along with API changes/improvements. All these
changes here are simple search/replace results.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-amd-mp2-plat.c | 2 +-
drivers/i2c/busses/i2c-at91-master.c | 2 +-
drivers/i2c/busses/i2c-at91-slave.c| 8
drivers/i2c/busses/i2c-axxia.c | 10 +-
drivers/i2c/busses/i2c-cros-ec-tunnel.c| 2 +-
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/i2c/busses/i2c-designware-slave.c | 8
drivers/i2c/busses/i2c-diolan-u2c.c| 2 +-
drivers/i2c/busses/i2c-exynos5.c | 4 ++--
drivers/i2c/busses/i2c-gxp.c | 12 ++--
drivers/i2c/busses/i2c-hisi.c | 4 ++--
drivers/i2c/busses/i2c-img-scb.c | 2 +-
drivers/i2c/busses/i2c-imx.c | 12 ++--
drivers/i2c/busses/i2c-jz4780.c| 2 +-
drivers/i2c/busses/i2c-kempld.c| 2 +-
drivers/i2c/busses/i2c-meson.c | 4 ++--
drivers/i2c/busses/i2c-mlxbf.c | 8
drivers/i2c/busses/i2c-mt65xx.c| 2 +-
drivers/i2c/busses/i2c-mxs.c | 2 +-
drivers/i2c/busses/i2c-nomadik.c | 2 +-
drivers/i2c/busses/i2c-npcm7xx.c | 12 ++--
drivers/i2c/busses/i2c-nvidia-gpu.c| 4 ++--
drivers/i2c/busses/i2c-ocores.c| 8
drivers/i2c/busses/i2c-octeon-platdrv.c| 2 +-
drivers/i2c/busses/i2c-omap.c | 4 ++--
drivers/i2c/busses/i2c-opal.c | 4 ++--
drivers/i2c/busses/i2c-pasemi-core.c | 2 +-
drivers/i2c/busses/i2c-pnx.c | 2 +-
drivers/i2c/busses/i2c-pxa.c | 12 ++--
drivers/i2c/busses/i2c-qcom-cci.c | 2 +-
drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
drivers/i2c/busses/i2c-robotfuzz-osif.c| 2 +-
drivers/i2c/busses/i2c-rzv2m.c | 8
drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
drivers/i2c/busses/i2c-stm32f7.c | 14 +++---
drivers/i2c/busses/i2c-tegra-bpmp.c| 4 ++--
drivers/i2c/busses/i2c-tegra.c | 4 ++--
drivers/i2c/busses/i2c-thunderx-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-virtio.c| 2 +-
drivers/i2c/busses/i2c-wmt.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
41 files changed, 95 insertions(+), 95 deletions(-)
diff --git a/drivers/i2c/busses/i2c-amd-mp2-plat.c
b/drivers/i2c/busses/i2c-amd-mp2-plat.c
index 112fe2bc5662..eb47de29ec90 100644
--- a/drivers/i2c/busses/i2c-amd-mp2-plat.c
+++ b/drivers/i2c/busses/i2c-amd-mp2-plat.c
@@ -179,7 +179,7 @@ static u32 i2c_amd_func(struct i2c_adapter *a)
}
static const struct i2c_algorithm i2c_amd_algorithm = {
- .master_xfer = i2c_amd_xfer,
+ .xfer = i2c_amd_xfer,
.functionality = i2c_amd_func,
};
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index d311981d3e60..56223eee7755 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -739,7 +739,7 @@ static u32 at91_twi_func(struct i2c_adapter *adapter)
}
static const struct i2c_algorithm at91_twi_algorithm = {
- .master_xfer= at91_twi_xfer,
+ .xfer = at91_twi_xfer,
.functionality = at91_twi_func,
};
diff --git a/drivers/i2c/busses/i2c-at91-slave.c
b/drivers/i2c/busses/i2c-at91-slave.c
index d6eeea5166c0..00234bf776ab 100644
--- a/drivers/i2c/busses/i2c-at91-slave.c
+++ b/drivers/i2c/busses/i2c-at91-slave.c
@@ -62,7 +62,7 @@ static irqreturn_t atmel_twi_interrupt_slave(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static int at91_reg_slave(struct i2c_client *slave)
+static int at91_reg_target(struct i2c_client *slave)
{
struct at91_twi_dev *dev = i2c_get_adapdata(slave->adapter);
@@ -86,7 +86,7 @@ static int at91_reg_slave(struct i2c_client *slave)
return 0;
}
-static int at91_unreg_slave(struct i2c_client *slave)
+static int at91_unreg_target(struct i2c_client *slave)
{
struct at91_twi_dev *dev = i2c_get_adapdata(slave->adapter);
@@ -111,8 +111,8 @@ static u32 at91_twi_func(struct i2c_adapter *adapter)
}
static const struct i2c_algorithm at91_twi_algorithm_slave = {
- .reg_slave = at91_reg_slave,
- .unreg_slave= at91_unreg_slave,
+ .reg_target = at91_reg_target,
+ .unreg_target = at91_unreg_target,
.functionality = at91_twi_func,
};
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index a66f7f67b3b8..19545a44dbc9 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/dr
[PATCH 42/64] i2c: powermac: reword according to newest specification
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-powermac.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8e57ebe595be..03abc5f3cb9e 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -25,7 +25,7 @@ MODULE_LICENSE("GPL");
/*
* SMBUS-type transfer entrypoint
*/
-static s32 i2c_powermac_smbus_xfer(struct i2c_adapter* adap,
+static s32 i2c_powermac_smbus_xfer(struct i2c_adapter *adap,
u16 addr,
unsigned short flags,
charread_write,
@@ -127,11 +127,11 @@ static s32 i2c_powermac_smbus_xfer( struct
i2c_adapter* adap,
}
/*
- * Generic i2c master transfer entrypoint. This driver only support single
+ * Generic i2c transfer entrypoint. This driver only supports single
* messages (for "lame i2c" transfers). Anything else should use the smbus
* entry point
*/
-static int i2c_powermac_master_xfer( struct i2c_adapter *adap,
+static int i2c_powermac_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
int num)
{
@@ -180,7 +180,7 @@ static u32 i2c_powermac_func(struct i2c_adapter * adapter)
/* For now, we only handle smbus */
static const struct i2c_algorithm i2c_powermac_algorithm = {
.smbus_xfer = i2c_powermac_smbus_xfer,
- .master_xfer= i2c_powermac_master_xfer,
+ .xfer = i2c_powermac_xfer,
.functionality = i2c_powermac_func,
};
--
2.43.0
[PATCH 14/64] i2c: cpm: reword according to newest specification
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-cpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 4404b4aac676..306e397fec0a 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -402,7 +402,7 @@ static u32 cpm_i2c_func(struct i2c_adapter *adap)
/* -exported algorithm data: - */
static const struct i2c_algorithm cpm_i2c_algo = {
- .master_xfer = cpm_i2c_xfer,
+ .xfer = cpm_i2c_xfer,
.functionality = cpm_i2c_func,
};
@@ -570,7 +570,7 @@ static int cpm_i2c_setup(struct cpm_i2c *cpm)
out_8(>i2c_reg->i2brg, brg);
out_8(>i2c_reg->i2mod, 0x00);
- out_8(>i2c_reg->i2com, I2COM_MASTER); /* Master mode */
+ out_8(>i2c_reg->i2com, I2COM_MASTER); /* Host mode */
/* Disable interrupts. */
out_8(>i2c_reg->i2cmr, 0);
--
2.43.0
[PATCH 00/64] i2c: reword i2c_algorithm according to newest specification
Okay, we need to begin somewhere... Start changing the wording of the I2C main header wrt. the newest I2C v7, SMBus 3.2, I3C specifications and replace "master/slave" with more appropriate terms. This first step renames the members of struct i2c_algorithm. Once all in-tree users are converted, the anonymous union will go away again. All this work will also pave the way for finally seperating the monolithic header into more fine-grained headers like "i2c/clients.h" etc. So, this is not a simple renaming-excercise but also a chance to update the I2C core to recent Linux standards. My motivation is to improve the I2C core API, in general. My motivation is not to clean each and every driver. I think this is impossible because register names based on official documentation will need to stay as they are. But the Linux-internal names should be updated IMO. That being said, I worked on 62 drivers in this series beyond plain renames inside 'struct i2c_algorithm' because the fruits were so low-hanging. Before this series, 112 files in the 'busses/' directory contained 'master' and/or 'slave'. After the series, only 57. Why not? Next step is updating the drivers outside the 'i2c'-folder regarding 'struct i2c_algorithm' so we can remove the anonymous union ASAP. To be able to work on this with minimal dependencies, I'd like to apply this series between -rc1 and -rc2. I hope this will work for you guys. The changes are really minimal. If you are not comfortable with changes to your driver or need more time to review, please NACK the patch and I will drop the patch and/or address the issues separeately. @Andi: are you okay with this approach? It means you'd need to merge -rc2 into your for-next branch. Or rebase if all fails. Speaking of Andi, thanks a lot to him taking care of the controller drivers these days. His work really gives me the freedom to work on I2C core issues again. Also, Renesas deserves a honorable mention here for increased support of my I2C activities. Thank you! If you have comments, hints, etc, please let me know. Happy hacking, Wolfram Wolfram Sang (64): i2c: reword i2c_algorithm according to newest specification i2c: ali15x3: reword according to newest specification i2c: altera: reword according to newest specification i2c: amd-mp2-pci: reword according to newest specification i2c: aspeed: reword according to newest specification i2c: au1550: reword according to newest specification i2c: bcm-iproc: reword according to newest specification i2c: bcm-kona: reword according to newest specification i2c: bcm2835: reword according to newest specification i2c: brcmstb: reword according to newest specification i2c: cadence: reword according to newest specification i2c: cht-wc: reword according to newest specification i2c: cp2615: reword according to newest specification i2c: cpm: reword according to newest specification i2c: davinci: reword according to newest specification i2c: digicolor: reword according to newest specification i2c: dln2: reword according to newest specification i2c: eg20t: reword according to newest specification i2c: emev2: reword according to newest specification i2c: fsi: reword according to newest specification i2c: gpio: reword according to newest specification i2c: highlander: reword according to newest specification i2c: hix5hd2: reword according to newest specification i2c: i801: reword according to newest specification i2c: ibm_iic: reword according to newest specification i2c: imx-lpi2c: reword according to newest specification i2c: iop3xx: reword according to newest specification i2c: isch: reword according to newest specification i2c: ismt: reword according to newest specification i2c: ljca: reword according to newest specification i2c: lpc2k: reword according to newest specification i2c: ls2x: reword according to newest specification i2c: mchp-pci1: reword according to newest specification i2c: microchip-corei2c: reword according to newest specification i2c: mlxcpld: reword according to newest specification i2c: mpc: reword according to newest specification i2c: mt7621: reword according to newest specification i2c: mv64xxx: reword according to newest specification i2c: octeon-core: reword according to newest specification i2c: owl: reword according to newest specification i2c: piix4: reword according to newest specification i2c: powermac: reword according to newest specification i2c: pxa-pci: reword according to newest specification i2c: qup: reword according to newest specification i2c: rcar: reword according to newest specification i2c: riic: reword according to newest specification i2c: rk3x: reword according to newest specification i2c: sh7760: reword according to newest specification i2c: sh_mobile: reword according to newest specification i2c: sis5595: reword according to newest specification i2c: sis630: reword according to
[PATCH 00/64] i2c: reword i2c_algorithm according to newest specification
Okay, we need to begin somewhere... Start changing the wording of the I2C main header wrt. the newest I2C v7, SMBus 3.2, I3C specifications and replace "master/slave" with more appropriate terms. This first step renames the members of struct i2c_algorithm. Once all in-tree users are converted, the anonymous union will go away again. All this work will also pave the way for finally seperating the monolithic header into more fine-grained headers like "i2c/clients.h" etc. So, this is not a simple renaming-excercise but also a chance to update the I2C core to recent Linux standards. My motivation is to improve the I2C core API, in general. My motivation is not to clean each and every driver. I think this is impossible because register names based on official documentation will need to stay as they are. But the Linux-internal names should be updated IMO. That being said, I worked on 62 drivers in this series beyond plain renames inside 'struct i2c_algorithm' because the fruits were so low-hanging. Before this series, 112 files in the 'busses/' directory contained 'master' and/or 'slave'. After the series, only 57. Why not? Next step is updating the drivers outside the 'i2c'-folder regarding 'struct i2c_algorithm' so we can remove the anonymous union ASAP. To be able to work on this with minimal dependencies, I'd like to apply this series between -rc1 and -rc2. I hope this will work for you guys. The changes are really minimal. If you are not comfortable with changes to your driver or need more time to review, please NACK the patch and I will drop the patch and/or address the issues separeately. @Andi: are you okay with this approach? It means you'd need to merge -rc2 into your for-next branch. Or rebase if all fails. Speaking of Andi, thanks a lot to him taking care of the controller drivers these days. His work really gives me the freedom to work on I2C core issues again. Also, Renesas deserves a honorable mention here for increased support of my I2C activities. Thank you! If you have comments, hints, etc, please let me know. Happy hacking, Wolfram Wolfram Sang (64): i2c: reword i2c_algorithm according to newest specification i2c: ali15x3: reword according to newest specification i2c: altera: reword according to newest specification i2c: amd-mp2-pci: reword according to newest specification i2c: aspeed: reword according to newest specification i2c: au1550: reword according to newest specification i2c: bcm-iproc: reword according to newest specification i2c: bcm-kona: reword according to newest specification i2c: bcm2835: reword according to newest specification i2c: brcmstb: reword according to newest specification i2c: cadence: reword according to newest specification i2c: cht-wc: reword according to newest specification i2c: cp2615: reword according to newest specification i2c: cpm: reword according to newest specification i2c: davinci: reword according to newest specification i2c: digicolor: reword according to newest specification i2c: dln2: reword according to newest specification i2c: eg20t: reword according to newest specification i2c: emev2: reword according to newest specification i2c: fsi: reword according to newest specification i2c: gpio: reword according to newest specification i2c: highlander: reword according to newest specification i2c: hix5hd2: reword according to newest specification i2c: i801: reword according to newest specification i2c: ibm_iic: reword according to newest specification i2c: imx-lpi2c: reword according to newest specification i2c: iop3xx: reword according to newest specification i2c: isch: reword according to newest specification i2c: ismt: reword according to newest specification i2c: ljca: reword according to newest specification i2c: lpc2k: reword according to newest specification i2c: ls2x: reword according to newest specification i2c: mchp-pci1: reword according to newest specification i2c: microchip-corei2c: reword according to newest specification i2c: mlxcpld: reword according to newest specification i2c: mpc: reword according to newest specification i2c: mt7621: reword according to newest specification i2c: mv64xxx: reword according to newest specification i2c: octeon-core: reword according to newest specification i2c: owl: reword according to newest specification i2c: piix4: reword according to newest specification i2c: powermac: reword according to newest specification i2c: pxa-pci: reword according to newest specification i2c: qup: reword according to newest specification i2c: rcar: reword according to newest specification i2c: riic: reword according to newest specification i2c: rk3x: reword according to newest specification i2c: sh7760: reword according to newest specification i2c: sh_mobile: reword according to newest specification i2c: sis5595: reword according to newest specification i2c: sis630: reword according to
Re: [sane-devel] Release issues
Hi Ralph, > I won't get chance until Wednesday to deal with this further, so please > bear with me as it is the first time trying to do this. No worries from my side. Thanks a lot for doing this! I just created a MR with some documentation updates. Would be nice to have them in the release but doesn't hurt if not. Dunno how far you are into the release cycle. I can also merge it if it is easier for you... Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [Openipmi-developer] [PATCH] ipmi: ipmb: Remove I2C_CLASS_HWMON from drivers w/o detect and address_list
On Sat, Jan 27, 2024 at 04:15:06PM +0100, Heiner Kallweit wrote: > Class-based I2C probing requires detect() and address_list to be > set in the I2C client driver, see checks in i2c_detect(). > It's misleading to declare I2C_CLASS_HWMON support if this > precondition isn't met. > > Signed-off-by: Heiner Kallweit Reviewed-by: Wolfram Sang signature.asc Description: PGP signature ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [PATCH] fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH
On Wed, Jan 31, 2024 at 05:08:23PM +0100, Geert Uytterhoeven wrote:
> Since commit f402f7a02af6956d ("staging: board: Remove Armadillo-800-EVA
> board staging code"), there are no more users of the legacy SuperH
> Mobile LCDC framebuffer driver on Renesas ARM platforms. All former
> users on these platforms have been converted to the SH-Mobile DRM
> driver, using DT.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
Re: [sane-devel] Proposed timeline for 1.3.0 release
Hi, > 1) Code freeze: 1 week from now (28th January), I will create a release > branch and MRs targeted for the release should target that branch. Anything Thanks for the heads up. I'll try to get as much as possible of the pending epson2 stuff done until Sunday. Happy hacking, Wolfram signature.asc Description: PGP signature
Bug#1061403: python3-pykwalify: Missing dependencies to docopt and dateutil
Package: python3-pykwalify
Version: 1.8.0-2
Severity: important
Dear Maintainer,
after upgrading to latest bookworm (but happened also with trixie),
running pykwalify failed with:
File "/usr/bin/pykwalify", line 33, in
sys.exit(load_entry_point('pykwalify==1.8.0', 'console_scripts',
'pykwalify')())
File "/usr/bin/pykwalify", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/pykwalify/cli.py", line 11, in
from docopt import docopt
ModuleNotFoundError: No module named 'docopt'
After manually installing python3-docopt, the same happened for module
'dateutil'. With both modules installed, everything works fine again.
Upstream explicitly mentions these packages as "required
dependencies"[1]. Yet, I don't see the dependencies mentioned in the
Debian package. I haven't researched why it worked before the update,
but I think the dependencies should be added in any case.
Thank you for your work,
Wolfram
[1] https://pykwalify.readthedocs.io/en/unstable/
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python3-pykwalify depends on:
ii python3 3.11.4-5+b1
Versions of packages python3-pykwalify recommends:
ii python3-ruamel.yaml 0.17.21-1
python3-pykwalify suggests no packages.
-- no debconf information
Re: [sane-devel] Release 1.3 anyone?
Hi, > I was looking through the supported scanners recently. Epson Expression > 12000XL (overseas version of the DS-G2) is listed as Complete support > with the epson2 backend. Yep, I am/was using this one. > I think the new model is Epson Expression 13000XL (probably the > overseas version of DS-G3). I wonder if this scanner is also > supported. This is one of the only high-grade flatbed scanners made > today, and it would be nice to be sure and keep documented if SANE > supports it. I am not aware of any reports. Might be worth looking around the net for such a report. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v2] i2c: cpm: Remove linux,i2c-index conversion from be32
On Wed, Dec 06, 2023 at 11:24:03PM +0100, Christophe Leroy wrote: > sparse reports an error on some data that gets converted from be32. > > That's because that data is typed u32 instead of __be32. > > The type is correct, the be32_to_cpu() conversion is not. > > Remove the conversion. > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202312042210.ql4da8av-...@intel.com/ > Signed-off-by: Christophe Leroy Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v2 00/10] Don't let i2c adapters declare I2C_CLASS_SPD support if they support I2C_CLASS_HWMON
> This series and my other series are sitting idle in patchwork > for 3 weeks now. AFAICS they have the needed ack's. > Anything missing before they can be applied? Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] drm/amd/pm: Remove I2C_CLASS_SPD support
On Mon, Nov 13, 2023 at 12:37:15PM +0100, Heiner Kallweit wrote: > I2C_CLASS_SPD was used to expose the EEPROM content to user space, > via the legacy eeprom driver. Now that this driver has been removed, > we can remove I2C_CLASS_SPD support. at24 driver with explicit > instantiation should be used instead. > > If in doubt this patch could be applied via the i2c tree. > > Signed-off-by: Heiner Kallweit Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] drm/amd/pm: Remove I2C_CLASS_SPD support
On Mon, Nov 13, 2023 at 12:37:15PM +0100, Heiner Kallweit wrote: > I2C_CLASS_SPD was used to expose the EEPROM content to user space, > via the legacy eeprom driver. Now that this driver has been removed, > we can remove I2C_CLASS_SPD support. at24 driver with explicit > instantiation should be used instead. > > If in doubt this patch could be applied via the i2c tree. > > Signed-off-by: Heiner Kallweit Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
> I created an immutable branch for this which the buildbots will > hopefully check over night. I will reply with comments tomorrow when I > got the buildbot results. Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
> I created an immutable branch for this which the buildbots will > hopefully check over night. I will reply with comments tomorrow when I > got the buildbot results. Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
> I created an immutable branch for this which the buildbots will > hopefully check over night. I will reply with comments tomorrow when I > got the buildbot results. Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
> I created an immutable branch for this which the buildbots will > hopefully check over night. I will reply with comments tomorrow when I > got the buildbot results. Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v5 00/20] remove I2C_CLASS_DDC support
On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote: > After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in > olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. > Class-based device auto-detection is a legacy mechanism and shouldn't > be used in new code. So we can remove this class completely now. > > Preferably this series should be applied via the i2c tree. > > v2: > - change tag in commit subject of patch 03 > - add ack tags > v3: > - fix a compile error in patch 5 > v4: > - more ack and review tags > v5: > - more acks > > Signed-off-by: Heiner Kallweit I created an immutable branch for this which the buildbots will hopefully check over night. I will reply with comments tomorrow when I got the buildbot results. signature.asc Description: PGP signature
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote: > After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in > olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. > Class-based device auto-detection is a legacy mechanism and shouldn't > be used in new code. So we can remove this class completely now. > > Preferably this series should be applied via the i2c tree. > > v2: > - change tag in commit subject of patch 03 > - add ack tags > v3: > - fix a compile error in patch 5 > v4: > - more ack and review tags > v5: > - more acks > > Signed-off-by: Heiner Kallweit I created an immutable branch for this which the buildbots will hopefully check over night. I will reply with comments tomorrow when I got the buildbot results. signature.asc Description: PGP signature
Re: [Freedreno] [PATCH v5 00/20] remove I2C_CLASS_DDC support
On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote: > After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in > olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. > Class-based device auto-detection is a legacy mechanism and shouldn't > be used in new code. So we can remove this class completely now. > > Preferably this series should be applied via the i2c tree. > > v2: > - change tag in commit subject of patch 03 > - add ack tags > v3: > - fix a compile error in patch 5 > v4: > - more ack and review tags > v5: > - more acks > > Signed-off-by: Heiner Kallweit I created an immutable branch for this which the buildbots will hopefully check over night. I will reply with comments tomorrow when I got the buildbot results. signature.asc Description: PGP signature
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote: > After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in > olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. > Class-based device auto-detection is a legacy mechanism and shouldn't > be used in new code. So we can remove this class completely now. > > Preferably this series should be applied via the i2c tree. > > v2: > - change tag in commit subject of patch 03 > - add ack tags > v3: > - fix a compile error in patch 5 > v4: > - more ack and review tags > v5: > - more acks > > Signed-off-by: Heiner Kallweit I created an immutable branch for this which the buildbots will hopefully check over night. I will reply with comments tomorrow when I got the buildbot results. signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH 00/20] remove I2C_CLASS_DDC support
> We're not in a hurry. It's just my experience with patch series' affecting > multiple subsystems that typically the decision was to apply the full > series via one tree. Also to avoid inquires from maintainers like: > Shall I take it or are you going to take it? > Of course there may be different opinions. Please advise. Ok, then this turns out to be a negotation thing between the drm/fbdev maintainers and me. I *can* take all the patches, of course. But since the number of patches touching the non-i2c subsystems is high, I'd like to hear their preference, too. signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH 00/20] remove I2C_CLASS_DDC support
> Preferably this series should be applied via the i2c tree. Are we in a hurry here, i.e. does it block further development of the i801 smbus driver? My gut feeling says the patches should rather go via drm and fbdev trees, but I may be convinced otherwise. signature.asc Description: PGP signature
Re: [PATCH 00/20] remove I2C_CLASS_DDC support
> We're not in a hurry. It's just my experience with patch series' affecting > multiple subsystems that typically the decision was to apply the full > series via one tree. Also to avoid inquires from maintainers like: > Shall I take it or are you going to take it? > Of course there may be different opinions. Please advise. Ok, then this turns out to be a negotation thing between the drm/fbdev maintainers and me. I *can* take all the patches, of course. But since the number of patches touching the non-i2c subsystems is high, I'd like to hear their preference, too. signature.asc Description: PGP signature
Re: [PATCH 00/20] remove I2C_CLASS_DDC support
> We're not in a hurry. It's just my experience with patch series' affecting > multiple subsystems that typically the decision was to apply the full > series via one tree. Also to avoid inquires from maintainers like: > Shall I take it or are you going to take it? > Of course there may be different opinions. Please advise. Ok, then this turns out to be a negotation thing between the drm/fbdev maintainers and me. I *can* take all the patches, of course. But since the number of patches touching the non-i2c subsystems is high, I'd like to hear their preference, too. signature.asc Description: PGP signature
Re: [Freedreno] [PATCH 00/20] remove I2C_CLASS_DDC support
> We're not in a hurry. It's just my experience with patch series' affecting > multiple subsystems that typically the decision was to apply the full > series via one tree. Also to avoid inquires from maintainers like: > Shall I take it or are you going to take it? > Of course there may be different opinions. Please advise. Ok, then this turns out to be a negotation thing between the drm/fbdev maintainers and me. I *can* take all the patches, of course. But since the number of patches touching the non-i2c subsystems is high, I'd like to hear their preference, too. signature.asc Description: PGP signature
Re: [PATCH 00/20] remove I2C_CLASS_DDC support
> Preferably this series should be applied via the i2c tree. Are we in a hurry here, i.e. does it block further development of the i801 smbus driver? My gut feeling says the patches should rather go via drm and fbdev trees, but I may be convinced otherwise. signature.asc Description: PGP signature
Re: [PATCH 00/20] remove I2C_CLASS_DDC support
> Preferably this series should be applied via the i2c tree. Are we in a hurry here, i.e. does it block further development of the i801 smbus driver? My gut feeling says the patches should rather go via drm and fbdev trees, but I may be convinced otherwise. signature.asc Description: PGP signature
Re: [Freedreno] [PATCH 00/20] remove I2C_CLASS_DDC support
> Preferably this series should be applied via the i2c tree. Are we in a hurry here, i.e. does it block further development of the i801 smbus driver? My gut feeling says the patches should rather go via drm and fbdev trees, but I may be convinced otherwise. signature.asc Description: PGP signature
Re: [PATCH 03/17] dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoC
On Wed, Nov 08, 2023 at 11:43:29AM +0100, Krzysztof Kozlowski wrote: > Samsung Exynos SoC reuses several devices from older designs, thus > historically we kept the old (block's) compatible only. This works fine > and there is no bug here, however guidelines expressed in > Documentation/devicetree/bindings/writing-bindings.rst state that: > 1. Compatibles should be specific. > 2. We should add new compatibles in case of bugs or features. > > Add compatibles specific to each SoC in front of all old-SoC-like > compatibles. > > Signed-off-by: Krzysztof Kozlowski > > --- > > I propose to take the patch through Samsung SoC (me). See cover letter > for explanation. I am fine that you take it once all review comments are addressed. Given that: Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 02/17] dt-bindings: i2c: exynos5: add specific compatibles for existing SoC
On Wed, Nov 08, 2023 at 11:43:28AM +0100, Krzysztof Kozlowski wrote: > Samsung Exynos SoC reuses several devices from older designs, thus > historically we kept the old (block's) compatible only. This works fine > and there is no bug here, however guidelines expressed in > Documentation/devicetree/bindings/writing-bindings.rst state that: > 1. Compatibles should be specific. > 2. We should add new compatibles in case of bugs or features. > > Add compatibles specific to each SoC in front of all old-SoC-like > compatibles. > > Signed-off-by: Krzysztof Kozlowski > > --- > > I propose to take the patch through Samsung SoC (me). See cover letter > for explanation. I am fine that you take it once all review comments are addressed. Given that: Acked-by: Wolfram Sang signature.asc Description: PGP signature
[PATCH v3] drm: renesas: rcar-du: use proper naming for R-Car
Not RCAR, but R-Car. Signed-off-by: Wolfram Sang Reviewed-by: Kieran Bingham Reviewed-by: Geert Uytterhoeven --- Changes since v2: * rebased to 6.6 * added Geert's tag (thanks!) drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h index f9893d7d6dfc..e9e59c5e70d5 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h @@ -16,7 +16,7 @@ struct rcar_du_format_info; struct rcar_du_group; /* - * The RCAR DU has 8 hardware planes, shared between primary and overlay planes. + * The R-Car DU has 8 hardware planes, shared between primary and overlay planes. * As using overlay planes requires at least one of the CRTCs being enabled, no * more than 7 overlay planes can be available. We thus create 1 primary plane * per CRTC and 7 overlay planes, for a total of up to 9 KMS planes. -- 2.35.1
Re: [PATCH v1 0/2] [PATCH] hwmon: (pmbus/max31785) Add minimum delay between bus accesses
Hi Guenter, > I didn't (want to) say that. I am perfectly happy with driver specific > code, and I would personally still very much prefer it. I only wanted to > suggest that _if_ a generic solution is implemented, it should cover all > existing use cases and not just this one. But, really, I'd rather leave > that alone and not risk introducing regressions to existing drivers. Okay, seems we are aligned again :) > I don't know about this device, but in general the problem is that the > devices need some delay between some or all transfers or otherwise react > badly in one way or another. The problem is not always the same. Ok, that again doesn't speak for a generic solution IMO. > Lower bus frequencies don't help, at least not for the devices where > I have seen to problem myself. The issue is not bus speed, but time between > transfers. Typically the underlying problem is that there is some > microcontroller on the affected chips, and the microcode is less than > perfect. For example, the microcode may not poll its I2C interface > while it is busy writing into the chip's internal EEPROM or while it is > updating some internal parameters as result of a previous I2C transfer. I see. Well, as you probably know, EEPROMs not reacting because they are busy with an erase cycle is well-known in the I2C world. The bus driver reports that the transfer couldn't get through, and then the EEPROM driver knows the details and does something apropriate, probably waiting a while. This assumes that the EEPROM can still play well on the I2C bus. If a faulty device will lock up a bus because of bad microcode while it is busy, then it surely needs handling of that :( And this convinces me just more that it should be in the driver... > The latter. I never bothered trying to write up a list. Typically the behavior > is not documented and needs to be tweaked a couple of times, and it may be > different across chips supported by the same driver, or even across chip > revisions. Any list trying to keep track of the various details would > be difficult to maintain and notoriously be outdated. ... especially because of that. If there is really some repeating pattern for some of the devices, we could introduce helper functions for the drivers to use maybe. But the I2C core functions are not the place to handle it. All the best, Wolfram signature.asc Description: PGP signature
Re: [PATCH v1 0/2] [PATCH] hwmon: (pmbus/max31785) Add minimum delay between bus accesses
Hi Guenter, > > > Reference to Andrew's previous proposal: > > > https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/ > > > > I do totally agree with Guenter's comment[1], though. This just affects > > a few drivers and this patch is way too intrusive for the I2C core. The > > later suggested prepare_device() callback[2] sounds better to me. I > > still haven't fully understood why this all cannot be handled in the > > driver's probe. Could someone give me a small summary about that? > > > > Lots of PMBus devices have the same problem, we have always handled > it in PMBus drivers by implementing local wait code, and your references > point that out. I am confused now. Reading your reply: "I am not sure if an implementation in the i2c core is desirable. It looks quite invasive to me, and it won't solve the problem for all devices since it isn't always a simple "wait microseconds between accesses". For example, some devices may require a wait after a write but not after a read, or a wait only after certain commands (such as commands writing to an EEPROM)." I get the impression you don't prefer to have a generic mechanism in the I2C core. This I share. Your response now sounds like you do support that idea now? > What other summary are you looking for ? What the actual problem is with these devices. The cover letter only mentions "issues with small command turn-around times". More details would be nice. Is it between transfers? Or even between messages within one transfer? Has it been tried to lower the bus frequency? Stuff like this. > On a side note, if anyone plans to implement the prepare_device() callback, > please make sure that it covers all requirements. It would be unfortunate > if such a callback was implemented if that would still require per-driver > code (besides the callback). Is there a list of that somewhere? Or does it mean going through all the drivers and see what they currently do? Regards, Wolfram signature.asc Description: PGP signature
Re: [PATCH v1 0/2] [PATCH] hwmon: (pmbus/max31785) Add minimum delay between bus accesses
Hi, thanks for this series! > Reference to Andrew's previous proposal: > https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/ I do totally agree with Guenter's comment[1], though. This just affects a few drivers and this patch is way too intrusive for the I2C core. The later suggested prepare_device() callback[2] sounds better to me. I still haven't fully understood why this all cannot be handled in the driver's probe. Could someone give me a small summary about that? All the best, Wolfram [1] https://lore.kernel.org/all/e7a64983-fe1d-1ba2-b0c3-ae4a791f7...@roeck-us.net/ [2] https://lore.kernel.org/all/120342ec-f44a-4550-8c54-45b97db41...@www.fastmail.com/ signature.asc Description: PGP signature
Re: [PATCH 3/3] PCI: Use PCI_HEADER_TYPE_* instead of literals
On Tue, Oct 03, 2023 at 03:53:00PM +0300, Ilpo Järvinen wrote: > Replace literals under drivers/pci/ with PCI_HEADER_TYPE_MASK, > PCI_HEADER_TYPE_NORMAL, and PCI_HEADER_TYPE_MFD. > > While at it, replace !! boolean conversion with FIELD_GET(). > > Signed-off-by: Ilpo Järvinen Reviewed-by: Wolfram Sang # for Renesas R-Car signature.asc Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: i2c: qcom-cci: Document SC7280 compatible
On Mon, Oct 02, 2023 at 08:55:30AM +0200, Luca Weiss wrote: > Document the compatible for the CCI block found on SC7280 SoC. > > Reviewed-by: Bryan O'Donoghue > Signed-off-by: Luca Weiss Applied to for-next, thanks! signature.asc Description: PGP signature
OFFLIST Re: [PATCH 0/5] ARM: at91: add first DT support for Calao usb/tny boards
Hi! > This is not yet a complete replacement: > > - We use the legacy NAND driver instead of the newly backported driver > that Linux uses with the hardware, presumably without issues > > - OHCI hangs during probe, so it's disabled for now > > - A barebox with comparative functionality to the non-DT version > exceeds the 256K partition size Aber brauchst Du das Gerät dann nicht noch etwas für diese Sachen? Grüße nach Paris, Wolfram signature.asc Description: PGP signature
Re: [PATCH] media: i2c: Annotate struct i2c_atr with __counted_by
On Fri, Sep 22, 2023 at 10:54:25AM -0700, Kees Cook wrote: > Prepare for the coming implementation by GCC and Clang of the __counted_by > attribute. Flexible array members annotated with __counted_by can have > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > functions). > > As found with Coccinelle[1], add __counted_by for struct i2c_atr. > > [1] > https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci > > Cc: Wolfram Sang > Cc: Tomi Valkeinen > Cc: Luca Ceresoli > Cc: Nathan Chancellor > Cc: Nick Desaulniers > Cc: Tom Rix > Cc: linux-...@vger.kernel.org > Cc: l...@lists.linux.dev > Signed-off-by: Kees Cook Removed "media: " from $subject and applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] i2c: mux: demux-pinctrl: Annotate struct i2c_demux_pinctrl_priv with __counted_by
On Fri, Sep 22, 2023 at 10:49:59AM -0700, Kees Cook wrote: > Prepare for the coming implementation by GCC and Clang of the __counted_by > attribute. Flexible array members annotated with __counted_by can have > their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > functions). > > As found with Coccinelle[1], add __counted_by for struct > i2c_demux_pinctrl_priv. > Additionally, since the element count member must be set before accessing > the annotated flexible array member, move its initialization earlier. > > [1] > https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci > > Cc: Wolfram Sang > Cc: Peter Rosin > Cc: linux-...@vger.kernel.org > Signed-off-by: Kees Cook Fixed a blank line and applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] i2c: replace deprecated strncpy
On Wed, Sep 20, 2023 at 11:07:35AM +, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > We should prefer more robust and less ambiguous string interfaces. > > `info.type` is expected to be NUL-terminated judging by its use in > `i2c_new_client_device()` wherein it is used to populate `client->name`: > | strscpy(client->name, info->type, sizeof(client->name)); > > NUL-padding is not required and even if it was, `client` is already > zero-initialized. > > Considering the two points from above, a suitable replacement is > `strscpy` [2] due to the fact that it guarantees NUL-termination on the > destination buffer without unnecessarily NUL-padding. > > Link: > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html > [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-harden...@vger.kernel.org > Signed-off-by: Justin Stitt Added "powermac: " to $subject and applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] i2c: replace deprecated strncpy
On Wed, Sep 20, 2023 at 11:07:35AM +, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > We should prefer more robust and less ambiguous string interfaces. > > `info.type` is expected to be NUL-terminated judging by its use in > `i2c_new_client_device()` wherein it is used to populate `client->name`: > | strscpy(client->name, info->type, sizeof(client->name)); > > NUL-padding is not required and even if it was, `client` is already > zero-initialized. > > Considering the two points from above, a suitable replacement is > `strscpy` [2] due to the fact that it guarantees NUL-termination on the > destination buffer without unnecessarily NUL-padding. > > Link: > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html > [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt Added "powermac: " to $subject and applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] i2c: cp2615: replace deprecated strncpy with strscpy
On Wed, Sep 20, 2023 at 08:08:52AM +, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > We should prefer more robust and less ambiguous string interfaces. > > We expect name to be NUL-terminated based on its numerous uses with > functions that expect NUL-terminated strings. > > For example in i2c-core-base.c +1533: > | dev_dbg(>dev, "adapter [%s] registered\n", adap->name); > > NUL-padding is not required as `adap` is already zero-alloacted with: > | adap = devm_kzalloc(>dev, sizeof(struct i2c_adapter), GFP_KERNEL); > > With the above in mind, a suitable replacement is `strscpy` [2] due to > the fact that it guarantees NUL-termination on the destination buffer > without unnecessarily NUL-padding. > > Link: > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html > [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt Applied to for-next, thanks! signature.asc Description: PGP signature
[PATCH] drm: tilcdc: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029ecc34 ("drivers/pinctrl: grab default handles from
device core"), we can rely on device core for setting the default pins.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 9aefd010acde..68093d6b6b16 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -6,7 +6,6 @@
#include
#include
-#include
#include
#include
@@ -308,7 +307,6 @@ static int panel_probe(struct platform_device *pdev)
struct backlight_device *backlight;
struct panel_module *panel_mod;
struct tilcdc_module *mod;
- struct pinctrl *pinctrl;
int ret;
/* bail out early if no DT data: */
@@ -342,10 +340,6 @@ static int panel_probe(struct platform_device *pdev)
tilcdc_module_init(mod, "panel", _module_ops);
- pinctrl = devm_pinctrl_get_select_default(>dev);
- if (IS_ERR(pinctrl))
- dev_warn(>dev, "pins are not configured\n");
-
panel_mod->timings = of_get_display_timings(node);
if (!panel_mod->timings) {
dev_err(>dev, "could not get panel timings\n");
--
2.30.2
[PATCH v2] drm: renesas: rcar-du: use proper naming for R-Car
Not RCAR, but R-Car. Signed-off-by: Wolfram Sang Reviewed-by: Kieran Bingham --- Changes since v1: * rebased to 6.6-rc2 * added tag from Kieran (Thanks!) drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h index f9893d7d6dfc..e9e59c5e70d5 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h @@ -16,7 +16,7 @@ struct rcar_du_format_info; struct rcar_du_group; /* - * The RCAR DU has 8 hardware planes, shared between primary and overlay planes. + * The R-Car DU has 8 hardware planes, shared between primary and overlay planes. * As using overlay planes requires at least one of the CRTCs being enabled, no * more than 7 overlay planes can be available. We thus create 1 primary plane * per CRTC and 7 overlay planes, for a total of up to 9 KMS planes. -- 2.35.1
Re: [Openipmi-developer] [PATCH] dt-bindings: Drop remaining unneeded quotes
On Wed, Aug 23, 2023 at 01:28:47PM -0500, Rob Herring wrote: > Cleanup bindings dropping the last remaining unneeded quotes. With this, > the check for this can be enabled in yamllint. > > Signed-off-by: Rob Herring Acked-by: Wolfram Sang # for AT24/I2C signature.asc Description: PGP signature ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[PATCH] drm: renesas: rcar-du: use proper naming for R-Car
Not RCAR, but R-Car. Signed-off-by: Wolfram Sang --- drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h index f9893d7d6dfc..e9e59c5e70d5 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h @@ -16,7 +16,7 @@ struct rcar_du_format_info; struct rcar_du_group; /* - * The RCAR DU has 8 hardware planes, shared between primary and overlay planes. + * The R-Car DU has 8 hardware planes, shared between primary and overlay planes. * As using overlay planes requires at least one of the CRTCs being enabled, no * more than 7 overlay planes can be available. We thus create 1 primary plane * per CRTC and 7 overlay planes, for a total of up to 9 KMS planes. -- 2.35.1
Re: [PATCH] I2C: Explicitly include correct DT includes
On Fri, Jul 14, 2023 at 11:46:16AM -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> > Without of_node, devm_clk_get() and friends falls back to registered > > clkdevs. So you could call clk_register_clkdev() from within the > > PMIC driver, and can keep on using devm_clk_get_optional() in the > > ISL1208 driver. > > Seriously, how many hacks are we piling ? :-) For this particular case, why do you consider this a hack? I previously suggested the solution that the PMIC driver exposes a clock to be consumed for the RTC driver even for the "two DT node solution". Because it then avoids a custom property with a phandle to the other node with regular DT clock bindings. I'd think we need sth like that in any case. signature.asc Description: PGP signature
Bug#1037955: egctl: New version 0.3 available
Package: egctl Version: 1:0.1-1.1 Severity: wishlist Dear Maintainer, upstream has now version 0.3 available. It adds support for the WLAN variant of the device which is the mainly available one these days. Also, the README now mentions how to overload PREFIX, so the Debian patch could be dropped, I assume. Thanks and happy hacking, Wolfram -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages egctl depends on: ii libc6 2.36-6 egctl recommends no packages. egctl suggests no packages. -- no debconf information
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Hi everyone, > Perhaps we should first think through what an ancillary device really > is. My understanding is that it is used to talk to secondary addresses > of a multi-address I2C slave device. As I mentioned somewhere before, this is not the case. Ancillary devices are when one *driver* handles more than one address. Everything else has been handled differently in the past (for all the uses I am aware of). Yet, I have another idea which is so simple that I wonder if it maybe has already been discussed so far? * have two regs in the bindings * use the second reg with i2c_new_client_device to instantiate the RTC sibling. 'struct i2c_board_info', which is one parameter, should have enough options to pass data, e.g it has a software_node. Should work or did I miss something here? Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Hi Geert, > > Would this binding allow to not use the RTC if the second reg is > > missing? What are the advantages of not enabling RTC? Saving power? > > It doesn't work if there is no clock? Maybe I am confusing something now, but if the RTC _needs_ to be enabled, then why we don't do it unconditionally? > > Thinking more about this: DT is hardware description, so the RTC should > > always be described in DT. If the RTC is actually activated is more a > > configuration thing, or? Brainstorming: maybe the PMIC driver could try > > to find the node with reg == 0x6f and see if firmware has enabled it or > > not? > > I guess the RTC part would acknowledge anyway? > It is always present, it is just part of the RAA215300. I mean the driver should scan for the DT node. Not on the bus. But a phandle is probably safer. > Sure, you can put that in DT. But it's a pity you have to do that, > as the device (the PMIC part) does know the revision... > That's why I suggested to let the PMIC part instantiate an i2c ancillary > device... I see. I'll let it sink in some more. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Hi Biju,
> DT-Maintainers suggestion:
> [1]
> raa215300: pmic@12 {
> compatible = "renesas,raa215300";
> reg = <0x12>, <0x6f>;
> reg-names = "main", "rtc";
>
> clocks = <>;
> clock-names = "xin";
> /* Add Optional shared IRQ resource and share it to child and handle it
> both in parent and child */
> };
Would this binding allow to not use the RTC if the second reg is
missing? What are the advantages of not enabling RTC? Saving power?
>
> Laurent/Wolfram suggestion to split it into two nodes and get rid of this
> patch:
> [2]
> raa215300: pmic @12 {
> compatible = "renesas,raa215300";
> reg = <0x12>;
>
> /* Add Optional shared IRQ */
> renesas,raa215300-rtc = <_raa215300>; /* Parse the handle
> and Enable RTC , if present.*/
Thinking more about this: DT is hardware description, so the RTC should
always be described in DT. If the RTC is actually activated is more a
configuration thing, or? Brainstorming: maybe the PMIC driver could try
to find the node with reg == 0x6f and see if firmware has enabled it or
not?
> };
>
> rtc_raa215300: rtc@6f {
> compatible = "renesas,raa215300-isl1208";
> reg = <0x6f>;
>
> /* Add Optional shared IRQ */
> clocks = <>;
> clock-names = "xin";
> renesas,raa215300-pmic = <>; /* Parse the handle to get
> PMIC version to check Oscillator bit is inverted or not */
> };
I have been scratching my head around this and wondered about one thing.
The RTC driver needs to know if the oscillator bit is inverted. AFAIU
this depends on the version of the PMIC (which includes the RTC). So,
can't we simply encode the version in the compatible string?
> compatible = "renesas,raa215300-isl1208-01";
> compatible = "renesas,raa215300-isl1208-a0";
I dunno the exact versions, but you probably get the idea.
Happy hacking,
Wolfram
signature.asc
Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Hi all, sorry for not being able to chime in earlier. > In Biju's particular use case, the i2c device responds to two addresses, > which is the standard i2c ancillary use case. However, what's special Not quite. ancillary is used when a *driver* needs to take care of two addresses. We already have devices bundling two features into the same chip. I recall at least RTC + EEPROM somewhere. And so far, we have been handling this by creating two nodes in DT and have proper binding docs. I think this is cleaner. First, you can see in DT already what the compound device really consists of. In this case, which RTC and RTC driver is exactly needed. Second, the code added here adds complexity to the I2C core with another layer of inderection for dummy devices. > As some resources are shared (knowledge about the clocks), splitting > this in two distinct devices in DT (which is what Biju's initial patch > series did) would need phandles to link both nodes together. > > Do you have a better idea how to represent this? Not sure if I understood this chip correctly, but maybe: The PMIC driver exposes a clock gate which can be consumed by the RTC driver? Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH 00/89] i2c: Convert to platform remove callback returning void
On Thu, Jun 01, 2023 at 03:54:50PM +0200, Wolfram Sang wrote: > > > I wonder how this series will go in. My expectation was that Wolfram > > picks up the whole series via his tree?! > > Will do. I am currently super-busy, though. Whole series applied to for-next. I squashed all the commits into one. These are mostly simple changes which we won't revert anyhow, but fix incrementally if we ever find an issue. signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> Wolfram: time to chime in ;-) I'll have a look this week. signature.asc Description: PGP signature
[PATCH v2] drm: rcar-du: remove R-Car H3 ES1.* workarounds
R-Car H3 ES1.* was only available to an internal development group and
needed a lot of quirks and workarounds. These become a maintenance
burden now, so our development group decided to remove upstream support
for this SoC and prevent booting it. Public users only have ES2 onwards.
Signed-off-by: Wolfram Sang
Reviewed-by: Kieran Bingham
---
This is the last ES1 bit remaining, would be awesome if it could go
soon.
Changes since v1:
* rebased to 6.4-rc1 (no code updates needed)
* added Kieran's tag (thanks!)
* mention in commit message that ES1 doesn't even boot anymore
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 ++--
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 48 --
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 3 +-
4 files changed, 4 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index d6d29be6b4f4..7e175dbfd892 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -223,20 +223,6 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
* DU channels that have a display PLL can't use the internal
* system clock, and have no internal clock divider.
*/
-
- /*
-* The H3 ES1.x exhibits dot clock duty cycle stability issues.
-* We can work around them by configuring the DPLL to twice the
-* desired frequency, coupled with a /2 post-divider. Restrict
-* the workaround to H3 ES1.x as ES2.0 and all other SoCs have
-* no post-divider when a display PLL is present (as shown by
-* the workaround breaking HDMI output on M3-W during testing).
-*/
- if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY) {
- target *= 2;
- div = 1;
- }
-
extclk = clk_get_rate(rcrtc->extclock);
rcar_du_dpll_divider(rcrtc, , extclk, target);
@@ -245,30 +231,13 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
| DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
| DPLLCR_STBY;
- if (rcrtc->index == 1) {
+ if (rcrtc->index == 1)
dpllcr |= DPLLCR_PLCS1
| DPLLCR_INCS_DOTCLKIN1;
- } else {
- dpllcr |= DPLLCR_PLCS0_PLL
+ else
+ dpllcr |= DPLLCR_PLCS0
| DPLLCR_INCS_DOTCLKIN0;
- /*
-* On ES2.x we have a single mux controlled via bit 21,
-* which selects between DCLKIN source (bit 21 = 0) and
-* a PLL source (bit 21 = 1), where the PLL is always
-* PLL1.
-*
-* On ES1.x we have an additional mux, controlled
-* via bit 20, for choosing between PLL0 (bit 20 = 0)
-* and PLL1 (bit 20 = 1). We always want to use PLL1,
-* so on ES1.x, in addition to setting bit 21, we need
-* to set the bit 20.
-*/
-
- if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PLL)
- dpllcr |= DPLLCR_PLCS0_H3ES1X_PLL1;
- }
-
rcar_du_group_write(rcrtc->group, DPLLCR, dpllcr);
escr = ESCR_DCLKSEL_DCLKIN | div;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index b9a94c5260e9..1ffde19cb87f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -387,43 +386,6 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
.dpll_mask = BIT(2) | BIT(1),
};
-static const struct rcar_du_device_info rcar_du_r8a7795_es1_info = {
- .gen = 3,
- .features = RCAR_DU_FEATURE_CRTC_IRQ
- | RCAR_DU_FEATURE_CRTC_CLOCK
- | RCAR_DU_FEATURE_VSP1_SOURCE
- | RCAR_DU_FEATURE_INTERLACED
- | RCAR_DU_FEATURE_TVM_SYNC,
- .quirks = RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY
- | RCAR_DU_QUIRK_H3_ES1_PLL,
- .channels_mask = BIT(3) | BIT(2) | BIT(1) | BIT(0),
- .routes = {
- /*
-* R8A7795 has one RGB output, two HDMI outputs and one
-* LVDS output.
-*/
- [RCAR_DU_OUTPUT_DPAD0] = {
- .possible_crtcs = BIT(3),
-
Bug#1035620: picocom: New upstream and new release
Package: picocom Version: 3.1-2+b1 Severity: normal Dear Maintainer, after 5 years of silence, I took over maintainership for picocom, collected bugfixes and pull requests and released a new version. Please find more information here: https://gitlab.com/wsakernel/picocom/-/releases I hope this can be added to Debian as-is. If not, please let me know and we can work it out. Happy hacking, Wolfram -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages picocom depends on: ii libc6 2.36-6 picocom recommends no packages. picocom suggests no packages. -- no debconf information
[PATCH 2/2] defconfigs: usb-a9g20: update to a working version
The defconfig needs to be updated to get a usable barebox: We need bigger malloc because of the increasing kernel size, soft ECC so NAND will work, ifup and relocatable for easier development. Fix the prompt while here. Sadly, because of size restrictions, FAT, NFS, menus, netconsole, and SHA1 have to go. Signed-off-by: Wolfram Sang --- arch/arm/configs/usb_a9g20_defconfig | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/arch/arm/configs/usb_a9g20_defconfig b/arch/arm/configs/usb_a9g20_defconfig index 20b1f27b9e..56f78ba7a8 100644 --- a/arch/arm/configs/usb_a9g20_defconfig +++ b/arch/arm/configs/usb_a9g20_defconfig @@ -5,9 +5,11 @@ CONFIG_AEABI=y CONFIG_ARM_OPTIMZED_STRING_FUNCTIONS=y CONFIG_MMU=y CONFIG_BAREBOX_MAX_IMAGE_SIZE=0x4 +CONFIG_MALLOC_SIZE=0x80 CONFIG_EXPERIMENTAL=y CONFIG_MALLOC_TLSF=y -CONFIG_PROMPT="USB-9G20:" +CONFIG_RELOCATABLE=y +CONFIG_PROMPT="USB-A9G20:" CONFIG_PROMPT_HUSH_PS2="y" CONFIG_HUSH_FANCY_PROMPT=y CONFIG_CMDLINE_EDITING=y @@ -33,16 +35,14 @@ CONFIG_CMD_EXPORT=y CONFIG_CMD_PRINTENV=y CONFIG_CMD_SAVEENV=y CONFIG_CMD_MD5SUM=y -CONFIG_CMD_SHA1SUM=y CONFIG_CMD_SLEEP=y CONFIG_CMD_DHCP=y +CONFIG_NET_CMD_IFUP=y CONFIG_CMD_PING=y CONFIG_CMD_TFTP=y CONFIG_CMD_ECHO_E=y CONFIG_CMD_EDIT=y CONFIG_CMD_LOGIN=y -CONFIG_CMD_MENU=y -CONFIG_CMD_MENU_MANAGEMENT=y CONFIG_CMD_PASSWD=y CONFIG_CMD_READLINE=y CONFIG_CMD_TIMEOUT=y @@ -53,14 +53,13 @@ CONFIG_CMD_SPI=y CONFIG_CMD_LED_TRIGGER=y CONFIG_CMD_OFTREE=y CONFIG_NET=y -CONFIG_NET_NFS=y -CONFIG_NET_NETCONSOLE=y CONFIG_NET_RESOLV=y CONFIG_DRIVER_NET_MACB=y CONFIG_DRIVER_SPI_ATMEL=y CONFIG_MTD=y # CONFIG_MTD_OOB_DEVICE is not set CONFIG_NAND=y +CONFIG_MTD_NAND_ECC_SOFT=y CONFIG_NAND_ATMEL=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DFU=y @@ -72,7 +71,5 @@ CONFIG_MMC_SPI_CRC_ON=y CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_LED_TRIGGERS=y +# CONFIG_VIRTIO_MENU is not set CONFIG_FS_TFTP=y -CONFIG_FS_FAT=y -CONFIG_FS_FAT_WRITE=y -CONFIG_FS_FAT_LFN=y -- 2.35.1
[PATCH 0/2] ARM: at91: usb-a9g20: make it work out of the box again
Here are the remaining two patches to make a (for me) useable barebox with the defconfig and no other patches. Comments welcome! Wolfram Sang (2): ARM: at91: usb-a926x: remove nand partitions from config defconfigs: usb-a9g20: update to a working version .../boards/usb-a926x/defaultenv-usb-a926x/config | 4 arch/arm/configs/usb_a9g20_defconfig | 15 ++- 2 files changed, 6 insertions(+), 13 deletions(-) -- 2.35.1
[PATCH 1/2] ARM: at91: usb-a926x: remove nand partitions from config
We define partitions as well in the board file. Leading to: New partition nand0.at91bootstrap (0x-0x0001) on nand0 overlaps with partition at91bootstrap_raw (0x-0x0001), not creating it cannot create nand0.at91bootstrap: Invalid argument addpart: Invalid argument So, remove it from the config file. Signed-off-by: Wolfram Sang --- Or shall I rather remove it from the board file? arch/arm/boards/usb-a926x/defaultenv-usb-a926x/config | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/boards/usb-a926x/defaultenv-usb-a926x/config b/arch/arm/boards/usb-a926x/defaultenv-usb-a926x/config index 49199ba391..f9159cb946 100644 --- a/arch/arm/boards/usb-a926x/defaultenv-usb-a926x/config +++ b/arch/arm/boards/usb-a926x/defaultenv-usb-a926x/config @@ -29,10 +29,6 @@ kernelimage=zImage #kernelimage=Image #kernelimage=Image.lzo -nand_device=atmel_nand -nand_parts="128k(at91bootstrap),256k(barebox)ro,128k(bareboxenv),128k(bareboxenv2),128k(oftree),4M(kernel),120M(rootfs),-(data)" -rootfs_mtdblock_nand=6 - autoboot_timeout=3 bootargs="console=ttyS0,115200" -- 2.35.1
Re: [PATCH 0/3] mtd: nand: atmel: legacy: fix boot on USB-A9G20
Hi Sascha, > Anyway, what's really missing is DT support. I scribbled a patch to get > you started in case you are motivated. Basically it's: Compile in the > device tree, throw away all the device registration from the board code, > see where it gets you and fix the fallout ;) So, I tried this patch and if the fallout was just some errnos or devices missing, I would have fixed it. Sadly, the actual fallout is that the board doesn't boot without any printing. This needs more debugging than what I am willing to invest currently. But I can bring the device to Prague if someone from PTX wants to try. All the best, Wolfram signature.asc Description: PGP signature
Re: [PATCH 0/3] mtd: nand: atmel: legacy: fix boot on USB-A9G20
> > I accidently erased it, so my journey for unbricking the device began. > > at91bootstrap, openocd, barebox - they all once supported A9G20, but > > nowadays all of them were broken. Well, I fixed openocd and barebox > > mostly so far, the bootstrap is still the missing piece. > > You may be hit by the newer gcc optimize the delays in > the sdram init code in at91bootstrap. The issue was something else: SAM-BA failed to flash the bootstrap because it couldn't get the SDRAM initialized before. I still didn't figure out why. Flashing the bootstrap with barebox never got it executed. I now found out that SAM-BA is modifying one vector at runtime before flashing. What is 'endaddress of blob in RAM' becomes 'filesize of blob'. If I modify my binary bootstrap like this, I can flash it with barebox and finally have a working device again. Phew! signature.asc Description: PGP signature
Re: [PATCH 0/3] mtd: nand: atmel: legacy: fix boot on USB-A9G20
Hi, > > It is a direct replacement for at91bootstrap and loads barebox as the > > next step bootloader. > The above is entirely correct - as the barebox variant supports booting from > SD card only, where at91bootstrap support additional boot sources. So, I quickly built the bootstrap for A9263 and it was ~71KB in size. This is OK for the A9263 with 96KB of SRAM, but the A9G20 only has 2x16KB. So, I think I'll need to update at91bootstrap to unbrick my device. at91bootstrap is ~4-5KB from what I observed. But thanks for the inspirtation! Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH 0/3] mtd: nand: atmel: legacy: fix boot on USB-A9G20
Hi Sascha! > Nice to hear from you here ;) Yeah, it has been only 10 years... :) > I have no idea how the SDRAM setup is done on the USB-A9G20. There seems > to be SDRAM setup code for the USB-A9263, but not for the USB-A9G20. Is > there some AT91Bootstrap required? Yes. There is a bootstrap required: https://github.com/linux4sam/at91bootstrap However, an old version is needed. I am still fighting the details. I accidently erased it, so my journey for unbricking the device began. at91bootstrap, openocd, barebox - they all once supported A9G20, but nowadays all of them were broken. Well, I fixed openocd and barebox mostly so far, the bootstrap is still the missing piece. Super interesting about the A9263 setup code. I missed it so far. Does that mean that barebox can replace the at91bootstrap? > Anyway, what's really missing is DT support. I scribbled a patch to get > you started in case you are motivated. Basically it's: Compile in the Motivated? No way ;) Obliged? More so. But first, I want to unbrick my device. First make it work, then make it beautiful. That being said, the two patches from this series are okay? I'd think they are still needed for other legacy systems even if I convert A9G20 to DT in some ages. Thanks for your help! Wolfram signature.asc Description: PGP signature
Re: [PATCH 0/3] mtd: nand: atmel: legacy: fix boot on USB-A9G20
Hi Sam, > It is only a few weeks ago I argued that there was no users of the older > at91sam* boards, and then you prove me wrong here. At your service ;) > I will try to remember that you may be able to test should someone > decide to move the barebox support for qil_a9g20 to DT and add PBL > support in the process. I am still new to at91 and barebox, but AFAICS the PBL support is only for MCI currently? I have an USB-A9G20-C01 and this one does not have SD exposed. The later version A9G20-LPW has it, but I don't own such a device, sadly. I really like the Calao USB form factor. Happy hacking, Wolfram signature.asc Description: PGP signature
[PATCH 3/3] mtd: nand: atmel: legacy: remove superfluous code
54bcca always populates 'ecc_mode' but forgot to remove the
code which overwrote the previously hardcoded 'NAND_ECC_SOFT'
when needed. This is obsolete now.
Fixes: 54bcca ("mtd: atmel_nand: retrieve ecc_mode from pdata")
Signed-off-by: Wolfram Sang
---
drivers/mtd/nand/atmel/legacy.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/mtd/nand/atmel/legacy.c b/drivers/mtd/nand/atmel/legacy.c
index 184cf465e3..cf402549b8 100644
--- a/drivers/mtd/nand/atmel/legacy.c
+++ b/drivers/mtd/nand/atmel/legacy.c
@@ -1242,21 +1242,12 @@ static int __init atmel_nand_probe(struct device *dev)
nand_chip->ecc.strength = pdata->ecc_strength ? : 1;
nand_chip->ecc.size = 1 << (pdata->ecc_size_shift ? : 9);
- if (pdata->ecc_mode == NAND_ECC_HW) {
- nand_chip->ecc.mode = NAND_ECC_HW;
- }
-
if (pdata->ecc_mode == NAND_ECC_SOFT) {
nand_chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
}
nand_chip->legacy.chip_delay = 40; /* 40us command delay
time */
- if (IS_ENABLED(CONFIG_NAND_ECC_BCH) &&
- pdata->ecc_mode == NAND_ECC_SOFT_BCH) {
- nand_chip->ecc.mode = NAND_ECC_SOFT_BCH;
- }
-
if (host->board->bus_width_16) {/* 16-bit bus width */
nand_chip->options |= NAND_BUSWIDTH_16;
nand_chip->legacy.read_buf = atmel_read_buf16;
--
2.35.1
[PATCH 1/3] mtd: nand: atmel: legacy: add 'algo' to use
Fixes "WARNING: Unsupported ECC algorithm!" on my USB-A9G20.
Fixes: b6bcd96de5 ("mtd: nand: Update to Linux-5.9")
Signed-off-by: Wolfram Sang
---
Or maybe we should make HAMMING the default fallback in nand_base.c?
drivers/mtd/nand/atmel/legacy.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/nand/atmel/legacy.c b/drivers/mtd/nand/atmel/legacy.c
index 44cd4d07e8..ea1fd64ad8 100644
--- a/drivers/mtd/nand/atmel/legacy.c
+++ b/drivers/mtd/nand/atmel/legacy.c
@@ -1246,6 +1246,10 @@ static int __init atmel_nand_probe(struct device *dev)
nand_chip->ecc.mode = NAND_ECC_HW;
}
+ if (pdata->ecc_mode == NAND_ECC_SOFT) {
+ nand_chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
+ }
+
nand_chip->legacy.chip_delay = 40; /* 40us command delay
time */
if (IS_ENABLED(CONFIG_NAND_ECC_BCH) &&
--
2.35.1
[PATCH 0/3] mtd: nand: atmel: legacy: fix boot on USB-A9G20
While trying to unbrick my Calao USB-A9G20, barebox couldn't read the NAND BB tables unlike the binary-only barebox from 2013. The first two patches fix that. The third one is a cleanup. Happy hacking! Wolfram Sang (3): mtd: nand: atmel: legacy: add 'algo' to use mtd: nand: atmel: legacy: use proper ecc_shift mtd: nand: atmel: legacy: remove superfluous code drivers/mtd/nand/atmel/legacy.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) -- 2.35.1
[PATCH 2/3] mtd: nand: atmel: legacy: use proper ecc_shift
The logic of the ternary operator is broken because '1 << x' is always
true even if 'x' is 0. Convert the logic to really use either the pdata
value or a sane default. Fixes "WARNING: Total number of ECC bytes
exceeded oobsize" on my USB-A9G20.
Fixes: babffbb193 ("mtd: atmel_nand: Add per board ECC setup")
Signed-off-by: Wolfram Sang
---
The other option is to revert babffbb193. I don't see any user. The code
was obviously not enough tested as well.
drivers/mtd/nand/atmel/legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/atmel/legacy.c b/drivers/mtd/nand/atmel/legacy.c
index ea1fd64ad8..184cf465e3 100644
--- a/drivers/mtd/nand/atmel/legacy.c
+++ b/drivers/mtd/nand/atmel/legacy.c
@@ -1240,7 +1240,7 @@ static int __init atmel_nand_probe(struct device *dev)
nand_chip->ecc.mode = pdata->ecc_mode;
nand_chip->ecc.strength = pdata->ecc_strength ? : 1;
- nand_chip->ecc.size = 1 << pdata->ecc_size_shift ? : 512;
+ nand_chip->ecc.size = 1 << (pdata->ecc_size_shift ? : 9);
if (pdata->ecc_mode == NAND_ECC_HW) {
nand_chip->ecc.mode = NAND_ECC_HW;
--
2.35.1
[PATCH] commands: edit: fix typo in Kconfig help text
Signed-off-by: Wolfram Sang --- commands/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/commands/Kconfig b/commands/Kconfig index ec15f4e543..27769950d9 100644 --- a/commands/Kconfig +++ b/commands/Kconfig @@ -1383,7 +1383,7 @@ config CMD_EDIT depends on CONSOLE_FULL || CONSOLE_SIMPLE prompt "edit" help - A small fill-screen editor. + A small full-screen editor. Usage: edit FILE -- 2.35.1
[PATCH] commands: nand: add missing parameters to help
Signed-off-by: Wolfram Sang
---
commands/Kconfig | 4 +++-
commands/nand.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/commands/Kconfig b/commands/Kconfig
index 27769950d9..76dfca2dfd 100644
--- a/commands/Kconfig
+++ b/commands/Kconfig
@@ -1950,12 +1950,14 @@ config CMD_NAND
help
NAND flash handling
- Usage: nand [-adb] NANDDEV
+ Usage: nand [-adbgi] NANDDEV
Options:
-aregister a bad block aware device ontop of a
normal NAND device
-dderegister a bad block aware device
-b OFFS mark block at OFFSet as bad
+ -g OFFS mark block at OFFSet as good
+ -iinfo. Show information about bad blocks
config CMD_NANDTEST
tristate
diff --git a/commands/nand.c b/commands/nand.c
index 67e43eba30..d07444aee0 100644
--- a/commands/nand.c
+++ b/commands/nand.c
@@ -165,7 +165,7 @@ BAREBOX_CMD_HELP_END
BAREBOX_CMD_START(nand)
.cmd= do_nand,
BAREBOX_CMD_DESC("NAND flash handling")
- BAREBOX_CMD_OPTS("[-adb] NANDDEV")
+ BAREBOX_CMD_OPTS("[-adbgi] NANDDEV")
BAREBOX_CMD_GROUP(CMD_GRP_HWMANIP)
BAREBOX_CMD_HELP(cmd_nand_help)
BAREBOX_CMD_END
--
2.35.1
[PATCH 00/11] tree-wide: remove support for Renesas R-Car H3 ES1
Because H3 ES1 becomes an increasing maintenance burden and was only available to a development group, we decided to remove upstream support for it. Here are the patches to remove driver changes. Review tags have been gathered before during an internal discussion. Only change since the internal version is a plain rebase to v6.3-rc1. A branch with all removals is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/h3es1-removal Please apply individually per subsystem. There are no dependencies and the SoC doesn't boot anymore since v6.3-rc1. Thanks and happy hacking! Wolfram Sang (11): iommu/ipmmu-vmsa: remove R-Car H3 ES1.* handling drm: rcar-du: remove R-Car H3 ES1.* workarounds media: rcar-vin: remove R-Car H3 ES1.* handling media: rcar-vin: csi2: remove R-Car H3 ES1.* handling media: renesas: fdp1: remove R-Car H3 ES1.* handling thermal/drivers/rcar_gen3_thermal: remove R-Car H3 ES1.* handling ravb: remove R-Car H3 ES1.* handling mmc: renesas_sdhi: remove R-Car H3 ES1.* handling usb: host: xhci-rcar: remove leftover quirk handling usb: host: xhci-rcar: remove R-Car H3 ES1.* handling usb: gadget: udc: renesas_usb3: remove R-Car H3 ES1.* handling drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 37 ++--- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 48 - drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_regs.h| 3 +- drivers/iommu/ipmmu-vmsa.c| 1 - .../platform/renesas/rcar-vin/rcar-core.c | 36 - .../platform/renesas/rcar-vin/rcar-csi2.c | 15 ++ drivers/media/platform/renesas/rcar_fdp1.c| 4 -- drivers/mmc/host/renesas_sdhi_internal_dmac.c | 10 ++-- drivers/net/ethernet/renesas/ravb_main.c | 15 -- drivers/thermal/rcar_gen3_thermal.c | 52 +-- drivers/usb/gadget/udc/renesas_usb3.c | 23 +--- drivers/usb/host/xhci-rcar.c | 34 +--- 13 files changed, 16 insertions(+), 264 deletions(-) -- 2.35.1
