Hi, > 2026年7月31日 16:07，Huacai Chen <[email protected]> 写道： > > On Fri, Jul 24, 2026 at 5:28 PM Miao Wang <[email protected]> wrote: >> >> Hi, >> >>> 2026年7月24日 16:55，Huacai Chen <[email protected]> 写道： >>> >>> Hi, Miao, >>> >>> On Fri, Jul 10, 2026 at 1:24 AM Miao Wang via B4 Relay >>> <[email protected]> wrote: >>>> >>>> Previously, the driver has been introduced to support the Loongson 2K >>>> BMC running on the Loongson Servers, which is essential to prevent >>>> the system from hanging when the BMC is being reset and the default >>>> efi-framebuffer is being used. However, there are some drawbacks in the >>>> driver. >>>> >>>> Firstly, the driver tries to read and write to the connected PCI-E host >>>> controller registers, assuming that the BMC is connected to LS7A PCI-E >>>> host controller. This assumption should be true for real products, but >>>> to prevent from accidentally reading and writing to the wrong PCI-E host >>>> controller, this driver should be modified to check this before >>>> accessing the registers. >>>> >>>> Secondly, the driver uses non-exported functions to tell the vt >>>> subsystem to redraw the screen, preventing the driver from being >>>> compiling as a module. This can be fixed by using the exported >>>> functions instead. >>> You can replace the redraw function, but I don't think it is necessary >>> to make the bmc driver modular. >>> >>> BMC core, IPMI and simpledrm display are usually (if not always) >>> supposed to work as early as possible. >> >> I believe that it should be the user's decision to choose whether to >> compile a module into the kernel or as a module and it would be better >> if we can provide the possibilities for the user to choose from. >> Additionally, I don't think these modules are supposed to work that >> early. The mfd module provide two functions, the display and the ipmi >> device. In the aspect of graphical display, without this module, the >> user can still see the output during booting on their monitors, since >> efifb is working, providing a basic display function. In the aspect of >> the ipmi device, I don't think the lack of such device will influence >> the boot of the system, since it is a common practice to compile ipmi >> device drivers as modules on other architectures. As a result, neither >> of the two functions are required to be loaded that early and it is >> reasonable to at lease leave the choice to compile it as a module >> to the user. > Flexibility is not always useful, if a config doesn't provide good > effect, then it just increases complexity and makes maintenance more > difficult.
I should emphasize that to allow this driver to be a module, there is no such increase on maintenance. Moreover, not all loongarch machines are requiring this driver. Especially only a part of the server models are quipped with this BMC. Comparing with other architectures, the driver for BMC are normally compiled as a module, such as mgag200 for iLO from HPE and iDRAC from DELL, hibmc_drm for Kunpeng server from Huawei. None of these BMC drivers requiring to be compiled into the kernel. I cannot see there is any reason keeping the driver from being allowed to be compiled as a module. I also do not think it will bring any significant maintenance burden. Implementing correct cleanup code should be necessary instead of burden. Cheers, Miao Wang _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
