ACPI bytecode hardware registers access

ACPI bytecode hardware registers access

[Rudolf Marek]

Hello all,

I would like to discuss some issues that we as the lm-sensors (hardware
monitoring) developers see. To make it short: ACPI bytecode pokes the hardware
without letting know the other linux drivers and this is bad. In the past it was
there but it somehow worked. Nowdays it is becoming larger problem not only for
the lm-sensors group but also for other drivers (video...)

ACPI provides the thermal zone methods to read the temps. Now imagine that this
method is implemented and executed:

            Method (_TMP, 0, NotSerialized)

            {

                And (SENF, 0x01, Local6)

                If (LEqual (Local6, 0x01))

                {

                    Return (RTMP ())

                }

                Else

                {

                    Return (0x0B86)

                }

            }

  Method (RTMP, 0, NotSerialized)

    {

        WBYT (0x4E, 0x01)

        Store (RBYT (0x50), Local0)

        If (LLess (Local0, 0x80))

        {

            Multiply (Local0, 0x0A, Local0)

            Add (Local0, 0x0AAC, Local0)

        }

        Else

        {

            Subtract (Local0, 0x80, Local0)

            Multiply (Local0, 0x0A, Local0)

            Subtract (0x0AAC, Local0, Local0)

        }



        If (LEqual (SSHU, 0x01))

        {

            Return (Local0)

        }

        Else

        {

            Return (Local0)

        }

    }

What it does? It reads the register 0x50 in bank 1 of W83627EHF chip. The
register for bank switch is 0x4e.

The w83627EHF driver update function is also changing the bank switch register.
We have seen already that this might be wrong - you will read nonsense when in
wrong bank... This happened in the past already - with some other drivers and hw :

http://www.lm-sensors.org/ticket/2072

That is not all. Now imagine that the smbus controller is programed in the
bytecode... (and it is if some special methods are implemented or the sensors is
located on smbus - to make it clear they dont use the APCI specified smbus
interface but the bytecode programs the controller)

Like this:

               Method (SWFS, 0, NotSerialized)

                {

                    And (HSTS, 0x02, Local0)

                    Sleep (0x02)

                    While (LEqual (Local0, Zero))

                    {

                        Stall (0x01)

                        Sleep (0x02)

                        And (HSTS, 0x02, Local0)

                    }



                    Sleep (0x02)

                    Store (0xFF, HSTS)

                    Sleep (0x02)

                }


This is no good :/

How can be this prevented/solved? Here are some ideas I had through some time,
none of them is my favourite, but please help me find some solution!

1) APCI AML code based locks.

   There are none standard implemented. Asus is using sometimes for their HW
    Mutex (\P4SM, 0x00)   to deal with concurrent smbus driver/acpi access.

some award based BIOSes contain that magic "SENF" value check the first example.
Quite a lot of BIOSes have this. Perhaps it is just cut and paste???

Plus with other vendor specific means.

Result: no way

2) some ACPI subsystem locking

Is it possible to stop/resume ACPI bytecode execution somehow? Will this lead to
crashes/deadlocks?

Result: ?

3) reesource region locking
Just imagine that the ioregion/mem resource region would have some kind of lock
in the structure, acpi and driver will need this lock to write to the device -
or at least acpi. This will/may lead to deadlock during suspend/resume????

Could it work ever work????

Result: ???

4) port forwarding

If the special bit in resource is set, ACPI will not do the actual access to
IO/mem but forward it to driver, which will handle the operation in safe way -
for example preserves the bank. Cares about the transactions...

Something like this would also work for the problems with super I/O chips which
are accessed with different drivers.

Imagine this like some coordinating driver...

Result: ????

5) some other ideas????

I wanted to write this mail long time, however I wrote it as fast as possible to
make it happen. Any questions, proposals etc etc very welcome!

Thanks,
Rudolf

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ACPI bytecode hardware registers access

[David Hubbard]

Hi all,

I am not on the linux-acpi list, so please include me in the To: for
future replies.

> What it does? It reads the register 0x50 in bank 1 of W83627EHF chip.
> The register for bank switch is 0x4e.
>
> The w83627EHF driver update function is also changing the bank switch
> register. We have seen already that this might be wrong - you will read
> nonsense when in wrong bank... This happened in the past already - with
> some other drivers and hw :
>
> http://www.lm-sensors.org/ticket/2072

The w83627ehf driver sets the bank register, causing all the problems,
for only a short period of time. The functions in w83627ehf.c are
w83627ehf_read_value and w83627ehf_write_value.

The good news is that adding a mutex to these functions would not be
any problem. Any program accessing the sysfs to read values from the
driver should be able to wait while the ACPI does its thing.

