Re: [PATCH v2] Input: silead - Do not try to directly access the GPIO when using ACPI pm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 07-03-17 12:51, Andy Shevchenko wrote:
On Mon, 2017-03-06 at 10:31 +0100, Hans de Goede wrote:

<mega snip>

forcible adding fake _DSD tables everywhere, see above.

Why are they fake?

Because they are not coming from the firmware,

They actually are. The problem here is that older firmwares and ACPI
specification lack of naming GPIO resources. So, this information is
complimentary to the existing GPIO resources. It's not fake.

 as said I believe it
is better to clearly differentiate between the no-connection-id (so we
use indexes) and the firmware provides connection-ids cases.

Indexes without label is error prone approach. Sorry, I'm not going to
vote for them. This is explained in the patches I have: we never know
what we get by index. The mapping makes it robust.

It was clearly my mistake to even think in this direction.

I believe this is better for 2 reasons:

1) Cleaner (and less) code for drivers which need to use indexes

Yes and no. Cleaner, indeed, but less code does not always mean less
error prone, more robust, etc.

2) It is easier to debug things if it is clear at all levels if we
are dealing with indexes or connection ids

And my point that adding labels along with connection IDs is a hiding of
a huge abuse of at least ACPI case! It will not get rid of the chaos we
have. And it will make API more confusing.

Ok, since it seems clear that I'm not going to be able to change your
mind on this, I will give your patches a try and see if they fix the
silead ts problems.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux