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 oth
> > 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 parti
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
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* hand
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 uncon
Hi Biju,
> DT-Maintainers suggestion:
> [1]
> raa215300: pmic@12 {
> compatible = "renesas,raa215300";
> reg = <0x12>, <0x6f>;
> reg-names = "main", "rtc";
>
> clocks = <&x2>;
> clock-names = "xin";
> /* Add Optional shared IRQ resource and share it to child an
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 h
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
> Wolfram: time to chime in ;-)
I'll have a look this week.
signature.asc
Description: PGP signature
: 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
drive
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 p
> > 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 h
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 a
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 re
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
> s
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
---
d
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
193 ("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
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
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
cking!
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
th
: 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/rc
{/'
>
> With this, a few errors in examples were exposed 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
eff
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 t
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 t
On Sat, Nov 05, 2022 at 07:56:49AM -0400, Arminder Singh wrote:
> This patch adds IRQ support to the PASemi I2C controller driver to
> increase the performace of I2C transactions on platforms with PASemi I2C
> controllers. While primarily intended for Apple silicon platforms, this
> patch should al
> > +complete(&smbus->irq_completion);
>
> I only realized just now that you also want to disable the interrupt
> right here by writing to IMASK. This is a level sensitive interrupt at
> AIC level so the moment this handler returns it will fire again until
> you reach the write above after th
> Thank you for your patience with me through many versions.
You are welcome. In the end, I think the update of the target interface
is an improvement, in deed. So, thank you for that!
signature.asc
Description: PGP signature
___
Openipmi-developer m
On Tue, Oct 04, 2022 at 04:31:06PM +0700, Quan Nguyen wrote:
> On I2C_SLAVE_WRITE_REQUESTED event, Slave already ACK'ed on the address
> phase. But as the backend driver is busy and unable to process any
> request from Master, issue RxCmdLast for Slave to auto send NACK on
> next incoming byte.
>
> Does fixing the alignment issues and the commit description justify a v3
> of the patch or should the minor fixes go out as a "resend"? Just not sure
> in this particular case as the fixes seem to be very minor ones.
Yes, please send a v3. Since you are only fixing whitespace issues, you
can ad
Hi,
some comments from me. Thanks for the patch and review!
> > This version of the patch has been tested on an M1 Ultra Mac Studio,
> > as well as an M1 MacBook Pro, and userspace launches successfully
> > while using the IRQ path for I2C transactions.
> >
> > Tested-by: Arminder Singh
>
> I t
> + if (ret == -EBUSY)
Since we documented this:
"+ 'ret': 0 if the backend is ready, otherwise some errno"
the code above should be '(ret < 0)'
signature.asc
Description: PGP signature
___
Openipmi-developer mailing list
Openipmi-deve
On Fri, Sep 16, 2022 at 11:08:02AM +0200, Uwe Kleine-König wrote:
> Commit ed5c2f5fd10d ("i2c: Make remove callback return void") changed
> the prototype of ams_i2c_remove() but failed to adapt the declaration.
> Catch up and fix the declaration accordingly.
>
> Fixes: ed5c2f5fd10d ("i2c: Make rem
> I don't know how to proceed with this fix. Squashing into the broken
> commit is out of the game as the commit is on a stable branch that is
> already merged in a few trees. Maybe let it go in via the i2c tree?
I think it would be simplest if I put it on top of my for-next branch.
The other opt
> Unfortunately looks like patchwork was unable to ingest this change :(
> Not sure why.
vger rejected this mail because the header was too big. I updated my
scripts to estimate that before sending out.
> Would you mind splitting it into 3 chunks - wireless, ethernet,
> everything else, and rese
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Hi Andy.
> > - strlcpy(sdp->sd_proto_name, proto, GFS2_FSNAME_LEN);
> > - strlcpy(sdp->sd_table_name, table, GFS2_FSNAME_LEN);
> > + strscpy(sdp->sd_proto_name, proto, GFS2_FSNAME_LEN);
> > + strscpy(sdp->sd_table_name, table, GFS2_FSNAME_LEN);
>
> Perhaps the size should be changed to GF
There were two DTs left specifying "spidev" directly. Remove them.
Wolfram Sang (2):
ARM: dts: stm32: argon: remove spidev node
powerpc/82xx: remove spidev node from mgcoge
arch/arm/boot/dts/stm32mp157c-emstamp-argon.dtsi | 6 --
arch/powerpc/boot/dts/mgcoge.dts
t;powerpc/82xx: add SPI support for mgcoge")
Cc: Heiko Schocher
Signed-off-by: Wolfram Sang
---
Please take it via your platform tree.
arch/powerpc/boot/dts/mgcoge.dts | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
> As some conflicts are expected I sent this early after -rc1 such that it
> can be included early into next and be put on an immutable branch for
> subsystems to resolve merge conflicts.
I pushed the series out now, so it should hit -next tomorrow.
The immutable branch is here:
git://git.kerne
On Mon, Aug 15, 2022 at 10:02:25AM +0200, Uwe Kleine-König wrote:
> A remove callback that just returns 0 is equivalent to no callback at all
> as can be seen in i2c_device_remove(). So simplify accordingly.
>
> Signed-off-by: Uwe Kleine-König
Applied to an immutable branch, thanks!
signature
On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote:
> Fix i2c transfers using GPI DMA mode for all message types that do not set
> the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
>
> In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
> and it has to synced back t
On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote:
> Fix i2c transfers using GPI DMA mode for all message types that do not set
> the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
>
> In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
> and it has to synced back t
ons of packages modem-manager-gui recommends:
ii modem-manager-gui-help 0.0.20-4
pn yelp
Versions of packages modem-manager-gui suggests:
pn evolution-data-server
pn libindicate5 | libmessaging-menu0
ii libnotify4 0.8.1-1
From: Wol
: Patrizio Tufarolo
Date: Wed, 25 May 2022 08:11:36 +0200
Subject: fix_segfault_on_DNS_entries
Slightly edited by Wolfram Sang
---
src/modules/nm09.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/modules/nm09.c b/src/modules/nm09.c
index 2b3098b..02d0e20 100644
--- a
Hi Quan,
> On the first occurrence of I2C_SLAVE_WRITE_REQUESTED, the address is already
> received with ACK. So if slave return -EBUSY, the NAK will occur on the next
> Rx byte (on I2C_SLAVE_WRITE_RECEIVED event).
This is exactly why I2C_SLAVE_WRITE_RECEIVED allows for an error code.
From the doc
Hi Quan,
> When tested with ast2500, it is observed that there's always a
> I2C_SLAVE_WRITE_REQUESTED comes first then other I2C_SLAVE_WRITE_RECEIVED's
> follow for all transactions.
Yes, that's the design of the interface :)
> In case slave is busy, the NAK will be asserted on the first occurre
On Fri, Apr 22, 2022 at 11:08:03AM +0700, Quan Nguyen wrote:
> When processing I2C_SLAVE_WRITE_REQUESTED event, if slave returns
> -EBUSY, i2c controller should issue RxCmdLast command to assert NAK
> on the bus.
That should be I2C_SLAVE_WRITE_RECEIVED and it should be NAKed on all
errnos. Have yo
On Sat, Apr 02, 2022 at 12:06:59PM +0200, Christophe Leroy wrote:
> powerpc's asm/prom.h brings some headers that it doesn't
> need itself.
>
> In order to clean it up, first add missing headers in
> users of asm/prom.h
>
> Signed-off-by: Christophe Leroy
Applied to for-next, thanks!
signatu
On Wed, May 04, 2022 at 04:44:47PM +0300, Andy Shevchenko wrote:
> Switch mpc5xxx_get_bus_frequency() to use fwnode in order to help
> cleaning up other parts of the kernel from OF specific code.
>
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
Acke
Wow, MPC5200, that was a long time ago for me...
> It seems mpc52xx_get_xtal_freq() is not used anywhere. Remove dead code.
Looks like it.
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
On Mon, May 02, 2022 at 03:34:54PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. I2C on R-Car V3U also supports some extra features (e.g. Slave
> Clock Stretch Select), which are supported by other R-Car Gen4 SoCs, but
> not by any o
On Mon, May 02, 2022 at 03:34:59PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
On Mon, May 02, 2022 at 03:34:58PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
On Mon, May 02, 2022 at 03:34:57PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
On Mon, May 02, 2022 at 03:34:55PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
; not by any other R-Car Gen3 SoC.
>
> Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@li
On Mon, May 02, 2022 at 03:34:53PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Wolfram Sang
On Tue, Mar 29, 2022 at 08:38:17PM +0200, Martin Povišer wrote:
> Wait for completion of write transfers before returning from the driver.
> At first sight it may seem advantageous to leave write transfers queued
> for the controller to carry out on its own time, but there's a couple of
> issues wi
To make it unambiguous that mmc_hw_reset() is for cards and not for
controllers, we make the function argument mmc_card instead of mmc_host.
Also, all users are converted.
Suggested-by: Ulf Hansson
Signed-off-by: Wolfram Sang
---
Ulf prefers one cross-subsystem patch to have all users
el/git/wsa/linux.git
renesas/mmc/reset-api-v2
Looking forward to comments. Happy hacking,
Wolfram
[1]
https://lore.kernel.org/all/20200916090121.2350-1-wsa+rene...@sang-engineering.com/
Wolfram Sang (3):
mmc: core: improve API to make clear mmc_hw_reset is for cards
mmc: core: improve A
> I tested it with my Renesas boards, so far no regressions. Buildbots are
Wishful thinking, the patches crash now when booting. Still checking
what is the difference to when I send the patches out.
Still, looking forward to comments on the general approach.
signature.asc
Description: PGP sig
g the identifier tables during probes.
>
> Signed-off-by: Stephen Kitt
Looks good and builds fine:
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
> I tested it with my Renesas boards, so far no regressions. Buildbots are
> currently checking the series.
Update: buildbots are happy \o/
signature.asc
Description: PGP signature
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infra
No functional change, only the name and the argument type change to
avoid confusion between resetting a card and a host controller.
Signed-off-by: Wolfram Sang
---
RFC, please do not apply yet.
drivers/net/wireless/ath/ath10k/sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
next as of yesterday. A branch is here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
renesas/mmc/reset-api
Looking forward to comments. Happy hacking,
Wolfram
[1]
https://lore.kernel.org/all/20200916090121.2350-1-wsa+rene...@sang-engineering.com/
Wolfram Sang (10):
mmc:
> Any objections?
More the opposite, I am all for it!
signature.asc
Description: PGP signature
On Thu, Mar 10, 2022 at 06:41:18PM +0700, Quan Nguyen wrote:
> From: Dan Carpenter
>
> The copy_from_user() function returns the number of bytes remaining to
> be copied but we should return -EFAULT here.
>
> Fixes: 501c25b59508 ("ipmi: ssif_bmc: Add SSIF BMC driver")
> Signed-off-by: Dan Carpen
101 - 200 of 11762 matches
Mail list logo
