' 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
' 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
quot; 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
> > 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
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
> >
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
>
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
> >
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
> >
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
> >
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
>
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
>
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
>
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
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
> 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
> 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
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
> 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
> > 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
> 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
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
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")
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")
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
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
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
;
> 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
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
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
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',
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
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.
>
>
> 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
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
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
> 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
> 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
> 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
> 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
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
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
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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
ozlowski
>
> ---
>
> 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
ozlowski
>
> ---
>
> 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
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
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
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
> >
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
ärvinen
Reviewed-by: Wolfram Sang # for Renesas R-Car
signature.asc
Description: PGP signature
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
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
; (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 Sa
lexible 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
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
>
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
>
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
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/
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
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
Desc
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
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
> > 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
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
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*
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
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
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
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 squ
> Wolfram: time to chime in ;-)
I'll have a look this week.
signature.asc
Description: PGP signature
-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
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
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
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
, 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
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
> > 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
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
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
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
>
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/atme
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 c
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
l_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
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
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
!
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
-by: Wolfram Sang
---
Please apply individually per subsystem. There are no dependencies and the SoC
doesn't boot anymore since v6.3-rc1.
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
ed and fixed.
>
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
> Yes, that's the plan. We're collecting the various patches people have sent
> in for arch/sh, review and test them and apply them.
>
> My test board is running the latest kernel now, so I can test new patches,
> too.
I am just witnessing this development, but I want to say thanks for your
Hi Uwe,
> This series completes all drivers to this new callback (unless I missed
> something). It's based on current next/master.
Thanks for this work, really, but oh my poor inbox...
> I don't think it's feasable to apply this series in one go, so I ask the
> maintainers of the changed files
Hi Uwe,
> This series completes all drivers to this new callback (unless I missed
> something). It's based on current next/master.
Thanks for this work, really, but oh my poor inbox...
> I don't think it's feasable to apply this series in one go, so I ask the
> maintainers of the changed files
1 - 100 of 16175 matches
Mail list logo
