Hi there El sáb, 27 ago 2022 a la(s) 05:51, Arvid Norlander (lkml@xxxxxxxxx) escribió: > > Hi, > > On 2022-08-25 19:00, Azael Avalos wrote: > > Hi there > > > > Sorry for pinging in a bit late, been under a lot of work lately. > > It happens to all of us. > > > You can poke the Toshiba BIOS interface directly via /dev/toshiba_acpi > > to test your findings, once it is ironed out, you can start making patches > > for inclusion in the kernel. > > Interesting. I'm new to kernel development and I can't find where in > toshiba_acpi.c this is implemented. Nor do I see any documentation for this > interface. I would love some hints with regards to this. > >From line 2248 onwards Here's a link to some documents you might find interesting: http://www.buzzard.me.uk/toshiba/docs.html The interface was introduced to the kernel many years ago, back when the (char) toshiba module was used, i just added support to the toshiba_acpi via ACPI calls > For now I have been using the out-of-tree acpi_call module: > > https://github.com/nix-community/acpi_call > > Arch Linux (which I use) packages it as a DKMS module. Handy to test with, > but probably really easy to screw up your system using it if you don't know > what you are doing. The interface is pretty straight forward, you can make a small C prog to test, basically you just need to: - Open the (/dev/toshiba_acpi) device for R/W (make sure you have permissions) - Fill out the SMMRegisters struct with your query and get the results - Rinse and repeat till you find what you're looking for WARNING: This might (or might not) set your house on fire... > > > I know there are a lot of areas where the driver is lacking features due to > > hardware restrictions on the machines I had at the time, so it's good to > > see a bit more movement here. > > > > Cheers > > Azael > > > > Best regards, > Arvid Norlander > > <snip> Saludos Azael -- -- El mundo apesta y vosotros apestais tambien --
