On Mon, Jan 16, 2023 at 04:18:59PM +0100, Arnd Bergmann wrote: > On Mon, Jan 16, 2023, at 14:42, Clay Chang wrote: > > On Thu, Jan 12, 2023 at 02:37:53PM +0100, Arnd Bergmann wrote: > >> On Thu, Jan 12, 2023, at 14:16, Clay Chang wrote: > >> For the user interface side, I don't really like the idea of > >> having a hardware register directly exposed as driver in > >> drivers/soc, this generally makes it impossible to have portable > >> userspace that works across implementations of multiple SoC > >> vendors, and it makes it too easy to come up with an ad-hoc > >> interface to make a chip work for a particular use case when > >> a more general solution would be better. > >> > > > > I agree with you. I have one question though: if we create a 'hpe' > > directory under drivers/soc, and put all HPE BMC specific drivers there, > > do you think this proper? > > It certainly wouldn't be right to put "all HPE BMC specific drivers" > in there. Most drivers will fit into some existing subsystem, and > should be moved there instead. drivers/soc is used primarily for > drivers using soc_device_register() to provide information about the > soc, and we also use it as a place for drivers that just export > soc-specific helper functions that can be used by other drivers. > Sorry for not saying it clearly. I meant to put those HPE BMC related drivers that are "not specific" to a particular subsystem in drivers/soc/hpe. For those fit into some existing subsystems go to their designated places. > >> Again, it's hard for me to tell why this even needs to be runtime > >> configurable, please try to describe what type of application > >> would access the sysfs interface here, and why this can't just > >> be set to a fixed value by bootloader or kernel without user > >> interaction. > > > > The register is used for communication and synchronization between the > > BMC and the host. During runtime, user-space daemons configures the > > value of the register for interactions. > > That does not sound very specific. What is the subsystem on the > host that this communicates with? Can you put the driver into the > same subsystem? > > Arnd This is a control register in the BMC chip that partially controls host boot behaviors. When writing to the register, privileged mode is required. That's why we rely on a kernel driver for writing to the control register. And, there is no corresponding subsystem in the host OS. For this case, is it acceptable to put this driver under drivers/soc/hpe? Thanks, Clay
