drivers/misc: Add Aspeed LPC control driver

In order to manage server systems, there is typically another processor known as a BMC (Baseboard Management Controller) which is responsible for powering the server and other various elements, sometimes fans, often the system flash.

The Aspeed BMC family which is what is used on OpenPOWER machines and a number of x86 as well is typically connected to the host via an LPC (Low Pin Count) bus (among others).

The LPC bus is an ISA bus on steroids. It's generally used by the BMC chip to provide the host with access to the system flash (via MEM/FW cycles) that contains the BIOS or other host firmware along with a number of SuperIO-style IOs (via IO space) such as UARTs, IPMI controllers.

On the BMC chip side, this is all configured via a bunch of registers whose content is related to a given policy of what devices are exposed at a per system level, which is system/vendor specific, so we don't want to bolt that into the BMC kernel. This started with a need to provide something nicer than /dev/mem for user space to configure these things.

One important aspect of the configuration is how the MEM/FW space is exposed to the host (ie, the x86 or POWER). Some registers in that bridge can define a window remapping all or portion of the LPC MEM/FW space to a portion of the BMC internal bus, with no specific limits imposed in HW.

I think it makes sense to ensure that this window is configured by a kernel driver that can apply some serious sanity checks on what it is configured to map.

In practice, user space wants to control this by flipping the mapping between essentially two types of portions of the BMC address space:

- The flash space. This is a region of the BMC MMIO space that
more/less directly maps the system flash (at least for reads, writes are somewhat more complicated).

- One (or more) reserved area(s) of the BMC physical memory.

The latter is needed for a number of things, such as avoiding letting the host manipulate the innards of the BMC flash controller via some evil backdoor, we want to do flash updates by routing the window to a portion of memory (under control of a mailbox protocol via some separate set of registers) which the host can use to write new data in bulk and then request the BMC to flash it. There are other uses, such as allowing the host to boot from an in-memory flash image rather than the one in flash (very handy for continuous integration and test, the BMC can just download new images).

It is important to note that due to the way the Aspeed chip lets the kernel configure the mapping between host LPC addresses and BMC ram addresses the offset within the window must be a multiple of size. Not doing so will fragment the accessible space rather than simply moving 'zero' upwards. This is caused by the nature of HICR8 being a mask and the way host LPC addresses are translated.

 drivers/misc/Kconfig                 |   8 ++
 drivers/misc/Makefile                |   1 +
 drivers/misc/aspeed-lpc-ctrl.c       | 263 +++++++++++++++++++++++++++++++++++

 include/uapi/linux/aspeed-lpc-ctrl.h |  36 +++++

drivers/misc/Makefile +3 -0

+       .mmap           = aspeed_lpc_ctrl_mmap,
+       .unlocked_ioctl = aspeed_lpc_ctrl_ioctl,
+};
 

drivers/misc/Makefile +5 -0

+       node = of_parse_phandle(dev->of_node, "flash", 0);
+       if (!node) {
+               dev_err(dev, "Didn't find host pnor flash node\n");
+               return -ENODEV;
+       }

Quoted 6 lines · Cyril Bur

In order to manage server systems, there is typically another processor known as a BMC (Baseboard Management Controller) which is responsible for powering the server and other various elements, sometimes fans, often the system flash.

Quoted 3 lines

The Aspeed BMC family which is what is used on OpenPOWER machines and a number of x86 as well is typically connected to the host via an LPC (Low Pin Count) bus (among others).

Perhaps I missed the discussion on previous versions, but here my question. If it's available on x86, how you access it there? This driver seems too OF oriented which is not a case on most of x86 platforms.

Quoted 10 lines

It is important to note that due to the way the Aspeed chip lets the kernel configure the mapping between host LPC addresses and BMC ram addresses the offset within the window must be a multiple of size. Not doing so will fragment the accessible space rather than simply moving 'zero' upwards. This is caused by the nature of HICR8 being a mask and the way host LPC addresses are translated. drivers/misc/Kconfig                 |   8 ++ drivers/misc/Makefile                |   1 + drivers/misc/aspeed-lpc-ctrl.c       | 263 +++++++++++++++++++++++++++++++++++ include/uapi/linux/aspeed-lpc-ctrl.h |  36 +++++

Since it's UAPI can it be more generic in case there will be other LPC implementations / devices?

Quoted 7 lines

drivers/misc/Makefile +0 -0

@@ -53,6 +53,7 @@ obj-$(CONFIG_ECHO)            += echo/

 obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o obj-$(CONFIG_CXL_BASE)         += cxl/ obj-$(CONFIG_PANEL)             += panel.o +obj-$(CONFIG_ASPEED_LPC_CTRL)  += aspeed-lpc-ctrl.o

Does it suit best under misc?

drivers/misc/Makefile

Quoted 9 lines

drivers/misc/Makefile +9 -0

+static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
+               unsigned long param)
+{
+       long rc;
+       struct aspeed_lpc_ctrl_mapping map;
+       struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
+       void __user *p = (void __user *)param;
+       u32 addr;
+       u32 size;

Reversed tree?

Quoted 7 lines

+               rc = regmap_write(lpc_ctrl->regmap, HICR7, +                               (addr | (map.addr >> 16))); +               if (rc)
+                       return rc;
+
+               return regmap_write(lpc_ctrl->regmap, HICR8, +                       (~(map.size - 1)) | ((map.size >> 16) - 1));

Magic stuff above and here. Perhaps some helpers?

drivers/misc/Makefile

Quoted 7 lines

+       }

drivers/misc/Makefile +6 -0