However, the bad news is, as you already said, where to find such a
mutex for the ACPI.

Here are my thoughts on the proposed solutions:

> 1) APCI AML code based locks.

Relying on ACPI to implement a lock is a risk. Some motherboards might
have broken ACPI (happens all the time!) with no locking or broken
locking.

However, this would be the easiest solution.

I am opposed to relying on ACPI to provide locking because the
motherboard manufacturers are not likely to fix old motherboards and
broken ACPI code. Meanwhile, linux and lm-sensors will take the blame.

> 2) some ACPI subsystem locking

This has the same problems as above. I am not going to make a claim
about your suggestion:

> Is it possible to stop/resume ACPI bytecode execution

I'm not familiar enough with the ACPI specification to say whether
this would work or not.

> 3) resource region locking

A hwmon driver would not deadlock on suspend or resume, but other
drivers probably would...

> 4) port forwarding

This sounds like the best idea. It would require a gradual migration
of drivers, but a driver that provides port forwarding support would
be able to coordinate ACPI or any other SMBus access and avoid
conflicts. It might even make sense to write a generic port-sharing
driver (total size < 1K) that would be loaded by a driver like
w83627ehf. Then the generic port-sharing driver would handle all
requests--from ACPI and w83627ehf. What do you think?

David

Re: ACPI bytecode hardware registers access

[Luming Yu]

Yes, that is bad to simultaneously access same hardware by ACPI and
native drivers without coordination. But the problem is if nativer
driver is really needed with the existence of the ACPI support for
that device?  Do you know the features that are NOT supported by ACPI?
Probably, just writing a acpi driver for SMBus controler could solve
this problem completely. Just my intuition. Please correct me if I'm
wrong.



On 2/5/07, Rudolf Marek <r.marek@assembler.cz> wrote:
> Hello all,
>
> I would like to discuss some issues that we as the lm-sensors (hardware
> monitoring) developers see. To make it short: ACPI bytecode pokes the hardware
> without letting know the other linux drivers and this is bad. In the past it was
> there but it somehow worked. Nowdays it is becoming larger problem not only for
> the lm-sensors group but also for other drivers (video...)
>
> ACPI provides the thermal zone methods to read the temps. Now imagine that this
> method is implemented and executed:
>
>             Method (_TMP, 0, NotSerialized)
>
>             {
>
>                 And (SENF, 0x01, Local6)
>
>                 If (LEqual (Local6, 0x01))
>
>                 {
>
>                     Return (RTMP ())
>
>                 }
>
>                 Else
>
>                 {
>
>                     Return (0x0B86)
>
>                 }
>
>             }
>
>   Method (RTMP, 0, NotSerialized)
>
>     {
>
>         WBYT (0x4E, 0x01)
>
>         Store (RBYT (0x50), Local0)
>
>         If (LLess (Local0, 0x80))
>
>         {
>
>             Multiply (Local0, 0x0A, Local0)
>
>             Add (Local0, 0x0AAC, Local0)
>
>         }
>
>         Else
>
>         {
>
>             Subtract (Local0, 0x80, Local0)
>
>             Multiply (Local0, 0x0A, Local0)
>
>             Subtract (0x0AAC, Local0, Local0)
>
>         }
>
>
>
>         If (LEqual (SSHU, 0x01))
>
>         {
>
>             Return (Local0)
>
>         }
>
>         Else
>
>         {
>
>             Return (Local0)
>
>         }
>
>     }
>
> What it does? It reads the register 0x50 in bank 1 of W83627EHF chip. The
> register for bank switch is 0x4e.
>
> The w83627EHF driver update function is also changing the bank switch register.
> We have seen already that this might be wrong - you will read nonsense when in
> wrong bank... This happened in the past already - with some other drivers and hw :
>
> http://www.lm-sensors.org/ticket/2072
>
> That is not all. Now imagine that the smbus controller is programed in the
> bytecode... (and it is if some special methods are implemented or the sensors is
> located on smbus - to make it clear they dont use the APCI specified smbus
> interface but the bytecode programs the controller)
>
> Like this:
>
>                Method (SWFS, 0, NotSerialized)
>
>                 {
>
>                     And (HSTS, 0x02, Local0)
>
>                     Sleep (0x02)
>
>                     While (LEqual (Local0, Zero))
>
>                     {
>
>                         Stall (0x01)
>
>                         Sleep (0x02)
>
>                         And (HSTS, 0x02, Local0)
>
>                     }
>
>
>
>                     Sleep (0x02)
>
>                     Store (0xFF, HSTS)
>
>                     Sleep (0x02)
>
>                 }
>
>
> This is no good :/
>
> How can be this prevented/solved? Here are some ideas I had through some time,
> none of them is my favourite, but please help me find some solution!
>
> 1) APCI AML code based locks.
>
>    There are none standard implemented. Asus is using sometimes for their HW
>     Mutex (\P4SM, 0x00)   to deal with concurrent smbus driver/acpi access.
>
> some award based BIOSes contain that magic "SENF" value check the first example.
> Quite a lot of BIOSes have this. Perhaps it is just cut and paste???
>
> Plus with other vendor specific means.
>
> Result: no way
>
> 2) some ACPI subsystem locking
>
> Is it possible to stop/resume ACPI bytecode execution somehow? Will this lead to
> crashes/deadlocks?
>
> Result: ?
>
> 3) reesource region locking
> Just imagine that the ioregion/mem resource region would have some kind of lock
> in the structure, acpi and driver will need this lock to write to the device -
> or at least acpi. This will/may lead to deadlock during suspend/resume????
>
> Could it work ever work????
>
> Result: ???
>
> 4) port forwarding
>
> If the special bit in resource is set, ACPI will not do the actual access to
> IO/mem but forward it to driver, which will handle the operation in safe way -
> for example preserves the bank. Cares about the transactions...
>
> Something like this would also work for the problems with super I/O chips which
> are accessed with different drivers.
>
> Imagine this like some coordinating driver...
>
> Result: ????
>
> 5) some other ideas????
>
> I wanted to write this mail long time, however I wrote it as fast as possible to
> make it happen. Any questions, proposals etc etc very welcome!
>
> Thanks,
> Rudolf
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ACPI bytecode hardware registers access

