* speed-bmc-misc driver @ 2019-10-09 17:47 Vijay Khemka 2019-10-09 22:46 ` Andrew Jeffery 0 siblings, 1 reply; 5+ messages in thread From: Vijay Khemka @ 2019-10-09 17:47 UTC (permalink / raw) To: andrew; +Cc: OpenBMC Maillist [-- Attachment #1: Type: text/plain, Size: 191 bytes --] Hi Andrew, I saw this driver in LF aspeed Linux and was wondering how to use. Can you please suggest some usage example like device tree entry as well as sysfs interface. Thanks -Vijay [-- Attachment #2: Type: text/html, Size: 1920 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: speed-bmc-misc driver 2019-10-09 17:47 speed-bmc-misc driver Vijay Khemka @ 2019-10-09 22:46 ` Andrew Jeffery 2019-10-10 1:16 ` Vijay Khemka 0 siblings, 1 reply; 5+ messages in thread From: Andrew Jeffery @ 2019-10-09 22:46 UTC (permalink / raw) To: Vijay Khemka; +Cc: OpenBMC Maillist Hi Vijay, On Thu, 10 Oct 2019, at 04:17, Vijay Khemka wrote: > > Hi Andrew, > > I saw this driver in LF aspeed Linux What do you mean by "LF aspeed Linux"? The only place this driver lives is in the OpenBMC kernel tree (openbmc/linux on github). > and was wondering how to use. Can > you please suggest some usage example like device tree entry as well as > sysfs interface. Honestly, I wouldn't recommend using (yet). It can't be upstreamed in its current form (I've tried), and so using it as is comes with userspace-breaking changes in the future. I reserve the right to break your machines if you do make use of it when I get the time to rework the patches. Having said that, its purpose is to expose arbitrary fields in arbitrary registers on the BMC to userspace via sysfs. This is useful when the field's value is entirely determined by userspace policy and there's no need for additional kernel infrastructure around the configuration. Originally this was intended to expose to userspace the bits that control the state of the ASPEED hardware backdoors, but we changed tack on the solution to CVE-2019-6260 before the bmc-misc idea got very far. However you can find some slightly abusive uses if you search the dtsis: https://github.com/openbmc/linux/blob/dev-5.3/arch/arm/boot/dts/aspeed-g5.dtsi#L1682 In that instance we're exposing the SuperIO scratch registers to userspace using this mechanism. The attributes can be found in sysfs associated with the devicetree node. I did have a hack to add a sysfs class for them, but that was even more controversial than the general concept of the "driver" so you're going to have to cope with changes to the devicetree potentially breaking userspace unless you're willing to rework the patches yourself. Hope that helps. Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: speed-bmc-misc driver 2019-10-09 22:46 ` Andrew Jeffery @ 2019-10-10 1:16 ` Vijay Khemka 2019-10-16 3:34 ` Yong Li 0 siblings, 1 reply; 5+ messages in thread From: Vijay Khemka @ 2019-10-10 1:16 UTC (permalink / raw) To: Andrew Jeffery; +Cc: OpenBMC Maillist Hi Andrew, Thanks for detailed explanation. Regards -Vijay On 10/9/19, 3:46 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote: Hi Vijay, On Thu, 10 Oct 2019, at 04:17, Vijay Khemka wrote: > > Hi Andrew, > > I saw this driver in LF aspeed Linux What do you mean by "LF aspeed Linux"? The only place this driver lives is in the OpenBMC kernel tree (openbmc/linux on github). > and was wondering how to use. Can > you please suggest some usage example like device tree entry as well as > sysfs interface. Honestly, I wouldn't recommend using (yet). It can't be upstreamed in its current form (I've tried), and so using it as is comes with userspace-breaking changes in the future. I reserve the right to break your machines if you do make use of it when I get the time to rework the patches. Having said that, its purpose is to expose arbitrary fields in arbitrary registers on the BMC to userspace via sysfs. This is useful when the field's value is entirely determined by userspace policy and there's no need for additional kernel infrastructure around the configuration. Originally this was intended to expose to userspace the bits that control the state of the ASPEED hardware backdoors, but we changed tack on the solution to CVE-2019-6260 before the bmc-misc idea got very far. However you can find some slightly abusive uses if you search the dtsis: https://github.com/openbmc/linux/blob/dev-5.3/arch/arm/boot/dts/aspeed-g5.dtsi#L1682 In that instance we're exposing the SuperIO scratch registers to userspace using this mechanism. The attributes can be found in sysfs associated with the devicetree node. I did have a hack to add a sysfs class for them, but that was even more controversial than the general concept of the "driver" so you're going to have to cope with changes to the devicetree potentially breaking userspace unless you're willing to rework the patches yourself. Hope that helps. Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: speed-bmc-misc driver 2019-10-10 1:16 ` Vijay Khemka @ 2019-10-16 3:34 ` Yong Li 2019-10-23 0:21 ` Andrew Jeffery 0 siblings, 1 reply; 5+ messages in thread From: Yong Li @ 2019-10-16 3:34 UTC (permalink / raw) To: 'Vijay Khemka', 'Andrew Jeffery' Cc: 'OpenBMC Maillist' Hi Andrew, Regarding this bmc-misc driver, I noticed the exported sysfs entries are read-write. Is it possible to export the register value as read-only? Sometimes we only want to display the registers, but users cannot change them. Thanks, Yong -----Original Message----- From: openbmc <openbmc-bounces+yong.b.li=linux.intel.com@lists.ozlabs.org> On Behalf Of Vijay Khemka Sent: Thursday, October 10, 2019 9:17 AM To: Andrew Jeffery <andrew@aj.id.au> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org> Subject: Re: speed-bmc-misc driver Hi Andrew, Thanks for detailed explanation. Regards -Vijay On 10/9/19, 3:46 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote: Hi Vijay, On Thu, 10 Oct 2019, at 04:17, Vijay Khemka wrote: > > Hi Andrew, > > I saw this driver in LF aspeed Linux What do you mean by "LF aspeed Linux"? The only place this driver lives is in the OpenBMC kernel tree (openbmc/linux on github). > and was wondering how to use. Can > you please suggest some usage example like device tree entry as well as > sysfs interface. Honestly, I wouldn't recommend using (yet). It can't be upstreamed in its current form (I've tried), and so using it as is comes with userspace-breaking changes in the future. I reserve the right to break your machines if you do make use of it when I get the time to rework the patches. Having said that, its purpose is to expose arbitrary fields in arbitrary registers on the BMC to userspace via sysfs. This is useful when the field's value is entirely determined by userspace policy and there's no need for additional kernel infrastructure around the configuration. Originally this was intended to expose to userspace the bits that control the state of the ASPEED hardware backdoors, but we changed tack on the solution to CVE-2019-6260 before the bmc-misc idea got very far. However you can find some slightly abusive uses if you search the dtsis: https://github.com/openbmc/linux/blob/dev-5.3/arch/arm/boot/dts/aspeed-g5.dtsi#L1682 In that instance we're exposing the SuperIO scratch registers to userspace using this mechanism. The attributes can be found in sysfs associated with the devicetree node. I did have a hack to add a sysfs class for them, but that was even more controversial than the general concept of the "driver" so you're going to have to cope with changes to the devicetree potentially breaking userspace unless you're willing to rework the patches yourself. Hope that helps. Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: speed-bmc-misc driver 2019-10-16 3:34 ` Yong Li @ 2019-10-23 0:21 ` Andrew Jeffery 0 siblings, 0 replies; 5+ messages in thread From: Andrew Jeffery @ 2019-10-23 0:21 UTC (permalink / raw) To: Yong Li, Vijay Khemka; +Cc: 'OpenBMC Maillist' On Wed, 16 Oct 2019, at 14:34, Yong Li wrote: > Hi Andrew, > > Regarding this bmc-misc driver, I noticed the exported sysfs entries > are read-write. Is it possible to export the register value as > read-only? Sometimes we only want to display the registers, but users > cannot change them. I strongly advise against using the driver for the reasons I outlined to Vijay. For OpenPOWER systems we're using it, but with the knowledge that I'll need to fix userspace when I fix the driver. I'd prefer not to go adding features to the existing code now for that reason, but I think controlling the read-write/read-only nature of attributes is a good idea. If you want to improve the "driver" so that it can be upstreamed I'm happy to help out with that. Basically it should be changed to a light API that enables creation of these types of attributes that can be called from drivers for the device in question. Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-10-23 0:20 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-09 17:47 speed-bmc-misc driver Vijay Khemka 2019-10-09 22:46 ` Andrew Jeffery 2019-10-10 1:16 ` Vijay Khemka 2019-10-16 3:34 ` Yong Li 2019-10-23 0:21 ` Andrew Jeffery
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.