> -----Original Message----- > From: Benjamin Tissoires [mailto:benjamin.tissoires@xxxxxxxxxx] > Sent: Friday, August 31, 2018 7:55 AM > To: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > Cc: Hans de Goede <hdegoede@xxxxxxxxxx>; Bastien Nocera > <hadess@xxxxxxxxxx>; stephenjust@xxxxxxxxx; Sebastian Reichel > <sre@xxxxxxxxxx>; Wysocki, Rafael J <rafael.j.wysocki@xxxxxxxxx>; > lenb@xxxxxxxxxx; Moore, Robert <robert.moore@xxxxxxxxx>; > lv.zheng@xxxxxxxxx; mika.westerberg@xxxxxxxxxxxxxxx; linux- > acpi@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx; lkml > <linux-kernel@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng > implementation > > Hi Andy, > > I am resurrecting this thread now that ACPICA seemed to finally have > fixed the bug that prevent the driver to work. > The patch I submitted was reverted shortly after, which lead me to > ignore this review until ACPICA was fixed. It took a lot of effort from > Hans to have a fix accepted, so now we can hope to upstream this driver. > [Moore, Robert] The worst part of all this is that the ACPI specification is so ambiguous in this area, that we were forced to *guess* at certain elements of the implementation. So, if anyone knows of any ASL/machines that use the serial bus stuff, please forward the code to me. This includes: GenericSerialBus SMBus IPMI And maybe: GeneralPurposeIo For completeness. > On Fri, Jun 30, 2017 at 6:37 PM Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: > > > > On Fri, Jun 30, 2017 at 6:57 PM, Benjamin Tissoires > > <benjamin.tissoires@xxxxxxxxxx> wrote: > > > On Jun 29 2017 or thereabouts, Andy Shevchenko wrote: > > >> On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires > > >> <benjamin.tissoires@xxxxxxxxxx> wrote: > > > > >> What devices (laptops, tablets) have it? > > >> Surface 3. What else? > > > > > > So far, Surface 3 only. It's a Microsoft PNPId, so I guess they > > > control which device has it. Maybe the model after the Surface 3 > > > (reduced > > > platform) will have such chip, but for now, it's unknown. > > > > Please, extend introduction in commit message to state above. > > OK. On this note, I have been mentioned that the Surface Pro 2017 uses a > similar mechanism as in it's also using an operation region handler, but > this time over UART, not I2C :) > > > > > >> > I couldn't manage to get the IRQ correctly triggered, so I am > > >> > using a good old polling thread to check for changes. > > >> > > >> It might be > > > > It seems I didn't finished the sentence here. > > > > I though it might be actually ACPI event, GPE or direct IRQ (when GPIO > > chip should not disable it, though if it's the case it likely a BIOS > > bug for this hardware). > > If you don't mind, I'd rather have the polling version that seems to be > working first. I haven't touched the logs I had from Windows since last > year, so I am a little bit rusty on debugging this. > FWIW, /proc/interrupts doesn't change a bit when I unplug/replug the > power cable. > > My guess is that the Windows driver initializes the chip in a different > way and this enables the cable detection. > > > > > >> > + help > > >> > + Select this option to enable support for ACPI operation > > >> > + region of the Surface 3 battery platform driver. > > >> > > >> > +/* > > >> > + * Supports for the power IC on the Surface 3 tablet. > > >> > > >> Shouldn't it go to drivers/acpi/pmic folder ? > > > > > > Already answered later in the thread, so yes, I'll move it there. > > > > Actually Hans did a good point, so, feel free to use > drivers/platform/x86. > > Roger that! > > > > > >> And did you check if it have actual chip IP vendor name and model? > > >> Most likely it's a TI (based?) solution. > > > > > > As mentioned, I have strictly no idea. I can not crack open the > > > Surface > > > 3 without breaking the warranty (I already had to return it once > > > because the disk crashed). > > > > We have one indeed cracked (screen is broken for good :-) ), so, I > > would check what I can find there. > > > > > And I do not find anything brand-related under Windows either: > > > - it's called "Surface Platform Power Driver" > > > - and the driver is provided by Microsoft > > > > Fair enough. > > > > >> > +static int mshw0011_bix(struct mshw0011_data *cdata, struct bix > > >> > +*bix) { > > >> > > >> > + memcpy(bix->serial, buf + 7, 3); > > >> > + memcpy(bix->serial + 3, buf, 6); > > >> > + bix->serial[9] = '\0'; > > >> > > >> snprintf()? > > > > > > probably :) > > > > I would do this until we have an evidence that it contains > > non-printable symbols (or, in case you want to fix ahead, make the > > buffer 4 times bigger and use %*pE) > > I can't really make the buffer 4 time bigger. The buffer is then used by > the DSDT table to report the _BIX status, so the length of 10 is > mandatory. > It doesn't seem to hurt, and worse case, we will just strip the serial, > not a big deal IMO. > > > > > >> > + memcpy(bix->OEM, buf, 3); > > >> > + bix->OEM[4] = '\0'; > > >> > > >> snprintf() ? > > > > Ditto. > > > > >> > + snprintf(prefix, ARRAY_SIZE(prefix), "%s: ", bat0->name); > > >> > > >> > + prefix[127] = '\0'; > > >> > > >> Why? > > > > > > Just me being paranoid in case the code doesn't follow the spec... > > > Yeah, I'll remove it. > > > > snprintf() despite n in the name takes care of terminating NUL. > > > > >> > +static int mshw0011_probe(struct i2c_client *client, > > >> > + const struct i2c_device_id *id) { > > >> > > >> > + data->notify_version = version == MSHW0011_EV_2_5; > > >> > > >> 0x1ff as version sounds hmm suspicious. > > > > > > So after a little bit of digging, it appears those values were taken > > > from the DSDT: > > > https://bugzilla.kernel.org/attachment.cgi?id=187171 line 11694. > > > > > > It appears 0x3F is EV 2.1 and before, and 0x1FF is EV 2.5 and above. > > > The returned value is not a version of the chip, just a flag to know > > > which path we are taking in the DSM. > > > > > > The name is probably not the best. > > > > 63 and 511 looks too suspicious to be a version. Rather block size, a > > mask or alike. > > I replaced the 'version' by 'mask' in v3. It doesn't hurt to do so. > > > > > >> > +static const struct i2c_device_id mshw0011_id[] = { > > >> > + { } > > >> > +}; > > >> > +MODULE_DEVICE_TABLE(i2c, mshw0011_id); > > >> > > >> ->probe_new(), please. > > > > > > Correct > > > > > >> > > >> If I2C framework is _still_ broken we need to fix that part. > > > > > > I haven't check, so let's see for v3. > > > > Cc: Wolfram for v3 and ask him directly. Last time I checked it looks > > like I2C core doesn't care about ACPI when ->probe_new() is used. > > Looks like things are working fine now. So I can just submit the driver > without bothering the I2C core team :) > > Cheers, > Benjamin
