to
the kernel in the first place. So, add it to the parser.
[1]
https://lore.kernel.org/all/39a2d0a7-20f3-4a51-b2e0-1ade3eab1...@sandeen.net/
Reported-by: Eric Sandeen
Signed-off-by: Wolfram Sang
---
util-linux/mount.c |2 ++
1 file changed, 2 insertions(+)
--- a/util-linux/mount.c
+++ b/util
vchenko
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
vchenko
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
vchenko
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
vchenko
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
vchenko
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
vchenko
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
> Evan no longer maintains the SWSMU code, it should be changed to Kenneth and
> Jun (CCed).
Thanks for the heads up! Kenneth, Jun, will you send a patch or shall I?
If you send one, please add:
Reported-by: Wolfram Sang
signature.asc
Description: PGP signature
> > remove I2C_CLASS_SPD without further dependencies? If you prefer to push
> > it through your tree, can you send it to Linus soon?
>
> Yes, I'll include the patch in my PR for this week.
Awesome, thank you!
signature.asc
Description: PGP signature
> > remove I2C_CLASS_SPD without further dependencies? If you prefer to push
> > it through your tree, can you send it to Linus soon?
>
> Yes, I'll include the patch in my PR for this week.
Awesome, thank you!
signature.asc
Description: PGP signature
The old email address bounced. I found the newer one in recent git history,
update MAINTAINERS accordingly.
Cc: Evan Quan
Signed-off-by: Wolfram Sang
---
Against v6.10-rc1. Still needs ack from Evan Quan
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Alex,
On Thu, May 09, 2024 at 01:15:32PM -0400, Alex Deucher wrote:
> On Thu, May 9, 2024 at 8:02 AM Heiner Kallweit wrote:
> >
> > Support for I2C_CLASS_SPD is currently being removed from the kernel.
> > Only remaining step is to remove the definition of I2C_CLASS_SPD.
> > Setting
Hi Alex,
On Thu, May 09, 2024 at 01:15:32PM -0400, Alex Deucher wrote:
> On Thu, May 9, 2024 at 8:02 AM Heiner Kallweit wrote:
> >
> > Support for I2C_CLASS_SPD is currently being removed from the kernel.
> > Only remaining step is to remove the definition of I2C_CLASS_SPD.
> > Setting
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:
> I will change the subject line to s/comeda/komeda/ when merging it.
Oh, thank you!
signature.asc
Description: PGP signature
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
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:
> > /* 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
' 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
1 - 100 of 16193 matches
Mail list logo