[Rudolf Marek]

Hello,

To all:
Please continue CCing me and the lm-sensors list thanks.

Luming Yu wrote:
> Yes, that is bad to simultaneously access same hardware by ACPI and
> native drivers without coordination. But the problem is if nativer
> driver is really needed with the existence of the ACPI support for
> that device? 

Yes for example, BIOS will export though ACPI just one temperature _TMP but the
chip monitors voltages and more temps etc etc. So from the lm-sensors point of
view the answer is yes we need a full driver for hardware monitoring.

> Do you know the features that are NOT supported by ACPI?

Yes as I wrote above - the voltages, fan speeds, various types of alarms...

Instead of one temperature reading, I got 9 voltage readings, 3 temps, 5 fans
etc etc

> Probably, just writing a acpi driver for SMBus controler could solve
> this problem completely. Just my intuition. Please correct me if I'm
> wrong.

Problem is that the device manufacturers may do what they want in ACPI bytecode.
  We cannot expect them to implement smbus bus control as specified in the
specs. They just drive the registers on their own.

What I'm trying to implement is the ACPI isolation from selected hardware
somehow, because the ACPI bytecode can contain code that modifies virtually any
hardware in the system without the clue what others drivers do.

Even the windows don't like it:
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx
(I/O Ports Blocked from BIOS AML)

Please help me find the solution.

Thanks,
Rudolf

Re: ACPI bytecode hardware registers access

[Rudolf Marek]

Hello,

To all:
Please continue CCing me and the lm-sensors list thanks.

Luming Yu wrote:
> Yes, that is bad to simultaneously access same hardware by ACPI and
> native drivers without coordination. But the problem is if nativer
> driver is really needed with the existence of the ACPI support for
> that device? 

Yes for example, BIOS will export though ACPI just one temperature _TMP but the
chip monitors voltages and more temps etc etc. So from the lm-sensors point of
view the answer is yes we need a full driver for hardware monitoring.

> Do you know the features that are NOT supported by ACPI?

Yes as I wrote above - the voltages, fan speeds, various types of alarms...

Instead of one temperature reading, I got 9 voltage readings, 3 temps, 5 fans
etc etc

> Probably, just writing a acpi driver for SMBus controler could solve
> this problem completely. Just my intuition. Please correct me if I'm
> wrong.

Problem is that the device manufacturers may do what they want in ACPI bytecode.
  We cannot expect them to implement smbus bus control as specified in the
specs. They just drive the registers on their own.

What I'm trying to implement is the ACPI isolation from selected hardware
somehow, because the ACPI bytecode can contain code that modifies virtually any
hardware in the system without the clue what others drivers do.

Even the windows don't like it:
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx
(I/O Ports Blocked from BIOS AML)

Please help me find the solution.

Thanks,
Rudolf

Re: ACPI bytecode hardware registers access

[Alexey Starikovskiy]

