Hi,
On 20-03-17 02:33, Sebastian Reichel wrote:
Hi,
On Thu, Mar 16, 2017 at 05:15:57PM +0100, Hans de Goede wrote:
The last 2 patches of this series depend on the first 2, as such it might
be better to merge all 4 through the acpi tree if Sebastius is ok with
that.
Otherwise these patches are pretty self-explanatory.
I'm fine with this going through acpi. I wonder if acpi has a method
to avoid loading the generic drivers in the first place, though.
I thought about just not loading them as a first approach, but it is
not really doable in a clean way. For example the Whiskey Cove fuel
gauge driver I'm working on will need to do the same thing, but devices
with that fuel-gauge use the same ACPI HID for different fuel-gauges
and we've some extra magic in the fuel-gauge's probe method to see
if it really is the one we want like this:
status = acpi_evaluate_integer(ACPI_HANDLE(dev), "PTYP", NULL, &ptyp);
if (ACPI_FAILURE(status)) {
dev_err(dev, "Failed to get PTYPE\n");
return -ENODEV;
}
/*
* The same ACPI HID is used with different PMICs check PTYP to
* ensure that we are dealing with a Whiskey Cove PMIC.
*/
if (ptyp != CHT_WC_FG_PTYPE)
return -ENODEV;
And on some Bay Trail / Cherry Trail devices there is a functional
ACPI battery so we really only want to not use the ACPI battery if
we have an alternative battery power_supply driver.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
