On 19.01.23 11:22, Hans de Goede wrote:
Hi,
I'm not entirely sure how these GPIOs are supposed to be
consumed / used by userspace. But since they are not used
directly in this driver I assume userspace is supposed to
use either the (deprecated) sysfs GPIO API or the new ioctl
based GPIO API to toggle say "simswap" if it needs to.
Exactly. There are existing applications relying on this in the field
(remote places). And the whole purpose of this here is letting the
device reset it's baseband in case of errors, so there's no need to send
specialized technicans by helicopter when the baseband is bitchy again.
I guess that means adding a new apu6_gpio_names[]
array for APU6, that is fine.
Yes, if the gpio configuration is different, then there has to be an
own array for that. KISS.
Note you can still do the "MPCIE2" -> "RESETM1" defines
if you want, to allow reusing the defines and the apu2_gpio_regs[]
array. But in order to not brake uAPI you must:
1. Not change the order of the pins
2. Keep the "mpcie2_reset" and "mpcie3_reset" names for the
already supported models.
Correct. But then I wonder about the practical purpose of renaming
the defines, which then become inconsistent with the names.
Also can you please split this patch into 2 patches,
1 adding the APU5 support and one adding the APU6 support
(not necessarily in that order) ?
ACK.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
