Re: experimental patch for toshiba_acpi

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

 



On Thu, 2009-02-26 at 13:59 +0000, Richard Hughes wrote:
> On Thu, 2009-02-26 at 13:27 +0000, Jonathan Buzzard wrote:
> > On Thu, 2009-02-26 at 12:52 +0000, Richard Hughes wrote:
> > > On Thu, 2009-02-26 at 10:34 +0000, Jonathan Buzzard wrote:
> > > > Yes. You really don't understand the Toshiba Hardware Configuration
> > > > Interface. It is like making a old style BIOS INT 13 call. There are
> > > > potentially 2^16 possible calls, and there is no way to determine what
> > > > calls are valid on what laptop models other than a large lookup table.
> > > 
> > > You mean there's no way of using dmi matching to do subsets of models?
> > > Is the A20 very much different from the A10?
> > 
> > Potentially. Sometimes yes sometimes no. Let's face it the same model
> > can have optional Bluetooth, and HCI calls have been known to brick a
> > laptop.
> 
> So if I do an HCI that enables bluetooth on a model without bluetooth,
> that will brick it? Sounds implausible to me.
> 

Possibly. The Toshiba provided Windows user space programs go to some
length to establish what models they are running on before attempting
any funny business. Over the years a number of users have tried randomly
poking the HCI without knowing what they are doing and bricked their
laptops. If you understood how the HCI really works under the hood, you
would understand. The error checking in it last time I looked is
virtually none existent.


> > > Leave that to the BIOS. Just because it can be done, doesn't mean it
> > > should be done.
> > 
> > Now you are dodging the issue. Besides a whole bunch of the settings
> > take effect after a suspend, why should I have to reboot?
> 
> Re-read my reply again.

Who the hell are you to decide that? If for example I want to change my
pointer from internal to external and go through a suspend cycle rather
than a reboot to get it, that is my business not yours.

> 
> > > > How do you propose to deal with the dozens of HCI calls and the hundreds
> > > > of models of laptops, with not all HCI calls being valid on all models,
> > > > and with the potential for a HCI call on the wrong laptop to brick it
> > > > and yes this *DOES* happen?
> > > 
> > > How many different HCI calls are there to increase the backlight
> > > brightness up by one unit?
> > 
> > Several, depends on the model in question. But we are not talking about
> > the backlight, we are talking about all the other methods that you
> > clearly know nothing about.
> 
> No, we're talking about sensible abstractions, rather than poking bits
> of memory in a device file that happen to do stuff on specific models.
> 

There are no sensible abstractions. If you had any knowledge of the HCI
you would understand that. However you don't and are arguing about
things you do not know about.


> > > > Why if I install a distribution of Linux on my new Toshiba laptop should
> > > > I have to install a new kernel module and keep it updated to make some
> > > > change because the table specifying which HCI calls can be made is not
> > > > up to date in my distro's kernel?
> > > 
> > > Dude, that happens all the time with other kernel modules. You see a
> > > patch on LKML saying "add product ID for foobuzz" and then it gets
> > > picked up by downstream as a patch until a new version is released.
> > 
> > Yes and it is sub optimal.
> 
> If there's new Toshiba hardware created, I have to update your client
> program. I don't see how it's any different to updating the kernel
> module.

Then you don't live in the real world. Let's say I run Debian (but it
could be any Linux distribution), lets say that Debian is running a
version of the Linux kernel that has the relevant patch for the Toshiba
HCI in the toshiba_acpi module.

I buy my brand new Toshiba laptop which has some fancy new feature that
is controlled by the HCI (say like the transflective screen on the
Portage R500 and R600). I spend an bit of time in Windows working out
what the HCI calls are, and write a small user space program to do the
same under Linux. That's it, I am now home free no need to do any work
going forward.

Your method I write and debug a kernel module. Quite possibly hard
locking laptop in the process. I run a genuine risk of bricking the
laptop as well in the meantime. Then Debian release a security update,
so I need to compile the kernel module again. Maybe patches to the
kernel module don't make it in time for the next release of the
distribution so I am on a kernel module compile treadmill for years.

It also means I have to run the latest version of the kernel anyway to
develop the module. Maybe I run RHEL/CentOS, I can hardly use a
RHEL/CentOS kernel to develop a kernel module can I. So I have to break
my distribution to do this rather than get on with more important
things.

Too need this explaining beggars belief. In addition it is just feasible
to get an end user to download a program to /usr/local/bin and run it.
Getting them involved in a constant cycle of kernel module compiling is
just not going to happen.

> > You also failed to explain how the supervisor, and user password setting
> > was going to work from a kernel mode proc interface.
> 
> Can't you do this from the BIOS?
> 

Do you even own a "pucker" Toshiba laptop??? The short answer is no,
there are a whole bunch of things that you can set with the HCI that can
be set *NO* other way.

> > You miss entirely the point of Toshiba's HCI. We are not talking
> about
> > backlight control here. We are talking about a bunch of other stuff.
> 
> "Bunch of other stuff". Could we not decide on a proper framework for
> this functionality?
> 

The proper framework is the HCI interface. What you can do with the HCI
is extremely wide ranging. While much of the pre ACPI, HCI commands (and
the complete Software Configuration Interface SCI) have been absorbed in
ACPI much of it has not. If the authors of the ACPI specification, and
manufactures of the laptop cannot come up with a consistent way of doing
this what makes you think you can?

> > > Well, I think the onus is on you to provide a proper kernel patch,
> > > rather than just exposing userspace to /dev/toshiba, afterall, that was
> > > the thing that's prompted my mail
> > 
> > We have a proper kernel patch, the use of /dev/toshiba was excepted
> > upstream a decade ago.
> 
> As was /proc/apm, /dev/pmu and all the other _obsolete_ interfaces. They
> were bad then, and they would be bad now. Userspace and the kernel have
> moved on from a decade ago.

These describe specified interfaces. Something that the Toshiba HCI is
not. It can do literally *anything* on your laptop. If you look in the
toshiba driver you will see some of the calls are deliberately blocked
for this reason.

> >  There is a range of software that supports this
> > interface. The patch extends this to modern Toshiba hardware. It is a no
> > brainer to anyone with any practical sense.
> 
> Maybe I have no brain.
> 

Clearly not.

In the meantime actual code trumps.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux