Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

Hello Linus,

On Tue, 2020-02-11 at 14:15 +0100, Linus Walleij wrote:

On Mon, Feb 10, 2020 at 3:03 PM Vaittinen, Matti
[off-list ref] wrote:

quoted

On Mon, 2020-02-10 at 14:12 +0100, Linus Walleij wrote:

quoted

If different devices have different batteries then the boot
loader
could ideally patch the DT with the right battery. This was the
solution
advocated for devices with different display panels, to a
question
from Hans de Goede at one point IIRC.

Hmm. This sounds simpler than adding bunch of charger drivers in
boot
loader. OTOH, if boot loader can detect the type of the battery,
then I
see why linux couldn't? And if type of battery can be hard-coded in
boot, then I don't see why it couldn't be hard-coded in DT. But
this
all goes far beyond my area of expertice ;)

It's a gray area.

The boot loader, as well as the kernel, can detect the presence of
some specific battery and screen using e.g. probing with i2c
addresses or by reading GPIO lines or some other magic number
such as the serial number of the device.

The kernel does have similar code in some places. Also the
function where we enter is module is deceptively named "probe()".

So at some point it was common practice for the kernel to do this.

Hm. I think I've seen some i2c drivers doing cool probing to detect if
connected decvice is what it is expected to be :) So this didn't really
come as surprize to me :)

After the introduction of device tree, there has been some pushback
from boot architecture people (this is the name for people doing
thinking around DT, ACPI, UEFI and U-Boot) that this kind of funny
probing code should be done in the boot loader, then the boot loader
need to figure out how the device tree should actually look,
construct
it and pass the result to the kernel. This works for anything that
detectable and not hot-plugged.

Ah. I didn't know about this push. Besides, this may fall apart when
hot-plug comes to play :/

Although, I once worked with a device that had pluggable cards - each
of the different type of cards had a dt-binary blob on on-board eeprom
describing the contents of this card - and when the card was plugged in
the processor was reading the EEPROM and did overlay merging of the
found dt-blob. That made devices on plugged card detected and usable.
If card was removed the dt-overlay was removed... Oh, that was a fancy
project all in all :)

As we are in parallel, especially on the ARM architectures, pushing
a "single kernel image" concept this makes a lot of sense, so we
keep down the number of funny probing code in that single kernel
image.

Maybe we should actually write this up somewhere. (Or it is already?)
I only picked the above up from misc conversations.

Well, that would be helpful - assuming the reader is able to look up
the documentation - I know that some people fail on this occasionally
*ahem*

Anyways, thanks for the explanation!

Best Regards
	Matti Vaittinen