[Openipmi-developer] [PATCH 33/34] drivers: remove incorrect of_match_ptr/ACPI_PTR annotations

[Arnd Bergmann]

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 = _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..e6189106c468 100644
--- a/drivers/fpga/versal-fpga.c
+++ b/drivers/fpga/versal-fpga.c
@@ -69,7 +69,7 @@ static struct platform_driver versal_fpga_driver = {

[Openipmi-developer] [PATCH 00/34] address all -Wunused-const warnings

[Arnd Bergmann]

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 +-
 drivers/net/wireless/intel/iwlegacy/4965-rs.c | 15 +---

Re: [Openipmi-developer] [PATCH 2/9] dma: Convert from tasklet to BH workqueue

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

'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();
-   pr_debug("**%s: %ld.%9.9ld\n", msg, (long) t.tv_sec, t.tv_nsec);
+   ktime_get_ts64();
+   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();
-   if (unlikely(timespec_compare(, 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(_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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

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(_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([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, );
 
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

[Arnd Bergmann]

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

[Arnd Bergmann]

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(_operation);
+   atomic_set(_operation, 1);
del_timer_sync(_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()

[Arnd Bergmann]

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();
+   ktime_get_ts64();
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();
+   ktime_get_ts64();
if (unlikely(timespec64_compare(, 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()

[Arnd Bergmann]

On Tue, Mar 6, 2018 at 11:40 AM, Dan Carpenter <dan.carpen...@oracle.com> 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 <dan.carpen...@oracle.com>
> ---
> v2: Don't initialize "rv" and fix a typo in the commit message

This addresses my comment, so

Acked-by: Arnd Bergmann <a...@arndb.de>

--
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()

[Arnd Bergmann]

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 = _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'

[Arnd Bergmann]

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'

[Arnd Bergmann]

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 <a...@arndb.de> 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 <c...@kaod.org>
> >>
> >> 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'

[Arnd Bergmann]

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

[Arnd Bergmann]

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

[Arnd Bergmann]

On Friday, September 16, 2016 12:39:25 PM CEST Cédric Le Goater wrote:
> From: Alistair Popple <alist...@popple.id.au>
> 
> 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 <alist...@popple.id.au>
> Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
> Signed-off-by: Joel Stanley <j...@jms.id.au>
> 

Acked-by: Arnd Bergmann <a...@arndb.de>

--
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH] ipmi: avoid gcc warning

[Arnd Bergmann]

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 a...@arndb.de
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

[Openipmi-developer] [PATCH] ipmi: work around gcc-4.9 build warning

[Arnd Bergmann]

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 a...@arndb.de

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)]

[Arnd Bergmann]

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:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; 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

[Arnd Bergmann]

On Wednesday 07 September 2011, Yong Zhang wrote:
 This flag is a NOOP and can be removed now.
 
 Signed-off-by: Yong Zhang yong.zha...@gmail.com

Acked-by: Arnd Bergmann a...@arndb.de

--
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 11/12] ipmi: autoconvert trivial BKL users to private mutex

[Arnd Bergmann]

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.*linux\/smp_lock.h/d' ${file}
else
sed -i 's/include.*linux\/smp_lock.h.*$/include 
linux\/mutex.h/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.*\smp_lock.h\/d' ${file}  \
-e '/cycle_kernel_lock()/d'
fi

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Corey Minyard miny...@acm.org
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 linux/init.h
 #include linux/device.h
 #include linux/compat.h
-#include linux/smp_lock.h
 
 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 linux/moduleparam.h
 #include linux/ipmi.h
 #include linux/ipmi_smi.h
-#include linux/smp_lock.h
+#include linux/mutex.h
 #include linux/watchdog.h
 #include linux/miscdevice.h
 #include linux/init.h
@@ -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

[Openipmi-developer] [PATCH 00/12] autoconvert trivial BKL users to private mutex

[Arnd Bergmann]

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

Re: [Openipmi-developer] [patch 1/1] updated version, fixed the compiler warning

[Arnd Bergmann]

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.phpp=sourceforgeCID=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

[Arnd Bergmann]

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.phpp=sourceforgeCID=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

[Arnd Bergmann]

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.phpp=sourceforgeCID=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

[Arnd Bergmann]

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.phpp=sourceforgeCID=DEVDEV
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer