Re: [Openipmi-developer] [PATCH -next 0/9] drivers: fix some module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote: > Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded > based on the alias from platform_device_id table. > > Yuntao Liu (9): > usb: ehci-mv: fix module autoloading > soc: pxa: ssp: fix module autoloading > misc: atmel-ssc: fix module autoloading > i2c: at91: fix module autoloading > mpc85xx_edac: fix module autoloading > dmaengine: pxa: fix module autoloading > dmaengine: mmp_pdma: fix module autoloading > dmaengine: at_hdmac: fix module autoloading > ipmi: ipmi_ssif: fix module autoloading I looked at all the patches and found that most of them do not use the table any more, or will stop using it in the near future. I think your work to validate the correctness of the entries is useful, but it may be more helpful to focus on removing all the unused tables, including those that have a MODULE_DEVICE_TABLE() tag. If you are planning to do more such cleanups, maybe you can go through them one subsystem at a time and look for drivers that have both of_device_id and i2c_device_id/platform_device_id/ spi_device_id tables. If nothing in the kernel creates a device with the legacy string, you can then send a patch that removes the old device ID list and at the same time makes the DT support unconditional in case there is an #ifdef CONFIG_OF check. If the probe() function accesses platform_data, this would also be unused, allowing an even nicer cleanup of removing the platofrm_data path in favor of OF properties. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 9/9] ipmi: ipmi_ssif: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote: > Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded > based on the alias from platform_device_id table. > > Signed-off-by: Yuntao Liu > --- The driver already has a MODULE_ALIAS() with the same string. I think the MODULE_DEVICE_TABLE() entry is slightly cleaner here, but it should only have one of the two, not both. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 8/9] dmaengine: at_hdmac: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote: > Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded > based on the alias from platform_device_id table. > > Signed-off-by: Yuntao Liu This table is again unused because at91 uses DT based probing. Please just remove the table and the #ifdef/of_match_ptr() around the of_device_id table. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 7/9] dmaengine: mmp_pdma: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote:
> Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
> based on the alias from platform_device_id table.
>
> Signed-off-by: Yuntao Liu
> ---
> drivers/dma/mmp_pdma.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
> index 136fcaeff8dd..05d051ecf833 100644
> --- a/drivers/dma/mmp_pdma.c
> +++ b/drivers/dma/mmp_pdma.c
> @@ -1129,6 +1129,7 @@ static const struct platform_device_id
> mmp_pdma_id_table[] = {
> { "mmp-pdma", },
> { },
> };
> +MODULE_DEVICE_TABLE(platform, mmp_pdma_id_table);
It appears that this table was never used in upstream kernels,
as the driver already used DT when it was first added.
Arnd
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 6/9] dmaengine: pxa: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote: > Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded > based on the alias from platform_device_id table. > > Signed-off-by: Yuntao Liu > --- > drivers/dma/pxa_dma.c | 1 + > 1 file changed, 1 insertion(+) > The legacy probe will soon be gone for pxa, so I would skip this one, like the other pxa patches. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 5/9] mpc85xx_edac: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote:
> Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
> based on the alias from platform_device_id table.
>
> Signed-off-by: Yuntao Liu
Acked-by: Arnd Bergmann
> },
> {}
> };
> +MODULE_DEVICE_TABLE(platform, mpc85xx_pci_err_match);
>
I see that this device is created in arch/powerpc/sysdev/fsl_pci.c,
so your change makes sense here.
Arnd
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 4/9] i2c: at91: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote:
> Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
> based on the alias from platform_device_id table.
>
> Signed-off-by: Yuntao Liu
> ---
> drivers/i2c/busses/i2c-at91-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/i2c/busses/i2c-at91-core.c
> b/drivers/i2c/busses/i2c-at91-core.c
> index dc52b3530725..bc3636f90712 100644
> --- a/drivers/i2c/busses/i2c-at91-core.c
> +++ b/drivers/i2c/busses/i2c-at91-core.c
> @@ -107,6 +107,7 @@ static const struct platform_device_id
> at91_twi_devtypes[] = {
> /* sentinel */
> }
> };
> +MODULE_DEVICE_TABLE(platform, at91_twi_devtypes);
>
> #if defined(CONFIG_OF)
> static struct at91_twi_pdata at91sam9x5_config = {
> --
This device is always probed from DT, so a better fix would
be to remove the table and the #ifdef/of_match_ptr() around
the atmel_twi_dt_ids.
Arnd
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 3/9] misc: atmel-ssc: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote:
> Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
> based on the alias from platform_device_id table.
>
> Signed-off-by: Yuntao Liu
> ---
> drivers/misc/atmel-ssc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 6eac0f335915..e7a87183bfbb 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -110,6 +110,7 @@ static const struct platform_device_id
> atmel_ssc_devtypes[] = {
> /* sentinel */
> }
> };
> +MODULE_DEVICE_TABLE(platform, atmel_ssc_devtypes);
I think this driver is autoloaded by the drivers using it,
so this entry is not needed. there is also an of_device_id
table that will load the driver based on the DT information.
Arnd
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 2/9] soc: pxa: ssp: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote:
> Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
> based on the alias from platform_device_id table.
>
> Signed-off-by: Yuntao Liu
> ---
> drivers/soc/pxa/ssp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/pxa/ssp.c b/drivers/soc/pxa/ssp.c
> index 854d32e04558..6ac3f376d030 100644
> --- a/drivers/soc/pxa/ssp.c
> +++ b/drivers/soc/pxa/ssp.c
> @@ -194,6 +194,7 @@ static const struct platform_device_id ssp_id_table[] = {
> { "pxa910-ssp", PXA910_SSP },
> { },
> };
> +MODULE_DEVICE_TABLE(platform, ssp_id_table);
>
I think we can drop support for legacy probing early next
year when the last pxa board files are gone, so this is
no longer needed.
Arnd
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH -next 1/9] usb: ehci-mv: fix module autoloading
On Mon, Aug 19, 2024, at 13:38, Yuntao Liu wrote:
> Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
> based on the alias from platform_device_id table.
>
> Signed-off-by: Yuntao Liu
> ---
> drivers/usb/host/ehci-mv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
> index 2f1fc7eb8b72..33d925316eec 100644
> --- a/drivers/usb/host/ehci-mv.c
> +++ b/drivers/usb/host/ehci-mv.c
> @@ -260,6 +260,7 @@ static const struct platform_device_id ehci_id_table[] = {
> {"pxa-sph", 0},
> {},
> };
> +MODULE_DEVICE_TABLE(platform, ehci_id_table);
Neither of the two entries is used any more, so a better
fix would be to remove the platform_device_id table.
Arnd
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH 33/34] drivers: remove incorrect of_match_ptr/ACPI_PTR annotations
From: Arnd Bergmann
When building with CONFIG_OF and/or CONFIG_ACPI disabled but W=1 extra
warnings enabled, a lot of driver cause a warning about an unused
ID table:
drivers/char/tpm/tpm_ftpm_tee.c:356:34: error: unused variable
'of_ftpm_tee_ids' [-Werror,-Wunused-const-variable]
drivers/dma/img-mdc-dma.c:863:34: error: unused variable 'mdc_dma_of_match'
[-Werror,-Wunused-const-variable]
drivers/fpga/versal-fpga.c:62:34: error: unused variable 'versal_fpga_of_match'
[-Werror,-Wunused-const-variable]
drivers/i2c/muxes/i2c-mux-ltc4306.c:200:34: error: unused variable
'ltc4306_of_match' [-Werror,-Wunused-const-variable]
drivers/i2c/muxes/i2c-mux-reg.c:242:34: error: unused variable
'i2c_mux_reg_of_match' [-Werror,-Wunused-const-variable]
drivers/memory/pl353-smc.c:62:34: error: unused variable
'pl353_smc_supported_children' [-Werror,-Wunused-const-variable]
drivers/regulator/pbias-regulator.c:136:34: error: unused variable
'pbias_of_match' [-Werror,-Wunused-const-variable]
drivers/regulator/twl-regulator.c:552:34: error: unused variable 'twl_of_match'
[-Werror,-Wunused-const-variable]
drivers/regulator/twl6030-regulator.c:645:34: error: unused variable
'twl_of_match' [-Werror,-Wunused-const-variable]
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c:3635:36: error: unused variable
'sas_v2_acpi_match' [-Werror,-Wunused-const-variable]
drivers/staging/pi433/pi433_if.c:1359:34: error: unused variable 'pi433_dt_ids'
[-Werror,-Wunused-const-variable]
drivers/tty/serial/amba-pl011.c:2945:34: error: unused variable
'sbsa_uart_of_match' [-Werror,-Wunused-const-variable]
The fix is always to just remove the of_match_ptr() and ACPI_PTR() wrappers
that remove the reference, rather than adding another #ifdef just for build
testing for a configuration that doesn't matter in practice.
I considered splitting up the large patch into per subsystem patches, but since
it's really just the same thing everywhere it feels better to do it all at once.
Signed-off-by: Arnd Bergmann
---
drivers/char/ipmi/ipmb_dev_int.c | 2 +-
drivers/char/tpm/tpm_ftpm_tee.c | 2 +-
drivers/dma/img-mdc-dma.c | 2 +-
drivers/fpga/versal-fpga.c| 2 +-
drivers/hid/hid-google-hammer.c | 6 ++
drivers/i2c/muxes/i2c-mux-ltc4306.c | 2 +-
drivers/i2c/muxes/i2c-mux-reg.c | 2 +-
drivers/input/touchscreen/wdt87xx_i2c.c | 2 +-
drivers/mux/adg792a.c | 2 +-
drivers/net/ethernet/apm/xgene-v2/main.c | 2 +-
drivers/net/ethernet/hisilicon/hns_mdio.c | 2 +-
drivers/regulator/pbias-regulator.c | 2 +-
drivers/regulator/twl-regulator.c | 2 +-
drivers/regulator/twl6030-regulator.c | 2 +-
drivers/rtc/rtc-fsl-ftm-alarm.c | 2 +-
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c| 2 +-
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c| 2 +-
drivers/staging/pi433/pi433_if.c | 2 +-
drivers/tty/serial/amba-pl011.c | 6 +++---
drivers/tty/serial/ma35d1_serial.c| 2 +-
20 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/char/ipmi/ipmb_dev_int.c b/drivers/char/ipmi/ipmb_dev_int.c
index 49100845fcb7..5e7bfc7c26e2 100644
--- a/drivers/char/ipmi/ipmb_dev_int.c
+++ b/drivers/char/ipmi/ipmb_dev_int.c
@@ -364,7 +364,7 @@ MODULE_DEVICE_TABLE(acpi, acpi_ipmb_id);
static struct i2c_driver ipmb_driver = {
.driver = {
.name = "ipmb-dev",
- .acpi_match_table = ACPI_PTR(acpi_ipmb_id),
+ .acpi_match_table = acpi_ipmb_id,
},
.probe = ipmb_probe,
.remove = ipmb_remove,
diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
index 2ea4882251cf..0c453f3f928d 100644
--- a/drivers/char/tpm/tpm_ftpm_tee.c
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -362,7 +362,7 @@ MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids);
static struct platform_driver ftpm_tee_plat_driver = {
.driver = {
.name = "ftpm-tee",
- .of_match_table = of_match_ptr(of_ftpm_tee_ids),
+ .of_match_table = of_ftpm_tee_ids,
},
.shutdown = ftpm_plat_tee_shutdown,
.probe = ftpm_plat_tee_probe,
diff --git a/drivers/dma/img-mdc-dma.c b/drivers/dma/img-mdc-dma.c
index 0532dd2640dc..6931c8a65415 100644
--- a/drivers/dma/img-mdc-dma.c
+++ b/drivers/dma/img-mdc-dma.c
@@ -1073,7 +1073,7 @@ static struct platform_driver mdc_dma_driver = {
.driver = {
.name = "img-mdc-dma",
.pm = &img_mdc_pm_ops,
- .of_match_table = of_match_ptr(mdc_dma_of_match),
+ .of_match_table = mdc_dma_of_match,
},
.probe = mdc_dma_probe,
.remove_new = mdc_dma_remove,
diff --git a/drivers/fpga/versal-fpga.c b/drivers/fpga/versal-fpga.c
index 3710e8f01be2..e618910
[Openipmi-developer] [PATCH 00/34] address all -Wunused-const warnings
From: Arnd Bergmann
Compilers traditionally warn for unused 'static' variables, but not
if they are constant. The reason here is a custom for C++ programmers
to define named constants as 'static const' variables in header files
instead of using macros or enums.
In W=1 builds, we get warnings only static const variables in C
files, but not in headers, which is a good compromise, but this still
produces warning output in at least 30 files. These warnings are
almost all harmless, but also trivial to fix, and there is no
good reason to warn only about the non-const variables being unused.
I've gone through all the files that I found using randconfig and
allmodconfig builds and created patches to avoid these warnings,
with the goal of retaining a clean build once the option is enabled
by default.
Unfortunately, there is one fairly large patch ("drivers: remove
incorrect of_match_ptr/ACPI_PTR annotations") that touches
34 individual drivers that all need the same one-line change.
If necessary, I can split it up by driver or by subsystem,
but at least for reviewing I would keep it as one piece for
the moment.
Please merge the individual patches through subsystem trees.
I expect that some of these will have to go through multiple
revisions before they are picked up, so anything that gets
applied early saves me from resending.
Arnd
Arnd Bergmann (31):
powerpc/fsl-soc: hide unused const variable
ubsan: fix unused variable warning in test module
platform: goldfish: remove ACPI_PTR() annotations
i2c: pxa: hide unused icr_bits[] variable
3c515: remove unused 'mtu' variable
tracing: hide unused ftrace_event_id_fops
Input: synaptics: hide unused smbus_pnp_ids[] array
power: rt9455: hide unused rt9455_boost_voltage_values
efi: sysfb: don't build when EFI is disabled
clk: ti: dpll: fix incorrect #ifdef checks
apm-emulation: hide an unused variable
sisfb: hide unused variables
dma/congiguous: avoid warning about unused size_bytes
leds: apu: remove duplicate DMI lookup data
iio: ad5755: hook up of_device_id lookup to platform driver
greybus: arche-ctrl: move device table to its right location
lib: checksum: hide unused expected_csum_ipv6_magic[]
sunrpc: suppress warnings for unused procfs functions
comedi: ni_atmio: avoid warning for unused device_ids[] table
iwlegacy: don't warn for unused variables with DEBUG_FS=n
drm/komeda: don't warn for unused debugfs files
firmware: qcom_scm: mark qcom_scm_qseecom_allowlist as __maybe_unused
crypto: ccp - drop platform ifdef checks
usb: gadget: omap_udc: remove unused variable
isdn: kcapi: don't build unused procfs code
cpufreq: intel_pstate: hide unused intel_pstate_cpu_oob_ids[]
net: xgbe: remove extraneous #ifdef checks
Input: imagis - remove incorrect ifdef checks
sata: mv: drop unnecessary #ifdef checks
ASoC: remove incorrect of_match_ptr/ACPI_PTR annotations
spi: remove incorrect of_match_ptr annotations
drivers: remove incorrect of_match_ptr/ACPI_PTR annotations
kbuild: always enable -Wunused-const-variable
Krzysztof Kozlowski (1):
Input: stmpe-ts - mark OF related data as maybe unused
arch/powerpc/sysdev/fsl_msi.c | 2 +
drivers/ata/sata_mv.c | 64 +--
drivers/char/apm-emulation.c | 5 +-
drivers/char/ipmi/ipmb_dev_int.c | 2 +-
drivers/char/tpm/tpm_ftpm_tee.c | 2 +-
drivers/clk/ti/dpll.c | 10 ++-
drivers/comedi/drivers/ni_atmio.c | 2 +-
drivers/cpufreq/intel_pstate.c| 2 +
drivers/crypto/ccp/sp-platform.c | 14 +---
drivers/dma/img-mdc-dma.c | 2 +-
drivers/firmware/efi/Makefile | 3 +-
drivers/firmware/efi/sysfb_efi.c | 2 -
drivers/firmware/qcom/qcom_scm.c | 2 +-
drivers/fpga/versal-fpga.c| 2 +-
.../gpu/drm/arm/display/komeda/komeda_dev.c | 8 ---
drivers/hid/hid-google-hammer.c | 6 +-
drivers/i2c/busses/i2c-pxa.c | 2 +-
drivers/i2c/muxes/i2c-mux-ltc4306.c | 2 +-
drivers/i2c/muxes/i2c-mux-reg.c | 2 +-
drivers/iio/dac/ad5755.c | 1 +
drivers/input/mouse/synaptics.c | 2 +
drivers/input/touchscreen/imagis.c| 4 +-
drivers/input/touchscreen/stmpe-ts.c | 2 +-
drivers/input/touchscreen/wdt87xx_i2c.c | 2 +-
drivers/isdn/capi/Makefile| 3 +-
drivers/isdn/capi/kcapi.c | 7 +-
drivers/leds/leds-apu.c | 3 +-
drivers/mux/adg792a.c | 2 +-
drivers/net/ethernet/3com/3c515.c | 3 -
drivers/net/ethernet/amd/xgbe/xgbe-platform.c | 8 ---
drivers/net/ethernet/apm/xgene-v2/main.c | 2 +-
drivers/net/ethernet/hisilicon/hns_mdio.c | 2 +-
Re: [Openipmi-developer] [PATCH 2/9] dma: Convert from tasklet to BH workqueue
On Thu, Mar 28, 2024, at 20:39, Allen wrote: >> > >> > Since almost every driver associates the tasklet with the >> > dma_chan, we could go one step further and add the >> > work_queue structure directly into struct dma_chan, >> > with the wrapper operating on the dma_chan rather than >> > the work_queue. >> >> I think that is very great idea. having this wrapped in dma_chan would >> be very good way as well >> >> Am not sure if Allen is up for it :-) > > Thanks Arnd, I know we did speak about this at LPC. I did start > working on using completion. I dropped it as I thought it would > be easier to move to workqueues. It's definitely easier to do the workqueue conversion as a first step, and I agree adding support for the completion right away is probably too much. Moving the work_struct into the dma_chan is probably not too hard though, if you leave your current approach for the cases where the tasklet is part of the dma_dev rather than the dma_chan. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 2/9] dma: Convert from tasklet to BH workqueue
On Thu, Mar 28, 2024, at 06:55, Vinod Koul wrote: > On 27-03-24, 16:03, Allen Pais wrote: >> The only generic interface to execute asynchronously in the BH context is >> tasklet; however, it's marked deprecated and has some design flaws. To >> replace tasklets, BH workqueue support was recently added. A BH workqueue >> behaves similarly to regular workqueues except that the queued work items >> are executed in the BH context. > > Thanks for conversion, am happy with BH alternative as it helps in > dmaengine where we need shortest possible time between tasklet and > interrupt handling to maximize dma performance I still feel that we want something different for dmaengine, at least in the long run. As we have discussed in the past, the tasklet context in these drivers is what the callbacks from the dma client device is run in, and a lot of these probably want something other than tasklet context, e.g. just call complete() on a client-provided completion structure. Instead of open-coding the use of the system_bh_wq in each dmaengine, how about we start with a custom WQ_BH specifically for the dmaengine subsystem and wrap them inside of another interface. Since almost every driver associates the tasklet with the dma_chan, we could go one step further and add the work_queue structure directly into struct dma_chan, with the wrapper operating on the dma_chan rather than the work_queue. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v3 03/38] char: impi, tpm: depend on HAS_IOPORT
On Tue, Mar 14, 2023, at 15:17, Geert Uytterhoeven wrote: >> --- a/drivers/char/Kconfig >> +++ b/drivers/char/Kconfig >> @@ -34,6 +34,7 @@ config TTY_PRINTK_LEVEL >> config PRINTER >> tristate "Parallel printer support" >> depends on PARPORT >> + depends on HAS_IOPORT > > This looks wrong to me. > drivers/char/lp.c uses the parport API, no direct I/O port access. It looks like include/linux/parport.h requires I/O port access when PARPORT_PC is enabled and PARPORT_NOT_PC is disabled. Maybe this would work: depends on PARPORT depends on HAS_IOPORT || PARPORT_NOT_PC Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v3 03/38] char: impi, tpm: depend on HAS_IOPORT
On Tue, Mar 14, 2023, at 13:20, Jarkko Sakkinen wrote: > On Tue, Mar 14, 2023 at 01:11:41PM +0100, Niklas Schnelle wrote: > Reviewed-by: Jarkko Sakkinen > > Who should pick this? All patches in this series depend on patch 1, so either I merge them all through the asm-generic tree, or I ask Linus to apply just patch 1 for now, and then each subsystem can pick up their own patches based on top of that. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH] HPE BMC GXP SUPPORT
On Wed, Feb 2, 2022 at 7:14 PM Verdun, Jean-Marie wrote: > > > This is far too big for a single patch. It needs to be broken into > > functional chunks that can be reviewed individually. Each driver and > > each device tree change along with it's accompanying code need to be > > done in individual patches. The way it is it can't be reviewed in any > > sane manner. > > > -corey > > Thanks for your feedback. We are getting a little bit lost here, as our plan > was to submit initial > > - bindings > - dts for SoC and 1 board > - initial platform init code > > Then drivers code avoiding to send many dts updates which might complexify the > review. We wanted to send all drivers code to relevant reviewers by tomorrow. > > So, what you are asking ( do not worry I am not trying to negotiate, I just > want > to avoid English misunderstandings as I am French) is to send per driver > > - binding > - dts update > - driver code > > For each driver through different submission (with each of them containing the > 3 associated parts) ? > > What shall be the initial one in our case as we are introducing a platform ? > An empty dts infrastructure and then we make it grow one step at a time ? Ideally, what I prefer to see is a series of patches for all "essential" drivers and the platform code that includes: - one patch for each new binding - one patch for each new driver - one patch that hooks up arch/arm/mach-hpe/, MAINTAINERS and any other changes to arch/arm/ other than dts - one patch that adds the initial .dts and .dtsi files, with all the devices added that have a valid binding, no need to split this up any further This should include everything you need to boot into an initramfs shell, typically cpu, serial, timer, clk, pinctrl, gpio, irqchip. We will merge these as a git branch in the soc tree. In parallel, you can work with subsystem maintainers for the "non-essential" drivers to review any other driver and binding, e.g. drm/kms, network, i2c, pci, usb, etc. The patches for the corresponding .dts additions also go through the soc tree, but to make things simpler, you can send those in for a later release. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH] ipmi: ipmb: add CONFIG_I2C dependency
From: Arnd Bergmann
When CONFIG_I2C is a loadable module, the slave interface is not
available to built-in drivers:
x86_64-linux-ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_remove':
ipmi_ipmb.c:(.text+0x37): undefined reference to `i2c_slave_unregister'
x86_64-linux-ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_thread':
ipmi_ipmb.c:(.text+0x284): undefined reference to `i2c_transfer'
Add another dependency to the ipmb backend to avoid this.
Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB")
Signed-off-by: Arnd Bergmann
---
drivers/char/ipmi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index ace882ed3d55..b061e6b513ed 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -77,7 +77,7 @@ config IPMI_SSIF
config IPMI_IPMB
tristate 'IPMI IPMB interface'
- depends on I2C_SLAVE
+ depends on I2C && I2C_SLAVE
help
Provides a driver for a system running right on the IPMB bus.
It supports normal system interface messages to a BMC on the IPMB
--
2.29.2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Tue, Apr 13, 2021 at 1:45 AM Andrew Jeffery wrote: > On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote: > > On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery wrote: > > > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > > > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > > > > > > > The existing IPMI chardev encodes IPMI behaviours as the name > > > > > suggests. > > > > > However, KCS devices are useful beyond IPMI (or keyboards), as they > > > > > provide a means to generate IRQs and exchange arbitrary data between a > > > > > BMC and its host system. > > > > > > > > I only noticed the series after Joel asked about the DT changes on the > > > > arm > > > > side. One question though: > > > > > > > > How does this related to the drivers/input/serio/ framework that also > > > > talks > > > > to the keyboard controller for things that are not keyboards? > > > > > > I've taken a brief look and I feel they're somewhat closely related. > > > > > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton > > > KCS drivers move under drivers/input/serio. If you squint, the i8042 > > > serio device driver has similarities with what the Aspeed and Nuvoton > > > device drivers are providing to the KCS IPMI stack. > > > > After looking some more into it, I finally understood that the two are > > rather complementary. While the drivers/char/ipmi/kcs_bmc.c > > is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems > > that the proposed kcs_bmc_cdev_raw.c interface would be > > what corresponds to the other side of > > drivers/input/serio/i8042.c+userio.c. > > Right. I guess the question is should we be splitting kernel subsystems > along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe > we can consolidate in the future if it makes sense? We actually have a number of subsystems with somewhat overlapping functionality. I brought up serio, because it has an abstraction for multiple things that communicate over the keyboard controller and I thought the problem you were trying to solve was also related to the keyboard controller. It is also one of multiple abstractions that allow you to connect a device to a uart (along with serdev and tty_ldisc, probably at least one more that you can nest above or below these). Consolidating the kcs_bmc.c interface into something that already exists would obviously be best, but it's not clear which of these that should be, that depends on the fundamental properties of the hardware interface. > > Then again, these are also on > > separate ports (0x60 for the keyboard controller, 0xca2 for the BMC > > KCS), so they would never actually talk to one another. > > Well, sort of I guess. On Power systems we don't use the keyboard > controller for IPMI or keyboards, so we're just kinda exploiting the > hardware for our own purposes. Can you describe in an abstract form what the hardware interface can do here and what you want from it? I wonder if it could be part of a higher-level interface such as drivers/mailbox/ instead. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery wrote: > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > > > The existing IPMI chardev encodes IPMI behaviours as the name suggests. > > > However, KCS devices are useful beyond IPMI (or keyboards), as they > > > provide a means to generate IRQs and exchange arbitrary data between a > > > BMC and its host system. > > > > I only noticed the series after Joel asked about the DT changes on the arm > > side. One question though: > > > > How does this related to the drivers/input/serio/ framework that also talks > > to the keyboard controller for things that are not keyboards? > > I've taken a brief look and I feel they're somewhat closely related. > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton > KCS drivers move under drivers/input/serio. If you squint, the i8042 > serio device driver has similarities with what the Aspeed and Nuvoton > device drivers are providing to the KCS IPMI stack. After looking some more into it, I finally understood that the two are rather complementary. While the drivers/char/ipmi/kcs_bmc.c is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems that the proposed kcs_bmc_cdev_raw.c interface would be what corresponds to the other side of drivers/input/serio/i8042.c+userio.c. Then again, these are also on separate ports (0x60 for the keyboard controller, 0xca2 for the BMC KCS), so they would never actually talk to one another. > Both the KCS IPMI and raw chardev I've implemented in this patch need > both read and write access to the status register (STR). serio could > potentially expose its value through serio_interrupt() using the > SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this > sentence. We'd need some extra support for writing STR via the serio > API. I'm not sure that fits into the abstraction (unless we make > serio_write() take a flags argument?). > > In that vein, the serio_raw interface is close to the functionality > that the raw chardev provides in this patch, though again serio_raw > lacks userspace access to STR. Flags are ignored in the ->interrupt() > callback so all values received via ->interrupt() are exposed as data. > The result is there's no way to take care of SERIO_OOB_DATA in the > read() path. Given that, I think we'd have to expose an ioctl() to > access the STR value after taking care of SERIO_OOB_DATA in > ->interrupt(). > > I'm not sure where that lands us. Based on what I looked up, I think you can just forget about my original question. We have two separate interfaces that use an Intel 8042-style protocol, but they don't really interact. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > The existing IPMI chardev encodes IPMI behaviours as the name suggests. > However, KCS devices are useful beyond IPMI (or keyboards), as they > provide a means to generate IRQs and exchange arbitrary data between a > BMC and its host system. I only noticed the series after Joel asked about the DT changes on the arm side. One question though: How does this related to the drivers/input/serio/ framework that also talks to the keyboard controller for things that are not keyboards? Are these separate communication channels on adjacent I/O ports, or does there need to be some arbitration? Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
On Fri, Apr 9, 2021 at 6:09 AM Joel Stanley wrote: > On Thu, 8 Apr 2021 at 23:47, Andrew Jeffery wrote: > > On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote: > > > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote: > > > There were some minor concerns that were unanswered, and there really > > > was no review by others for many of the patches. > > > > Right; I was planning to clean up the minor concerns once I'd received > > some more feedback. I could have done a better job of communicating > > that :) > > I'll merge the first five through the aspeed tree this coming merge > window. We have acks from the relevant maintainers. > > Arnd: would you prefer that this come as it's own pull request, or as > part of the device tree branch? When you are unsure, it's almost never wrong to go for a separate branch, which gives you a chance to have a concise description of the contents in the tag. This would be particularly helpful if there are incompatible changes to the DT binding that require a justification. If you are only adding a few DT nodes to existing files, then merging these through the regular branch is probably easier. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v1 1/1] kernel.h: Split out panic and oops helpers
On Tue, Apr 6, 2021 at 3:31 PM Andy Shevchenko wrote: > > kernel.h is being used as a dump for all kinds of stuff for a long time. > Here is the attempt to start cleaning it up by splitting out panic and > oops helpers. > > At the same time convert users in header and lib folder to use new header. > Though for time being include new header back to kernel.h to avoid twisted > indirected includes for existing users. > > Signed-off-by: Andy Shevchenko Nice! Acked-by: Arnd Bergmann ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 0/5] drivers/char: Constify static variables
On Wed, Jul 1, 2020 at 11:48 PM Rikard Falkeborn wrote: > > Constify some static variables (mostly structs) that are not modified. > > Rikard Falkeborn (5): > hwrng: bcm2835 - Constify bcm2835_rng_devtype[] > hwrng: nomadik - Constify nmk_rng_ids[] > hwrng: virtio - Constify id_table[] > ipmi: watchdog: Constify ident > virtio_console: Constify some static variables I just realized it was a series rather than a single patch I received. They all look correct, so Acked-by: Arnd Bergmann but if you do more of those, I would suggest not including the 'size' output for the small variables as that is not the main point here. ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 4/8] ipmi: kill off 'timespec' usage again
On Fri, Nov 8, 2019 at 11:11 PM Corey Minyard wrote:
>
> On Fri, Nov 08, 2019 at 09:34:27PM +0100, Arnd Bergmann wrote:
> > 'struct timespec' is getting removed from the kernel. The usage in ipmi
> > was fixed before in commit 48862ea2ce86 ("ipmi: Update timespec usage
> > to timespec64"), but unfortunately it crept back in.
> >
> > The busy looping code can better use ktime_t anyway, so use that
> > there to simplify the implementation.
>
> Thanks, this is a big improvement. I have this queued, but if you
> are going to submit this, I can remove it, and:
>
> Reviewed-by: Corey Minyard
I'd prefer to have this go through your tree, one less thing for me
to worry about (out of the 90 patches).
> Do you think this should go in to 5.4?
Up to you, it probably depends on how well you can test that the change
is correct beyond the review.
Arnd
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH 4/8] ipmi: kill off 'timespec' usage again
'struct timespec' is getting removed from the kernel. The usage in ipmi
was fixed before in commit 48862ea2ce86 ("ipmi: Update timespec usage
to timespec64"), but unfortunately it crept back in.
The busy looping code can better use ktime_t anyway, so use that
there to simplify the implementation.
Fixes: cbb19cb1eef0 ("ipmi_si: Convert timespec64 to timespec")
Signed-off-by: Arnd Bergmann
---
drivers/char/ipmi/ipmi_si_intf.c | 40 +++-
1 file changed, 13 insertions(+), 27 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 6b9a0593d2eb..c7cc8538b84a 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -265,10 +265,10 @@ static void cleanup_ipmi_si(void);
#ifdef DEBUG_TIMING
void debug_timestamp(char *msg)
{
- struct timespec t;
+ struct timespec64 t;
- ktime_get_ts(&t);
- pr_debug("**%s: %ld.%9.9ld\n", msg, (long) t.tv_sec, t.tv_nsec);
+ ktime_get_ts64(&t);
+ pr_debug("**%s: %lld.%9.9ld\n", msg, t.tv_sec, t.tv_nsec);
}
#else
#define debug_timestamp(x)
@@ -935,38 +935,25 @@ static void set_run_to_completion(void *send_info, bool
i_run_to_completion)
}
/*
- * Use -1 in the nsec value of the busy waiting timespec to tell that
- * we are spinning in kipmid looking for something and not delaying
- * between checks
+ * Use -1 as a special constant to tell that we are spinning in kipmid
+ * looking for something and not delaying between checks
*/
-static inline void ipmi_si_set_not_busy(struct timespec *ts)
-{
- ts->tv_nsec = -1;
-}
-static inline int ipmi_si_is_busy(struct timespec *ts)
-{
- return ts->tv_nsec != -1;
-}
-
+#define IPMI_TIME_NOT_BUSY ns_to_ktime(-1ull)
static inline bool ipmi_thread_busy_wait(enum si_sm_result smi_result,
const struct smi_info *smi_info,
-struct timespec *busy_until)
+ktime_t *busy_until)
{
unsigned int max_busy_us = 0;
if (smi_info->si_num < num_max_busy_us)
max_busy_us = kipmid_max_busy_us[smi_info->si_num];
if (max_busy_us == 0 || smi_result != SI_SM_CALL_WITH_DELAY)
- ipmi_si_set_not_busy(busy_until);
- else if (!ipmi_si_is_busy(busy_until)) {
- ktime_get_ts(busy_until);
- timespec_add_ns(busy_until, max_busy_us * NSEC_PER_USEC);
+ *busy_until = IPMI_TIME_NOT_BUSY;
+ else if (*busy_until == IPMI_TIME_NOT_BUSY) {
+ *busy_until = ktime_get() + max_busy_us * NSEC_PER_USEC;
} else {
- struct timespec now;
-
- ktime_get_ts(&now);
- if (unlikely(timespec_compare(&now, busy_until) > 0)) {
- ipmi_si_set_not_busy(busy_until);
+ if (unlikely(ktime_get() > *busy_until)) {
+ *busy_until = IPMI_TIME_NOT_BUSY;
return false;
}
}
@@ -988,9 +975,8 @@ static int ipmi_thread(void *data)
struct smi_info *smi_info = data;
unsigned long flags;
enum si_sm_result smi_result;
- struct timespec busy_until = { 0, 0 };
+ ktime_t busy_until = IPMI_TIME_NOT_BUSY;
- ipmi_si_set_not_busy(&busy_until);
set_user_nice(current, MAX_NICE);
while (!kthread_should_stop()) {
int busy_wait;
--
2.20.0
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH 0/8] y2038: bug fixes from y2038 work
I've gone through the remaining uses of time_t etc and come up with a set of 90 patches of varying complexity and importance, to the point of being able to remove the old time_t/timeval/timespec from the kernel headers completely. This set includes the eight patches that I think should be merged right away and backported into stable kernels if possible. Please apply individual patches to the respective maintainer trees for either v5.4 or v5.5 as appropriate. For reference, the full series of 90 patches can be found at https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame Arnd Arnd Bergmann (8): y2038: timex: remove incorrect time_t truncation timekeeping: optimize ns_to_timespec64 powerpc: fix vdso32 for ppc64le ipmi: kill off 'timespec' usage again netfilter: xt_time: use time64_t lp: fix sparc64 LPSETTIMEOUT ioctl ppdev: fix PPGETTIME/PPSETTIME ioctls Input: input_event: fix struct padding on sparc64 arch/powerpc/kernel/vdso32/gettimeofday.S | 2 +- drivers/char/ipmi/ipmi_si_intf.c | 40 --- drivers/char/lp.c | 4 +++ drivers/char/ppdev.c | 16 ++--- drivers/input/evdev.c | 3 ++ drivers/input/misc/uinput.c | 3 ++ include/uapi/linux/input.h| 1 + kernel/time/ntp.c | 2 +- kernel/time/time.c| 21 +++- net/netfilter/xt_time.c | 19 ++- 10 files changed, 61 insertions(+), 50 deletions(-) Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Corey Minyard Cc: Greg Kroah-Hartman Cc: Sudip Mukherjee Cc: Dmitry Torokhov Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: Pablo Neira Ayuso Cc: Jozsef Kadlecsik Cc: Florian Westphal Cc: "David S. Miller" Cc: linuxppc-...@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org Cc: openipmi-developer@lists.sourceforge.net Cc: linux-in...@vger.kernel.org Cc: netfilter-de...@vger.kernel.org Cc: coret...@netfilter.org Cc: net...@vger.kernel.org Cc: sparcli...@vger.kernel.org -- 2.20.0 ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[PATCH v5 06/18] compat_ioctl: move WDIOC handling into wdt drivers
All watchdog drivers implement the same set of ioctl commands, and
fortunately all of them are compatible between 32-bit and 64-bit
architectures.
Modern drivers always go through drivers/watchdog/wdt.c as an abstraction
layer, but older ones implement their own file_operations on a character
device for this.
Move the handling from fs/compat_ioctl.c into the individual drivers.
Note that most of the legacy drivers will never be used on 64-bit
hardware, because they are for an old 32-bit SoC implementation, but
doing them all at once is safer than trying to guess which ones do
or do not need the compat_ioctl handling.
Signed-off-by: Arnd Bergmann
---
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1 +
arch/um/drivers/harddog_kern.c| 1 +
drivers/char/ipmi/ipmi_watchdog.c | 1 +
drivers/hwmon/fschmd.c| 1 +
drivers/rtc/rtc-ds1374.c | 1 +
drivers/watchdog/acquirewdt.c | 1 +
drivers/watchdog/advantechwdt.c | 1 +
drivers/watchdog/alim1535_wdt.c | 1 +
drivers/watchdog/alim7101_wdt.c | 1 +
drivers/watchdog/ar7_wdt.c| 1 +
drivers/watchdog/at91rm9200_wdt.c | 1 +
drivers/watchdog/ath79_wdt.c | 1 +
drivers/watchdog/bcm63xx_wdt.c| 1 +
drivers/watchdog/cpu5wdt.c| 1 +
drivers/watchdog/eurotechwdt.c| 1 +
drivers/watchdog/f71808e_wdt.c| 1 +
drivers/watchdog/gef_wdt.c| 1 +
drivers/watchdog/geodewdt.c | 1 +
drivers/watchdog/ib700wdt.c | 1 +
drivers/watchdog/ibmasr.c | 1 +
drivers/watchdog/indydog.c| 1 +
drivers/watchdog/intel_scu_watchdog.c | 1 +
drivers/watchdog/iop_wdt.c| 1 +
drivers/watchdog/it8712f_wdt.c| 1 +
drivers/watchdog/ixp4xx_wdt.c | 1 +
drivers/watchdog/ks8695_wdt.c | 1 +
drivers/watchdog/m54xx_wdt.c | 1 +
drivers/watchdog/machzwd.c| 1 +
drivers/watchdog/mixcomwd.c | 1 +
drivers/watchdog/mtx-1_wdt.c | 1 +
drivers/watchdog/mv64x60_wdt.c| 1 +
drivers/watchdog/nuc900_wdt.c | 1 +
drivers/watchdog/nv_tco.c | 1 +
drivers/watchdog/pc87413_wdt.c| 1 +
drivers/watchdog/pcwd.c | 1 +
drivers/watchdog/pcwd_pci.c | 1 +
drivers/watchdog/pcwd_usb.c | 1 +
drivers/watchdog/pika_wdt.c | 1 +
drivers/watchdog/pnx833x_wdt.c| 1 +
drivers/watchdog/rc32434_wdt.c| 1 +
drivers/watchdog/rdc321x_wdt.c| 1 +
drivers/watchdog/riowd.c | 1 +
drivers/watchdog/sa1100_wdt.c | 1 +
drivers/watchdog/sb_wdog.c| 1 +
drivers/watchdog/sbc60xxwdt.c | 1 +
drivers/watchdog/sbc7240_wdt.c| 1 +
drivers/watchdog/sbc_epx_c3.c | 1 +
drivers/watchdog/sbc_fitpc2_wdt.c | 1 +
drivers/watchdog/sc1200wdt.c | 1 +
drivers/watchdog/sc520_wdt.c | 1 +
drivers/watchdog/sch311x_wdt.c| 1 +
drivers/watchdog/scx200_wdt.c | 1 +
drivers/watchdog/smsc37b787_wdt.c | 1 +
drivers/watchdog/w83877f_wdt.c| 1 +
drivers/watchdog/w83977f_wdt.c| 1 +
drivers/watchdog/wafer5823wdt.c | 1 +
drivers/watchdog/watchdog_dev.c | 1 +
drivers/watchdog/wdrtas.c | 1 +
drivers/watchdog/wdt.c| 1 +
drivers/watchdog/wdt285.c | 1 +
drivers/watchdog/wdt977.c | 1 +
drivers/watchdog/wdt_pci.c| 1 +
fs/compat_ioctl.c | 11 ---
63 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index ba12dc14a3d1..8c0d324f657e 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -650,6 +650,7 @@ static const struct file_operations mpc52xx_wdt_fops = {
.llseek = no_llseek,
.write = mpc52xx_wdt_write,
.unlocked_ioctl = mpc52xx_wdt_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
.open = mpc52xx_wdt_open,
.release= mpc52xx_wdt_release,
};
diff --git a/arch/um/drivers/harddog_kern.c b/arch/um/drivers/harddog_kern.c
index 000cb69ba0bc..e6d4f43deba8 100644
--- a/arch/um/drivers/harddog_kern.c
+++ b/arch/um/drivers/harddog_kern.c
@@ -165,6 +165,7 @@ static const struct file_operations harddog_fops = {
.owner = THIS_MODULE,
.write = harddog_write,
.unlocked_ioctl = harddog_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
.open = harddog_open,
.release= harddog_release,
.llseek
[Openipmi-developer] [PATCH v5 00/18] compat_ioctl.c removal, part 2/3
This is a follow-up to part 1/3 that I posted after -rc2. I hope these are still largely uncontroversial changes, and I would like to get them into linux-5.4. Part 1 was in https://lore.kernel.org/lkml/capcyv4i_nhzv155rcgnaq189aq2lfd2g8pa1d5nbzqo9e_u...@mail.gmail.com/ Part 3 will be one kernel release after part 2 is merged, as that still needs a little extra work. The entire series is available at git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git compat_ioctl Arnd Al Viro (2): compat_ioctl: unify copy-in of ppp filters compat_ioctl: move PPPIOCSCOMPRESS to ppp_generic Arnd Bergmann (16): xfs: compat_ioctl: use compat_ptr() xfs: compat_ioctl: add missing conversions gfs2: add compat_ioctl support fs: compat_ioctl: move FITRIM emulation into file systems watchdog: cpwd: use generic compat_ptr_ioctl compat_ioctl: move WDIOC handling into wdt drivers compat_ioctl: reimplement SG_IO handling af_unix: add compat_ioctl support compat_ioctl: handle SIOCOUTQNSD compat_ioctl: move SIOCOUTQ out of compat_ioctl.c tty: handle compat PPP ioctls compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t compat_ioctl: ppp: move simple commands into ppp_generic.c compat_ioctl: move SG_GET_REQUEST_TABLE handling pktcdvd: add compat_ioctl handler scsi: sd: enable compat ioctls for sed-opal Documentation/networking/ppp_generic.txt | 2 + arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1 + arch/um/drivers/harddog_kern.c| 1 + block/scsi_ioctl.c| 132 - drivers/block/pktcdvd.c | 25 ++ drivers/char/ipmi/ipmi_watchdog.c | 1 + drivers/hwmon/fschmd.c| 1 + drivers/net/ppp/ppp_generic.c | 245 ++- drivers/rtc/rtc-ds1374.c | 1 + drivers/scsi/sd.c | 14 +- drivers/scsi/sg.c | 59 +++- drivers/tty/tty_io.c | 5 + drivers/watchdog/acquirewdt.c | 1 + drivers/watchdog/advantechwdt.c | 1 + drivers/watchdog/alim1535_wdt.c | 1 + drivers/watchdog/alim7101_wdt.c | 1 + drivers/watchdog/ar7_wdt.c| 1 + drivers/watchdog/at91rm9200_wdt.c | 1 + drivers/watchdog/ath79_wdt.c | 1 + drivers/watchdog/bcm63xx_wdt.c| 1 + drivers/watchdog/cpu5wdt.c| 1 + drivers/watchdog/cpwd.c | 25 +- drivers/watchdog/eurotechwdt.c| 1 + drivers/watchdog/f71808e_wdt.c| 1 + drivers/watchdog/gef_wdt.c| 1 + drivers/watchdog/geodewdt.c | 1 + drivers/watchdog/ib700wdt.c | 1 + drivers/watchdog/ibmasr.c | 1 + drivers/watchdog/indydog.c| 1 + drivers/watchdog/intel_scu_watchdog.c | 1 + drivers/watchdog/iop_wdt.c| 1 + drivers/watchdog/it8712f_wdt.c| 1 + drivers/watchdog/ixp4xx_wdt.c | 1 + drivers/watchdog/ks8695_wdt.c | 1 + drivers/watchdog/m54xx_wdt.c | 1 + drivers/watchdog/machzwd.c| 1 + drivers/watchdog/mixcomwd.c | 1 + drivers/watchdog/mtx-1_wdt.c | 1 + drivers/watchdog/mv64x60_wdt.c| 1 + drivers/watchdog/nuc900_wdt.c | 1 + drivers/watchdog/nv_tco.c | 1 + drivers/watchdog/pc87413_wdt.c| 1 + drivers/watchdog/pcwd.c | 1 + drivers/watchdog/pcwd_pci.c | 1 + drivers/watchdog/pcwd_usb.c | 1 + drivers/watchdog/pika_wdt.c | 1 + drivers/watchdog/pnx833x_wdt.c| 1 + drivers/watchdog/rc32434_wdt.c| 1 + drivers/watchdog/rdc321x_wdt.c| 1 + drivers/watchdog/riowd.c | 1 + drivers/watchdog/sa1100_wdt.c | 1 + drivers/watchdog/sb_wdog.c| 1 + drivers/watchdog/sbc60xxwdt.c | 1 + drivers/watchdog/sbc7240_wdt.c| 1 + drivers/watchdog/sbc_epx_c3.c | 1 + drivers/watchdog/sbc_fitpc2_wdt.c | 1 + drivers/watchdog/sc1200wdt.c | 1 + drivers/watchdog/sc520_wdt.c | 1 + drivers/watchdog/sch311x_wdt.c| 1 + drivers/watchdog/scx200_wdt.c | 1 + drivers/watchdog/smsc37b787_wdt.c | 1 + drivers/watchdog/w83877f_wdt.c| 1 + drivers/watchdog/w83977f_wdt.c| 1 + drivers/watchdog/wafer5823wdt.c | 1 + drivers/watchdog/watchdog_dev.c | 1 + drivers/watchdog/wdrtas.c | 1 + drivers/watchdog/wdt.c| 1 + drivers/watchdog/wdt285.c | 1 + drivers/watchdog/wdt977.c | 1 + drivers/watchdog/wdt_pci.c| 1 + fs/compat_ioctl.c
[Openipmi-developer] [PATCH] ipmi: ipmb: don't allocate i2c_client on stack
The i2c_client structure can be fairly large, which leads to
a warning about possible kernel stack overflow in some
configurations:
drivers/char/ipmi/ipmb_dev_int.c:115:16: error: stack frame size of 1032 bytes
in function 'ipmb_write' [-Werror,-Wframe-larger-than=]
There is no real reason to even declare an i2c_client, as we can simply
call i2c_smbus_xfer() directly instead of the i2c_smbus_write_block_data()
wrapper.
Convert the ipmb_write() to use an open-coded i2c_smbus_write_block_data()
here, without changing the behavior.
It seems that there is another problem with this implementation;
when user space passes a length of more than I2C_SMBUS_BLOCK_MAX
bytes, all the rest is silently ignored. This should probably be
addressed in a separate patch, but I don't know what the intended
behavior is here.
Fixes: 51bd6f291583 ("Add support for IPMB driver")
Signed-off-by: Arnd Bergmann
---
drivers/char/ipmi/ipmb_dev_int.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/char/ipmi/ipmb_dev_int.c b/drivers/char/ipmi/ipmb_dev_int.c
index 2895abf72e61..c9724f6cf32d 100644
--- a/drivers/char/ipmi/ipmb_dev_int.c
+++ b/drivers/char/ipmi/ipmb_dev_int.c
@@ -117,7 +117,7 @@ static ssize_t ipmb_write(struct file *file, const char
__user *buf,
{
struct ipmb_dev *ipmb_dev = to_ipmb_dev(file);
u8 rq_sa, netf_rq_lun, msg_len;
- struct i2c_client rq_client;
+ union i2c_smbus_data data;
u8 msg[MAX_MSG_LEN];
ssize_t ret;
@@ -138,17 +138,17 @@ static ssize_t ipmb_write(struct file *file, const char
__user *buf,
/*
* subtract rq_sa and netf_rq_lun from the length of the msg passed to
-* i2c_smbus_write_block_data_local
+* i2c_smbus_xfer
*/
msg_len = msg[IPMB_MSG_LEN_IDX] - SMBUS_MSG_HEADER_LENGTH;
-
- strcpy(rq_client.name, "ipmb_requester");
- rq_client.adapter = ipmb_dev->client->adapter;
- rq_client.flags = ipmb_dev->client->flags;
- rq_client.addr = rq_sa;
-
- ret = i2c_smbus_write_block_data(&rq_client, netf_rq_lun, msg_len,
- msg + SMBUS_MSG_IDX_OFFSET);
+ if (msg_len > I2C_SMBUS_BLOCK_MAX)
+ msg_len = I2C_SMBUS_BLOCK_MAX;
+
+ data.block[0] = msg_len;
+ memcpy(&data.block[1], msg + SMBUS_MSG_IDX_OFFSET, msg_len);
+ ret = i2c_smbus_xfer(ipmb_dev->client->adapter, rq_sa,
ipmb_dev->client->flags,
+I2C_SMBUS_WRITE, netf_rq_lun,
+I2C_SMBUS_BLOCK_DATA, &data);
return ret ? : count;
}
--
2.20.0
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH] ipmi: avoid atomic_inc in exit function
On Mon, Apr 15, 2019 at 7:39 PM Corey Minyard wrote: > > On Mon, Apr 15, 2019 at 09:40:22AM -0700, Christoph Hellwig wrote: > > On Mon, Apr 15, 2019 at 05:55:00PM +0200, Arnd Bergmann wrote: > > > This causes a link failure on ARM in certain configurations, > > > when we reference each atomic operation from .alt.smp.init in > > > order to patch out atomics on non-SMP systems: > > > > > > `.exit.text' referenced in section `.alt.smp.init' of > > > drivers/char/ipmi/ipmi_msghandler.o: defined in discarded section > > > `.exit.text' of drivers/char/ipmi/ipmi_msghandler.o > > > > > > In this case, we can trivially replace the atomic_inc() with > > > an atomic_set() that has the same effect and does not require > > > a fixup. > > > > I'd rather fіx the arm section management. Using atomic in exit > > routines is perfectly valid, and it would seem odd to forbid it. > > That was my first thought, too. It's kind of hard to believe that > the IPMI driver is the only thing that does an atomic_inc() in the > exit code. That's what I had thought as well at first, and I carried a patch to work around this by not dropping the .text.exit section on ARM when SMP patching is enabled for a few years. I never sent this because that can waste a significant amount of kernel memory, and I knew the warning is harmless. When revisiting it now, I found that this one was the only instance I ever hit. It seems to be that using atomics in module_exit() is indeed odd, because the function is rarely concurrent with anything else. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH] ipmi: avoid atomic_inc in exit function
This causes a link failure on ARM in certain configurations, when we reference each atomic operation from .alt.smp.init in order to patch out atomics on non-SMP systems: `.exit.text' referenced in section `.alt.smp.init' of drivers/char/ipmi/ipmi_msghandler.o: defined in discarded section `.exit.text' of drivers/char/ipmi/ipmi_msghandler.o In this case, we can trivially replace the atomic_inc() with an atomic_set() that has the same effect and does not require a fixup. Signed-off-by: Arnd Bergmann --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index e8ba67834746..c48198eef510 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -5164,7 +5164,7 @@ static void __exit cleanup_ipmi(void) * avoids problems with race conditions removing the timer * here. */ - atomic_inc(&stop_operation); + atomic_set(&stop_operation, 1); del_timer_sync(&ipmi_timer); initialized = false; -- 2.20.0 ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH] ipmi: Change to ktime_get_ts64()
getnstimeofday64() is deprecated because of the inconsistent naming,
it is only a wrapper around ktime_get_real_ts64() now, which could be
used as a direct replacement.
However, it is generally better to use CLOCK_MONOTONIC timestamps
where possible, to avoid glitches with a concurrent settimeofday()
or leap second.
The uses in ipmi are either for debugging prints or for comparing against
a prior timestamp, so using a monotonic ktime_get_ts64() is probably
best here.
Signed-off-by: Arnd Bergmann
---
drivers/char/ipmi/ipmi_si_intf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index ad353be871bf..fb19c796f0fa 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -269,7 +269,7 @@ void debug_timestamp(char *msg)
{
struct timespec64 t;
- getnstimeofday64(&t);
+ ktime_get_ts64(&t);
pr_debug("**%s: %lld.%9.9ld\n", msg, (long long) t.tv_sec, t.tv_nsec);
}
#else
@@ -961,12 +961,12 @@ static inline int ipmi_thread_busy_wait(enum si_sm_result
smi_result,
if (max_busy_us == 0 || smi_result != SI_SM_CALL_WITH_DELAY)
ipmi_si_set_not_busy(busy_until);
else if (!ipmi_si_is_busy(busy_until)) {
- getnstimeofday64(busy_until);
+ ktime_get_ts64(busy_until);
timespec64_add_ns(busy_until, max_busy_us*NSEC_PER_USEC);
} else {
struct timespec64 now;
- getnstimeofday64(&now);
+ ktime_get_ts64(&now);
if (unlikely(timespec64_compare(&now, busy_until) > 0)) {
ipmi_si_set_not_busy(busy_until);
return 0;
--
2.9.0
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2] ipmi: Fix error code in try_smi_init()
On Tue, Mar 6, 2018 at 11:40 AM, Dan Carpenter wrote: > If platform_device_alloc() fails, then we should return -ENOMEM instead > of returning success. I've also removed the "rv" initialization so that > GCC can maybe detect if we forget to set it in the future. > > Signed-off-by: Dan Carpenter > --- > v2: Don't initialize "rv" and fix a typo in the commit message This addresses my comment, so Acked-by: Arnd Bergmann -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH] ipmi: missing error code in try_smi_init()
On Tue, Mar 6, 2018 at 10:58 AM, Dan Carpenter wrote:
> If platform_device_alloc() then we should return -ENOMEM instead of
> returning success.
>
> Signed-off-by: Dan Carpenter
Looks good, though I would probably remove that incorrect 'rv = 0' as well
so gcc can catch similar problems in case the function gets changed
again.
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c
> b/drivers/char/ipmi/ipmi_si_intf.c
> index f2a294f78892..ff870aa91cfe 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2071,6 +2071,7 @@ static int try_smi_init(struct smi_info *new_smi)
> new_smi->intf_num);
> if (!new_smi->pdev) {
> pr_err(PFX "Unable to allocate platform device\n");
> + rv = -ENOMEM;
> goto out_err;
> }
> new_smi->io.dev = &new_smi->pdev->dev;
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
On Tuesday, November 8, 2016 12:15:57 PM CET Corey Minyard wrote: > On 11/08/2016 09:52 AM, Cédric Le Goater wrote: > > O > snip > > While we're modifying the binding, should we add a compat string for > the ast2500? > >>> Well, if the change in this patch is fine for all, may be we can add > >>> the ast2500 compat string in a followup patch ? > >> Sounds good to me. > > OK. So, how do we proceed with this patch ? Who would include it in its > > tree ? > > I don't have anything for 4.9 at the moment. Arnd, if you have > something, can > you take this? Otherwise I will. > > And I guess I should add: > > Acked-by: Corey Minyard Thanks, I've added it to my todo folder. Olof, if you do fixes before I do, please pick up this patch with Corey's Ack. Arnd -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
On Wednesday, November 2, 2016 3:28:01 PM CET Cédric Le Goater wrote: > On 11/02/2016 02:56 PM, Joel Stanley wrote: > > On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann wrote: > >> On Wednesday 02 November 2016, Cédric Le Goater wrote: > >>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the > >>> other is H8S/2168 compliant. > >>> > >>> The current ipmi/bt-bmc driver implements the IPMI version and we > >>> should reflect its nature in the compatible node name using > >>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The > >>> latter should be used for a H8S interface driver if it is implemented > >>> one day. > >>> > >>> Signed-off-by: Cédric Le Goater > >> > >> We generally try to avoid changing the compatible strings after the > >> fact, but it's probably ok in this case. > > As the device tree changes are not merged yet, we thought we had some > more time to fine tune the naming. Ok, I see. No problem then. > >> I don't understand who decides which of the two interfaces is used: > >> is it the same register set that can be driven by either one or the > >> other driver, or do you expect to have two drivers that can both > >> be active in the same system and talk to different hardware once > >> you get there? > > > > It's the second case. The H8S BT has a different register layout so it > > would require a different driver. > > yes. > > > We don't yet have a driver for the other BT device, but there was > > recent talk of using it as an alternate (non-ipmi channel) between the > > BMC and the host. Before that discussion I wasn't aware that the H8S > > BT existed. I suggested we fix this up before it hits a final release. > > > > Cédric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a > > better job of describing the hardware here? > > The specs refer to the two interfaces as BT (non IPMI) and iBT (IPMI). > I think we can keep the same naming. Ok > > While we're modifying the binding, should we add a compat string for > > the ast2500? > > Well, if the change in this patch is fine for all, may be we can add > the ast2500 compat string in a followup patch ? Sounds good to me. Arnd -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
On Wednesday 02 November 2016, Cédric Le Goater wrote: > The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the > other is H8S/2168 compliant. > > The current ipmi/bt-bmc driver implements the IPMI version and we > should reflect its nature in the compatible node name using > 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The > latter should be used for a H8S interface driver if it is implemented > one day. > > Signed-off-by: Cédric Le Goater We generally try to avoid changing the compatible strings after the fact, but it's probably ok in this case. I don't understand who decides which of the two interfaces is used: is it the same register set that can be driven by either one or the other driver, or do you expect to have two drivers that can both be active in the same system and talk to different hardware once you get there? If the first one of these is true, it seems a little awkward to use the DT compatible string to decide which driver to use rather than making the decision in the OS. Arnd -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 0/3] ARM: aspeed: add support for the BT IPMI interface
On Friday, September 16, 2016 12:39:24 PM CEST Cédric Le Goater wrote: > > Cédric Le Goater (2): > ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC > ARM: dts: aspeed: Enable BT IPMI BMC device These two should go through the arm-soc tree, I assume Joel will forward them to a...@kernel.org once the driver gets picked up into the ipmi tree. Arnd -- ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 1/3] ipmi: add an Aspeed BT IPMI BMC driver
On Friday, September 16, 2016 12:39:25 PM CEST Cédric Le Goater wrote: > From: Alistair Popple > > This patch adds a simple device driver to expose the iBT interface on > Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are > commonly used as BMCs (BaseBoard Management Controllers) and this > driver implements the BMC side of the BT interface. > > The BT (Block Transfer) interface is used to perform in-band IPMI > communication between a host and its BMC. Entire messages are buffered > before sending a notification to the other end, host or BMC, that > there is data to be read. Usually, the host emits requests and the BMC > responses but the specification provides a mean for the BMC to send > SMS Attention (BMC-to-Host attention or System Management Software > attention) messages. > > For this purpose, the driver introduces a specific ioctl on the > device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running > on the BMC to signal the host of such an event. > > The device name defaults to '/dev/ipmi-bt-host' > > Signed-off-by: Alistair Popple > Signed-off-by: Jeremy Kerr > Signed-off-by: Joel Stanley > Acked-by: Arnd Bergmann -- ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [Y2038] [PATCH v2] char: ipmi: ipmi_ssif: Replace timeval with timespec64
On Saturday 24 October 2015 01:21:04 Amitoj Kaur Chawla wrote: > This patch replaces timeval with timespec64 as 32 bit 'struct timeval' > will not give current time beyond 2038. > > The patch changes the code to use ktime_get_real_ts64() which returns > a 'struct timespec64' instead of do_gettimeofday() which returns a > 'struct timeval' > > This patch also alters the format string in pr_info() for now.tv_sec > to incorporate 'long long' on 32 bit architectures. > > Signed-off-by: Amitoj Kaur Chawla > Reviewed-by: Arnd Bergmann -- ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH] ipmi: avoid gcc warning
A new harmless warning has come up on ARM builds with gcc-4.9:
drivers/char/ipmi/ipmi_msghandler.c: In function 'smi_send.isra.11':
include/linux/spinlock.h:372:95: warning: 'flags' may be used uninitialized in
this function [-Wmaybe-uninitialized]
raw_spin_unlock_irqrestore(&lock->rlock, flags);
^
drivers/char/ipmi/ipmi_msghandler.c:1490:16: note: 'flags' was declared here
unsigned long flags;
^
This could be worked around by initializing the 'flags' variable, but it
seems better to rework the code to avoid this.
Signed-off-by: Arnd Bergmann
Fixes: 7ea0ed2b5be81 ("ipmi: Make the message handler easier to use for SMI
interfaces")
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b/drivers/char/ipmi/ipmi_msghandler.c
index 6b65fa4e0c55..fb0f8eacd208 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -1483,14 +1483,10 @@ static inline void format_lan_msg(struct ipmi_smi_msg
*smi_msg,
smi_msg->msgid = msgid;
}
-static void smi_send(ipmi_smi_t intf, struct ipmi_smi_handlers *handlers,
-struct ipmi_smi_msg *smi_msg, int priority)
+static struct ipmi_smi_msg *smi_add_send_msg(ipmi_smi_t intf,
+struct ipmi_smi_msg *smi_msg,
+int priority)
{
- int run_to_completion = intf->run_to_completion;
- unsigned long flags;
-
- if (!run_to_completion)
- spin_lock_irqsave(&intf->xmit_msgs_lock, flags);
if (intf->curr_msg) {
if (priority > 0)
list_add_tail(&smi_msg->link, &intf->hp_xmit_msgs);
@@ -1500,8 +1496,24 @@ static void smi_send(ipmi_smi_t intf, struct
ipmi_smi_handlers *handlers,
} else {
intf->curr_msg = smi_msg;
}
- if (!run_to_completion)
+
+ return smi_msg;
+}
+
+
+static void smi_send(ipmi_smi_t intf, struct ipmi_smi_handlers *handlers,
+struct ipmi_smi_msg *smi_msg, int priority)
+{
+ int run_to_completion = intf->run_to_completion;
+
+ if (run_to_completion) {
+ smi_msg = smi_add_send_msg(intf, smi_msg, priority);
+ } else {
+ unsigned long flags;
+ spin_lock_irqsave(&intf->xmit_msgs_lock, flags);
+ smi_msg = smi_add_send_msg(intf, smi_msg, priority);
spin_unlock_irqrestore(&intf->xmit_msgs_lock, flags);
+ }
if (smi_msg)
handlers->sender(intf->send_info, smi_msg);
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 2/2][RFC] ipmi: Update timespec usage to timespec64
On Wednesday 07 January 2015 12:51:50 John Stultz wrote: > As part of the internal y2038 cleanup, this patch removes > timespec usage in the ipmi driver, replacing it timespec64 > > Cc: Corey Minyard > Cc: openipmi-developer@lists.sourceforge.net > Cc: Arnd Bergmann > Signed-off-by: John Stultz > In other drivers, we tended to use ktime_t and monotonic time, but your approach is definitely simpler because it doesn't have to rework the ipmi_si_is_busy logic and just do a s/timespec/timespec64/ conversion. Do you think it makes sense to use ktime_get_ts64 instead of getnstimeofday64 to get a monotonic time? The advantage would be to have the code work slightly better when racing against settimeofday, the downside would be that the debug printk shows the changed time base, but that would hopefully be irrelevant to someone debugging the code. Arnd -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH] ipmi: work around gcc-4.9 build warning
Building ipmi on arm with gcc-4.9 results in this warning
for an allmodconfig build:
drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_thread':
include/linux/time.h:28:5: warning: 'busy_until.tv_sec' may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (lhs->tv_sec > rhs->tv_sec)
^
drivers/char/ipmi/ipmi_si_intf.c:1007:18: note: 'busy_until.tv_sec' was
declared here
struct timespec busy_until;
^
The warning is bogus and this case can not occur. Apparently
this is a false positive resulting from gcc getting a little
smarter about tracking assignments but not smart enough. Marking
the ipmi_thread_busy_wait function as inline gives the gcc
optimization logic enough information to figure out for itself
that the case cannot happen, which gets rid of the warning
without adding any fake initialization.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 5d665680ae33..539ff0db52fc 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -965,9 +965,9 @@ static inline int ipmi_si_is_busy(struct timespec *ts)
return ts->tv_nsec != -1;
}
-static int ipmi_thread_busy_wait(enum si_sm_result smi_result,
-const struct smi_info *smi_info,
-struct timespec *busy_until)
+static inline int ipmi_thread_busy_wait(enum si_sm_result smi_result,
+ const struct smi_info *smi_info,
+ struct timespec *busy_until)
{
unsigned int max_busy_us = 0;
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] IPMI misbehaving on ARM defconfigs, was [Re: stable boot: 18 pass, 4 fail (v3.10.39)]
On Wednesday 07 May 2014 10:20:56 Jason Cooper wrote: > > ipmi message handler version 39.2 > > IPMI System Interface driver. > > ipmi_si: Adding default-specified kcs state machine > > ipmi_si: Trying default-specified kcs state machine at i/o address 0xca2, > > slave address 0x0, irq 0 > > ipmi_si: Could not set up I/O space > > Trying to free nonexistent resource <0ca2-0ca2> > > Trying to free nonexistent resource <0ca3-0ca3> > > ipmi_si: Adding default-specified smic state machine > > ipmi_si: Trying default-specified smic state machine at i/o address 0xca9, > > slave address 0x0, irq 0 > > ipmi_si: Could not set up I/O space > > Trying to free nonexistent resource <0ca9-0ca9> > > Trying to free nonexistent resource <0caa-0caa> > > Trying to free nonexistent resource <0cab-0cab> > > ipmi_si: Adding default-specified bt state machine > > ipmi_si: Trying default-specified bt state machine at i/o address 0xe4, > > slave address 0x0, irq 0 > > ipmi_si: Could not set up I/O space > > Trying to free nonexistent resource <00e4-00e4> > > Trying to free nonexistent resource <00e5-00e5> > > Trying to free nonexistent resource <00e6-00e6> > > ipmi_si: Unable to find any System Interface(s) > > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled > ... > > It appears to be unrelated to the failure this original message was > about. However, the failure brought the above to our attention. > > Is the IPMI driver used on ARM? Documentation/IPMI.txt indicates a > dependency on ACPI, but that isn't reflected in the Kconfig. At any > rate, it seems rather unhappy. :( It certainly can be used, and it can be probed through a known PC-style port number or through the DT binding. However, we don't normally want it to try the PC style addresses, which appear to be used in this case. This should only happen if CONFIG_IPMI_SI_PROBE_DEFAULTS is set, as far as I can tell. Is that set in your configuration? Arnd -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH 31/62] driver/char: irq: Remove IRQF_DISABLED
On Wednesday 07 September 2011, Yong Zhang wrote: > This flag is a NOOP and can be removed now. > > Signed-off-by: Yong Zhang Acked-by: Arnd Bergmann -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH 4/7] ipmi: autoconvert trivial BKL users to private mutex
All these files use the big kernel lock in a trivial
way to serialize their private file operations,
typically resulting from an earlier semi-automatic
pushdown from VFS.
None of these drivers appears to want to lock against
other code, and they all use the BKL as the top-level
lock in their file operations, meaning that there
is no lock-order inversion problem.
Consequently, we can remove the BKL completely,
replacing it with a per-file mutex in every case.
Using a scripted approach means we can avoid
typos.
file=$1
name=$2
if grep -q lock_kernel ${file} ; then
if grep -q 'include.*linux.mutex.h' ${file} ; then
sed -i '/include.*/d' ${file}
else
sed -i 's/include.*.*$/include
/g' ${file}
fi
sed -i ${file} \
-e "/^#include.*linux.mutex.h/,$ {
1,/^\(static\|int\|long\)/ {
/^\(static\|int\|long\)/istatic
DEFINE_MUTEX(${name}_mutex);
} }" \
-e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
-e '/[ ]*cycle_kernel_lock();/d'
else
sed -i -e '/include.*\/d' ${file} \
-e '/cycle_kernel_lock()/d'
fi
Signed-off-by: Arnd Bergmann
Cc: Corey Minyard
Cc: openipmi-developer@lists.sourceforge.net
---
drivers/char/ipmi/ipmi_devintf.c | 14 +++---
drivers/char/ipmi/ipmi_watchdog.c |8
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_devintf.c b/drivers/char/ipmi/ipmi_devintf.c
index d8ec92a..44833de 100644
--- a/drivers/char/ipmi/ipmi_devintf.c
+++ b/drivers/char/ipmi/ipmi_devintf.c
@@ -44,7 +44,6 @@
#include
#include
#include
-#include
struct ipmi_file_private
{
@@ -59,6 +58,7 @@ struct ipmi_file_private
unsigned int default_retry_time_ms;
};
+static DEFINE_MUTEX(ipmi_mutex);
static void file_receive_handler(struct ipmi_recv_msg *msg,
void *handler_data)
{
@@ -102,9 +102,9 @@ static int ipmi_fasync(int fd, struct file *file, int on)
struct ipmi_file_private *priv = file->private_data;
int result;
- lock_kernel(); /* could race against open() otherwise */
+ mutex_lock(&ipmi_mutex); /* could race against open() otherwise */
result = fasync_helper(fd, file, on, &priv->fasync_queue);
- unlock_kernel();
+ mutex_unlock(&ipmi_mutex);
return (result);
}
@@ -125,7 +125,7 @@ static int ipmi_open(struct inode *inode, struct file *file)
if (!priv)
return -ENOMEM;
- lock_kernel();
+ mutex_lock(&ipmi_mutex);
priv->file = file;
rv = ipmi_create_user(if_num,
@@ -150,7 +150,7 @@ static int ipmi_open(struct inode *inode, struct file *file)
priv->default_retry_time_ms = 0;
out:
- unlock_kernel();
+ mutex_unlock(&ipmi_mutex);
return rv;
}
@@ -639,9 +639,9 @@ static long ipmi_unlocked_ioctl(struct file *file,
{
int ret;
- lock_kernel();
+ mutex_lock(&ipmi_mutex);
ret = ipmi_ioctl(file, cmd, data);
- unlock_kernel();
+ mutex_unlock(&ipmi_mutex);
return ret;
}
diff --git a/drivers/char/ipmi/ipmi_watchdog.c
b/drivers/char/ipmi/ipmi_watchdog.c
index 654d566..ed10b74 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -149,6 +149,7 @@
#defineWDIOC_GET_PRETIMEOUT _IOW(WATCHDOG_IOCTL_BASE, 22, int)
#endif
+static DEFINE_MUTEX(ipmi_watchdog_mutex);
static int nowayout = WATCHDOG_NOWAYOUT;
static ipmi_user_t watchdog_user;
@@ -748,9 +749,9 @@ static long ipmi_unlocked_ioctl(struct file *file,
{
int ret;
- lock_kernel();
+ mutex_lock(&ipmi_watchdog_mutex);
ret = ipmi_ioctl(file, cmd, arg);
- unlock_kernel();
+ mutex_unlock(&ipmi_watchdog_mutex);
return ret;
}
@@ -844,7 +845,6 @@ static int ipmi_open(struct inode *ino, struct file *filep)
if (test_and_set_bit(0, &ipmi_wdog_open))
return -EBUSY;
- cycle_kernel_lock();
/*
* Don't start the timer now, let it start on the
--
1.7.1
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] [PATCH 00/12] autoconvert trivial BKL users to private mutex
This is a repost of an earlier patch to remove those users of the big kernel lock that can be converted to a mutex using a simple script. The only use of the BKL is in file operations that are called without any other lock, so the new mutex is the top-level serialization and cannot introduce any AB-BA deadlock. Please apply to the respective maintainer trees if the patches look good. Arnd Bergmann (12): staging: autoconvert trivial BKL users to private mutex isdn: autoconvert trivial BKL users to private mutex scsi: autoconvert trivial BKL users to private mutex media: autoconvert trivial BKL users to private mutex usb: autoconvert trivial BKL users to private mutex net: autoconvert trivial BKL users to private mutex cris: autoconvert trivial BKL users to private mutex sbus: autoconvert trivial BKL users to private mutex mtd: autoconvert trivial BKL users to private mutex mac: autoconvert trivial BKL users to private mutex ipmi: autoconvert trivial BKL users to private mutex drivers: autoconvert trivial BKL users to private mutex arch/cris/arch-v10/drivers/eeprom.c|2 - arch/cris/arch-v10/drivers/i2c.c |2 - arch/cris/arch-v32/drivers/cryptocop.c |2 - arch/cris/arch-v32/drivers/i2c.c | 12 drivers/block/paride/pg.c |7 ++-- drivers/block/paride/pt.c | 19 ++-- drivers/char/apm-emulation.c | 11 --- drivers/char/applicom.c|9 +++-- drivers/char/ds1302.c | 15 + drivers/char/ds1620.c |8 ++-- drivers/char/dsp56k.c | 27 + drivers/char/dtlk.c|8 ++-- drivers/char/generic_nvram.c |7 ++-- drivers/char/genrtc.c | 13 drivers/char/i8k.c |7 ++-- drivers/char/ip2/ip2main.c |8 ++-- drivers/char/ipmi/ipmi_devintf.c | 14 drivers/char/ipmi/ipmi_watchdog.c |8 ++-- drivers/char/lp.c | 15 + drivers/char/mbcs.c|8 ++-- drivers/char/mmtimer.c |7 ++-- drivers/char/mwave/mwavedd.c | 44 ++-- drivers/char/nvram.c | 11 --- drivers/char/nwflash.c | 12 drivers/char/pcmcia/cm4000_cs.c| 11 --- drivers/char/pcmcia/cm4040_cs.c|7 ++-- drivers/char/ppdev.c |8 ++-- drivers/char/rio/rio_linux.c |7 ++-- drivers/char/snsc.c|9 +++-- drivers/char/toshiba.c |9 +++-- drivers/char/viotape.c | 11 --- drivers/char/xilinx_hwicap/xilinx_hwicap.c |6 ++-- drivers/hwmon/fschmd.c |6 ++-- drivers/hwmon/w83793.c |6 ++-- drivers/input/misc/hp_sdc_rtc.c|7 ++-- drivers/isdn/capi/capi.c |6 ++-- drivers/isdn/divert/divert_procfs.c|7 ++-- drivers/isdn/hardware/eicon/divamnt.c |7 ++-- drivers/isdn/hardware/eicon/divasi.c |2 - drivers/isdn/hardware/eicon/divasmain.c|2 - drivers/isdn/hysdn/hysdn_procconf.c| 21 +++-- drivers/isdn/hysdn/hysdn_proclog.c | 15 + drivers/isdn/i4l/isdn_common.c | 27 + drivers/isdn/mISDN/timerdev.c |7 ++-- drivers/macintosh/adb.c| 10 +++--- drivers/macintosh/smu.c|6 ++-- drivers/macintosh/via-pmu.c| 11 --- drivers/media/dvb/bt8xx/dst_ca.c |7 ++-- drivers/media/video/cx88/cx88-blackbird.c | 13 drivers/media/video/dabusb.c | 18 ++-- drivers/media/video/se401.c|9 +++-- drivers/media/video/stradis.c |9 +++-- drivers/media/video/usbvideo/vicam.c | 14 drivers/message/fusion/mptctl.c| 15 + drivers/message/i2o/i2o_config.c | 23 +++--- drivers/misc/phantom.c | 11 --- drivers/mtd/mtdchar.c | 15 + drivers/net/ppp_generic.c | 19 ++-- drivers/net/wan/cosa.c | 10 +++--- drivers/pci/hotplug/cpqphp_sysfs.c | 13 drivers/rtc/rtc-m41t80.c | 13 drivers/sbus/char/display7seg.c|8 ++-- drivers/sbus/char/envctrl.c|2 - drivers/sbus/char/flash.c | 15 + drivers/sbus/char/openprom.c | 15 + drivers/sbus/char/uctrl.c |7 ++-- drivers/scsi/3w-9xxx.c |7
[Openipmi-developer] [PATCH 11/12] ipmi: autoconvert trivial BKL users to private mutex
All these files use the big kernel lock in a trivial
way to serialize their private file operations,
typically resulting from an earlier semi-automatic
pushdown from VFS.
None of these drivers appears to want to lock against
other code, and they all use the BKL as the top-level
lock in their file operations, meaning that there
is no lock-order inversion problem.
Consequently, we can remove the BKL completely,
replacing it with a per-file mutex in every case.
Using a scripted approach means we can avoid
typos.
file=$1
name=$2
if grep -q lock_kernel ${file} ; then
if grep -q 'include.*linux.mutex.h' ${file} ; then
sed -i '/include.*/d' ${file}
else
sed -i 's/include.*.*$/include
/g' ${file}
fi
sed -i ${file} \
-e "/^#include.*linux.mutex.h/,$ {
1,/^\(static\|int\|long\)/ {
/^\(static\|int\|long\)/istatic
DEFINE_MUTEX(${name}_mutex);
} }" \
-e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
-e '/[ ]*cycle_kernel_lock();/d'
else
sed -i -e '/include.*\/d' ${file} \
-e '/cycle_kernel_lock()/d'
fi
Signed-off-by: Arnd Bergmann
Cc: Corey Minyard
Cc: openipmi-developer@lists.sourceforge.net
---
drivers/char/ipmi/ipmi_devintf.c | 14 +++---
drivers/char/ipmi/ipmi_watchdog.c |8
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_devintf.c b/drivers/char/ipmi/ipmi_devintf.c
index d8ec92a..44833de 100644
--- a/drivers/char/ipmi/ipmi_devintf.c
+++ b/drivers/char/ipmi/ipmi_devintf.c
@@ -44,7 +44,6 @@
#include
#include
#include
-#include
struct ipmi_file_private
{
@@ -59,6 +58,7 @@ struct ipmi_file_private
unsigned int default_retry_time_ms;
};
+static DEFINE_MUTEX(ipmi_mutex);
static void file_receive_handler(struct ipmi_recv_msg *msg,
void *handler_data)
{
@@ -102,9 +102,9 @@ static int ipmi_fasync(int fd, struct file *file, int on)
struct ipmi_file_private *priv = file->private_data;
int result;
- lock_kernel(); /* could race against open() otherwise */
+ mutex_lock(&ipmi_mutex); /* could race against open() otherwise */
result = fasync_helper(fd, file, on, &priv->fasync_queue);
- unlock_kernel();
+ mutex_unlock(&ipmi_mutex);
return (result);
}
@@ -125,7 +125,7 @@ static int ipmi_open(struct inode *inode, struct file *file)
if (!priv)
return -ENOMEM;
- lock_kernel();
+ mutex_lock(&ipmi_mutex);
priv->file = file;
rv = ipmi_create_user(if_num,
@@ -150,7 +150,7 @@ static int ipmi_open(struct inode *inode, struct file *file)
priv->default_retry_time_ms = 0;
out:
- unlock_kernel();
+ mutex_unlock(&ipmi_mutex);
return rv;
}
@@ -639,9 +639,9 @@ static long ipmi_unlocked_ioctl(struct file *file,
{
int ret;
- lock_kernel();
+ mutex_lock(&ipmi_mutex);
ret = ipmi_ioctl(file, cmd, data);
- unlock_kernel();
+ mutex_unlock(&ipmi_mutex);
return ret;
}
diff --git a/drivers/char/ipmi/ipmi_watchdog.c
b/drivers/char/ipmi/ipmi_watchdog.c
index 82bcdb2..d80b8c9 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -149,6 +149,7 @@
#defineWDIOC_GET_PRETIMEOUT _IOW(WATCHDOG_IOCTL_BASE, 22, int)
#endif
+static DEFINE_MUTEX(ipmi_watchdog_mutex);
static int nowayout = WATCHDOG_NOWAYOUT;
static ipmi_user_t watchdog_user;
@@ -736,9 +737,9 @@ static long ipmi_unlocked_ioctl(struct file *file,
{
int ret;
- lock_kernel();
+ mutex_lock(&ipmi_watchdog_mutex);
ret = ipmi_ioctl(file, cmd, arg);
- unlock_kernel();
+ mutex_unlock(&ipmi_watchdog_mutex);
return ret;
}
@@ -832,7 +833,6 @@ static int ipmi_open(struct inode *ino, struct file *filep)
if (test_and_set_bit(0, &ipmi_wdog_open))
return -EBUSY;
- cycle_kernel_lock();
/*
* Don't start the timer now, let it start on the
--
1.7.1
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] updated version, fixed the compiler warning
On Friday 26 January 2007 03:54, Christoph Hellwig wrote:
> >
> > +#ifdef CONFIG_PPC_OF
> > +#include
> > +#include
> > +#endif
>
> Adding this OF-specific code to the generic file doesn't look exactly
> nice. Is it possible to separate the code out to a separate ipmi_of.c
> file?
This file already contains the same code for a number of other bus
layers, it might be possible to split out the of part, but then we
should also have separate files for ACPI, PCI and all the others.
I think that reworking the ipmi layer is outside of the scope of
what we want right now, that can be another patch if there is
a consensus that it would be a good idea.
> > +static int __devexit ipmi_of_remove(struct of_device *dev)
> > +{
> > + /* should call
> > + * cleanup_one_si(dev->dev.driver_data); */
>
> Wo why doesn't it do that currently?
This mimics the pci driver that also doesn't do it. The comment
is a hint that when it the ipmi driver gets cleaned up so
that _pci gets it right, _of should do the same. That should
also be a separate patch.
Arnd <><
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] next updated version, fixed cleanup and some minors
On Thursday 25 January 2007 04:34, Christian Krafft wrote: > This patch adds support for of_platform_driver to the ipmi_si module. > When loading the module, the driver will be registered to of_platform. > The driver will be probed for all devices with the type ipmi. It's supporting > devices with compatible settings ipmi-kcs, ipmi-smic and ipmi-bt. > Only ipmi-kcs could be tested. > > Signed-off-by: Christian Krafft <[EMAIL PROTECTED]> > Acked-by: Heiko J Schick <[EMAIL PROTECTED]> > Signed-off-by: Corey Minyard <[EMAIL PROTECTED]> Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> Of course, the subject line is wrong, but I guess Corey can fix that up to come out as 'ipmi: add support for of_device probing' or something like that. Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] updated version, fixed the compiler warning
On Thursday 25 January 2007 01:45, Benjamin Herrenschmidt wrote: > If the underlying ipmi stuff cannot cleanup, then the driver should not > have a module_exit() so the module cannot be removed. It can do the cleanup, but it won't go through the driver's remove function currently, because it also tries to deal with implementations that don't have a 'struct device' abstraction and therefore all ipmi interfaces get torn down by the ipmi driver. Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 0/1] updated version
On Wednesday 20 December 2006 15:45, Christian Krafft wrote:
> I'm about to send an updated version,
>
> I added
> length check for the properties,
> DEFAULT_REGSIZE,
> simplified the comparison,
>
> I did not fix the compiler warning.
>
You should really fix the warning before sending the patch, ideally
you also check that you don't introduce new warnings found by 'sparse'.
Is the warning just about the cast from void* to enum? If so, you
need to replace that with a cast to unsigned long, like
enum { A, B, } e;
void *p;
p = (void *)(unsigned long)A;
e = (unsigned long)p;
Arnd <><
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 0/1] ipmi: update: add autosensing of ipmi devices on powerpc using of device tree
On Monday 18 December 2006 22:52, Segher Boessenkool wrote:
> > +static int ipmi_of_probe(struct of_device *dev,
> > + const struct of_device_id *match)
>
> Shouldn't this (and everything else) be some kind of __init?
It should be __devinit.
> > + regsize = get_property(np, "reg-size", NULL);
> > + regspacing = get_property(np, "reg-spacing", NULL);
> > + regshift = get_property(np, "reg-shift", NULL);
>
> You should check whether you get exactly 4 bytes back or not.
>
> > + if (!regsize)
> > + info->io.regsize = DEFAULT_REGSPACING;
> > + else
> > + info->io.regsize = *regsize;
>
> info->io_regsize = regsize ? *regsize : DEFAULT_REGSIZE;
>
> [Please note that fixes a copy/paste bug, too].
These two changes are contradictory. It's either
regsize = get_property(np, "reg-size", NULL);
info->io_regsize = regsize ? *regsize : DEFAULT_REGSIZE;
or
regsize = get_property(np, "reg-size", &proplen);
info->io_regsize = (proplen == 4) ? *regsize : DEFAULT_REGSIZE;
> > +static int ipmi_of_remove(struct of_device *dev)
> > +{
> > + /* should call
> > + * cleanup_one_si(dev->dev.driver_data); */
>
> So fix that :-)
That should be a separate patch that fixes the same thing for
pci ipmi devices as well. It needs to move code around for this
(or introduce forward declarations), and the effect is no
different, so it's really just a cleanup.
> > +static struct of_device_id ipmi_match[] =
> > +{
> > + { .type = "ipmi", .compatible = "ipmi-kcs", .data = (void*)
> > SI_KCS },
> > + { .type = "ipmi", .compatible = "ipmi-smic", .data = (void*)
> > SI_SMIC },
> > + { .type = "ipmi", .compatible = "ipmi-bt", .data = (void*)SI_BT },
>
> That cast-to-pointer is what gives you that warning when
> casting back. Is there no better solution?
The one alternative might be something more complicated like:
static const enum si_type __devinitdata of_ipmi_dev_info[] = {
[SI_KCS] SI_KCS,
[SI_SMIC] SI_SMIC,
[SI_BT] SI_BT,
};
static const struct of_device_id of_ipmi_match[] = {
{ .type = "ipmi", .compatible = "ipmi-kcs", .data =
&of_ipmi_dev_info[SI_KCS] },
{ .type = "ipmi", .compatible = "ipmi-kcs", .data =
&of_ipmi_dev_info[SI_SMIC] },
{ .type = "ipmi", .compatible = "ipmi-kcs", .data =
&of_ipmi_dev_info[SI_BT] },
};
Not sure if that's worth it.
Arnd <><
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] ipmi: add autosensing of ipmi device on powerpc using device-tree
On Monday 11 December 2006 14:18, Segher Boessenkool wrote: > > We have to include the IPMI information in a way which can be used > > for controllers which are accessed via memory mapped or legacy I/O. > > How to access registers is implicit in the device tree; > just look at the parent bus, it knows how to do it, given > the "reg" value in your device. right, though it's a little different if you need special opcodes, like DCR on ppc4xx or PIO on i386. Let's not worry about those for now. > > (2) > > name = ipmi > > device_type > > device_type = ipmi-kcs > > There's no real reason to include the IPMI version number > in here, if you really need the version it's trivial to > probe for; it's not a property of the hardware but of the > software on the controller (unless some day the IPMI spec > breaks backwards compatibility, of course). Why not this? device-type = ipmi compatible = ipmi-kcs I thought the device-type tells you what kind of bindings to use, and the compatible (and/or model) tells you how to access it. E.g. all PHBs have device-type=pci and compatible=whatever, which tells you how to access the config space registers. > > regs = > > reg-spacing = > > reg-size = > > reg-shift = > > > > The main difference between (1) and (2) is that (2) will represent > > the whole register region within the reg property. > > Which is the proper thing to do. The "reg" property should > describe all of the address space your device listens to. > Some IPMI-KCS devices listen to just the two registers, some > listen to an 8-reg block, some to a 16-reg block. ok Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] ipmi: add autosensing of ipmi device on powerpc using device-tree
On Sunday 10 December 2006 19:42, Heiko J Schick wrote: > On 09.12.2006, at 12:44, Arnd Bergmann wrote: > > We have to include the IPMI information in a way which can be used > for controllers which are accessed via memory mapped or legacy I/O. There should be no legacy I/O on an of_platform device, but only on behind a PCI or ISA bus, right? For PCI, the probing happens using the pci ipmi driver, so that's not our problem here, and I hope we don't need to worry about ISA buses any more. > Furthermore, we have to include the register information that it will > work not only for KCS interfaces. It should be possible to include BT > and SMIC interfaces, too. yes > We have two options how we wanna present IPMI in the OFDT. > > (1) > > name = ipmi > device_type = ipmi > compatible = ipmi-kcs, ipmi-1.5, ... > > regs = (for KCS interfaces) > or > regs = (for BT and SMIC > interfaces) > > (2) > name = ipmi > device_type > regs = > reg-spacing = > reg-size = > reg-shift = > > The main difference between (1) and (2) is that (2) will represent > the whole register region within the reg property. Because of that > you have to include additional properties. > > In (1) you will include every register (e.g. Cmd / Status, Data_In / > Data_Out, etc.) within the reg property. The values for reg-spacing > are calculated by subtracting addr2 - addr1. The reg-size are the > len's within the reg property. > > Personally I prefer (1), because I a the moment I don't see a big > benefit in (2). For both options of have to implement source code > which checks the compatible node to get the used interface type. > According to the emitted interface type you have to read in (1) two > or three registers from the reg property. > > In (2) you have to calculate two or three addresses (with the help of > reg and the additional reg-spacing, etc. properties). I'd like to see (2), because that's what the driver currently expects. The common ipmi code in linux _always_ does this calculation anyway, and (1) only means we have to compute the reg-spacing and reg-size from the layout of the registers, which gets rather complicated if you have more than two of them in the reg property. Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] ipmi: add autosensing of ipmi device on powerpc using device-tree
On Saturday 09 December 2006 10:46, Segher Boessenkool wrote: > How do you know? Some later compatible implementation might add > some regs. Also, there are implementations that simply ignore > the lower address bits, so size=1 in the "reg" property is wrong > for those. > > > but depending on the HW implementation, they may be > > between 1 and 4 bytes wide, and can have a different spacing. > > Always one byte wide. AFAICS, some implementations require word access on the registers, even if only part of it is used. That's why the driver has the concept of reg-size and reg-shift. Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] ipmi: add autosensing of ipmi device on powerpc using device-tree
On Saturday 09 December 2006 01:07, Corey Minyard wrote: > > I think the current representation is perfect. AFAICS, there are always > > two registers, but depending on the HW implementation, they may be > > between 1 and 4 bytes wide, and can have a different spacing. > > > The BT and SMIC interfaces have three registers. Does that break things? > It should still work, but I have to admit that at this point it gets ugly. How about defining the properties just like the driver expects them: reg : the area spanning all registers (2 or three) reg-spacing : offset of the start of each register (default 1) reg-size : length of each register (1, 2, or 4, default 1) reg-shift : bit-position of the data inside the register (default 0). Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] ipmi: add autosensing of ipmi device on powerpc using device-tree
On Friday 08 December 2006 23:50, Benjamin Herrenschmidt wrote: > > > > > + info->io.regsize= resource0.end - resource0.start + 1; > > + info->io.regspacing = resource1.start - resource0.start; > > > > Are you sure this is a reliable way to check the register spacing and > > register size? Register size means "how big is a register (8, 16, 32 > > bits)". Register spacing means (how many bytes are there between > > registers. If you had two registers that were 8 bits and 4 bytes > > apart, for instance, I don't believe the above calculations would work. > > How many registers do we expect here ? Might be better to have one > resource represent the whole MMIO area, and have a separate property > that indicates the stride between 2 registers. I think the current representation is perfect. AFAICS, there are always two registers, but depending on the HW implementation, they may be between 1 and 4 bytes wide, and can have a different spacing. By having two separate areas in the reg property, the driver can easily determine both the size and the spacing. It will then do a single ioremap that spans both anyway. Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 1/1] ipmi: add autosensing of ipmi device on powerpc using device-tree
On Friday 08 December 2006 19:59, Corey Minyard wrote:
>
> + if (match->data) {
> + dev_warn(&dev->dev, "unknown interface type\n");
> + return -ENODEV;
> + }
> +
>
> What's this mean? I don't understand the error.
The check is bogus and should be removed. The effect is that
only SI_KCS can work, all others will be rejected.
> + info->io.regsize= resource0.end - resource0.start + 1;
> + info->io.regspacing = resource1.start - resource0.start;
>
> Are you sure this is a reliable way to check the register spacing and
> register size? Register size means "how big is a register (8, 16, 32
> bits)". Register spacing means (how many bytes are there between
> registers. If you had two registers that were 8 bits and 4 bytes
> apart, for instance, I don't believe the above calculations would work.
Looks right to me. Assume these of properties
#address-cells: <1>
#size-cells: <1>
reg: <0x100> <1> <0x104> <1> /* start, length, start, length */
converting them to resources gives you
resource0 = { .start = 0x100, .end = 0x100, }
resource1 = { .start = 0x104, .end = 0x104, }
consequently, you end up with
info->io = {
.regsize = 1,
.regspacing = 4,
.addr_data = 0x100,
};
which is exactly what you want.
> +static int ipmi_of_remove(struct of_device *dev)
> +{
> + return 0;
> +}
>
> With the newest IPMI patches (only in git right now), hot removal of
> interfaces is supported. Is that what this is for? If so, you can
> call cleanup_one_si() on the interface.
ok, great.
> Here's a new patch. Can you test that unloading the module works
> correctly?
Christian has already gone home for the weekend, and I don't have
access to his machine, so testing will probably have to wait until
Monday.
> +static void __devinit of_find_bmc(void)
> +{
> + of_register_platform_driver(&ipmi_of_platform_driver);
> +}
> +#endif /* CONFIG_PPC_OF */
I guess this function could also be removed entirely, it doesn't
add anything useful.
Arnd <><
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [patch 0/1] ipmi: add autosensing of ipmi device on powerpc using device-tree
On Friday 08 December 2006 01:41, Paul Mackerras wrote: > Christian Krafft writes: > > > the patch I'll send, adds of_device support to the ipmi_si module. > > Having the correct device-tree entries, the ipmi module can be loaded > > without > > specifying the resources as module parameters. > > Which powerpc-based machines have IPMI? This particular one is for an upcoming product, benh knows which one this is for. The JS21 blade already has an IPMI controller, though that is hidden behind the hypervisor, see http://www-03.ibm.com/systems/bladecenter/js21/specs.html. Arnd <>< - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
