s and newer kernel use ACPI, older bios
match your driver,
people upgrading from kernels more than about a year old don't notice since
they move from "old"
names to "acpi names" which are identical.
> * simsw:
> * similar to mpcie-reset (still experimental, ...) ...
> * seems to be really bound to M2 ports
Not experimental. Works reliably. Just don't toggle them during bootup (as your
driver was doing in
the past - current driver doesn't do this anymore - problem resolved)
The GPIO lines are wired to a SIM swap chip which does all the work. The LTE
cards don't know or see
what is happening
Regards
Ed W
PI, then
it's on them, not us.
This seems to be the direction the kernel is heading, with ACPI and device
trees being used to
configure the boards, in preference to heavy platform drivers?
Hans, can you arbitrate here please? Your previous suggestion was to implement
a compatibility shim
for older BIOS, that's done here. Happy to implement something else, just need
a guide?
Thanks all
Ed W
On 14/10/2020 12:29, Hans de Goede wrote:
> Hi,
>
> On 10/14/20 1:21 PM, Ed W wrote:
>> On 14/10/2020 09:41, Hans de Goede wrote:
>>>
>>> So I have a suggested compromise:
>>>
>>> Keep the current LED/gpio setup code, but make executing it condit
s clumsy using the existing detection mechanism,
I think whatever I
come up with you should kick back and recommend a new board detection
structure, but perhaps we can
shortcut that step with a few comments up front?
Cheers
Ed W
On 13/10/2020 09:48, Hans de Goede wrote:
> On 10/12/20 9:39 PM, Enrico Weigelt, metux IT consult wrote:
>> On 22.09.20 00:17, Ed W wrote:
>>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>>> variant of the APU 2-4
>>> boards
On 12/10/2020 20:39, Enrico Weigelt, metux IT consult wrote:
> On 22.09.20 00:17, Ed W wrote:
>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>> variant of the APU 2-4 boards
>> with some nice features. The current platform driver for pce
do you have an
opinion?
However, perhaps it's already acceptable as is?
Kind regards
Ed W
On 21/09/2020 09:40, Ed W wrote:
> On 21/09/2020 08:55, Andy Shevchenko wrote:
>> On Sun, Sep 20, 2020 at 11:33 PM Ed Wildgoose wrote:
>>> Schematics show that the GPIO number is
xport() to achieve this, but I concede I'm really not
clear how to
implement this in the platform module as currently structured... Any tips
please?
Thanks
Ed W
"G55/DEVSLP" (no 0)
(In contrast G59 is labelled "G59/DEVSLP1")
What is the quorum opinion on name?
Thanks
Ed W
#define APU2_GPIO_REG_LED3 AMD_FCH_GPIO_REG_GPIO59_DEVSLP1
#define APU2_GPIO_REG_MODESW AMD_FCH_GPIO_REG_GPIO32_GE1
#def
debugging this? How do I find out why the driver is finding my
hardware, but no eth0 device is being created?
Ed W
...
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2
10 matches
Mail list logo
