The format string is still broken after the first attempt to fix it:
drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe':
drivers/misc/aspeed-lpc-ctrl.c:232:17: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Werror=format=]
We can actually just print the resource structure directly here.
Fixes: 132c93d421 ("drivers/misc: Aspeed LPC control fix compile error and warning")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pgprot_dmachoerent() is not defined on every architecture. Having
COMPILE_TEST set for the driver causes it to be compiled on
architectures which do not have pgprot_dmachoerent():
drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_mmap':
drivers/misc/aspeed-lpc-ctrl.c:51:9: error: implicit declaration of
function 'pgprot_dmacoherent' [-Werror=implicit-function-declaration]
prot = pgprot_dmacoherent(prot);
There are two possible solutions:
1. Remove COMPILE_TEST to ensure the driver is only compiled on ARM
2. Use pgprot_noncached() instead of pgprot_dmachoerent()
The first option results in less compile testing of the LPC control
driver which is undesirable.
The second option uses a function that is declared on all architectures
and therefore should always build. Currently there is no practical
difference between pgprot_noncached() and pgprot_dmachoerent() for the
aspeed chips that this driver is compatible with. The reason for
pgprot_dmachoerent() was that there may be chips made at some point in
the future that could include hardware that pgprot_dmachoerent() could
optimise for. As none of this hardware has even been announced there
isn't really a need for pgprot_dmachoerent().
Using pgprot_noncached() is completely correct and optimal for all
existing hardware on which the LPC control driver will run.
This commit also addresses that phys_addr_t should be printed using %pap
rather than %x:
In file included from include/linux/miscdevice.h:6:0,
from drivers/misc/aspeed-lpc-ctrl.c:11:
drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe':
drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects
argument of type 'unsigned int', but argument 3 has type 'phys_addr_t
{aka long long unsigned int}' [-Wformat=]
dev_info(dev, "Loaded at 0x%08x (0x%08x)\n",
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <cyrilbur@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann
Cyril Bur