Provide /sys/../ec with read/write access and some cleanups
in [Kernel]
|
Prev: [PATCH 5/6] X86 platform drivers: Remove EC dump from thinkpad_acpi
Next: [PATCH 4/6] ACPI: Remove /proc/acpi/embedded_controller/..
From: Thomas Renninger on 1 Jul 2010 11:10 These patches are diffed against the test branch of the ACPI tree, but also patch fine with 2.6.35-rc3. I thought about tainting the kernel if someone writes to the EC, but as userspace can also write to graphics IO, PCI config or MSRs, it shouldn't matter that much. Eventually this should still be added (by a separate patch), one can easily confuse the EC to not switch on the fans anymore. A small tool to read out and write to /sys/devices/system/ec/*/io can be found here: ftp://ftp.suse.com/pub/people/trenn/sources/ec/ec_access.c Len: Can you apply these into your test branch and schedule them for linux-next and 2.6.36 if there are no objections, please. Thanks, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on 1 Jul 2010 12:30 On Thu, 01 Jul 2010, Thomas Renninger wrote: > These patches are diffed against the test branch of the ACPI tree, but also > patch fine with 2.6.35-rc3. > > I thought about tainting the kernel if someone writes to the EC, but as > userspace can also write to graphics IO, PCI config or MSRs, it shouldn't > matter that much. > Eventually this should still be added (by a separate patch), one can easily > confuse the EC to not switch on the fans anymore. > > A small tool to read out and write to /sys/devices/system/ec/*/io can be > found here: > ftp://ftp.suse.com/pub/people/trenn/sources/ec/ec_access.c > > Len: Can you apply these into your test branch and schedule them for linux-next > and 2.6.36 if there are no objections, please. I am just wondering if we shouldn't have this in debugfs instead of regular /sys. Do you envision *production* use of this facility, or should it just be something to use for debugging and hacking? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Renninger on 1 Jul 2010 15:50 On Thursday 01 July 2010 06:22:39 pm Henrique de Moraes Holschuh wrote: > On Thu, 01 Jul 2010, Thomas Renninger wrote: > > These patches are diffed against the test branch of the ACPI tree, but > > also patch fine with 2.6.35-rc3. > > > > I thought about tainting the kernel if someone writes to the EC, but as > > userspace can also write to graphics IO, PCI config or MSRs, it shouldn't > > matter that much. > > Eventually this should still be added (by a separate patch), one can > > easily confuse the EC to not switch on the fans anymore. > > > > A small tool to read out and write to /sys/devices/system/ec/*/io can be > > found here: > > ftp://ftp.suse.com/pub/people/trenn/sources/ec/ec_access.c > > > > Len: Can you apply these into your test branch and schedule them for > > linux-next and 2.6.36 if there are no objections, please. > > I am just wondering if we shouldn't have this in debugfs instead of regular > /sys. Do you envision *production* use of this facility, or should it just > be something to use for debugging and hacking? Only for debugging and hacking. Apps must not use it for production. On the one hand I agree, on the other hand side I think the EC somehow fits into /sys/devices/system/ec. I don't have a strong opion on that, though. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Maxim Levitsky on 1 Jul 2010 16:50 On Thu, 2010-07-01 at 17:02 +0200, Thomas Renninger wrote: > These patches are diffed against the test branch of the ACPI tree, but also > patch fine with 2.6.35-rc3. > > I thought about tainting the kernel if someone writes to the EC, but as > userspace can also write to graphics IO, PCI config or MSRs, it shouldn't > matter that much. > Eventually this should still be added (by a separate patch), one can easily > confuse the EC to not switch on the fans anymore. > > A small tool to read out and write to /sys/devices/system/ec/*/io can be > found here: > ftp://ftp.suse.com/pub/people/trenn/sources/ec/ec_access.c > > Len: Can you apply these into your test branch and schedule them for linux-next > and 2.6.36 if there are no objections, please. > > Thanks, > > Thomas This is great patchset, I was even thinking doing that myself. While at it, could you also provide a broken down table of EC GPEs like the one in /sys/firmware/acpi/interrupts/ ? Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on 1 Jul 2010 19:30
On Thu, 01 Jul 2010, Thomas Renninger wrote: > On Thursday 01 July 2010 06:22:39 pm Henrique de Moraes Holschuh wrote: > > On Thu, 01 Jul 2010, Thomas Renninger wrote: > > > These patches are diffed against the test branch of the ACPI tree, but > > > also patch fine with 2.6.35-rc3. > > > > > > I thought about tainting the kernel if someone writes to the EC, but as > > > userspace can also write to graphics IO, PCI config or MSRs, it shouldn't > > > matter that much. > > > Eventually this should still be added (by a separate patch), one can > > > easily confuse the EC to not switch on the fans anymore. > > > > > > A small tool to read out and write to /sys/devices/system/ec/*/io can be > > > found here: > > > ftp://ftp.suse.com/pub/people/trenn/sources/ec/ec_access.c > > > > > > Len: Can you apply these into your test branch and schedule them for > > > linux-next and 2.6.36 if there are no objections, please. > > > > I am just wondering if we shouldn't have this in debugfs instead of regular > > /sys. Do you envision *production* use of this facility, or should it just > > be something to use for debugging and hacking? > Only for debugging and hacking. Apps must not use it for production. > On the one hand I agree, on the other hand side I think the EC somehow > fits into /sys/devices/system/ec. I don't have a strong opion on that, though. You can have the ec metadata in sys, and the EC direct access in debugfs, for example... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |