RE: speed-bmc-misc driver

["Yong Li" <yong.b.li@linux.intel.com>]

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