+
+       return -EINVAL;
+}
+
+static const struct file_operations aspeed_lpc_ctrl_fops = {
+       .owner          = THIS_MODULE,

Do we still need this?

drivers/misc/Makefile

Quoted 12 lines

+       .mmap           = aspeed_lpc_ctrl_mmap,
+       .unlocked_ioctl = aspeed_lpc_ctrl_ioctl,

drivers/misc/Makefile +10 -0

+};
+static int aspeed_lpc_ctrl_probe(struct platform_device *pdev)
+{
+       struct aspeed_lpc_ctrl *lpc_ctrl;
+       struct device *dev;
+       struct device_node *node;
+       struct resource resm;
+       int rc;
+
+       dev = &pdev->dev;

You can do this in the definition block.

Quoted 6 lines

+       node = of_parse_phandle(dev->of_node, "flash", 0); +       if (!node) {
+               dev_err(dev, "Didn't find host pnor flash node\n"); +               return -ENODEV;
+       }
+

Quoted 8 lines

+       rc = of_property_read_u32_index(node, "reg", 3, +                       &lpc_ctrl->pnor_size); +       if (rc)
+               return rc;
+       rc = of_property_read_u32_index(node, "reg", 2, +                       &lpc_ctrl->pnor_base); +       if (rc)
+               return rc;

Isn't something you may read at once?

Quoted 5 lines

+       lpc_ctrl->miscdev.minor = MISC_DYNAMIC_MINOR; +       lpc_ctrl->miscdev.name = DEVICE_NAME; +       lpc_ctrl->miscdev.fops = &aspeed_lpc_ctrl_fops; +       lpc_ctrl->miscdev.parent = dev;
+       rc = misc_register(&lpc_ctrl->miscdev);

No devm_ variant?

Quoted 4 lines

+       if (rc)
+               dev_err(dev, "Unable to register device\n"); +       else
+               dev_info(dev, "Loaded at 0x%08x (0x%08x)\n",

%pa
%pa

drivers/misc/Makefile

Quoted 12 lines

+                       lpc_ctrl->mem_base, lpc_ctrl->mem_size);

drivers/misc/Makefile +11 -0

+
+       return rc;
+}
+struct aspeed_lpc_ctrl_mapping {
+       __u8    window_type;
+       __u8    window_id;
+       __u16   flags;
+       __u32   addr;
+       __u32   offset;
+       __u32   size;
+};

It will suck. So, no room for manoeuvre?

In order to manage server systems, there is typically another processor known as a BMC (Baseboard Management Controller) which is responsible for powering the server and other various elements, sometimes fans, often the system flash.

The Aspeed BMC family which is what is used on OpenPOWER machines and a number of x86 as well is typically connected to the host via an LPC (Low Pin Count) bus (among others).

The LPC bus is an ISA bus on steroids. It's generally used by the BMC chip to provide the host with access to the system flash (via MEM/FW cycles) that contains the BIOS or other host firmware along with a number of SuperIO-style IOs (via IO space) such as UARTs, IPMI controllers.

On the BMC chip side, this is all configured via a bunch of registers whose content is related to a given policy of what devices are exposed at a per system level, which is system/vendor specific, so we don't want to bolt that into the BMC kernel. This started with a need to provide something nicer than /dev/mem for user space to configure these things.

One important aspect of the configuration is how the MEM/FW space is exposed to the host (ie, the x86 or POWER). Some registers in that bridge can define a window remapping all or portion of the LPC MEM/FW space to a portion of the BMC internal bus, with no specific limits imposed in HW.

I think it makes sense to ensure that this window is configured by a kernel driver that can apply some serious sanity checks on what it is configured to map.

In practice, user space wants to control this by flipping the mapping between essentially two types of portions of the BMC address space:

- The flash space. This is a region of the BMC MMIO space that
more/less directly maps the system flash (at least for reads, writes are somewhat more complicated).

- One (or more) reserved area(s) of the BMC physical memory.

The latter is needed for a number of things, such as avoiding letting the host manipulate the innards of the BMC flash controller via some evil backdoor, we want to do flash updates by routing the window to a portion of memory (under control of a mailbox protocol via some separate set of registers) which the host can use to write new data in bulk and then request the BMC to flash it. There are other uses, such as allowing the host to boot from an in-memory flash image rather than the one in flash (very handy for continuous integration and test, the BMC can just download new images).

It is important to note that due to the way the Aspeed chip lets the kernel configure the mapping between host LPC addresses and BMC ram addresses the offset within the window must be a multiple of size. Not doing so will fragment the accessible space rather than simply moving 'zero' upwards. This is caused by the nature of HICR8 being a mask and the way host LPC addresses are translated.

Signed-off-by Cyril Bur <[email protected]>

---

Quoted 2 lines · Cyril Bur

Signed-off-by Cyril Bur <[email protected]>

---

Without some other reviewed-by: or at least tested-by lines here, I'm not going to take this. Go poke your fellow ppc people to do some work here, it shouldn't be up to me to do it for them :(

thanks,

greg k-h

Without some other reviewed-by: or at least tested-by lines here, I'm not going to take this.  Go poke your fellow ppc people to do some work
here, it shouldn't be up to me to do it for them :(

Quoted 4 lines · Cyril Bur

In order to manage server systems, there is typically another processor known as a BMC (Baseboard Management Controller) which is responsible for powering the server and other various elements, sometimes fans, often the system flash.

Without some other reviewed-by: or at least tested-by lines here, I'm not going to take this. Go poke your fellow ppc people to do some work here, it shouldn't be up to me to do it for them :(