Rudolf Marek wrote:
> Problem is that the device manufacturers may do what they want in ACPI 
> bytecode.
>   We cannot expect them to implement smbus bus control as specified in the
> specs. They just drive the registers on their own.
>
> What I'm trying to implement is the ACPI isolation from selected hardware
> somehow, because the ACPI bytecode can contain code that modifies virtually any
> hardware in the system without the clue what others drivers do.
>
> Even the windows don't like it:
> http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx
> (I/O Ports Blocked from BIOS AML)
>
>   
There are no any devices in the list above (e.g. there is no 
sm-bus/fan/thermal, e.t.c chip blocked).
> Please help me find the solution.
>   
Why do you think such a solution exists? One solution would be to create generic "thermal" interface, under which all drivers could provide their capabilities... Say if lm-sensors could keep system from overheating, it could say so, and system could skip loading of ACPI thermal driver.
Problem is, lm-sensors doesn't know, what to do to control system. You still need to figure out, that for example turning fan #3 on helps to decrease temp #2... It's not possible to associate termal devices of ACPI with those from lm-sensors, so lm-sensors cannot steal info about trip-points from ACPI, or use ACPI as a governor. 

Returning to your example, there are two registers in ACPI space, access to which should be locked by single mutex. So you could provide mapping from I/O address to mutex. So if ACPI wants to access IO register, it asks, which mutex it should acquire. Question on how to extend mutex lock until access to second register remains open...

Regards,
	Alex.

Re: ACPI bytecode hardware registers access

[Rudolf Marek]

Hello Alex,

Thanks for the comments.

> Why do you think such a solution exists?

I asked help to find a solution, this does not mean I believe there is one.

> One solution would be to create generic "thermal" interface, under which all
> drivers could provide their capabilities... Say if lm-sensors could keep
> system from overheating, it could say so, and system could skip loading of
> ACPI thermal driver. Problem is, lm-sensors doesn't know, what to do to
> control system. You still need to figure out, that for example turning fan #3
> on helps to decrease temp #2... It's not possible to associate termal devices
> of ACPI with those from lm-sensors, so lm-sensors cannot steal info about 
> trip-points from ACPI, or use ACPI as a governor.

Well this is quite a different level of abstraction. I believe that thermal
control for laptops should be left alone, or driven by ACPI.

My current focus is to stop changing the registers from ACPI AML same time as
other drivers are using same device. (on desktop/server systems) This causes
problems to APCI and also to other drivers. Once such collision is detected we
may warn the user to use for example just the thermal module and not lm-sensors
one...

In ideal case user should use the ACPI thermal policy OR the lm-sensors, but
without the actual inspection of ACPI bytecode there is no chance to know if
ACPI and lm-sensors driver are talking to same chip? (maybe through the I/O
space regions it may work, however not for smbus bused stuff, because it will
advertise the controller and not the actual smbus device)

> Returning to your example, there are two registers in ACPI space, access to
> which should be locked by single mutex. So you could provide mapping from I/O
> address to mutex. So if ACPI wants to access IO register, it asks, which
> mutex it should acquire. Question on how to extend mutex lock until access to
> second register remains open...

So if I understand correctly you propose something like I did in 3) in my
original post. However this will not help much because we need to hold the mutex
longer time. If I look from the "other" side, typical driver just sets the bank,
do the reads/writes and then does not care about it. This could be generalized -
the driver guards its "transactions" - once done it does not care what happens
with the device (suppose the driver preserves the chip state after transaction
is done - this is easy for monitoring chips but hard for smbus cotrollers)

I studied ACPI spec once a while and there is only global lock (this is used for
SMM ) and also there might be some per device mutexes, but I never seen them
implemented. Maybe there might be implemented some per ACPI device mutex, so
regions belonging to this device will be locked if the code execution is still
in device methods. I dont know if it would work for the "globaly" declared
regions...

Second possibility is to have some kind of that port forwarder, which will
direct the actual access from ACPI to the Linux driver. The driver then knows if
is safe to read or write from/to that location.

This principle would be also handy for the super I/O because this chips needs
some magic sequence to open them, read the config and close them. There are many
drivers (watchdog, parport, irda, mmc, lm-sensors) in the kernel trying to write
to same super I/O port (0x2e/0x2f) this generic port forwarder would solve it too.

Question for ACPI people: If I would come with some kind of this port-forwarder
class - will you accept it as solution if all technical stuff is solved? I mean
- will be solution acceptable in principle for you?

Thanks,

Regards
Rudolf

Keep me CCed thanks.

Re: ACPI bytecode hardware registers access

[Alexey Starikovskiy]

Hi,

