On Tue Oct 20, 2026 at 1:05 PM IST, Konrad Dybcio wrote:
> On 10/14/26 9:13 AM, Luca Weiss wrote:
>> On Wed Oct 14, 2026 at 3:28 AM CEST, Dmitry Baryshkov wrote:
>>> On Tue, Oct 13, 2026 at 12:17:05PM +0200, Luca Weiss wrote:
>>>> On Tue Oct 13, 2026 at 12:10 PM CEST, Konrad Dybcio wrote:
>>>>> On 10/12/26 8:11 PM, Luca Weiss wrote:
>>>>>> From: Jasper Korten <[email protected]>
>
> [...]
>
>
>>>>> I'm assuming there's no pmic-glink on this device?
>>>>
>>>> I'm not quite sure yet how the USB stuff works. For sure from
>>>> observation, USB-C only works when stuff was plugged-in at boot time
>>>> (UEFI?), and charger also only supplies any power (but not actually
>>>> charging) when plugged in at boot time.
>>>
>>> This means that something is not 100% correct, for example, missing EC
>>> support.
>> 
>> For sure some bits are missing. This laptop doesn't have an EC per-se,
>> it's got a "EMEC" - Emulated EC, where on Windows there's just a bunch
>> of drivers handling EC-like functionality.
>> 
>> So e.g. already for battery, we just talk with the sbs-battery directly.
>> I assume this will be the case for the other components on this laptop
>> as well.
>
> I guess sweeping the i2c busses would be a good start. The other day

We have one list of I2C devices from ACPI description, and a different
list from i2cdetect. They overlap to a certain extent but also have
enough bits that differ for some reason.

> we got a contribution for a SM8550-based Samsung tablet which also
> didn't have pmic-glink, but used a SM5714 IC instead:

Interesting, will keep that in mind. Difficult to figure out what an I2C
chip is based on just the address and potentially basic register reads.
Downstream Linux devicetree would help where it's not just an obscure
"EMEC" device with a million I2C addresses in ACPI.

Regards
Luca

>
> https://lore.kernel.org/linux-arm-msm/[email protected]/
>
> Konrad


Reply via email to