Bug 97841

(In reply to Bastien Nocera from comment #0)
> I have access to a convertible Toshiba machine where the 2nd battery 
> is in detachable keyboard. This is the decompiled DSDT:
> https://hadess.fedorapeople.org/toshiba.dsl
> 
> There's no BAT0, BAT1 is in the screen, and BAT2 is in the keyboard.
> 
> BAT2 can be ejected (it has an _EJD method), but the dock code doesn't 
> see it as having a battery:
> $ pwd
> /sys/devices/platform/dock.0
> $ cat flags
> 16
> $ cat type
> dock_station

The kernel creates a dock station when it sees the following three types of ACPI device node:
1 ACPI device node that has _DCK control method, as the DOCK device node in your dsdt table and is represented as dock.0 above;
2 Battery, when it has a _EJ0 control method;
3 ATA, when it has a _EJ0 control method.

The 4-8 bits of the flag is used to represent such information, but not that if it contains some devices in it.

> 
> I'd eventually like to be able to say that, if I can detect that the 
> battery is inside the dock, to mark it as such in the UI[1] (even 

It should be easy to get such information by checking if a device node has the _EJD control method in the kernel but would require a way to pass such information to user space.

(In reply to Aaron Lu from comment #1)
> (In reply to Bastien Nocera from comment #0)
> > I have access to a convertible Toshiba machine where the 2nd battery 
> > is in detachable keyboard. This is the decompiled DSDT:
> > https://hadess.fedorapeople.org/toshiba.dsl
> > 
> > There's no BAT0, BAT1 is in the screen, and BAT2 is in the keyboard.
> > 
> > BAT2 can be ejected (it has an _EJD method), but the dock code doesn't 
> > see it as having a battery:
> > $ pwd
> > /sys/devices/platform/dock.0
> > $ cat flags
> > 16
> > $ cat type
> > dock_station
> 
> The kernel creates a dock station when it sees the following three types of
> ACPI device node:
> 1 ACPI device node that has _DCK control method, as the DOCK device node in
> your dsdt table and is represented as dock.0 above;
> 2 Battery, when it has a _EJ0 control method;
> 3 ATA, when it has a _EJ0 control method.
> 
> The 4-8 bits of the flag is used to represent such information, but not that
> if it contains some devices in it.

Right. But why don't the flags get set to mention "DOCK_IS_BAT" when it has the _EJD method?

The device:

        Device (BAT2)
        {
            Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)  // _HID: Hardware ID
            Name (_UID, 0x02)  // _UID: Unique ID
            Name (_PCL, Package (0x01)  // _PCL: Power Consumer List

matches the requirement for acpi_device_is_battery() returning TRUE:

bool acpi_device_is_battery(struct acpi_device *adev)
{
        struct acpi_hardware_id *hwid;

        list_for_each_entry(hwid, &adev->pnp.ids, list)
                if (!strcmp("PNP0C0A", hwid->id))
                        return true;

Are you suggesting set the DOCK_IS_BAT flag of the dock.0 device? That would mean the dock.0 device is a battery itself, which is not the case here.

But the fact that the battery is on a dock suggests that this battery is ejectable and the kernel currently lacks a way to pass such information to user space.

Where is it documented?

Documented here means I have explained the situation, i.e. in comment #3. Is there something more you need?

(In reply to Aaron Lu from comment #6)
> Documented here means I have explained the situation, i.e. in comment #3. Is
> there something more you need?

Well, it doesn't fix my problem, which is to detect that the battery is inside the "dock" from user-space.

(In reply to Bastien Nocera from comment #7)
> (In reply to Aaron Lu from comment #6)
> > Documented here means I have explained the situation, i.e. in comment #3.
> Is
> > there something more you need?
> 
> Well, it doesn't fix my problem, which is to detect that the battery is
> inside the "dock" from user-space.

I'll need to think about how to solve this(previously I thought this is a feature request and we do not deal with feature request in kernel bugzilla, but now I agree that the current code doesn't handle the BAT2 properly).

The information is apparently exported in DMI for some machines, but, in user-space, we don't have enough visibility to match those devices.

See https://bugs.freedesktop.org/show_bug.cgi?id=89400

From a Lenovo x240:
=============================== dmidecode ====================
Handle 0x0023, DMI type 22, 26 bytes
Portable Battery
        Location: Front
        Manufacturer: SONY
        Name: 45N1111
        Design Capacity: 23200 mWh
        Design Voltage: 11100 mV
        SBDS Version: 03.01
        Maximum Error: Unknown
        SBDS Serial Number: 0843
        SBDS Manufacture Date: 2013-02-05
        SBDS Chemistry: LiP
        OEM-specific Information: 0x00000000

Handle 0x0024, DMI type 22, 26 bytes
Portable Battery
        Location: Rear
        Manufacturer: SANYO
        Name: 45N1737
        Design Capacity: 71280 mWh
        Design Voltage: 10800 mV
        SBDS Version: 03.01
        Maximum Error: Unknown
        SBDS Serial Number: 682B
        SBDS Manufacture Date: 2013-10-23
        SBDS Chemistry: LION
        OEM-specific Information: 0x00000000

(In reply to Bastien Nocera from comment #9)
> The information is apparently exported in DMI for some machines, but, in
> user-space, we don't have enough visibility to match those devices.

Do you mean to match /sys/class/power_supply/BATx with the below "Portable Battery"? I saw they both have the serial number, do they match?

> 
> See https://bugs.freedesktop.org/show_bug.cgi?id=89400
> 
> From a Lenovo x240:
> =============================== dmidecode ====================
> Handle 0x0023, DMI type 22, 26 bytes
> Portable Battery
>         Location: Front
>         Manufacturer: SONY
>         Name: 45N1111
>         Design Capacity: 23200 mWh
>         Design Voltage: 11100 mV
>         SBDS Version: 03.01
>         Maximum Error: Unknown
>         SBDS Serial Number: 0843
>         SBDS Manufacture Date: 2013-02-05
>         SBDS Chemistry: LiP
>         OEM-specific Information: 0x00000000
> 
> Handle 0x0024, DMI type 22, 26 bytes
> Portable Battery
>         Location: Rear
>         Manufacturer: SANYO
>         Name: 45N1737
>         Design Capacity: 71280 mWh
>         Design Voltage: 10800 mV
>         SBDS Version: 03.01
>         Maximum Error: Unknown
>         SBDS Serial Number: 682B
>         SBDS Manufacture Date: 2013-10-23
>         SBDS Chemistry: LION
>         OEM-specific Information: 0x00000000

(In reply to Aaron Lu from comment #10)
> (In reply to Bastien Nocera from comment #9)
> > The information is apparently exported in DMI for some machines, but, in
> > user-space, we don't have enough visibility to match those devices.
> 
> Do you mean to match /sys/class/power_supply/BATx with the below "Portable
> Battery"? I saw they both have the serial number, do they match?

They do, but we can't run dmidecode in user-space, that data needs to be exported from the kernel, and it would be best if all the battery metadata was in one place...

It seems DMI is exported to user space at: /sys/firmware/dmi/tables/DMI

ping...

(In reply to Aaron Lu from comment #12)
> It seems DMI is exported to user space at: /sys/firmware/dmi/tables/DMI

Which is also only readable by root, and needs to be processed by whatever application will take the decision. This information should be attached to the battery sysfs attributes themselves.

This should be a feature request I guess? i.e. the previous kernel doesn't support his functionality either.
Bastien, can you please confirm? If it is a feature request, I think you should send the request to the mailing list.

ping...

Bug closed as this is a feature gap instead of bug.