On Thu, Aug 29, 2013 at 05:25:51PM +0100, Matthew Garrett wrote: > On Thu, Aug 29, 2013 at 09:08:30AM -0700, Guenter Roeck wrote: > > On Thu, Aug 29, 2013 at 04:37:38PM +0100, Matthew Garrett wrote: > > > On Thu, Aug 29, 2013 at 06:41:41AM -0700, Guenter Roeck wrote: > > > The majority of board vendors clearly don't expect the OS to drive the > > > hwmon chips - they're there for the benefit of ACPI and SMM code. That > > > doesn't mean that there's no benefit in having drivers for them, just > > > that the board vendors don't care about that use case and so won't do > > > anything to make it easier. > > > > > Actually, not entirely true. Some vendors even provide software running on > > Windows to access those chips (including access to fans controlled through > > GPIO pins) and to provide information to the user. It might be more accurate > > to say that some board vendors don't care about Linux (or about providing > > access through ACPI, for that matter). > > Eh. If they're really providing code that just assumes that hardware is > present and bangs on it, what choice do we have? You've checked that the > machines in question don't have a magic ACPI device that provides > resource information? > > > Question here is what the Linux kernel community's policy is going to be > > to handle such cases. Pragmatic or dogmatic ? > > I don't see any benefit in changing the status quo. Sometimes hardware > is just shit. The majority of x86 vendors certainly don't care about > anything we do, so it's not like we're in a position to force them to > change.
Almost all the LaCie NASes are running a Linux based OS. I can assure you that LaCie really takes care of Linux. Now, the main reason why the Super-I/O ACPI support is missing on this boards is a lack of knowledge. Thanks to this discussion, I am now aware of that. Then, for the next products, I will do my best to get AMLs or at least ACPI IDs. Thanks, Simon
signature.asc
Description: Digital signature
