Re: [PATCH v2 00/16] intel-lpss: support non-ACPI platforms

[Laura Abbott <labbott@redhat.com>]

On 01/08/2016 11:22 AM, Hans de Goede wrote:
> Hi,
>
> On 08-01-16 18:08, Laura Abbott wrote:
>> On 01/07/2016 04:03 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, January 06, 2016 08:19:49 AM Laura Abbott wrote:
>>>> On 01/05/2016 03:59 PM, Rafael J. Wysocki wrote:
>>>>> On Tuesday, January 05, 2016 09:57:35 AM Laura Abbott wrote:
>>>>>> On 12/06/2015 05:44 PM, Rafael J. Wysocki wrote:
>>>>>>> On Monday, November 30, 2015 05:11:28 PM Andy Shevchenko wrote:
>>>>>>>> This series includes few logical sets that bring a support of non-ACPI
>>>>>>>> platforms for Intel Skylake.
>>>>>>>>
>>>>>>>> First part is a refactoring of built-in device properties support:
>>>>>>>> - keep single value inside the structure
>>>>>>>> - provide helper macros to define built-in properties
>>>>>>>> - fall back to secondary fwnode if primary has no asked property
>>>>>>>>
>>>>>>>> Second is a propagating built-in device properties in platform core.
>>>>>>>>
>>>>>>>> Third one is modifications to MFD code and intel-lpss.c driver in particular
>>>>>>>> to define and pass built-in properties to the individual drivers.
>>>>>>>>
>>>>>>>> And last part is a fix for I2C bug found on Lenovo Yoga hardware and a first
>>>>>>>> converted user.
>>>>>>>>
>>>>>>>> Built-in device properties is an alternative to platform data. It provides a
>>>>>>>> unified API that drivers can use to cover all cases at once: DT, ACPI, and
>>>>>>>> built-in properties.
>>>>>>>>
>>>>>>>> With this series applied a platform data can be considered obsolete. Moreover,
>>>>>>>> built-in device properties allow to adjust the existing configuration, for
>>>>>>>> example, in cases when ACPI values are wrong on some platforms.
>>>>>>>>
>>>>>>>> The series has been tested on available hardware and doesn't break current
>>>>>>>> behaviour. But we ask people who have the affected hardware to apply the series
>>>>>>>> on your side and check with Lenovo hardware.
>>>>>>>>
>>>>>>>> Changelog v2:
>>>>>>>> - fix isuues found by kbuild bot (kbuild)
>>>>>>>> - append a patch to propagate device properties in polatform code (Arnd)
>>>>>>>> - update few existing and add couple of new patches due to above
>>>>>>>> - check with kmemleak
>>>>>>>>
>>>>>>>> Andy Shevchenko (9):
>>>>>>>>      device property: always check for fwnode type
>>>>>>>>      device property: rename helper functions
>>>>>>>>      device property: refactor built-in properties support
>>>>>>>>      device property: keep single value inplace
>>>>>>>>      device property: improve readability of macros
>>>>>>>>      device property: return -EINVAL when property isn't found in ACPI
>>>>>>>>      device property: Fallback to secondary fwnode if primary misses the
>>>>>>>>        property
>>>>>>>>      mfd: core: propagate device properties to sub devices drivers
>>>>>>>>      mfd: intel-lpss: Pass HSUART configuration via properties
>>>>>>>>
>>>>>>>> Heikki Krogerus (1):
>>>>>>>>      device property: helper macros for property entry creation
>>>>>>>>
>>>>>>>> Mika Westerberg (6):
>>>>>>>>      device property: Take a copy of the property set
>>>>>>>>      driver core: platform: Add support for built-in device properties
>>>>>>>>      driver core: Do not overwrite secondary fwnode with NULL if it is set
>>>>>>>>      mfd: intel-lpss: Add support for passing device properties
>>>>>>>>      mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
>>>>>>>>      i2c: designware: Convert to use unified device property API
>>>>>>>
>>>>>>> I'm going to queue up this series for v4.5.
>>>>>>>
>>>>>>> If there are any problems with it or objections from anyone, please let me know.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Raising an old thread, I pulled this series into Fedora rawhide and
>>>>>> while it worked for Lenovo Yoga we received a report that it caused
>>>>>> a regression on the Dell Inspiron 7559 (see
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1275718#c27) . I haven't
>>>>>> asked the reporter about bisecting to see which patch broke it.
>>>>>> Were there any known follow up patches?
>>>>>
>>>>> There were a few.
>>>>>
>>>>> All of them are in my linux-next branch if you can try this one.
>>>>>
>>>>> Alternatively, I can expose a branch with these to you to test.
>>>>>
>>>>
>>>> I picked up all the patches from the device-properties merge but the
>>>> problem still shows up. Are there others I should pick up? Hardware
>>>> details about the touchpad are at https://bugzilla.redhat.com/show_bug.cgi?id=1275718#c34
>>>
>>> Well, in that case can you please ask the reporter to bisect?
>>>
>>> Rafael
>>>
>>
>> I'll see if I can help the reporter bisect although it looks like Hans
>> has an idea about what might be failing.
>
> Nope, sorry if I left the impression that I have an idea where things are failing.
>
> Benjamin Tissoires latest reply in this thread (or was it in bugzilla ?) however
> seems to point in the right direction, as with this patch-set the i2c controller
> on the laptop in question starts working (as intended by this patch-set) and then
> i2c-hid tries to talk to the touchpad, but fails too. However it gets far enough
> for the touchpad to drop of the ps/2 bus.
>
> So what seems to be happening is that this is a dual protocol / bus (ps2 / i2c)
> touchpad (not that uncommon actually) and now that we've the i2c bus working due
> to this patchset, we start talking i2c to the touchpad, kicking it from ps2 mode
> to i2c mode, but our i2c driver then fails to work properly with the touchpad
> leaving it non functional.
>
> Regards,
>
> Hans

Thanks for clarifying. I'm going to see if I can help the reporter bisect.
It may take a few days.

Thanks,
Laura