> I studied ACPI spec once a while and there is only global lock (this is used for
> SMM ) and also there might be some per device mutexes, but I never seen them
> implemented. Maybe there might be implemented some per ACPI device mutex, so
> regions belonging to this device will be locked if the code execution is still
> in device methods. I dont know if it would work for the "globaly" declared
> regions...
>
>   
Mutexes are ACPI internal things, they guard either ACPI BIOS vs. ACPI 
OS-side (Global Lock) or just ACPI os-side.
There is no requirement for mutexes to exist for a physical device, so 
using them to manage access to physical
device will not generally work.
> Second possibility is to have some kind of that port forwarder, which will
> direct the actual access from ACPI to the Linux driver. The driver then knows if
> is safe to read or write from/to that location.
>
> This principle would be also handy for the super I/O because this chips needs
> some magic sequence to open them, read the config and close them. There are many
> drivers (watchdog, parport, irda, mmc, lm-sensors) in the kernel trying to write
> to same super I/O port (0x2e/0x2f) this generic port forwarder would solve it too.
>
> Question for ACPI people: If I would come with some kind of this port-forwarder
> class - will you accept it as solution if all technical stuff is solved? I mean
> - will be solution acceptable in principle for you?
>
>   
You should be careful with such forwarder, as ACPI for example tends to 
be the last to access some ports during shutdown, for example...
As I understand your idea, if physical device driver loads, your port 
forwarder switches direct ACPI access to this driver,
so driver needs to advertise itself as capable of this to "forwarder". 
Also in case of driver suspend/shutdown/unload it needs to notify 
"forwarder",
such that ACPI is able to directly access device again. Also, driver 
should preserve "state" of the device across ACPI accesses,
because ACPI may not initialize device each time. It seems like every 
device will need in addition of having native driver to have a virtual 
one for ACPI...

I will be glad to see any implementation of this :)

Regards,
    Alex.

Re: ACPI bytecode hardware registers access

[Wim Van Sebroeck]

Hi Rudolf,

My feeling: I/O-devices that provide different functions via the
same register-set, should have a core that takes care of the 
communication with the I/O-device. (like for instance the w83627hf
chipset that has sensor functionailty but also watchdog capabilities).
The core needs to make sure that all different drivers can function
without interfering with each other (via proper locking mechanism's
off-course).

You could get something like this:
w83627hf_core
w83627hf_sensors -> depends on w83627hf_core
w83627hf_watchdog -> depends also on w83627hf_core

Don't know if this is a solution for the acpi problem also.

Greetings,
Wim.

Re: ACPI bytecode hardware registers access

[Luming Yu]

Is your ioport included in the microsoft's list being blocked by XP?
Please give me an example (acpidump output from a real box)
that demonstrates ACPI is missing something which must be done
through native driver. I'm wondering the designer of the box should
already known AML code will directly access these ioport. why they
needs some other native driver to access same set of ioport at same
time with acpi. It sounds like obvious broken design.  So my real
question is the native driver is really wanted by the platform
designer? As a hacker, it make senses to discover more
hardware/platform features. But do these features make sense to the
designer of the box.

On 2/5/07, Rudolf Marek <r.marek@assembler.cz> wrote:
> Hello,
>
> To all:
> Please continue CCing me and the lm-sensors list thanks.
>
> Luming Yu wrote:
> > Yes, that is bad to simultaneously access same hardware by ACPI and
> > native drivers without coordination. But the problem is if nativer
> > driver is really needed with the existence of the ACPI support for
> > that device?
>
> Yes for example, BIOS will export though ACPI just one temperature _TMP but the
> chip monitors voltages and more temps etc etc. So from the lm-sensors point of
> view the answer is yes we need a full driver for hardware monitoring.
>
> > Do you know the features that are NOT supported by ACPI?
>
> Yes as I wrote above - the voltages, fan speeds, various types of alarms...
>
> Instead of one temperature reading, I got 9 voltage readings, 3 temps, 5 fans
> etc etc
>
> > Probably, just writing a acpi driver for SMBus controler could solve
> > this problem completely. Just my intuition. Please correct me if I'm
> > wrong.
>
> Problem is that the device manufacturers may do what they want in ACPI bytecode.
>   We cannot expect them to implement smbus bus control as specified in the
> specs. They just drive the registers on their own.
>
> What I'm trying to implement is the ACPI isolation from selected hardware
> somehow, because the ACPI bytecode can contain code that modifies virtually any
> hardware in the system without the clue what others drivers do.
>
> Even the windows don't like it:
> http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx
> (I/O Ports Blocked from BIOS AML)
>
> Please help me find the solution.
>
> Thanks,
> Rudolf
>