On 2017-03-23 13:16, Andy Shevchenko wrote: > On Thu, 2017-03-23 at 12:21 +0100, Peter Rosin wrote: >> On 2017-03-23 11:04, Pavel Machek wrote: >>> On Thu 2017-03-23 08:45:58, Peter Rosin wrote: >>>> On 2017-03-22 14:05, Andy Shevchenko wrote: >>>>> On Wed, 2017-03-22 at 11:23 +0100, Peter Rosin wrote: >>>>>> On 2017-03-21 20:13, Andy Shevchenko wrote: > >> Also, the general tone from Andy indicates a certain amount of >> frustration >> with the whole issue, > > I'm sorry for my tone, it begins with amount of abuse case of GPIO for > ACPI in kernel followed by wilfully invented ACPI IDs in the drivers. No worries, it's understandable that someone chasing after the same bleeding issue over and over will get tired of it. >> which perhaps has no bearing on the seriousness, >> but what do I know? >> >> So, I'm still seeking guidance on how to handle these two patches. > > I have no strong opinion, but IDs might collide in the future if PCAxxxx > will be assigned to something else and the patch will go stable@ (yeah, > OTOH it's quite unlikely). > > So, we may postpone any stable@ back porting up to some real issue > appears. Regarding second one, it's not important at all (could be even > dropped). Consider it as example how to use _DSD and PRP0001 in ACPI > case for DT-enabled drivers. Ok, I have added 1/2 to my i2c-mux for-current branch and will drop 2/2 unless someone pipes up. Cheers, peda
