Re: [PATCH v1 6/7] mfd: lpc_ich: Add support for pinctrl in non-ACPI system

[Henning Schild]

Am Mon, 12 Apr 2021 20:34:45 +0300
schrieb Andy Shevchenko :

> On Mon, Apr 12, 2021 at 07:16:53PM +0200, Henning Schild wrote:
> > Am Mon, 12 Apr 2021 19:59:05 +0300
> > schrieb Andy Shevchenko :  
> > > On Mon, Apr 12, 2021 at 06:40:01PM +0200, Henning Schild wrote:  
> > > > Tan or Andy,
> > > > 
> > > > maybe you can point me to a user of that patch. I guess there
> > > > might be an out-of-tree driver or userland code on how to use
> > > > the GPIOs from there.
> > > 
> > > I'm confused. User of this patch is pinctrl-broxton driver.
> > > It's in upstream.  
> > 
> > Should this appear in /sys/class/gpio as chip so that pins can be
> > exported?  
> 
> No. Sysfs interface is deprecated. It should appear as /dev/gpiochip0
> or so.

Ok, just found that there is a null pointer deref in the probe function
of the pinctrl driver, looking into that.

Meanwhile i think i will need a similar patch for
pinctrl-sunrisepoint.c for that wdt, do you happen to have that as
well? Or a spec where to find all the magic numbers.

regards,
Henning

> 
> > That is what i tried and failed with.
> >   
> > > Using GPIOs from it is something as done in a few drivers already
> > > (Assuming we have no resources described in the ACPI). I.e. you
> > > need to register in board file the GPIO mapping table with help of
> > > devm_acpi_dev_add_driver_gpios() and use one of gpiod_get()
> > > family of functions to request it.
> > > 
> > > In case of LEDs you simple describe GPIO device name in lookup
> > > table and that's it. The drivers/platform/x86/pcengines-apuv2.c
> > > not the best but will give you an idea how to use "leds-gpio"
> > > driver in board files.  
> > 
> > I am aware of that driver and had a look at it. In order to figure
> > out the arguments for the macros/functions i was hoping for
> > userland gpio "export", but maybe that does not work here ...
> > For now i will assume that it does not show up in sysfs and can
> > maybe still be used, and try to build on top.  
> 
> Just switch to use libgpiod and associated tools / bindings in user
> space. Sysfs ABI is not being developed anymore.
> 

Re: [PATCH v1 6/7] mfd: lpc_ich: Add support for pinctrl in non-ACPI system

[Henning Schild]

Am Mon, 12 Apr 2021 19:51:42 +0300
schrieb Andy Shevchenko :

> On Mon, Apr 12, 2021 at 06:01:06PM +0200, Henning Schild wrote:
> > Am Mon, 8 Mar 2021 14:20:19 +0200
> > schrieb Andy Shevchenko :
> >   
> > > From: Tan Jui Nee 
> > > 
> > > Add support for non-ACPI systems, such as system that uses
> > > Advanced Boot Loader (ABL) whereby a platform device has to be
> > > created in order to bind with pin control and GPIO.
> > > 
> > > At the moment, Intel Apollo Lake In-Vehicle Infotainment (IVI)
> > > system requires a driver to hide and unhide P2SB to lookup P2SB
> > > BAR and pass the PCI BAR address to GPIO.  
> 
> ...
> 
> > > +/* Offset data for Apollo Lake GPIO controllers */
> > > +#define APL_GPIO_SOUTHWEST_OFFSET0xc0
> > > +#define APL_GPIO_SOUTHWEST_SIZE  0x654
> > > +#define APL_GPIO_NORTHWEST_OFFSET0xc4
> > > +#define APL_GPIO_NORTHWEST_SIZE  0x764
> > > +#define APL_GPIO_NORTH_OFFSET0xc5
> > > +#define APL_GPIO_NORTH_SIZE  0x76c  
> > 
> > drivers/pinctrl/intel/pinctrl-broxton.c:653
> > BXT_COMMUNITY(0, 77),
> >   
> > > +#define APL_GPIO_WEST_OFFSET 0xc7
> > > +#define APL_GPIO_WEST_SIZE   0x674  
> > 
> > All these sizes correlate with 4 magic numbers from pinctrl-broxton.
> > 
> > SIZE - 0x500 (pad_base?) - 4 (no clue) / 8
> > 
> > It might be worth basing both numbers on a define and giving the
> > magic numbers some names.  
> 
> I didn't get this, sorry. The numbers above just precise sizes of the
> resources. Actually they all one page anyway, so, I can drop magic of
> SIZEs and leave only offsets.

That precise size is also in the broxton driver, i think. Say we did
have

#define BXT_NORTH_COUNT 77
#define PAD_BASE 0x500

in some central place

then we could use

size = 0x500 + 8 * BXT_NORTH_COUNT + 4 (no clue what that is)

the same pattern would work for all those sizes and their
BXT_COMMUNITY(0, XX) counterparts

So the real size seems to be a function of the magic numbers in
BXT_COMMUNITY(0, XX)

Or simply take one page as you say.

> > But all this seems like duplication of pinctrl-broxton, maybe the
> > pinctrl driver should unhide the p2sb ...  
> 
> Definitely should not. It's not a business of the pin control driver
> to know how it has to be instantiated (or from what data). These
> offsets belong to the platform description and since firmware hides
> the device without given an appropriate ACPI device node, we have
> only one choice (assuming firmware is carved in stone) -- board files.
> 
> P2SB on the other hand is a slice of many (independent) devices.
> There is no "proper" place to unhide it except some core part of x86
> / PCI.

Got it, still the fact that there are 4 regions/communities is also part
of the broxton driver so there is duplication.

regards,
Henning

Re: [PATCH v1 6/7] mfd: lpc_ich: Add support for pinctrl in non-ACPI system

[Henning Schild]

Am Mon, 12 Apr 2021 19:59:05 +0300
schrieb Andy Shevchenko :

> On Mon, Apr 12, 2021 at 06:40:01PM +0200, Henning Schild wrote:
> > Tan or Andy,
> > 
> > maybe you can point me to a user of that patch. I guess there might
> > be an out-of-tree driver or userland code on how to use the GPIOs
> > from there.  
> 
> I'm confused. User of this patch is pinctrl-broxton driver.
> It's in upstream.

Should this appear in /sys/class/gpio as chip so that pins can be
exported?

That is what i tried and failed with.

> Using GPIOs from it is something as done in a few drivers already
> (Assuming we have no resources described in the ACPI). I.e. you need
> to register in board file the GPIO mapping table with help of
> devm_acpi_dev_add_driver_gpios() and use one of gpiod_get() family of
> functions to request it.
> 
> In case of LEDs you simple describe GPIO device name in lookup table
> and that's it. The drivers/platform/x86/pcengines-apuv2.c not the
> best but will give you an idea how to use "leds-gpio" driver in board
> files.

I am aware of that driver and had a look at it. In order to figure out
the arguments for the macros/functions i was hoping for userland gpio
"export", but maybe that does not work here ...
For now i will assume that it does not show up in sysfs and can maybe
still be used, and try to build on top.

regards,
Henning

> 
> > Feel free to send directly to me in case it is not published
> > anywhere and should not yet be on the list, i could just use it for
> > inspiration. A driver will likely be GPL anyways.  
> 

Re: [PATCH v1 6/7] mfd: lpc_ich: Add support for pinctrl in non-ACPI system

[Henning Schild]

Tan or Andy,

maybe you can point me to a user of that patch. I guess there might be
an out-of-tree driver or userland code on how to use the GPIOs from
there.

Feel free to send directly to me in case it is not published anywhere
and should not yet be on the list, i could just use it for inspiration.
A driver will likely be GPL anyways.

regards,
Henning

Am Mon, 12 Apr 2021 18:01:06 +0200
schrieb Henning Schild :

> Am Mon, 8 Mar 2021 14:20:19 +0200
> schrieb Andy Shevchenko :
> 
> > From: Tan Jui Nee 
> > 
> > Add support for non-ACPI systems, such as system that uses
> > Advanced Boot Loader (ABL) whereby a platform device has to be
> > created in order to bind with pin control and GPIO.
> > 
> > At the moment, Intel Apollo Lake In-Vehicle Infotainment (IVI)
> > system requires a driver to hide and unhide P2SB to lookup P2SB BAR
> > and pass the PCI BAR address to GPIO.
> > 
> > Signed-off-by: Tan Jui Nee 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  drivers/mfd/lpc_ich.c | 100
> > +- 1 file changed, 99
> > insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> > index 8e9bd6813287..959247b6987a 100644
> > --- a/drivers/mfd/lpc_ich.c
> > +++ b/drivers/mfd/lpc_ich.c
> > @@ -8,7 +8,8 @@
> >   *  Configuration Registers.
> >   *
> >   *  This driver is derived from lpc_sch.
> > -
> > + *
> > + *  Copyright (C) 2017, 2021 Intel Corporation
> >   *  Copyright (c) 2011 Extreme Engineering Solution, Inc.
> >   *  Author: Aaron Sierra 
> >   *
> > @@ -43,6 +44,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -140,6 +142,73 @@ static struct mfd_cell lpc_ich_gpio_cell = {
> > .ignore_resource_conflicts = true,
> >  };
> >  
> > +/* Offset data for Apollo Lake GPIO controllers */
> > +#define APL_GPIO_SOUTHWEST_OFFSET  0xc0
> > +#define APL_GPIO_SOUTHWEST_SIZE0x654
> > +#define APL_GPIO_NORTHWEST_OFFSET  0xc4
> > +#define APL_GPIO_NORTHWEST_SIZE0x764
> > +#define APL_GPIO_NORTH_OFFSET  0xc5
> > +#define APL_GPIO_NORTH_SIZE0x76c  
> 
> drivers/pinctrl/intel/pinctrl-broxton.c:653
> BXT_COMMUNITY(0, 77),
> 
> > +#define APL_GPIO_WEST_OFFSET   0xc7
> > +#define APL_GPIO_WEST_SIZE 0x674  
> 
> All these sizes correlate with 4 magic numbers from pinctrl-broxton.
> 
> SIZE - 0x500 (pad_base?) - 4 (no clue) / 8
> 
> It might be worth basing both numbers on a define and giving the magic
> numbers some names.
> 
> But all this seems like duplication of pinctrl-broxton, maybe the
> pinctrl driver should unhide the p2sb ...
> 
> regards,
> Henning
> 
> > +
> > +#define APL_GPIO_NR_DEVICES4
> > +#define APL_GPIO_IRQ   14
> > +
> > +static struct resource apl_gpio_resources[APL_GPIO_NR_DEVICES][2]
> > = {
> > +   {
> > +   DEFINE_RES_MEM(APL_GPIO_NORTH_OFFSET,
> > APL_GPIO_NORTH_SIZE),
> > +   DEFINE_RES_IRQ(APL_GPIO_IRQ),
> > +   },
> > +   {
> > +   DEFINE_RES_MEM(APL_GPIO_NORTHWEST_OFFSET,
> > APL_GPIO_NORTHWEST_SIZE),
> > +   DEFINE_RES_IRQ(APL_GPIO_IRQ),
> > +   },
> > +   {
> > +   DEFINE_RES_MEM(APL_GPIO_WEST_OFFSET,
> > APL_GPIO_WEST_SIZE),
> > +   DEFINE_RES_IRQ(APL_GPIO_IRQ),
> > +   },
> > +   {
> > +   DEFINE_RES_MEM(APL_GPIO_SOUTHWEST_OFFSET,
> > APL_GPIO_SOUTHWEST_SIZE),
> > +   DEFINE_RES_IRQ(APL_GPIO_IRQ),
> > +   },
> > +};
> > +
> > +/* The order must be in sync with apl_pinctrl_soc_data */
> > +static const struct mfd_cell apl_gpio_devices[APL_GPIO_NR_DEVICES]
> > = {
> > +   {
> > +   /* North */
> > +   .name = "apollolake-pinctrl",
> > +   .id = 0,
> > +   .num_resources = ARRAY_SIZE(apl_gpio_resources[0]),
> > +   .resources = apl_gpio_resources[0],
> > +   .ignore_resource_conflicts = true,
> > +   },
> > +   {
> > +   /* NorthWest */
> > +   .name = "apollolake-pinctrl",
> > +   .id = 1,
> > +   .num_resources = ARRAY_SIZE(apl_gpio_resources[1]),
> > +   .resources = apl_gpio_resources[1],
> > +   .ignore_resource_conflicts = true,
> > +   },
> > +   {
> > +   /* West */
> 

Re: [PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

Am Mon, 12 Apr 2021 09:06:10 -0700
schrieb Guenter Roeck :

> On 4/12/21 8:35 AM, Henning Schild wrote:
> > Am Thu, 1 Apr 2021 18:15:41 +0200
> > schrieb "Enrico Weigelt, metux IT consult" :
> >   
> >> On 29.03.21 19:49, Henning Schild wrote:
> >>
> >> Hi,
> >>  
> >>> This driver adds initial support for several devices from Siemens.
> >>> It is based on a platform driver introduced in an earlier commit.
> >>>
> >>
> >> Where does the wdt actually come from ?
> >>
> >> Is it in the SoC ? (which SoC exactly). SoC-builtin wdt is a
> >> pretty usual case.
> >>
> >> Or some external chip ?
> >>
> >> The code smells a bit like two entirely different wdt's that just
> >> have some similarities. If that's the case, I'd rather split it
> >> into two separate drivers and let the parent driver (board file)
> >> instantiate the correct one.  
> > 
> > In fact they are the same watchdog device. The only difference is
> > the "secondary enable" which controls whether the watchdog causes a
> > reboot or just raises an alarm. The alarm feature is not even
> > implemented in the given driver, we just enable that secondary
> > enable regardless. 
> 
> Confusing statement; I can't parse "we just enable that secondary
> enable regardless". What secondary enable do you enable ?
>
> The code says "set safe_en_n so we are not just WDIOF_ALARMONLY",
> which suggests that it disables the alarm feature, and does make
> sense.

Yes go with the second statement. But the alarm is the default after
boot, and turning it off needs to be done with p2sb gpio on the 427.
 
> > In one range of devices (227E) that second enable is part of a
> > pio-based control register. On the other range (427E) it
> > unfortunately is a P2SB gpio, which gets us right into the
> > discussion we have around the LEDs.
> > With that i have my doubts that two drivers would be the way to go,
> > most likely not. 
> >   
> 
> Reading the code again, I agree. Still, you'll need to sort out how
> to determine if the watchdog or the LED driver should be enabled,
> and how to access the gpio port. The GPIO pin detection and use
> for 427E is a bit awkward.

Yes it is awkward, and that is exactly the discussion happening for the
LEDs. Using generic GPIO code, the mail was more to Andy as i am hoping
he might help me connect the dots here. On the other hand i wanted wdt
discussions in the wdt thread, and not talk about that one gpio-pin in
the LED thread.

regards,
Henning

> Thanks,
> Guenter
> 
> > Only that i have no clue which pinctrl driver should be used here.
> > My guess is "sunrisepoint" because the CPUs are "SkyLake" i.e.
> > i5-6442EQ, i3-6102E
> > And "grep INT344B /sys/firmware/acpi/tables/DSDT" matches. I booted
> > a kernel patched with the series from Andy but the
> > "pinctrl-sunrisepoint" does not seem to even claim the memory.
> > Still trying to understand how to make use of these pinctrl drivers
> > they are in place but i lack example users (drivers). If they
> > should be available in sysfs, i might be looking at the wrong place
> > ... /sys/class/gpio/ does not list anything
> > 
> > regards,
> > Henning
> > 
> > 
> >   
> >>
> >> --mtx
> >>  
> >   
> 

Re: [PATCH v1 6/7] mfd: lpc_ich: Add support for pinctrl in non-ACPI system

[Henning Schild]

Am Mon, 8 Mar 2021 14:20:19 +0200
schrieb Andy Shevchenko :

> From: Tan Jui Nee 
> 
> Add support for non-ACPI systems, such as system that uses
> Advanced Boot Loader (ABL) whereby a platform device has to be created
> in order to bind with pin control and GPIO.
> 
> At the moment, Intel Apollo Lake In-Vehicle Infotainment (IVI) system
> requires a driver to hide and unhide P2SB to lookup P2SB BAR and pass
> the PCI BAR address to GPIO.
> 
> Signed-off-by: Tan Jui Nee 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/lpc_ich.c | 100
> +- 1 file changed, 99
> insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> index 8e9bd6813287..959247b6987a 100644
> --- a/drivers/mfd/lpc_ich.c
> +++ b/drivers/mfd/lpc_ich.c
> @@ -8,7 +8,8 @@
>   *  Configuration Registers.
>   *
>   *  This driver is derived from lpc_sch.
> -
> + *
> + *  Copyright (C) 2017, 2021 Intel Corporation
>   *  Copyright (c) 2011 Extreme Engineering Solution, Inc.
>   *  Author: Aaron Sierra 
>   *
> @@ -43,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -140,6 +142,73 @@ static struct mfd_cell lpc_ich_gpio_cell = {
>   .ignore_resource_conflicts = true,
>  };
>  
> +/* Offset data for Apollo Lake GPIO controllers */
> +#define APL_GPIO_SOUTHWEST_OFFSET0xc0
> +#define APL_GPIO_SOUTHWEST_SIZE  0x654
> +#define APL_GPIO_NORTHWEST_OFFSET0xc4
> +#define APL_GPIO_NORTHWEST_SIZE  0x764
> +#define APL_GPIO_NORTH_OFFSET0xc5
> +#define APL_GPIO_NORTH_SIZE  0x76c

drivers/pinctrl/intel/pinctrl-broxton.c:653
BXT_COMMUNITY(0, 77),

> +#define APL_GPIO_WEST_OFFSET 0xc7
> +#define APL_GPIO_WEST_SIZE   0x674

All these sizes correlate with 4 magic numbers from pinctrl-broxton.

SIZE - 0x500 (pad_base?) - 4 (no clue) / 8

It might be worth basing both numbers on a define and giving the magic
numbers some names.

But all this seems like duplication of pinctrl-broxton, maybe the
pinctrl driver should unhide the p2sb ...

regards,
Henning

> +
> +#define APL_GPIO_NR_DEVICES  4
> +#define APL_GPIO_IRQ 14
> +
> +static struct resource apl_gpio_resources[APL_GPIO_NR_DEVICES][2] = {
> + {
> + DEFINE_RES_MEM(APL_GPIO_NORTH_OFFSET,
> APL_GPIO_NORTH_SIZE),
> + DEFINE_RES_IRQ(APL_GPIO_IRQ),
> + },
> + {
> + DEFINE_RES_MEM(APL_GPIO_NORTHWEST_OFFSET,
> APL_GPIO_NORTHWEST_SIZE),
> + DEFINE_RES_IRQ(APL_GPIO_IRQ),
> + },
> + {
> + DEFINE_RES_MEM(APL_GPIO_WEST_OFFSET,
> APL_GPIO_WEST_SIZE),
> + DEFINE_RES_IRQ(APL_GPIO_IRQ),
> + },
> + {
> + DEFINE_RES_MEM(APL_GPIO_SOUTHWEST_OFFSET,
> APL_GPIO_SOUTHWEST_SIZE),
> + DEFINE_RES_IRQ(APL_GPIO_IRQ),
> + },
> +};
> +
> +/* The order must be in sync with apl_pinctrl_soc_data */
> +static const struct mfd_cell apl_gpio_devices[APL_GPIO_NR_DEVICES] =
> {
> + {
> + /* North */
> + .name = "apollolake-pinctrl",
> + .id = 0,
> + .num_resources = ARRAY_SIZE(apl_gpio_resources[0]),
> + .resources = apl_gpio_resources[0],
> + .ignore_resource_conflicts = true,
> + },
> + {
> + /* NorthWest */
> + .name = "apollolake-pinctrl",
> + .id = 1,
> + .num_resources = ARRAY_SIZE(apl_gpio_resources[1]),
> + .resources = apl_gpio_resources[1],
> + .ignore_resource_conflicts = true,
> + },
> + {
> + /* West */
> + .name = "apollolake-pinctrl",
> + .id = 2,
> + .num_resources = ARRAY_SIZE(apl_gpio_resources[2]),
> + .resources = apl_gpio_resources[2],
> + .ignore_resource_conflicts = true,
> + },
> + {
> + /* SouthWest */
> + .name = "apollolake-pinctrl",
> + .id = 3,
> + .num_resources = ARRAY_SIZE(apl_gpio_resources[3]),
> + .resources = apl_gpio_resources[3],
> + .ignore_resource_conflicts = true,
> + },
> +};
>  
>  static struct mfd_cell lpc_ich_spi_cell = {
>   .name = "intel-spi",
> @@ -1082,6 +1151,29 @@ static int lpc_ich_init_wdt(struct pci_dev
> *dev) return ret;
>  }
>  
> +static int lpc_ich_init_pinctrl(struct pci_dev *dev)
> +{
> + struct resource base;
> + unsigned int i;
> + int ret;
> +
> + ret = pci_p2sb_bar(dev, PCI_DEVFN(13, 0), );
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < ARRAY_SIZE(apl_gpio_devices); i++) {
> + struct resource *mem = _gpio_resources[i][0];
> +
> + /* Fill MEM resource */
> + mem->start += base.start;
> + mem->end += base.start;
> + mem->flags = base.flags;
> + }
> +
> + return mfd_add_devices(>dev, 0, 

Re: [PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

Am Thu, 1 Apr 2021 18:15:41 +0200
schrieb "Enrico Weigelt, metux IT consult" :

> On 29.03.21 19:49, Henning Schild wrote:
> 
> Hi,
> 
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.  
> 
> Where does the wdt actually come from ?
> 
> Is it in the SoC ? (which SoC exactly). SoC-builtin wdt is a pretty 
> usual case.
> 
> Or some external chip ?
> 
> The code smells a bit like two entirely different wdt's that just have
> some similarities. If that's the case, I'd rather split it into two
> separate drivers and let the parent driver (board file) instantiate
> the correct one.

In fact they are the same watchdog device. The only difference is the
"secondary enable" which controls whether the watchdog causes a reboot
or just raises an alarm. The alarm feature is not even implemented in
the given driver, we just enable that secondary enable regardless.

In one range of devices (227E) that second enable is part of a
pio-based control register. On the other range (427E) it unfortunately
is a P2SB gpio, which gets us right into the discussion we have around
the LEDs.
With that i have my doubts that two drivers would be the way to go,
most likely not. 

Only that i have no clue which pinctrl driver should be used here. My
guess is "sunrisepoint" because the CPUs are "SkyLake" i.e. i5-6442EQ,
i3-6102E
And "grep INT344B /sys/firmware/acpi/tables/DSDT" matches. I booted a
kernel patched with the series from Andy but the "pinctrl-sunrisepoint"
does not seem to even claim the memory. Still trying to understand how
to make use of these pinctrl drivers they are in place but i lack
example users (drivers). If they should be available in sysfs, i might
be looking at the wrong place ... /sys/class/gpio/ does not list
anything

regards,
Henning



> 
> --mtx
> 

Re: [PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Thu, 1 Apr 2021 14:04:51 +0300
schrieb Andy Shevchenko :

> On Thu, Apr 1, 2021 at 1:44 PM Henning Schild
>  wrote:
> >
> > Am Wed, 31 Mar 2021 18:40:23 +0300
> > schrieb Andy Shevchenko :
> >  
> > > On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
> > >  wrote:  
> > > > Am Tue, 30 Mar 2021 15:41:53 +0300
> > > > schrieb Andy Shevchenko :  
> > > > > On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
> > > > >  wrote:  
> > > > > > Am Tue, 30 Mar 2021 15:15:16 +0300
> > > > > > schrieb Andy Shevchenko :  
> > > > > > > On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> > > > > > >  wrote:  
> > > > > > > > Am Tue, 30 Mar 2021 14:04:35 +0300
> > > > > > > > schrieb Andy Shevchenko :  
> > > > > > > > > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > > > > > > > >  wrote:  
> > > > >  
> > > > > > > > > > +static struct simatic_ipc_led
> > > > > > > > > > simatic_ipc_leds_mem[] = {
> > > > > > > > > > +   {0x500 + 0x1A0, "red:" LED_FUNCTION_STATUS
> > > > > > > > > > "-1"},
> > > > > > > > > > +   {0x500 + 0x1A8, "green:" LED_FUNCTION_STATUS
> > > > > > > > > > "-1"},
> > > > > > > > > > +   {0x500 + 0x1C8, "red:" LED_FUNCTION_STATUS
> > > > > > > > > > "-2"},
> > > > > > > > > > +   {0x500 + 0x1D0, "green:" LED_FUNCTION_STATUS
> > > > > > > > > > "-2"},
> > > > > > > > > > +   {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS
> > > > > > > > > > "-3"},
> > > > > > > > > > +   {0x500 + 0x198, "green:" LED_FUNCTION_STATUS
> > > > > > > > > > "-3"},
> > > > > > > > > > +   { }
> > > > > > > > > > +};  
> > > > > > > > >
> > > > > > > > > It seems to me like poking GPIO controller registers
> > > > > > > > > directly. This is not good. The question still
> > > > > > > > > remains: Can we simply register a GPIO (pin control)
> > > > > > > > > driver and use an LED GPIO driver with an additional
> > > > > > > > > board file that instantiates it?  
> > > > > > > >
> > > > > > > > I wrote about that in reply to the cover letter. My
> > > > > > > > view is still that it would be an abstraction with only
> > > > > > > > one user, just causing work and likely not ending up as
> > > > > > > > generic as it might eventually have to be.
> > > > > > > >
> > > > > > > > The region is reserved, not sure what the problem with
> > > > > > > > the "poking" is.  
> > > > > > >
> > > > > > >  
> > > > > > > > Maybe i do not understand all the benefits of such a
> > > > > > > > split at this point in time. At the moment i only see
> > > > > > > > work with hardly any benefit, not just work for me but
> > > > > > > > also for maintainers. I sure do not mean to be
> > > > > > > > ignorant. Maybe you go into details and convince me or
> > > > > > > > we wait for other peoples opinions on how to proceed,
> > > > > > > > maybe there is a second user that i am not aware of?
> > > > > > > > Until i am convinced otherwise i will try to argue that
> > > > > > > > a single-user-abstraction is needless work/code, and
> > > > > > > > should be done only when actually needed.  
> > > > > > >
> > > > > > > I have just read your messages (there is a cover letter
> > > > > > > and additional email which was sent lately).
> > > > > > >
> > > > > > > I would like to know what the CPU model number on that
> > > > > > > board is. Than we can continue to see what possibilities
> 

Re: [PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Thu, 1 Apr 2021 14:04:51 +0300
schrieb Andy Shevchenko :

> On Thu, Apr 1, 2021 at 1:44 PM Henning Schild
>  wrote:
> >
> > Am Wed, 31 Mar 2021 18:40:23 +0300
> > schrieb Andy Shevchenko :
> >  
> > > On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
> > >  wrote:  
> > > > Am Tue, 30 Mar 2021 15:41:53 +0300
> > > > schrieb Andy Shevchenko :  
> > > > > On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
> > > > >  wrote:  
> > > > > > Am Tue, 30 Mar 2021 15:15:16 +0300
> > > > > > schrieb Andy Shevchenko :  
> > > > > > > On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> > > > > > >  wrote:  
> > > > > > > > Am Tue, 30 Mar 2021 14:04:35 +0300
> > > > > > > > schrieb Andy Shevchenko :  
> > > > > > > > > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > > > > > > > >  wrote:  
> > > > >  
> > > > > > > > > > +static struct simatic_ipc_led
> > > > > > > > > > simatic_ipc_leds_mem[] = {
> > > > > > > > > > +   {0x500 + 0x1A0, "red:" LED_FUNCTION_STATUS
> > > > > > > > > > "-1"},
> > > > > > > > > > +   {0x500 + 0x1A8, "green:" LED_FUNCTION_STATUS
> > > > > > > > > > "-1"},
> > > > > > > > > > +   {0x500 + 0x1C8, "red:" LED_FUNCTION_STATUS
> > > > > > > > > > "-2"},
> > > > > > > > > > +   {0x500 + 0x1D0, "green:" LED_FUNCTION_STATUS
> > > > > > > > > > "-2"},
> > > > > > > > > > +   {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS
> > > > > > > > > > "-3"},
> > > > > > > > > > +   {0x500 + 0x198, "green:" LED_FUNCTION_STATUS
> > > > > > > > > > "-3"},
> > > > > > > > > > +   { }
> > > > > > > > > > +};  
> > > > > > > > >
> > > > > > > > > It seems to me like poking GPIO controller registers
> > > > > > > > > directly. This is not good. The question still
> > > > > > > > > remains: Can we simply register a GPIO (pin control)
> > > > > > > > > driver and use an LED GPIO driver with an additional
> > > > > > > > > board file that instantiates it?  
> > > > > > > >
> > > > > > > > I wrote about that in reply to the cover letter. My
> > > > > > > > view is still that it would be an abstraction with only
> > > > > > > > one user, just causing work and likely not ending up as
> > > > > > > > generic as it might eventually have to be.
> > > > > > > >
> > > > > > > > The region is reserved, not sure what the problem with
> > > > > > > > the "poking" is.  
> > > > > > >
> > > > > > >  
> > > > > > > > Maybe i do not understand all the benefits of such a
> > > > > > > > split at this point in time. At the moment i only see
> > > > > > > > work with hardly any benefit, not just work for me but
> > > > > > > > also for maintainers. I sure do not mean to be
> > > > > > > > ignorant. Maybe you go into details and convince me or
> > > > > > > > we wait for other peoples opinions on how to proceed,
> > > > > > > > maybe there is a second user that i am not aware of?
> > > > > > > > Until i am convinced otherwise i will try to argue that
> > > > > > > > a single-user-abstraction is needless work/code, and
> > > > > > > > should be done only when actually needed.  
> > > > > > >
> > > > > > > I have just read your messages (there is a cover letter
> > > > > > > and additional email which was sent lately).
> > > > > > >
> > > > > > > I would like to know what the CPU model number on that
> > > > > > > board is. Than we can continue to see what possibilities
> 

Re: [PATCH v3 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

Am Wed, 7 Apr 2021 13:36:40 +0200
schrieb Hans de Goede :

> Hi,
> 
> On 3/29/21 7:49 PM, Henning Schild wrote:
> > changes since v2:
> > 
> > - remove "simatic-ipc" prefix from LED names
> > - fix style issues found in v2, mainly LED driver
> > - fix OEM specific dmi code, and remove magic numbers
> > - more "simatic_ipc" name prefixing
> > - improved pmc quirk code using callbacks
> > 
> > changes since v1:
> > 
> > - fixed lots of style issues found in v1
> >   - (debug) printing
> >   - header ordering
> > - fixed license issues GPLv2 and SPDX in all files
> > - module_platform_driver instead of __init __exit
> > - wdt simplifications cleanup
> > - lots of fixes in wdt driver, all that was found in v1
> > - fixed dmi length in dmi helper
> > - changed LED names to allowed ones
> > - move led driver to simple/
> > - switched pmc_atom to dmi callback with global variable
> > 
> > --
> > 
> > This series adds support for watchdogs and leds of several x86
> > devices from Siemens.
> > 
> > It is structured with a platform driver that mainly does
> > identification of the machines. It might trigger loading of the
> > actual device drivers by attaching devices to the platform bus.
> > 
> > The identification is vendor specific, parsing a special binary DMI
> > entry. The implementation of that platform identification is
> > applied on pmc_atom clock quirks in the final patch.
> > 
> > It is all structured in a way that we can easily add more devices
> > and more platform drivers later. Internally we have some more code
> > for hardware monitoring, more leds, watchdogs etc. This will follow
> > some day.  
> 
> IT seems there still is significant discussion surrounding the LED
> and watchdog drivers which use patch 1/4 as parent-driver.
> 
> I'm going to hold of on merging 1/4 and 4/4 until there is more
> consensus surrounding this series.

Yes. Whithout 2 and 3, 1 would be way too big.

Henning

> Regards,
> 
> Hans
> 
> 
> > 
> > Henning Schild (4):
> >   platform/x86: simatic-ipc: add main driver for Siemens devices
> >   leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
> >   watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial
> > PCs platform/x86: pmc_atom: improve critclk_systems matching for
> > Siemens PCs
> > 
> >  drivers/leds/Kconfig  |   3 +
> >  drivers/leds/Makefile |   3 +
> >  drivers/leds/simple/Kconfig   |  11 +
> >  drivers/leds/simple/Makefile  |   2 +
> >  drivers/leds/simple/simatic-ipc-leds.c| 202
> >  drivers/platform/x86/Kconfig  |
> > 12 + drivers/platform/x86/Makefile |   3 +
> >  drivers/platform/x86/pmc_atom.c   |  57 +++--
> >  drivers/platform/x86/simatic-ipc.c| 169 ++
> >  drivers/watchdog/Kconfig  |  11 +
> >  drivers/watchdog/Makefile |   1 +
> >  drivers/watchdog/simatic-ipc-wdt.c| 215
> > ++ .../platform_data/x86/simatic-ipc-base.h  |
> > 29 +++ include/linux/platform_data/x86/simatic-ipc.h |  72 ++
> >  14 files changed, 769 insertions(+), 21 deletions(-)
> >  create mode 100644 drivers/leds/simple/Kconfig
> >  create mode 100644 drivers/leds/simple/Makefile
> >  create mode 100644 drivers/leds/simple/simatic-ipc-leds.c
> >  create mode 100644 drivers/platform/x86/simatic-ipc.c
> >  create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
> >  create mode 100644
> > include/linux/platform_data/x86/simatic-ipc-base.h create mode
> > 100644 include/linux/platform_data/x86/simatic-ipc.h 
> 

Re: [PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

Am Thu, 1 Apr 2021 18:15:41 +0200
schrieb "Enrico Weigelt, metux IT consult" :

> On 29.03.21 19:49, Henning Schild wrote:
> 
> Hi,
> 
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.  
> 
> Where does the wdt actually come from ?
> 
> Is it in the SoC ? (which SoC exactly). SoC-builtin wdt is a pretty 
> usual case.
>
> Or some external chip ?

I guess external chip, but again we are talking about multiple
machines. And the manuals i read so far do not go into that sort of
detail. In fact on some of the machines you will have two watchdogs,
one from the SoC and that "special" one.
That has several reasons, probably not too important here. The HW guys
are adding another wd not just for fun, and it would be nice to have a
driver.
 
> The code smells a bit like two entirely different wdt's that just have
> some similarities. If that's the case, I'd rather split it into two
> separate drivers and let the parent driver (board file) instantiate
> the correct one.

Yes, it is two. Just like for the LEDs. One version PIO-based another
version gpio/p2sb/mmio based.
In fact the latter should very likely be based on that gpio pinctl,
whether it really needs to be a separate driver will have to be seen.
There are probably pros and cons for both options.

regards,
Henning

> 
> --mtx
> 

Re: [PATCH v1 3/7] PCI: New Primary to Sideband (P2SB) bridge support library

[Henning Schild]

Am Fri, 2 Apr 2021 15:09:12 +0200
schrieb "Enrico Weigelt, metux IT consult" :

> On 09.03.21 09:42, Henning Schild wrote:
> 
> > The device will respond to MMIO while being hidden. I am afraid
> > nothing stops a collision, except for the assumption that the BIOS
> > is always right and PCI devices never get remapped. But just
> > guessing here.  
> 
> What could go wrong if it is remapped, except that this driver would
> write to the wrong mmio space ?
> 
> If it's unhidden, pci-core should see it and start the usual probing,
> right ?

I have seen this guy exposed to Linux on coreboot machines. No issues.
But i can imagine BIOSs that somehow make use of the device and assume
it wont move. So we would at least need a parameter to allow keeping
that device hidden, or "fixed" in memory.

Henning

> 
> --mtx
> 

Re: [PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Wed, 31 Mar 2021 18:40:23 +0300
schrieb Andy Shevchenko :

> On Tue, Mar 30, 2021 at 6:33 PM Henning Schild
>  wrote:
> > Am Tue, 30 Mar 2021 15:41:53 +0300
> > schrieb Andy Shevchenko :  
> > > On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
> > >  wrote:  
> > > > Am Tue, 30 Mar 2021 15:15:16 +0300
> > > > schrieb Andy Shevchenko :  
> > > > > On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> > > > >  wrote:  
> > > > > > Am Tue, 30 Mar 2021 14:04:35 +0300
> > > > > > schrieb Andy Shevchenko :  
> > > > > > > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > > > > > >  wrote:  
> > >  
> > > > > > > > +static struct simatic_ipc_led simatic_ipc_leds_mem[] =
> > > > > > > > {
> > > > > > > > +   {0x500 + 0x1A0, "red:" LED_FUNCTION_STATUS
> > > > > > > > "-1"},
> > > > > > > > +   {0x500 + 0x1A8, "green:" LED_FUNCTION_STATUS
> > > > > > > > "-1"},
> > > > > > > > +   {0x500 + 0x1C8, "red:" LED_FUNCTION_STATUS
> > > > > > > > "-2"},
> > > > > > > > +   {0x500 + 0x1D0, "green:" LED_FUNCTION_STATUS
> > > > > > > > "-2"},
> > > > > > > > +   {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS
> > > > > > > > "-3"},
> > > > > > > > +   {0x500 + 0x198, "green:" LED_FUNCTION_STATUS
> > > > > > > > "-3"},
> > > > > > > > +   { }
> > > > > > > > +};  
> > > > > > >
> > > > > > > It seems to me like poking GPIO controller registers
> > > > > > > directly. This is not good. The question still remains:
> > > > > > > Can we simply register a GPIO (pin control) driver and
> > > > > > > use an LED GPIO driver with an additional board file that
> > > > > > > instantiates it?  
> > > > > >
> > > > > > I wrote about that in reply to the cover letter. My view is
> > > > > > still that it would be an abstraction with only one user,
> > > > > > just causing work and likely not ending up as generic as it
> > > > > > might eventually have to be.
> > > > > >
> > > > > > The region is reserved, not sure what the problem with the
> > > > > > "poking" is.  
> > > > >
> > > > >  
> > > > > > Maybe i do not understand all the benefits of such a split
> > > > > > at this point in time. At the moment i only see work with
> > > > > > hardly any benefit, not just work for me but also for
> > > > > > maintainers. I sure do not mean to be ignorant. Maybe you
> > > > > > go into details and convince me or we wait for other
> > > > > > peoples opinions on how to proceed, maybe there is a second
> > > > > > user that i am not aware of? Until i am convinced otherwise
> > > > > > i will try to argue that a single-user-abstraction is
> > > > > > needless work/code, and should be done only when actually
> > > > > > needed.  
> > > > >
> > > > > I have just read your messages (there is a cover letter and
> > > > > additional email which was sent lately).
> > > > >
> > > > > I would like to know what the CPU model number on that board
> > > > > is. Than we can continue to see what possibilities we have
> > > > > here.  
> > > >
> > > > I guess we are talking about the one that uses memory mapped,
> > > > that is called an "IPC127E" and seems to have either Intel Atom
> > > > E3940 or E3930 which seems to be Apollo Lake.  
> > >
> > > Yep. And now the question, in my patch series you should have got
> > > the apollolake-pinctrl driver loaded (if not, we have to
> > > investigate why it's not being instantiated). This will give you
> > > a read GPIO driver.  
> >
> > Ok, so there is the existing driver i asked about several times.
> > Thanks for pointing it out.  
> 
> If you remember, I asked you about the chip twice :-)
> I assumed that we were talking about Apollo Lake and that's why I
> insisted that the driver is in the kernel source tree.

Sorry, maybe i did not get the context of your question and which of
the machines you asked about. Now it is clear i guess.

> 
> > > So, you may use regular LED GPIO on top of it
> > > (https://elixir.bootlin.com/linux/latest/source/drivers/leds/leds-gpio.c).
> > > I would like to understand why it can't be achieved.  
> >
> > Will have a look. Unfortunately this one box is missing in my
> > personal collection, but let us assume that one can be converted to
> > that existing driver.  
> 
> OK!
> 
> > I guess that will still mean the PIO-based part of the LED driver
> > will have to stay as is.  
> 
> Probably yes. I haven't looked into that part and I have no idea
> what's going on on that platform(s).
> 

Which i guess means the series can be reviewed as if the mmio bits for
that apollo lake would not be in it, maybe i will even send a version
without that one box. We have others in the "backlog" might as well
delay that one if it helps sorting out a base-line.

regards,
Henning

Re: [PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Tue, 30 Mar 2021 15:41:53 +0300
schrieb Andy Shevchenko :

> On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
>  wrote:
> > Am Tue, 30 Mar 2021 15:15:16 +0300
> > schrieb Andy Shevchenko :  
> > > On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> > >  wrote:  
> > > > Am Tue, 30 Mar 2021 14:04:35 +0300
> > > > schrieb Andy Shevchenko :  
> > > > > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > > > >  wrote:  
> 
> > > > > > +static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
> > > > > > +   {0x500 + 0x1A0, "red:" LED_FUNCTION_STATUS "-1"},
> > > > > > +   {0x500 + 0x1A8, "green:" LED_FUNCTION_STATUS "-1"},
> > > > > > +   {0x500 + 0x1C8, "red:" LED_FUNCTION_STATUS "-2"},
> > > > > > +   {0x500 + 0x1D0, "green:" LED_FUNCTION_STATUS "-2"},
> > > > > > +   {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS "-3"},
> > > > > > +   {0x500 + 0x198, "green:" LED_FUNCTION_STATUS "-3"},
> > > > > > +   { }
> > > > > > +};  
> > > > >
> > > > > It seems to me like poking GPIO controller registers directly.
> > > > > This is not good. The question still remains: Can we simply
> > > > > register a GPIO (pin control) driver and use an LED GPIO
> > > > > driver with an additional board file that instantiates it?  
> > > >
> > > > I wrote about that in reply to the cover letter. My view is
> > > > still that it would be an abstraction with only one user, just
> > > > causing work and likely not ending up as generic as it might
> > > > eventually have to be.
> > > >
> > > > The region is reserved, not sure what the problem with the
> > > > "poking" is.  
> > >
> > >  
> > > > Maybe i do not understand all the benefits of such a split at
> > > > this point in time. At the moment i only see work with hardly
> > > > any benefit, not just work for me but also for maintainers. I
> > > > sure do not mean to be ignorant. Maybe you go into details and
> > > > convince me or we wait for other peoples opinions on how to
> > > > proceed, maybe there is a second user that i am not aware of?
> > > > Until i am convinced otherwise i will try to argue that a
> > > > single-user-abstraction is needless work/code, and should be
> > > > done only when actually needed.  
> > >
> > > I have just read your messages (there is a cover letter and
> > > additional email which was sent lately).
> > >
> > > I would like to know what the CPU model number on that board is.
> > > Than we can continue to see what possibilities we have here.  
> >
> > I guess we are talking about the one that uses memory mapped, that
> > is called an "IPC127E" and seems to have either Intel Atom E3940 or
> > E3930 which seems to be Apollo Lake.  
> 
> Yep. And now the question, in my patch series you should have got the
> apollolake-pinctrl driver loaded (if not, we have to investigate why
> it's not being instantiated). This will give you a read GPIO driver.

Ok, so there is the existing driver i asked about several times. Thanks
for pointing it out.

> So, you may use regular LED GPIO on top of it
> (https://elixir.bootlin.com/linux/latest/source/drivers/leds/leds-gpio.c).
> I would like to understand why it can't be achieved.

Will have a look. Unfortunately this one box is missing in my personal
collection, but let us assume that one can be converted to that
existing driver.
I guess that will still mean the PIO-based part of the LED driver will
have to stay as is.

regards,
Henning

Re: [PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Tue, 30 Mar 2021 15:15:16 +0300
schrieb Andy Shevchenko :

> On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
>  wrote:
> > Am Tue, 30 Mar 2021 14:04:35 +0300
> > schrieb Andy Shevchenko :  
> > > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > >  wrote:  
> > > >
> > > > This driver adds initial support for several devices from
> > > > Siemens. It is based on a platform driver introduced in an
> > > > earlier commit.  
> > >
> > > ...
> > >  
> > > > +#define SIMATIC_IPC_LED_PORT_BASE  0x404E  
> > >  
> > > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > > +   {1 << 15, "green:" LED_FUNCTION_STATUS "-1" },
> > > > +   {1 << 7,  "yellow:" LED_FUNCTION_STATUS "-1" },
> > > > +   {1 << 14, "red:" LED_FUNCTION_STATUS "-2" },
> > > > +   {1 << 6,  "yellow:" LED_FUNCTION_STATUS "-2" },
> > > > +   {1 << 13, "red:" LED_FUNCTION_STATUS "-3" },
> > > > +   {1 << 5,  "yellow:" LED_FUNCTION_STATUS "-3" },
> > > > +   { }
> > > > +};  
> > >  
> > > > +static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
> > > > +   {0x500 + 0x1A0, "red:" LED_FUNCTION_STATUS "-1"},
> > > > +   {0x500 + 0x1A8, "green:" LED_FUNCTION_STATUS "-1"},
> > > > +   {0x500 + 0x1C8, "red:" LED_FUNCTION_STATUS "-2"},
> > > > +   {0x500 + 0x1D0, "green:" LED_FUNCTION_STATUS "-2"},
> > > > +   {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS "-3"},
> > > > +   {0x500 + 0x198, "green:" LED_FUNCTION_STATUS "-3"},
> > > > +   { }
> > > > +};  
> > >
> > > It seems to me like poking GPIO controller registers directly.
> > > This is not good. The question still remains: Can we simply
> > > register a GPIO (pin control) driver and use an LED GPIO driver
> > > with an additional board file that instantiates it?  
> >
> > I wrote about that in reply to the cover letter. My view is still
> > that it would be an abstraction with only one user, just causing
> > work and likely not ending up as generic as it might eventually
> > have to be.
> >
> > The region is reserved, not sure what the problem with the "poking"
> > is.  
> 
> 
> > Maybe i do not understand all the benefits of such a split at this
> > point in time. At the moment i only see work with hardly any
> > benefit, not just work for me but also for maintainers. I sure do
> > not mean to be ignorant. Maybe you go into details and convince me
> > or we wait for other peoples opinions on how to proceed, maybe
> > there is a second user that i am not aware of?
> > Until i am convinced otherwise i will try to argue that a
> > single-user-abstraction is needless work/code, and should be done
> > only when actually needed.  
> 
> I have just read your messages (there is a cover letter and additional
> email which was sent lately).
> 
> I would like to know what the CPU model number on that board is. Than
> we can continue to see what possibilities we have here.

I guess we are talking about the one that uses memory mapped, that is
called an "IPC127E" and seems to have either Intel Atom E3940 or E3930
which seems to be Apollo Lake.

Henning

Re: [PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Tue, 30 Mar 2021 14:04:35 +0300
schrieb Andy Shevchenko :

> On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
>  wrote:
> >
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.  
> 
> ...
> 
> > +#define SIMATIC_IPC_LED_PORT_BASE  0x404E  
> 
> > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > +   {1 << 15, "green:" LED_FUNCTION_STATUS "-1" },
> > +   {1 << 7,  "yellow:" LED_FUNCTION_STATUS "-1" },
> > +   {1 << 14, "red:" LED_FUNCTION_STATUS "-2" },
> > +   {1 << 6,  "yellow:" LED_FUNCTION_STATUS "-2" },
> > +   {1 << 13, "red:" LED_FUNCTION_STATUS "-3" },
> > +   {1 << 5,  "yellow:" LED_FUNCTION_STATUS "-3" },
> > +   { }
> > +};  
> 
> > +static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
> > +   {0x500 + 0x1A0, "red:" LED_FUNCTION_STATUS "-1"},
> > +   {0x500 + 0x1A8, "green:" LED_FUNCTION_STATUS "-1"},
> > +   {0x500 + 0x1C8, "red:" LED_FUNCTION_STATUS "-2"},
> > +   {0x500 + 0x1D0, "green:" LED_FUNCTION_STATUS "-2"},
> > +   {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS "-3"},
> > +   {0x500 + 0x198, "green:" LED_FUNCTION_STATUS "-3"},
> > +   { }
> > +};  
> 
> It seems to me like poking GPIO controller registers directly. This
> is not good. The question still remains: Can we simply register a
> GPIO (pin control) driver and use an LED GPIO driver with an
> additional board file that instantiates it?

I wrote about that in reply to the cover letter. My view is still that
it would be an abstraction with only one user, just causing work and
likely not ending up as generic as it might eventually have to be.

The region is reserved, not sure what the problem with the "poking" is.

Maybe i do not understand all the benefits of such a split at this
point in time. At the moment i only see work with hardly any benefit,
not just work for me but also for maintainers. I sure do not mean to be
ignorant. Maybe you go into details and convince me or we wait for other
peoples opinions on how to proceed, maybe there is a second user that i
am not aware of?
Until i am convinced otherwise i will try to argue that a
single-user-abstraction is needless work/code, and should be done only
when actually needed.

regards,
Henning

Re: [PATCH v3 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

Guys,

sorry for the delay. This one did in fact not change too much after all.

The biggest points that are still kind of open are the naming of the
LEDs. If what is proposed here is acceptable it is not open from my
side.

The other big point was "using a generic gpio" driver as a basis. My
current understanding of that point is, that such a driver does not yet
exist. Meaning an introduction of the abstractions can and probably
should wait for a second user. Without the second user it is just hard
to test and find the right abstraction, plus we will end up with more
code meaning more work for everyone.

regards,
Henning

Am Mon, 29 Mar 2021 19:49:24 +0200
schrieb Henning Schild :

> changes since v2:
> 
> - remove "simatic-ipc" prefix from LED names
> - fix style issues found in v2, mainly LED driver
> - fix OEM specific dmi code, and remove magic numbers
> - more "simatic_ipc" name prefixing
> - improved pmc quirk code using callbacks
> 
> changes since v1:
> 
> - fixed lots of style issues found in v1
>   - (debug) printing
>   - header ordering
> - fixed license issues GPLv2 and SPDX in all files
> - module_platform_driver instead of __init __exit
> - wdt simplifications cleanup
> - lots of fixes in wdt driver, all that was found in v1
> - fixed dmi length in dmi helper
> - changed LED names to allowed ones
> - move led driver to simple/
> - switched pmc_atom to dmi callback with global variable
> 
> --
> 
> This series adds support for watchdogs and leds of several x86 devices
> from Siemens.
> 
> It is structured with a platform driver that mainly does
> identification of the machines. It might trigger loading of the
> actual device drivers by attaching devices to the platform bus.
> 
> The identification is vendor specific, parsing a special binary DMI
> entry. The implementation of that platform identification is applied
> on pmc_atom clock quirks in the final patch.
> 
> It is all structured in a way that we can easily add more devices and
> more platform drivers later. Internally we have some more code for
> hardware monitoring, more leds, watchdogs etc. This will follow some
> day.
> 
> Henning Schild (4):
>   platform/x86: simatic-ipc: add main driver for Siemens devices
>   leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
>   watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
>   platform/x86: pmc_atom: improve critclk_systems matching for Siemens
> PCs
> 
>  drivers/leds/Kconfig  |   3 +
>  drivers/leds/Makefile |   3 +
>  drivers/leds/simple/Kconfig   |  11 +
>  drivers/leds/simple/Makefile  |   2 +
>  drivers/leds/simple/simatic-ipc-leds.c| 202 
>  drivers/platform/x86/Kconfig  |  12 +
>  drivers/platform/x86/Makefile |   3 +
>  drivers/platform/x86/pmc_atom.c   |  57 +++--
>  drivers/platform/x86/simatic-ipc.c| 169 ++
>  drivers/watchdog/Kconfig  |  11 +
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/simatic-ipc-wdt.c| 215
> ++ .../platform_data/x86/simatic-ipc-base.h  |
> 29 +++ include/linux/platform_data/x86/simatic-ipc.h |  72 ++
>  14 files changed, 769 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/leds/simple/Kconfig
>  create mode 100644 drivers/leds/simple/Makefile
>  create mode 100644 drivers/leds/simple/simatic-ipc-leds.c
>  create mode 100644 drivers/platform/x86/simatic-ipc.c
>  create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
>  create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
>  create mode 100644 include/linux/platform_data/x86/simatic-ipc.h
> 

[PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.

Signed-off-by: Henning Schild 
Reviewed-by: Guenter Roeck 
---
 drivers/watchdog/Kconfig   |  11 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/simatic-ipc-wdt.c | 215 +
 3 files changed, 227 insertions(+)
 create mode 100644 drivers/watchdog/simatic-ipc-wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1fe0042a48d2..948497eb4bef 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1575,6 +1575,17 @@ config NIC7018_WDT
  To compile this driver as a module, choose M here: the module will be
  called nic7018_wdt.
 
+config SIEMENS_SIMATIC_IPC_WDT
+   tristate "Siemens Simatic IPC Watchdog"
+   depends on SIEMENS_SIMATIC_IPC
+   select WATCHDOG_CORE
+   help
+ This driver adds support for several watchdogs found in Industrial
+ PCs from Siemens.
+
+ To compile this driver as a module, choose M here: the module will be
+ called simatic-ipc-wdt.
+
 # M68K Architecture
 
 config M54xx_WATCHDOG
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f3a6540e725e..7f5c73ec058c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
 obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
 obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
 obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
+obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
 
 # M68K Architecture
 obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
diff --git a/drivers/watchdog/simatic-ipc-wdt.c 
b/drivers/watchdog/simatic-ipc-wdt.c
new file mode 100644
index ..e901718d05b9
--- /dev/null
+++ b/drivers/watchdog/simatic-ipc-wdt.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC driver for Watchdogs
+ *
+ * Copyright (c) Siemens AG, 2020-2021
+ *
+ * Authors:
+ *  Gerd Haeussler 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WD_ENABLE_IOADR0x62
+#define WD_TRIGGER_IOADR   0x66
+#define GPIO_COMMUNITY0_PORT_ID0xaf
+#define PAD_CFG_DW0_GPP_A_23   0x4b8
+#define SAFE_EN_N_427E 0x01
+#define SAFE_EN_N_227E 0x04
+#define WD_ENABLED 0x01
+#define WD_TRIGGERED   0x80
+#define WD_MACROMODE   0x02
+
+#define TIMEOUT_MIN2
+#define TIMEOUT_DEF64
+#define TIMEOUT_MAX64
+
+#define GP_STATUS_REG_227E 0x404D  /* IO PORT for SAFE_EN_N on 227E */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static struct resource gp_status_reg_227e_res =
+   DEFINE_RES_IO_NAMED(GP_STATUS_REG_227E, SZ_1, KBUILD_MODNAME);
+
+static struct resource io_resource =
+   DEFINE_RES_IO_NAMED(WD_ENABLE_IOADR, SZ_1,
+   KBUILD_MODNAME " WD_ENABLE_IOADR");
+
+/* the actual start will be discovered with pci, 0 is a placeholder */
+static struct resource mem_resource =
+   DEFINE_RES_MEM_NAMED(0, SZ_4, "WD_RESET_BASE_ADR");
+
+static u32 wd_timeout_table[] = {2, 4, 6, 8, 16, 32, 48, 64 };
+static void __iomem *wd_reset_base_addr;
+
+static int wd_start(struct watchdog_device *wdd)
+{
+   outb(inb(WD_ENABLE_IOADR) | WD_ENABLED, WD_ENABLE_IOADR);
+   return 0;
+}
+
+static int wd_stop(struct watchdog_device *wdd)
+{
+   outb(inb(WD_ENABLE_IOADR) & ~WD_ENABLED, WD_ENABLE_IOADR);
+   return 0;
+}
+
+static int wd_ping(struct watchdog_device *wdd)
+{
+   inb(WD_TRIGGER_IOADR);
+   return 0;
+}
+
+static int wd_set_timeout(struct watchdog_device *wdd, unsigned int t)
+{
+   int timeout_idx = find_closest(t, wd_timeout_table,
+  ARRAY_SIZE(wd_timeout_table));
+
+   outb((inb(WD_ENABLE_IOADR) & 0xc7) | timeout_idx << 3, WD_ENABLE_IOADR);
+   wdd->timeout = wd_timeout_table[timeout_idx];
+   return 0;
+}
+
+static const struct watchdog_info wdt_ident = {
+   .options= WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING |
+ WDIOF_SETTIMEOUT,
+   .identity   = KBUILD_MODNAME,
+};
+
+static const struct watchdog_ops wdt_ops = {
+   .owner  = THIS_MODULE,
+   .start  = wd_start,
+   .stop   = wd_stop,
+   .ping   = wd_ping,
+   .set_timeout= wd_set_timeout,
+};
+
+static void wd_secondary_enable(u32 wdtmode)
+{
+   u16 resetbit;
+
+   /* set safe_en_n so we are not just WDIOF_ALARMONLY */
+   

[PATCH v3 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.

Signed-off-by: Henning Schild 
---
 drivers/leds/Kconfig   |   3 +
 drivers/leds/Makefile  |   3 +
 drivers/leds/simple/Kconfig|  11 ++
 drivers/leds/simple/Makefile   |   2 +
 drivers/leds/simple/simatic-ipc-leds.c | 202 +
 5 files changed, 221 insertions(+)
 create mode 100644 drivers/leds/simple/Kconfig
 create mode 100644 drivers/leds/simple/Makefile
 create mode 100644 drivers/leds/simple/simatic-ipc-leds.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b6742b4231bf..5c8558a4fa60 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -937,4 +937,7 @@ source "drivers/leds/trigger/Kconfig"
 comment "LED Blink"
 source "drivers/leds/blink/Kconfig"
 
+comment "Simple LED drivers"
+source "drivers/leds/simple/Kconfig"
+
 endif # NEW_LEDS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 2a698df9da57..2de7fdd8d629 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -111,3 +111,6 @@ obj-$(CONFIG_LEDS_TRIGGERS) += trigger/
 
 # LED Blink
 obj-$(CONFIG_LEDS_BLINK)+= blink/
+
+# Simple LED drivers
+obj-y  += simple/
diff --git a/drivers/leds/simple/Kconfig b/drivers/leds/simple/Kconfig
new file mode 100644
index ..9f6a68336659
--- /dev/null
+++ b/drivers/leds/simple/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config LEDS_SIEMENS_SIMATIC_IPC
+   tristate "LED driver for Siemens Simatic IPCs"
+   depends on LEDS_CLASS
+   depends on SIEMENS_SIMATIC_IPC
+   help
+ This option enables support for the LEDs of several Industrial PCs
+ from Siemens.
+
+ To compile this driver as a module, choose M here: the module
+ will be called simatic-ipc-leds.
diff --git a/drivers/leds/simple/Makefile b/drivers/leds/simple/Makefile
new file mode 100644
index ..8481f1e9e360
--- /dev/null
+++ b/drivers/leds/simple/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_LEDS_SIEMENS_SIMATIC_IPC) += simatic-ipc-leds.o
diff --git a/drivers/leds/simple/simatic-ipc-leds.c 
b/drivers/leds/simple/simatic-ipc-leds.c
new file mode 100644
index ..043edbf81b76
--- /dev/null
+++ b/drivers/leds/simple/simatic-ipc-leds.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC driver for LEDs
+ *
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ *  Henning Schild 
+ *  Jan Kiszka 
+ *  Gerd Haeussler 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SIMATIC_IPC_LED_PORT_BASE  0x404E
+
+struct simatic_ipc_led {
+   unsigned int value; /* mask for io and offset for mem */
+   char *name;
+   struct led_classdev cdev;
+};
+
+static struct simatic_ipc_led simatic_ipc_leds_io[] = {
+   {1 << 15, "green:" LED_FUNCTION_STATUS "-1" },
+   {1 << 7,  "yellow:" LED_FUNCTION_STATUS "-1" },
+   {1 << 14, "red:" LED_FUNCTION_STATUS "-2" },
+   {1 << 6,  "yellow:" LED_FUNCTION_STATUS "-2" },
+   {1 << 13, "red:" LED_FUNCTION_STATUS "-3" },
+   {1 << 5,  "yellow:" LED_FUNCTION_STATUS "-3" },
+   { }
+};
+
+/* the actual start will be discovered with PCI, 0 is a placeholder */
+struct resource simatic_ipc_led_mem_res = DEFINE_RES_MEM_NAMED(0, SZ_4K, 
KBUILD_MODNAME);
+
+static void *simatic_ipc_led_memory;
+
+static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
+   {0x500 + 0x1A0, "red:" LED_FUNCTION_STATUS "-1"},
+   {0x500 + 0x1A8, "green:" LED_FUNCTION_STATUS "-1"},
+   {0x500 + 0x1C8, "red:" LED_FUNCTION_STATUS "-2"},
+   {0x500 + 0x1D0, "green:" LED_FUNCTION_STATUS "-2"},
+   {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS "-3"},
+   {0x500 + 0x198, "green:" LED_FUNCTION_STATUS "-3"},
+   { }
+};
+
+static struct resource simatic_ipc_led_io_res =
+   DEFINE_RES_IO_NAMED(SIMATIC_IPC_LED_PORT_BASE, SZ_1, KBUILD_MODNAME);
+
+static DEFINE_SPINLOCK(reg_lock);
+
+static inline struct simatic_ipc_led *cdev_to_led(struct led_classdev *led_cd)
+{
+   return container_of(led_cd, struct simatic_ipc_led, cdev);
+}
+
+static void simatic_ipc_led_set_io(struct led_classdev *led_cd,
+  enum led_brightness brightness)
+{
+   struct simatic_ipc_led *led = cdev_to_led(led_cd);
+   unsigned long flags;
+   unsigned int val;
+
+   spin_lock_irqsave(_lock, flags);
+
+   val = in

[PATCH v3 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

changes since v2:

- remove "simatic-ipc" prefix from LED names
- fix style issues found in v2, mainly LED driver
- fix OEM specific dmi code, and remove magic numbers
- more "simatic_ipc" name prefixing
- improved pmc quirk code using callbacks

changes since v1:

- fixed lots of style issues found in v1
  - (debug) printing
  - header ordering
- fixed license issues GPLv2 and SPDX in all files
- module_platform_driver instead of __init __exit
- wdt simplifications cleanup
- lots of fixes in wdt driver, all that was found in v1
- fixed dmi length in dmi helper
- changed LED names to allowed ones
- move led driver to simple/
- switched pmc_atom to dmi callback with global variable

--

This series adds support for watchdogs and leds of several x86 devices
from Siemens.

It is structured with a platform driver that mainly does identification
of the machines. It might trigger loading of the actual device drivers
by attaching devices to the platform bus.

The identification is vendor specific, parsing a special binary DMI
entry. The implementation of that platform identification is applied on
pmc_atom clock quirks in the final patch.

It is all structured in a way that we can easily add more devices and
more platform drivers later. Internally we have some more code for
hardware monitoring, more leds, watchdogs etc. This will follow some
day.

Henning Schild (4):
  platform/x86: simatic-ipc: add main driver for Siemens devices
  leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
  watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
  platform/x86: pmc_atom: improve critclk_systems matching for Siemens
PCs

 drivers/leds/Kconfig  |   3 +
 drivers/leds/Makefile |   3 +
 drivers/leds/simple/Kconfig   |  11 +
 drivers/leds/simple/Makefile  |   2 +
 drivers/leds/simple/simatic-ipc-leds.c| 202 
 drivers/platform/x86/Kconfig  |  12 +
 drivers/platform/x86/Makefile |   3 +
 drivers/platform/x86/pmc_atom.c   |  57 +++--
 drivers/platform/x86/simatic-ipc.c| 169 ++
 drivers/watchdog/Kconfig  |  11 +
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/simatic-ipc-wdt.c| 215 ++
 .../platform_data/x86/simatic-ipc-base.h  |  29 +++
 include/linux/platform_data/x86/simatic-ipc.h |  72 ++
 14 files changed, 769 insertions(+), 21 deletions(-)
 create mode 100644 drivers/leds/simple/Kconfig
 create mode 100644 drivers/leds/simple/Makefile
 create mode 100644 drivers/leds/simple/simatic-ipc-leds.c
 create mode 100644 drivers/platform/x86/simatic-ipc.c
 create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
 create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
 create mode 100644 include/linux/platform_data/x86/simatic-ipc.h

-- 
2.26.3

[PATCH v3 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

This mainly implements detection of these devices and will allow
secondary drivers to work on such machines.

The identification is DMI-based with a vendor specific way to tell them
apart in a reliable way.

Drivers for LEDs and Watchdogs will follow to make use of that platform
detection.

Signed-off-by: Henning Schild 
---
 drivers/platform/x86/Kconfig  |  12 ++
 drivers/platform/x86/Makefile |   3 +
 drivers/platform/x86/simatic-ipc.c| 169 ++
 .../platform_data/x86/simatic-ipc-base.h  |  29 +++
 include/linux/platform_data/x86/simatic-ipc.h |  72 
 5 files changed, 285 insertions(+)
 create mode 100644 drivers/platform/x86/simatic-ipc.c
 create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
 create mode 100644 include/linux/platform_data/x86/simatic-ipc.h

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 461ec61530eb..1eaa03d0d183 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1289,6 +1289,18 @@ config INTEL_TELEMETRY
  directly via debugfs files. Various tools may use
  this interface for SoC state monitoring.
 
+config SIEMENS_SIMATIC_IPC
+   tristate "Siemens Simatic IPC Class driver"
+   depends on PCI
+   help
+ This Simatic IPC class driver is the central of several drivers. It
+ is mainly used for system identification, after which drivers in other
+ classes will take care of driving specifics of those machines.
+ i.e. LEDs and watchdog.
+
+ To compile this driver as a module, choose M here: the module
+ will be called simatic-ipc.
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 60d554073749..26cdebf2e701 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -138,3 +138,6 @@ obj-$(CONFIG_INTEL_TELEMETRY)   += 
intel_telemetry_core.o \
   intel_telemetry_pltdrv.o \
   intel_telemetry_debugfs.o
 obj-$(CONFIG_PMC_ATOM) += pmc_atom.o
+
+# Siemens Simatic Industrial PCs
+obj-$(CONFIG_SIEMENS_SIMATIC_IPC)  += simatic-ipc.o
diff --git a/drivers/platform/x86/simatic-ipc.c 
b/drivers/platform/x86/simatic-ipc.c
new file mode 100644
index ..52e8596bc63d
--- /dev/null
+++ b/drivers/platform/x86/simatic-ipc.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC platform driver
+ *
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ *  Henning Schild 
+ *  Jan Kiszka 
+ *  Gerd Haeussler 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct platform_device *ipc_led_platform_device;
+static struct platform_device *ipc_wdt_platform_device;
+
+static const struct dmi_system_id simatic_ipc_whitelist[] = {
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
+   },
+   },
+   {}
+};
+
+static struct simatic_ipc_platform platform_data;
+
+static struct {
+   u32 station_id;
+   u8 led_mode;
+   u8 wdt_mode;
+} device_modes[] = {
+   {SIMATIC_IPC_IPC127E, SIMATIC_IPC_DEVICE_127E, SIMATIC_IPC_DEVICE_NONE},
+   {SIMATIC_IPC_IPC227D, SIMATIC_IPC_DEVICE_227D, SIMATIC_IPC_DEVICE_NONE},
+   {SIMATIC_IPC_IPC227E, SIMATIC_IPC_DEVICE_427E, SIMATIC_IPC_DEVICE_227E},
+   {SIMATIC_IPC_IPC277E, SIMATIC_IPC_DEVICE_NONE, SIMATIC_IPC_DEVICE_227E},
+   {SIMATIC_IPC_IPC427D, SIMATIC_IPC_DEVICE_427E, SIMATIC_IPC_DEVICE_NONE},
+   {SIMATIC_IPC_IPC427E, SIMATIC_IPC_DEVICE_427E, SIMATIC_IPC_DEVICE_427E},
+   {SIMATIC_IPC_IPC477E, SIMATIC_IPC_DEVICE_NONE, SIMATIC_IPC_DEVICE_427E},
+};
+
+static int register_platform_devices(u32 station_id)
+{
+   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
+   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;
+   int i;
+
+   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
+
+   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
+   if (device_modes[i].station_id == station_id) {
+   ledmode = device_modes[i].led_mode;
+   wdtmode = device_modes[i].wdt_mode;
+   break;
+   }
+   }
+
+   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
+   platform_data.devmode = ledmode;
+   ipc_led_platform_device =
+   platform_device_register_data(NULL,
+   KBUILD_MODNAME "_leds", PLATFORM_DEVID_NONE,
+   _data,
+   sizeof(struct simatic_ipc_platform));
+   if (IS_ERR(ipc_led_platform_device))
+   return PTR_ERR(ipc_led_platform_device);
+
+ 

[PATCH v3 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs

[Henning Schild]

Siemens industrial PCs unfortunately can not always be properly
identified the way we used to. An earlier commit introduced code that
allows proper identification without looking at DMI strings that could
differ based on product branding.
Switch over to that proper way and revert commits that used to collect
the machines based on unstable strings.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Fixes: e8796c6c69d1 ("platform/x86: pmc_atom: Add Siemens CONNECT ...")
Fixes: f110d252ae79 ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Fixes: ad0d315b4d4e ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Tested-by: Michael Haener 
Signed-off-by: Henning Schild 
---
 drivers/platform/x86/pmc_atom.c | 57 +
 1 file changed, 36 insertions(+), 21 deletions(-)

diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
index ca684ed760d1..9904fe6973df 100644
--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -362,6 +363,30 @@ static void pmc_dbgfs_register(struct pmc_dev *pmc)
 }
 #endif /* CONFIG_DEBUG_FS */
 
+static bool pmc_clk_is_critical = true;
+
+static int dmi_callback(const struct dmi_system_id *d)
+{
+   pr_info("%s critclks quirk enabled\n", d->ident);
+
+   return 1;
+}
+
+static int dmi_callback_siemens(const struct dmi_system_id *d)
+{
+   u32 st_id;
+
+   if (dmi_walk(simatic_ipc_find_dmi_entry_helper, _id))
+   goto out;
+
+   if (st_id == SIMATIC_IPC_IPC227E || st_id == SIMATIC_IPC_IPC277E)
+   return dmi_callback(d);
+
+out:
+   pmc_clk_is_critical = false;
+   return 1;
+}
+
 /*
  * Some systems need one or more of their pmc_plt_clks to be
  * marked as critical.
@@ -370,6 +395,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk0 is used for an external HSIC USB HUB */
.ident = "MPL CEC1x",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "MPL AG"),
DMI_MATCH(DMI_PRODUCT_NAME, "CEC10 Family"),
@@ -378,6 +404,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk0 - 3 are used for the 4 ethernet controllers */
.ident = "Lex 3I380D",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"),
@@ -386,6 +413,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Lex 2I385SW",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
DMI_MATCH(DMI_PRODUCT_NAME, "2I385SW"),
@@ -394,6 +422,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB3163",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
@@ -402,6 +431,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB4063",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
@@ -410,6 +440,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB6263",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB6263"),
@@ -418,30 +449,17 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB6363",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB6363"),
},
},
   

Re: [PATCH v2 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

Am Mon, 15 Mar 2021 08:10:25 -0700
schrieb Guenter Roeck :

> On 3/15/21 2:57 AM, Henning Schild wrote:
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.
> > 
> > Signed-off-by: Henning Schild   
> 
> Reviewed-by: Guenter Roeck 

I assume that means i should insert this into v3, will do. The diff
between v2 and v3 is only going to be a name change

-module_platform_driver(wdt_driver);
+module_platform_driver(simatic_ipc_wdt_driver);

Henning


> > ---
> >  drivers/watchdog/Kconfig   |  11 ++
> >  drivers/watchdog/Makefile  |   1 +
> >  drivers/watchdog/simatic-ipc-wdt.c | 215
> > + 3 files changed, 227 insertions(+)
> >  create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
> > 
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 1fe0042a48d2..948497eb4bef 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -1575,6 +1575,17 @@ config NIC7018_WDT
> >   To compile this driver as a module, choose M here: the
> > module will be called nic7018_wdt.
> >  
> > +config SIEMENS_SIMATIC_IPC_WDT
> > +   tristate "Siemens Simatic IPC Watchdog"
> > +   depends on SIEMENS_SIMATIC_IPC
> > +   select WATCHDOG_CORE
> > +   help
> > + This driver adds support for several watchdogs found in
> > Industrial
> > + PCs from Siemens.
> > +
> > + To compile this driver as a module, choose M here: the
> > module will be
> > + called simatic-ipc-wdt.
> > +
> >  # M68K Architecture
> >  
> >  config M54xx_WATCHDOG
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index f3a6540e725e..7f5c73ec058c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> >  obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
> >  obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
> >  obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
> > +obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
> >  
> >  # M68K Architecture
> >  obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
> > diff --git a/drivers/watchdog/simatic-ipc-wdt.c
> > b/drivers/watchdog/simatic-ipc-wdt.c new file mode 100644
> > index ..f0f948968db3
> > --- /dev/null
> > +++ b/drivers/watchdog/simatic-ipc-wdt.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Siemens SIMATIC IPC driver for Watchdogs
> > + *
> > + * Copyright (c) Siemens AG, 2020-2021
> > + *
> > + * Authors:
> > + *  Gerd Haeussler 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define WD_ENABLE_IOADR0x62
> > +#define WD_TRIGGER_IOADR   0x66
> > +#define GPIO_COMMUNITY0_PORT_ID0xaf
> > +#define PAD_CFG_DW0_GPP_A_23   0x4b8
> > +#define SAFE_EN_N_427E 0x01
> > +#define SAFE_EN_N_227E 0x04
> > +#define WD_ENABLED 0x01
> > +#define WD_TRIGGERED   0x80
> > +#define WD_MACROMODE   0x02
> > +
> > +#define TIMEOUT_MIN2
> > +#define TIMEOUT_DEF64
> > +#define TIMEOUT_MAX64
> > +
> > +#define GP_STATUS_REG_227E 0x404D  /* IO PORT for
> > SAFE_EN_N on 227E */ +
> > +static bool nowayout = WATCHDOG_NOWAYOUT;
> > +module_param(nowayout, bool, );
> > +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
> > started (default="
> > +__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > +
> > +static struct resource gp_status_reg_227e_res =
> > +   DEFINE_RES_IO_NAMED(GP_STATUS_REG_227E, SZ_1,
> > KBUILD_MODNAME); +
> > +static struct resource io_resource =
> > +   DEFINE_RES_IO_NAMED(WD_ENABLE_IOADR, SZ_1,
> > +   KBUILD_MODNAME " WD_ENABLE_IOADR");
> > +
> > +/* the actual start will be discovered with pci, 0 is a
> > placeholder */ +static struct resource mem_resource =
> > +   DEFINE_RES_MEM_NAMED(0, SZ_4, "WD_RESET_BASE_ADR");
> > +
> > +static u32 wd_timeout_table[] = {2, 4, 6, 8, 16, 32, 48, 64 };
> > +s

Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Sat, 27 Mar 2021 12:16:23 +0100
schrieb Henning Schild :

> Am Thu, 18 Mar 2021 11:25:10 +0100
> schrieb "Enrico Weigelt, metux IT consult" :
> 
> > On 15.03.21 10:57, Henning Schild wrote:
> > 
> > Hi,
> >   
> > > diff --git a/drivers/leds/simple/simatic-ipc-leds.c
> > > b/drivers/leds/simple/simatic-ipc-leds.c new file mode 100644
> > > index ..0f7e6320e10d
> > > --- /dev/null
> > > +++ b/drivers/leds/simple/simatic-ipc-leds.c
> > > @@ -0,0 +1,210 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Siemens SIMATIC IPC driver for LEDs
> > > + *
> > > + * Copyright (c) Siemens AG, 2018-2021
> > > + *
> > > + * Authors:
> > > + *  Henning Schild 
> > > + *  Jan Kiszka 
> > > + *  Gerd Haeussler 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define SIMATIC_IPC_LED_PORT_BASE0x404E
> > > +
> > > +struct simatic_ipc_led {
> > > + unsigned int value; /* mask for io and offset for mem */
> > > + char name[32];
> > > + struct led_classdev cdev;
> > > +};
> > > +
> > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > + {1 << 15, "simatic-ipc:green:" LED_FUNCTION_STATUS "-1"
> > > },
> > > + {1 << 7,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-1"
> > > },
> > > + {1 << 14, "simatic-ipc:red:" LED_FUNCTION_STATUS "-2" },
> > > + {1 << 6,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-2"
> > > },
> > > + {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
> > > + {1 << 5,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3"
> > > },
> > > + {0, ""},
> > > +};
> > 
> > Wouldn't it be better to name them like they're labeled on the
> > device, as shown on page #19 of the manual, or perhaps a little bit
> > more generic nameing (eg. power, status, error, maint) ?  
> 
> That was proposed in v1 but modern LED drivers should stick to known
> LED_FUNCTION_*
> Here the numbers reflect what is on the device labels. We are talking
> about roughly 10 boxes at the moment, not all having the same labels
> ... but all share 1, 2, 3 
> 
> At the end of the day the software view might be more important than
> the labels. So that people can write generic "echo 1 >
> brightness"-code that works across the full range, possibly even on
> other machines from different vendors. I guess that is also why Pavel
> wants people to use established names.
> 
> > > +/* the actual start will be discovered with pci, 0 is a
> > > placeholder */ +struct resource simatic_ipc_led_mem_res =
> > > + DEFINE_RES_MEM_NAMED(0, SZ_4K, KBUILD_MODNAME);
> >  > +
> >  > +static void *simatic_ipc_led_memory;
> >  > +
> > 
> > hmm, could there *ever* be multiple instances of the driver ?  
> 
> No, the platform bus makes sure there can only be one.
>  
> > Wouldn't it be better to put this in the device priv data instead ?
> >  
> 
> I guess no need for priv because of "highlander ... only 1"
> 
> > > +static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
> > > + {0x500 + 0x1A0, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > > "-1"},
> > > + {0x500 + 0x1A8, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > > "-1"},
> > > + {0x500 + 0x1C8, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > > "-2"},
> > > + {0x500 + 0x1D0, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > > "-2"},
> > > + {0x500 + 0x1E0, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > > "-3"},
> > > + {0x500 + 0x198, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > > "-3"},
> > > + {0, ""},
> > > +};
> > > +
> > > +static struct resource simatic_ipc_led_io_res =
> > > + DEFINE_RES_IO_NAMED(SIMATIC_IPC_LED_PORT_BASE, SZ_1,
> > > KBUILD_MODNAME); +
> > > +static DEFINE_SPINLOCK(reg_lock);
> > 
> > Does this protect global data structures ? If not, I'd rather put it
> > into the device

Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Thu, 18 Mar 2021 11:25:10 +0100
schrieb "Enrico Weigelt, metux IT consult" :

> On 15.03.21 10:57, Henning Schild wrote:
> 
> Hi,
> 
> > diff --git a/drivers/leds/simple/simatic-ipc-leds.c
> > b/drivers/leds/simple/simatic-ipc-leds.c new file mode 100644
> > index ..0f7e6320e10d
> > --- /dev/null
> > +++ b/drivers/leds/simple/simatic-ipc-leds.c
> > @@ -0,0 +1,210 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Siemens SIMATIC IPC driver for LEDs
> > + *
> > + * Copyright (c) Siemens AG, 2018-2021
> > + *
> > + * Authors:
> > + *  Henning Schild 
> > + *  Jan Kiszka 
> > + *  Gerd Haeussler 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SIMATIC_IPC_LED_PORT_BASE  0x404E
> > +
> > +struct simatic_ipc_led {
> > +   unsigned int value; /* mask for io and offset for mem */
> > +   char name[32];
> > +   struct led_classdev cdev;
> > +};
> > +
> > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > +   {1 << 15, "simatic-ipc:green:" LED_FUNCTION_STATUS "-1" },
> > +   {1 << 7,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-1" },
> > +   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_STATUS "-2" },
> > +   {1 << 6,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-2" },
> > +   {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
> > +   {1 << 5,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3" },
> > +   {0, ""},
> > +};  
> 
> Wouldn't it be better to name them like they're labeled on the device,
> as shown on page #19 of the manual, or perhaps a little bit more
> generic nameing (eg. power, status, error, maint) ?

That was proposed in v1 but modern LED drivers should stick to known
LED_FUNCTION_*
Here the numbers reflect what is on the device labels. We are talking
about roughly 10 boxes at the moment, not all having the same labels
... but all share 1, 2, 3 

At the end of the day the software view might be more important than
the labels. So that people can write generic "echo 1 > brightness"-code
that works across the full range, possibly even on other machines from
different vendors. I guess that is also why Pavel wants people to use
established names.

> > +/* the actual start will be discovered with pci, 0 is a
> > placeholder */ +struct resource simatic_ipc_led_mem_res =
> > +   DEFINE_RES_MEM_NAMED(0, SZ_4K, KBUILD_MODNAME);
>  > +
>  > +static void *simatic_ipc_led_memory;
>  > +  
> 
> hmm, could there *ever* be multiple instances of the driver ?

No, the platform bus makes sure there can only be one.
 
> Wouldn't it be better to put this in the device priv data instead ?

I guess no need for priv because of "highlander ... only 1"

> > +static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
> > +   {0x500 + 0x1A0, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > "-1"},
> > +   {0x500 + 0x1A8, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > "-1"},
> > +   {0x500 + 0x1C8, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > "-2"},
> > +   {0x500 + 0x1D0, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > "-2"},
> > +   {0x500 + 0x1E0, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > "-3"},
> > +   {0x500 + 0x198, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > "-3"},
> > +   {0, ""},
> > +};
> > +
> > +static struct resource simatic_ipc_led_io_res =
> > +   DEFINE_RES_IO_NAMED(SIMATIC_IPC_LED_PORT_BASE, SZ_1,
> > KBUILD_MODNAME); +
> > +static DEFINE_SPINLOCK(reg_lock);  
> 
> Does this protect global data structures ? If not, I'd rather put it
> into the device priv data instead.

highlander, no need for priv

It protects the setter, which needs to inw + outw and is not atomic

> BTW: doesn't have struct led_classdev already have a lock that
> can be used ? Can multiple calls to led ops (within the same device)
> at the same time happen at all, or does led core already serialize
> that ?

Not sure, i probably did check that in 4.19 at the time of writing.
Pavel did not complain so far. And other drivers have locks in their
setters.

> > +static void simatic_ipc_led_set_io(struct led_classdev *led_cd,
> > +  enum led_brightness brightness)
> > +

Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Mon, 15 Mar 2021 12:19:15 +0100
schrieb Pavel Machek :

> > > +   struct led_classdev cdev;
> > > +};
> > > +
> > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > +   {1 << 15, "simatic-ipc:green:" LED_FUNCTION_STATUS "-1" },
> > > +   {1 << 7,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-1"
> > > },
> > > +   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_STATUS "-2" },
> > > +   {1 << 6,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-2"
> > > },
> > > +   {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
> > > +   {1 << 5,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3"
> > > },  
> > 
> > Can you use BIT() macro here? And can it be sorted by the bit
> > order?  
> 
> There's nothing wrong with << and this order is fine.
> 
> But I still don't like the naming. simantic-ipc: prefix is
> useless. Having 6 status leds is not good, either.

With some of my questions still not being answered i will probably
remove that prefix entirely, not even use "platform:".

And i might stick with 6x "status". Since that allows reflecting the
labels on the machines, while using "above functions if you can"

regards,
Henning

> > > +   struct simatic_ipc_led *led =
> > > +   container_of(led_cd, struct simatic_ipc_led,
> > > cdev);  
> > 
> > One line?  
> 
> 80 columns. It is fine as it is.
> 
> Best regards,
> 
>   Pavel

Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Thu, 18 Mar 2021 12:38:53 +0100
schrieb "Enrico Weigelt, metux IT consult" :

> On 15.03.21 12:19, Pavel Machek wrote:
> 
> > But I still don't like the naming. simantic-ipc: prefix is
> > useless. Having 6 status leds is not good, either.  
> 
> Do we have some standard naming policy those kinds of LEDs ?

There is include/dt-bindings/leds/common.h with LED_FUNCTION_*

> In this case, they seem to be assigned to certain specific functions
> (by physical labels on the box), so IMHO the LED names should reflect
> that in some ways.

The choice for "status" was because of

>> /* Miscelleaus functions. Use functions above if you can. */

And those known names do not really come with an explanation of their
meaning. Names like "bluetooth" seem obvious, but "activity" or
"indicator" leave a lot of room for speculation.

The choice in numbers was inspired by labels on the box, which i wanted
to reflect in some way.

Henning

> There're other cases (eg. apu board familiy) that just have several
> front panel leds w/o any dedication, so we can just count them up.
> 
> 
> --mtx
> 

Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Mon, 15 Mar 2021 12:48:19 +0200
schrieb Andy Shevchenko :

> On Mon, Mar 15, 2021 at 11:57 AM Henning Schild
>  wrote:
> >
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.  
> 
> ...
> 
> > +struct simatic_ipc_led {
> > +   unsigned int value; /* mask for io and offset for mem */  
> 
> > +   char name[32];  
> 
> Hmm... Dunno if LED framework defines its own constraints for the
> length of the name.
> 
> > +   struct led_classdev cdev;
> > +};
> > +
> > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > +   {1 << 15, "simatic-ipc:green:" LED_FUNCTION_STATUS "-1" },
> > +   {1 << 7,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-1" },
> > +   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_STATUS "-2" },
> > +   {1 << 6,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-2" },
> > +   {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
> > +   {1 << 5,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3" },
> >  
> 
> Can you use BIT() macro here? And can it be sorted by the bit order?
> 
> > +   {0, ""},  
> 
> { } is enough (no comma for terminator lines in general, and no need
> to show structure member assignments separately in particular).
> 
> > +};
> > +
> > +/* the actual start will be discovered with pci, 0 is a
> > placeholder */  
> 
> PCI
> 
> > +struct resource simatic_ipc_led_mem_res =
> > +   DEFINE_RES_MEM_NAMED(0, SZ_4K, KBUILD_MODNAME);  
> 
> One line?
> 
> ...
> 
> > +static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
> > +   {0x500 + 0x1A0, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > "-1"},
> > +   {0x500 + 0x1A8, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > "-1"},
> > +   {0x500 + 0x1C8, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > "-2"},
> > +   {0x500 + 0x1D0, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > "-2"},
> > +   {0x500 + 0x1E0, "simatic-ipc:red:" LED_FUNCTION_STATUS
> > "-3"},
> > +   {0x500 + 0x198, "simatic-ipc:green:" LED_FUNCTION_STATUS
> > "-3"},
> > +   {0, ""},  
> 
> As per above.
> 
> > +};  
> 
> ...
> 
> > +   struct simatic_ipc_led *led =
> > +   container_of(led_cd, struct simatic_ipc_led, cdev);
> >  
> 
> One line?
> 
> ...
> 
> > +   struct simatic_ipc_led *led =
> > +   container_of(led_cd, struct simatic_ipc_led, cdev);
> >  
> 
> One line?
> 
> ...
> 
> > +   struct simatic_ipc_led *led =
> > +   container_of(led_cd, struct simatic_ipc_led, cdev);
> >  
> 
> Ditto.
> 
> 
> Btw, usually for such cases we create an inline helper
> ... to_simatic_ipc_led(...)
> {
>   return container_of(...);
> }
> 
> ...
> 
> > +static int simatic_ipc_leds_probe(struct platform_device *pdev)
> > +{
> > +   struct simatic_ipc_platform *plat;  
> 
> const?
> 
> > +   struct device *dev = >dev;
> > +   struct simatic_ipc_led *ipcled;
> > +   struct led_classdev *cdev;
> > +   struct resource *res;
> > +   int err, type;
> > +   u32 *p;  
> 
> > +   plat = pdev->dev.platform_data;  
> 
> Can be done directly in the definition block.
> 
> > +   switch (plat->devmode) {
> > +   case SIMATIC_IPC_DEVICE_227D:
> > +   case SIMATIC_IPC_DEVICE_427E:
> > +   res = _ipc_led_io_res;
> > +   ipcled = simatic_ipc_leds_io;
> > +   /* the 227D is high on while 427E is low on, invert
> > the struct
> > +* we have
> > +*/
> > +   if (plat->devmode == SIMATIC_IPC_DEVICE_227D) {  
> 
> > +   while (ipcled->value) {
> > +   ipcled->value =
> > swab16(ipcled->value);
> > +   ipcled++;
> > +   }  
> 
> This seems fishy. If you have a BE CPU it won't work the same way.
> Better:
>  a) to use cpu_to_le16 / be16
>  b) create this as a helper that we may move to the generic header of
> byteorder.
> 
> But looking at the use of it, per

Re: [PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

Am Thu, 18 Mar 2021 12:45:01 +0100
schrieb Hans de Goede :

> Hi,
> 
> On 3/18/21 12:30 PM, Enrico Weigelt, metux IT consult wrote:
> > On 17.03.21 21:03, Hans de Goede wrote:
> > 
> > Hi,
> >   
> >>> It just identifies the box and tells subsequent drivers which one
> >>> it is, which watchdog and LED path to take. Moving the knowledge
> >>> of which box has which LED/watchdog into the respective drivers
> >>> seems to be the better way to go.
> >>>
> >>> So we would end up with a LED and a watchdog driver both
> >>> MODULE_ALIAS("dmi:*:svnSIEMENSAG:*");  
> > 
> > Uh, isn't that a bit too broad ? This basically implies that Siemens
> > will never produce boards with different configurations.  
> 
> There is a further check done in probe() based on some Siemens
> specific DMI table entries.
> 
> >>> and doing the identification with the inline dmi from that header,
> >>> doing p2sb with the support to come ... possibly a
> >>> "//TODO\ninline" in the meantime.
> >>>
> >>> So no "main platform" driver anymore, but still central platform
> >>> headers.
> >>>
> >>> Not sure how this sounds, but i think making that change should be
> >>> possible. And that is what i will try and go for in v3.  
> >>
> >> Dropping the main drivers/platform/x86 driver sounds good to me,
> >> I was already wondering a bit about its function since it just
> >> instantiates devs to which the other ones bind to then instantiate
> >> more devs (in the LED case).  
> > 
> > hmm, IMHO that depends on whether the individual sub-devices can be
> > more generic than just that specific machine. (@Hanning: could you
> > tell us more about that ?).
> > 
> > Another question is how they're actually probed .. only dmi or maybe
> > also pci dev ? (i've seen some refs to pci stuff in the led driver,
> > but missed the other code thats called here).
> > 
> > IMHO, if the whole thing lives on some PCI device (which can be
> > probed via pci ID), and that device has the knowledge, where the
> > LED registers actually are (eg. based on device ID, pci mmio
> > mapping, ...) then there should be some parent driver that
> > instantiates the led devices (and possibly other board specific
> > stuff). That would be a clear separation, modularization. In that
> > case, maybe this LED driver could even be replaced by some really
> > generic "register-based-LED" driver, which just needs to be fed
> > with some parameters like register ranges, bitmasks, etc.
> > 
> > OTOH, if everything can be derived entirely from DMI match, w/o
> > things like pci mappings involved (IOW: behaves like directly wired
> > to the cpu's mem/io bus, no other "intelligent" bus involved), and
> > it's all really board specific logic (no generic led or gpio
> > controllers involved), then it might be better to have entirely
> > separate drivers.  

In fact it does dmi and not "common" but unfortunately vendor-specific.
On top it does pci, so it might be fair to call it "intelligent" and
keep it.

> FWIW I'm fine with either solution, and if we go the "parent driver"
> route I'm happy to have that driver sit in drivers/platform/x86
> (once all the discussions surrounding this are resolved).
> 
> My reply was because I noticed that the Led driver seemed to sort of
> also act as a parent driver (last time I looked) and instantiated
> a bunch of stuff, so then we have 2 parent(ish) drivers. If things
> stay that way then having 2 levels of parent drivers seems a bit too
> much to me, esp. if it can all be done cleanly in e.g. the LED driver.

One "leds" driver doing multiple leds seems to be a common pattern. So
that "1 parent N children" maybe does not count as parentish.

> But as said I'm fine either way as long as the code is reasonably
> clean and dealing with this sort of platform specific warts happens
> a lot in drivers/platform/x86 .

I thought about it again and also prefer the "parent driver" idea as it
is. That parent identifies the machine and depending on it, causes
device drivers to be loaded. At the moment LED and watchdog, but with
nvram, hwmon to come.

I will stick with "platform" instead of "mfd" because it is really a
machine having multiple devices. Not a device having multiple functions.

regards,
Henning

> Regards,
> 
> Hans
> 

Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Thu, 18 Mar 2021 13:40:58 +0100
schrieb Alexander Dahl :

> Hei hei,
> 
> > Enrico Weigelt, metux IT consult  hat am 18.03.2021
> > 11:27 geschrieben:
> > 
> >  
> > On 15.03.21 11:48, Andy Shevchenko wrote:
> > 
> > Hi,
> >   
> > > I have a question, why we can't provide a GPIO driver which is
> > > already in the kernel and, with use of the patch series I sent,
> > > to convert this all magic to GPIO LEDs as it's done for all
> > > normal cases?  
> > 
> > Do we alread have a generic led driver that for cases that just
> > set/clear bits in some mem/io location ? If not, that would be
> > really great to have.  
> 
> Yes, there is. Look out for compatible "register-bit-led" in device
> tree. That's from driver in drivers/leds/leds-syscon.c and you can
> use it inside a syscon node in dts.
> 
> It assumes one bit per LED.

Sorry guys, i am lost here. Is there a driver i can base mine on, if so
which one? Maybe you can point me to a good example that is
conceptually similar.

As i already wrote in the reviews of v1, the ACPI tables will not
change on the machines in question. So there is a need for a driver.
Either one like i did propose or maybe something that patches ACPI or
loads device-tree snippets, again please point me to good examples.

We are talking about x86-only here.

Henning 

> Greets
> Alex

Re: [PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

Am Mon, 15 Mar 2021 12:31:11 +0200
schrieb Andy Shevchenko :

> On Mon, Mar 15, 2021 at 12:02 PM Henning Schild
>  wrote:
> >
> > This mainly implements detection of these devices and will allow
> > secondary drivers to work on such machines.
> >
> > The identification is DMI-based with a vendor specific way to tell
> > them apart in a reliable way.
> >
> > Drivers for LEDs and Watchdogs will follow to make use of that
> > platform detection.  
> 
> ...
> 
> > +static int register_platform_devices(u32 station_id)
> > +{
> > +   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
> > +   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;
> > +   int i;
> > +
> > +   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
> > +   if (device_modes[i].station_id == station_id) {
> > +   ledmode = device_modes[i].led_mode;
> > +   wdtmode = device_modes[i].wdt_mode;
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
> > +   platform_data.devmode = ledmode;
> > +   ipc_led_platform_device =
> > +   platform_device_register_data(NULL,
> > +   KBUILD_MODNAME "_leds",
> > PLATFORM_DEVID_NONE,
> > +   _data,
> > +   sizeof(struct
> > simatic_ipc_platform));
> > +   if (IS_ERR(ipc_led_platform_device))
> > +   return PTR_ERR(ipc_led_platform_device);
> > +
> > +   pr_debug("device=%s created\n",
> > +ipc_led_platform_device->name);
> > +   }
> > +
> > +   if (wdtmode != SIMATIC_IPC_DEVICE_NONE) {
> > +   platform_data.devmode = wdtmode;
> > +   ipc_wdt_platform_device =
> > +   platform_device_register_data(NULL,
> > +   KBUILD_MODNAME "_wdt",
> > PLATFORM_DEVID_NONE,
> > +   _data,
> > +   sizeof(struct
> > simatic_ipc_platform));
> > +   if (IS_ERR(ipc_wdt_platform_device))
> > +   return PTR_ERR(ipc_wdt_platform_device);
> > +
> > +   pr_debug("device=%s created\n",
> > +ipc_wdt_platform_device->name);
> > +   }
> > +
> > +   if (ledmode == SIMATIC_IPC_DEVICE_NONE &&
> > +   wdtmode == SIMATIC_IPC_DEVICE_NONE) {
> > +   pr_warn("unsupported IPC detected, station
> > id=%08x\n",
> > +   station_id);
> > +   return -EINVAL;
> > +   }
> > +
> > +   return 0;
> > +}  
> 
> Why not use MFD here?

Never had a close look at mfd to be honest. I might

With the custom dmi matching on 129 being part of the header, and the
p2sb unhide moving out as well ... that first driver ends up being not
too valuable indeed

It just identifies the box and tells subsequent drivers which one it
is, which watchdog and LED path to take. Moving the knowledge of which
box has which LED/watchdog into the respective drivers seems to be the
better way to go.

So we would end up with a LED and a watchdog driver both
MODULE_ALIAS("dmi:*:svnSIEMENSAG:*");
and doing the identification with the inline dmi from that header,
doing p2sb with the support to come ... possibly a "//TODO\ninline" in
the meantime.

So no "main platform" driver anymore, but still central platform
headers.

Not sure how this sounds, but i think making that change should be
possible. And that is what i will try and go for in v3.

regards,
Henning

> ...
> 
> > +/*
> > + * Get membase address from PCI, used in leds and wdt modul. Here
> > we read
> > + * the bar0. The final address calculation is done in the
> > appropriate modules
> > + */  
> 
> No blank line here.
> 
> I would add FIXME or REVISIT here to point out that this should be
> deduplicated in the future.
> 
> > +u32 simatic_ipc_get_membase0(unsigned int p2sb)
> > +{
> > +   struct pci_bus *bus;
> > +   u32 bar0 = 0;
> > +
> > +   /*
> > +* The GPIO memory is bar0 of the hidden P2SB device.
> > Unhide the device  
> 
> No, it's not a GPIO's bar. It's P2SB's one. GPIO resides in that bar
> somewhere.
> 
> > +   

Re: [PATCH v3 1/1] rtc: rx6110: add ACPI bindings to I2C

[Henning Schild]

Am Tue, 16 Mar 2021 13:30:36 +0200
schrieb Andy Shevchenko :

> On Tue, Mar 16, 2021 at 11:08:05AM +0100, Claudius Heine wrote:
> > From: Johannes Hahn 
> > 
> > This allows the RX6110 driver to be automatically assigned to the
> > right device on the I2C bus.  
> 
> Thanks for all effort!
> Reviewed-by: Andy Shevchenko 
> after addressing the below comments.
> 
> > Signed-off-by: Johannes Hahn 
> > Signed-off-by: Claudius Heine   
> 
> > Signed-off-by: Henning Schild   

Claudius, just remove that. I guess just add yours and mention authors
in the code if they should receive some recognition.

Henning

> I think this is somehow confusing. Either you need to add
> Co-developed-by of the corresponding people, or remove SoB (because
> of From line), i.o.w seems like Co-dB tag is needed for Johannes or
> you and something should be done with Henning's SoB.
> 
> > ---
> >  drivers/rtc/rtc-rx6110.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/rtc/rtc-rx6110.c b/drivers/rtc/rtc-rx6110.c
> > index 79161d4c6ce4..29bd697f82cb 100644
> > --- a/drivers/rtc/rtc-rx6110.c
> > +++ b/drivers/rtc/rtc-rx6110.c
> > @@ -13,6 +13,7 @@
> >  #include 
> >  #include 
> >  #include   
> 
> > +#include   
> 
> Usually it's not needed if you leave IDs always to be compiled.
> Instead mod_devicetable.h is used. But it's all up to you and
> maintainer.
> 
> >  #include 
> >  #include 
> >  #include 
> > @@ -447,6 +448,14 @@ static int rx6110_i2c_probe(struct i2c_client
> > *client, return rx6110_probe(rx6110, >dev);
> >  }
> >  
> > +#ifdef CONFIG_ACPI
> > +static const struct acpi_device_id rx6110_i2c_acpi_match[] = {
> > +   { "SECC6110", },
> > +   { },
> > +};
> > +MODULE_DEVICE_TABLE(acpi, rx6110_i2c_acpi_match);
> > +#endif
> > +
> >  static const struct i2c_device_id rx6110_i2c_id[] = {
> > { "rx6110", 0 },
> > { }
> > @@ -456,6 +465,9 @@ MODULE_DEVICE_TABLE(i2c, rx6110_i2c_id);
> >  static struct i2c_driver rx6110_i2c_driver = {
> > .driver = {
> > .name = RX6110_DRIVER_NAME,
> > +#ifdef CONFIG_ACPI  
> 
> This is implied by the stub ACPI_PTR() macro for ACPI=n case.
> I.o.w drop this ugly and redundant ifdeffery.
> 
> > +   .acpi_match_table =
> > ACPI_PTR(rx6110_i2c_acpi_match), +#endif
> > },
> > .probe  = rx6110_i2c_probe,
> > .id_table   = rx6110_i2c_id,
> > -- 
> > 2.30.1
> >   
> 

Re: [PATCH] platform/x86: pmc_atom: use callback for all dmi quirk entries

[Henning Schild]

Hoi Hans,

on a slighly different but also related topic. Did you ever come across
SMSC SCH5347? Seems to be pretty similar to 56xx, only with spec non
public ... and probably less often in use
Maybe you happen to have code, or know the differences. We already have
it working with a modified copy of sch56xx but that is still rough and
i thought i ask before we potentially duplicate work.

groetjes,
Henning

Am Mon, 15 Mar 2021 19:01:13 +0100
schrieb Hans de Goede :

> Hi,
> 
> On 3/15/21 6:00 PM, Henning Schild wrote:
> > Am Mon, 15 Mar 2021 17:31:49 +0100
> > schrieb Hans de Goede :
> >   
> >> Hi,
> >>
> >> On 3/15/21 3:58 PM, Henning Schild wrote:  
> >>> Introduce a global variable to remember the matching entry for
> >>> later printing. Also having a callback allows to stop matching
> >>> after the first hit.
> >>>
> >>> Signed-off-by: Henning Schild 
> >>> ---
> >>>  drivers/platform/x86/pmc_atom.c | 26 --
> >>>  1 file changed, 20 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/platform/x86/pmc_atom.c
> >>> b/drivers/platform/x86/pmc_atom.c index 38542d547f29..d0f74856cd8b
> >>> 100644 --- a/drivers/platform/x86/pmc_atom.c
> >>> +++ b/drivers/platform/x86/pmc_atom.c
> >>> @@ -364,8 +364,16 @@ static void pmc_dbgfs_register(struct pmc_dev
> >>> *pmc) #endif /* CONFIG_DEBUG_FS */
> >>>  
> >>>  static bool pmc_clk_is_critical = true;
> >>> +static const struct dmi_system_id *dmi_critical;
> >>>  
> >>> -static int siemens_clk_is_critical(const struct dmi_system_id *d)
> >>> +static int dmi_callback(const struct dmi_system_id *d)
> >>> +{
> >>> + dmi_critical = d;
> >>
> >> Don't introduce a global variable for this please. Instead just
> >> directly print the ident of the matching dmi_system_id here.  
> > 
> > Sorry, missed that part. Result looks nice and clean, thanks. I
> > think i will squash it into 4/4 in v3 and not follow up here for
> > now.  
> 
> Ack, that sounds good to me.
> 
> Regards,
> 
> Hans
> 
> 
> >>> +
> >>> + return 1;
> >>> +}
> >>> +
> >>> +static int dmi_callback_siemens(const struct dmi_system_id *d)
> >>>  {
> >>>   u32 st_id;
> >>>  
> >>> @@ -373,7 +381,7 @@ static int siemens_clk_is_critical(const
> >>> struct dmi_system_id *d) goto out;
> >>>  
> >>>   if (st_id == SIMATIC_IPC_IPC227E || st_id ==
> >>> SIMATIC_IPC_IPC277E)
> >>> - return 1;
> >>> + return dmi_callback(d);
> >>>  
> >>>  out:
> >>>   pmc_clk_is_critical = false;
> >>> @@ -388,6 +396,7 @@ static const struct dmi_system_id
> >>> critclk_systems[] = { {
> >>>   /* pmc_plt_clk0 is used for an external HSIC USB
> >>> HUB */ .ident = "MPL CEC1x",
> >>> + .callback = dmi_callback,
> >>>   .matches = {
> >>>   DMI_MATCH(DMI_SYS_VENDOR, "MPL AG"),
> >>>   DMI_MATCH(DMI_PRODUCT_NAME, "CEC10
> >>> Family"), @@ -396,6 +405,7 @@ static const struct dmi_system_id
> >>> critclk_systems[] = { {
> >>>   /* pmc_plt_clk0 - 3 are used for the 4 ethernet
> >>> controllers */ .ident = "Lex 3I380D",
> >>> + .callback = dmi_callback,
> >>>   .matches = {
> >>>   DMI_MATCH(DMI_SYS_VENDOR, "Lex
> >>> BayTrail"), DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"),
> >>> @@ -404,6 +414,7 @@ static const struct dmi_system_id
> >>> critclk_systems[] = { {
> >>>   /* pmc_plt_clk* - are used for ethernet
> >>> controllers */ .ident = "Lex 2I385SW",
> >>> + .callback = dmi_callback,
> >>>   .matches = {
> >>>   DMI_MATCH(DMI_SYS_VENDOR, "Lex
> >>> BayTrail"), DMI_MATCH(DMI_PRODUCT_NAME, "2I385SW"),
> >>> @@ -412,6 +423,7 @@ static const struct dmi_system_id
> >>> critclk_systems[] = { {
> >>>   /* pmc_plt_clk* - are used for ethernet
> >>> controllers */ .ident = "Beckhoff CB3163",
> >>> + .callback = dmi_callback,
> >>>   .matches = {
> >>>   DMI

Re: [PATCH] platform/x86: pmc_atom: use callback for all dmi quirk entries

[Henning Schild]

Am Mon, 15 Mar 2021 17:31:49 +0100
schrieb Hans de Goede :

> Hi,
> 
> On 3/15/21 3:58 PM, Henning Schild wrote:
> > Introduce a global variable to remember the matching entry for later
> > printing. Also having a callback allows to stop matching after the
> > first hit.
> > 
> > Signed-off-by: Henning Schild 
> > ---
> >  drivers/platform/x86/pmc_atom.c | 26 --
> >  1 file changed, 20 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/pmc_atom.c
> > b/drivers/platform/x86/pmc_atom.c index 38542d547f29..d0f74856cd8b
> > 100644 --- a/drivers/platform/x86/pmc_atom.c
> > +++ b/drivers/platform/x86/pmc_atom.c
> > @@ -364,8 +364,16 @@ static void pmc_dbgfs_register(struct pmc_dev
> > *pmc) #endif /* CONFIG_DEBUG_FS */
> >  
> >  static bool pmc_clk_is_critical = true;
> > +static const struct dmi_system_id *dmi_critical;
> >  
> > -static int siemens_clk_is_critical(const struct dmi_system_id *d)
> > +static int dmi_callback(const struct dmi_system_id *d)
> > +{
> > +   dmi_critical = d;  
> 
> Don't introduce a global variable for this please. Instead just
> directly print the ident of the matching dmi_system_id here.

Sorry, missed that part. Result looks nice and clean, thanks. I think i
will squash it into 4/4 in v3 and not follow up here for now.

Henning

> Regards,
> 
> Hans
> 
> 
> > +
> > +   return 1;
> > +}
> > +
> > +static int dmi_callback_siemens(const struct dmi_system_id *d)
> >  {
> > u32 st_id;
> >  
> > @@ -373,7 +381,7 @@ static int siemens_clk_is_critical(const struct
> > dmi_system_id *d) goto out;
> >  
> > if (st_id == SIMATIC_IPC_IPC227E || st_id ==
> > SIMATIC_IPC_IPC277E)
> > -   return 1;
> > +   return dmi_callback(d);
> >  
> >  out:
> > pmc_clk_is_critical = false;
> > @@ -388,6 +396,7 @@ static const struct dmi_system_id
> > critclk_systems[] = { {
> > /* pmc_plt_clk0 is used for an external HSIC USB
> > HUB */ .ident = "MPL CEC1x",
> > +   .callback = dmi_callback,
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "MPL AG"),
> > DMI_MATCH(DMI_PRODUCT_NAME, "CEC10
> > Family"), @@ -396,6 +405,7 @@ static const struct dmi_system_id
> > critclk_systems[] = { {
> > /* pmc_plt_clk0 - 3 are used for the 4 ethernet
> > controllers */ .ident = "Lex 3I380D",
> > +   .callback = dmi_callback,
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
> > DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"),
> > @@ -404,6 +414,7 @@ static const struct dmi_system_id
> > critclk_systems[] = { {
> > /* pmc_plt_clk* - are used for ethernet
> > controllers */ .ident = "Lex 2I385SW",
> > +   .callback = dmi_callback,
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
> > DMI_MATCH(DMI_PRODUCT_NAME, "2I385SW"),
> > @@ -412,6 +423,7 @@ static const struct dmi_system_id
> > critclk_systems[] = { {
> > /* pmc_plt_clk* - are used for ethernet
> > controllers */ .ident = "Beckhoff CB3163",
> > +   .callback = dmi_callback,
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff
> > Automation"), DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
> > @@ -420,6 +432,7 @@ static const struct dmi_system_id
> > critclk_systems[] = { {
> > /* pmc_plt_clk* - are used for ethernet
> > controllers */ .ident = "Beckhoff CB4063",
> > +   .callback = dmi_callback,
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff
> > Automation"), DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
> > @@ -428,6 +441,7 @@ static const struct dmi_system_id
> > critclk_systems[] = { {
> > /* pmc_plt_clk* - are used for ethernet
> > controllers */ .ident = "Beckhoff CB6263",
> > +   .callback = dmi_callback,
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff
> > Automation"), DMI_MATCH(DMI_BOARD_NAME, "CB6263"),
> > @@ -436,13 +450,14 @@ static const struct dmi_system_id
> > critclk_systems[] = { {
> > /* pmc_plt_clk* - are used for ethernet
> 

Re: [PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

Am Mon, 15 Mar 2021 12:31:11 +0200
schrieb Andy Shevchenko :

> On Mon, Mar 15, 2021 at 12:02 PM Henning Schild
>  wrote:
> >
> > This mainly implements detection of these devices and will allow
> > secondary drivers to work on such machines.
> >
> > The identification is DMI-based with a vendor specific way to tell
> > them apart in a reliable way.
> >
> > Drivers for LEDs and Watchdogs will follow to make use of that
> > platform detection.  
> 
> ...
> 
> > +static int register_platform_devices(u32 station_id)
> > +{
> > +   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
> > +   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;
> > +   int i;
> > +
> > +   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
> > +   if (device_modes[i].station_id == station_id) {
> > +   ledmode = device_modes[i].led_mode;
> > +   wdtmode = device_modes[i].wdt_mode;
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
> > +   platform_data.devmode = ledmode;
> > +   ipc_led_platform_device =
> > +   platform_device_register_data(NULL,
> > +   KBUILD_MODNAME "_leds",
> > PLATFORM_DEVID_NONE,
> > +   _data,
> > +   sizeof(struct
> > simatic_ipc_platform));
> > +   if (IS_ERR(ipc_led_platform_device))
> > +   return PTR_ERR(ipc_led_platform_device);
> > +
> > +   pr_debug("device=%s created\n",
> > +ipc_led_platform_device->name);
> > +   }
> > +
> > +   if (wdtmode != SIMATIC_IPC_DEVICE_NONE) {
> > +   platform_data.devmode = wdtmode;
> > +   ipc_wdt_platform_device =
> > +   platform_device_register_data(NULL,
> > +   KBUILD_MODNAME "_wdt",
> > PLATFORM_DEVID_NONE,
> > +   _data,
> > +   sizeof(struct
> > simatic_ipc_platform));
> > +   if (IS_ERR(ipc_wdt_platform_device))
> > +   return PTR_ERR(ipc_wdt_platform_device);
> > +
> > +   pr_debug("device=%s created\n",
> > +ipc_wdt_platform_device->name);
> > +   }
> > +
> > +   if (ledmode == SIMATIC_IPC_DEVICE_NONE &&
> > +   wdtmode == SIMATIC_IPC_DEVICE_NONE) {
> > +   pr_warn("unsupported IPC detected, station
> > id=%08x\n",
> > +   station_id);
> > +   return -EINVAL;
> > +   }
> > +
> > +   return 0;
> > +}  
> 
> Why not use MFD here?
> 
> ...
> 
> > +/*
> > + * Get membase address from PCI, used in leds and wdt modul. Here
> > we read
> > + * the bar0. The final address calculation is done in the
> > appropriate modules
> > + */  
> 
> No blank line here.
> 
> I would add FIXME or REVISIT here to point out that this should be
> deduplicated in the future.

Sure i forgot the mention that ordering problem of the two series here
again specifically. Was kind of assuming yours would maybe be first and
that code not being reviewed again ... 
The code is there to test and propose something "working" not something
i expect to be merged as is.

regards,
Henning

> > +u32 simatic_ipc_get_membase0(unsigned int p2sb)
> > +{
> > +   struct pci_bus *bus;
> > +   u32 bar0 = 0;
> > +
> > +   /*
> > +* The GPIO memory is bar0 of the hidden P2SB device.
> > Unhide the device  
> 
> No, it's not a GPIO's bar. It's P2SB's one. GPIO resides in that bar
> somewhere.
> 
> > +* to have a quick look at it, before we hide it again.
> > +* Also grab the pci rescan lock so that device does not
> > get discovered
> > +* and remapped while it is visible.
> > +* This code is inspired by drivers/mfd/lpc_ich.c
> > +*/
> > +   bus = pci_find_bus(0, 0);
> > +   pci_lock_rescan_remove();
> > +   pci_bus_write_config_byte(bus, p2sb, 0xE1, 0x0);
> > +   pci_bus_read_config_dword(bus, p2sb, PCI_BASE_ADDRESS_0,
> > ); +
> > +   bar0 &= ~0xf;
> > +   pci_bus_write_config_byte(bus, p2sb, 0

Re: [PATCH v2 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

Am Mon, 15 Mar 2021 12:55:13 +0200
schrieb Andy Shevchenko :

> On Mon, Mar 15, 2021 at 12:12 PM Henning Schild
>  wrote:
> >
> > changes since v1:
> >
> > - fixed lots of style issues found in v1
> >   - (debug) printing
> >   - header ordering
> > - fixed license issues GPLv2 and SPDX in all files
> > - module_platform_driver instead of __init __exit
> > - wdt simplifications cleanup
> > - lots of fixes in wdt driver, all that was found in v1
> > - fixed dmi length in dmi helper
> > - changed LED names to allowed ones
> > - move led driver to simple/
> > - switched pmc_atom to dmi callback with global variable
> >
> > --
> >
> > This series adds support for watchdogs and leds of several x86
> > devices from Siemens.
> >
> > It is structured with a platform driver that mainly does
> > identification of the machines. It might trigger loading of the
> > actual device drivers by attaching devices to the platform bus.
> >
> > The identification is vendor specific, parsing a special binary DMI
> > entry. The implementation of that platform identification is
> > applied on pmc_atom clock quirks in the final patch.
> >
> > It is all structured in a way that we can easily add more devices
> > and more platform drivers later. Internally we have some more code
> > for hardware monitoring, more leds, watchdogs etc. This will follow
> > some day.  
> 
> Thanks for an update!
> 
> I did review more thoughtfully the series and realized that you can
> avoid that P2SB thingy and may the approach be much cleaner if you
> register the real GPIO driver and convert your LEDs to be a GPIO LEDs.
> Then you won't need any custom code for it (except some board file, or
> what would be better to file _DSD in your ACPI tables.

Thanks Andy. I will need to read through your comments and existing
code. Are you saying there already is a GPIO driver that i should
rather hook into ... given there is and will not be WDAT any time soon?
Can you please point it out to me, the driver and maybe an example.

If you are suggesting to write a generic GPIO driver, i would probably
say that this can hopefully wait until we have a second user and need
that level of abstraction.

regards,
Henning

> --
> With Best Regards,
> Andy Shevchenko

[PATCH] platform/x86: pmc_atom: use callback for all dmi quirk entries

[Henning Schild]

Introduce a global variable to remember the matching entry for later
printing. Also having a callback allows to stop matching after the first
hit.

Signed-off-by: Henning Schild 
---
 drivers/platform/x86/pmc_atom.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
index 38542d547f29..d0f74856cd8b 100644
--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -364,8 +364,16 @@ static void pmc_dbgfs_register(struct pmc_dev *pmc)
 #endif /* CONFIG_DEBUG_FS */
 
 static bool pmc_clk_is_critical = true;
+static const struct dmi_system_id *dmi_critical;
 
-static int siemens_clk_is_critical(const struct dmi_system_id *d)
+static int dmi_callback(const struct dmi_system_id *d)
+{
+   dmi_critical = d;
+
+   return 1;
+}
+
+static int dmi_callback_siemens(const struct dmi_system_id *d)
 {
u32 st_id;
 
@@ -373,7 +381,7 @@ static int siemens_clk_is_critical(const struct 
dmi_system_id *d)
goto out;
 
if (st_id == SIMATIC_IPC_IPC227E || st_id == SIMATIC_IPC_IPC277E)
-   return 1;
+   return dmi_callback(d);
 
 out:
pmc_clk_is_critical = false;
@@ -388,6 +396,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk0 is used for an external HSIC USB HUB */
.ident = "MPL CEC1x",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "MPL AG"),
DMI_MATCH(DMI_PRODUCT_NAME, "CEC10 Family"),
@@ -396,6 +405,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk0 - 3 are used for the 4 ethernet controllers */
.ident = "Lex 3I380D",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"),
@@ -404,6 +414,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Lex 2I385SW",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Lex BayTrail"),
DMI_MATCH(DMI_PRODUCT_NAME, "2I385SW"),
@@ -412,6 +423,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB3163",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
@@ -420,6 +432,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB4063",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
@@ -428,6 +441,7 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB6263",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB6263"),
@@ -436,13 +450,14 @@ static const struct dmi_system_id critclk_systems[] = {
{
/* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB6363",
+   .callback = dmi_callback,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_BOARD_NAME, "CB6363"),
},
},
{
-   .callback = siemens_clk_is_critical,
+   .callback = dmi_callback_siemens,
.ident = "SIEMENS AG",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
@@ -457,7 +472,6 @@ static int pmc_setup_clks(struct pci_dev *pdev, void 
__iomem *pmc_regmap,
 {
struct platform_device *clkdev;
struct pmc_clk_data *clk_data;
-   const struct dmi_system_id *d;
 
clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
if (!clk_data)
@@ -468,8 +482,8 @@ static int pmc_setup_clks(struct pci_dev *pdev, void 

Re: [PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Mon, 15 Mar 2021 12:19:15 +0100
schrieb Pavel Machek :

> > > +   struct led_classdev cdev;
> > > +};
> > > +
> > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > +   {1 << 15, "simatic-ipc:green:" LED_FUNCTION_STATUS "-1" },
> > > +   {1 << 7,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-1"
> > > },
> > > +   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_STATUS "-2" },
> > > +   {1 << 6,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-2"
> > > },
> > > +   {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
> > > +   {1 << 5,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3"
> > > },  
> > 
> > Can you use BIT() macro here? And can it be sorted by the bit
> > order?  
> 
> There's nothing wrong with << and this order is fine.
> 
> But I still don't like the naming. simantic-ipc: prefix is
> useless. Having 6 status leds is not good, either.

You asked about a picture before, so here is one example

https://support.industry.siemens.com/cs/document/67235073/simatic-ipc427d?dti=0=16756=en-WW

page 19 shows how the box looks like
page 135 it what the implementation is based on

Externally human visible are 3 "lights", which can be off, red, green,
yellow. Internally every single "light" has two leds and yellow is a
mix when red and green are on.
Unfortunately hw does not allow all 4 states for all 3 lights. Some
boxes implement "yellow" mixing in hw.

That is why the same name is used with two colors.

maybe those LEDs qualify for multi-color? 

"status" was the best name i found in the dt-bindings header

i guess i can be creative with the names and take ie "status", "fault",
and "indicator"

i will also drop that prefix "simatic-ipc" that was inspired by
"tpacpi", or should it be "platform::"?

regards,
Henning

> > > +   struct simatic_ipc_led *led =
> > > +   container_of(led_cd, struct simatic_ipc_led,
> > > cdev);  
> > 
> > One line?  
> 
> 80 columns. It is fine as it is.
> 
> Best regards,
> 
>   Pavel

Re: [PATCH v2 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs

[Henning Schild]

Am Mon, 15 Mar 2021 11:19:24 +0100
schrieb Hans de Goede :

> Hi,
> 
> On 3/15/21 11:14 AM, Henning Schild wrote:
> > Am Mon, 15 Mar 2021 10:57:10 +0100
> > schrieb Henning Schild :
> >   
> >> Siemens industrial PCs unfortunately can not always be properly
> >> identified the way we used to. An earlier commit introduced code
> >> that allows proper identification without looking at DMI strings
> >> that could differ based on product branding.
> >> Switch over to that proper way and revert commits that used to
> >> collect the machines based on unstable strings.
> >>
> >> Fixes: 648e921888ad ("clk: x86: Stop marking clocks as
> >> CLK_IS_CRITICAL") Fixes: e8796c6c69d1 ("platform/x86: pmc_atom: Add
> >> Siemens CONNECT ...") Fixes: f110d252ae79 ("platform/x86: pmc_atom:
> >> Add Siemens SIMATIC ...") Fixes: ad0d315b4d4e ("platform/x86:
> >> pmc_atom: Add Siemens SIMATIC ...") Tested-by: Michael Haener
> >>  Signed-off-by: Henning Schild
> >>  ---
> >>  drivers/platform/x86/pmc_atom.c | 47
> >> +++-- 1 file changed, 27 insertions(+),
> >> 20 deletions(-)
> >>
> >> diff --git a/drivers/platform/x86/pmc_atom.c
> >> b/drivers/platform/x86/pmc_atom.c index ca684ed760d1..38542d547f29
> >> 100644 --- a/drivers/platform/x86/pmc_atom.c
> >> +++ b/drivers/platform/x86/pmc_atom.c
> >> @@ -13,6 +13,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -362,6 +363,23 @@ static void pmc_dbgfs_register(struct pmc_dev
> >> *pmc) }
> >>  #endif /* CONFIG_DEBUG_FS */
> >>  
> >> +static bool pmc_clk_is_critical = true;
> >> +
> >> +static int siemens_clk_is_critical(const struct dmi_system_id *d)
> >> +{
> >> +  u32 st_id;
> >> +
> >> +  if (dmi_walk(simatic_ipc_find_dmi_entry_helper, _id))
> >> +  goto out;
> >> +
> >> +  if (st_id == SIMATIC_IPC_IPC227E || st_id ==
> >> SIMATIC_IPC_IPC277E)
> >> +  return 1;
> >> +
> >> +out:
> >> +  pmc_clk_is_critical = false;
> >> +  return 1;
> >> +}
> >> +
> >>  /*
> >>   * Some systems need one or more of their pmc_plt_clks to be
> >>   * marked as critical.
> >> @@ -424,24 +442,10 @@ static const struct dmi_system_id
> >> critclk_systems[] = { },
> >>},
> >>{
> >> -  .ident = "SIMATIC IPC227E",
> >> -  .matches = {
> >> -  DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
> >> -  DMI_MATCH(DMI_PRODUCT_VERSION,
> >> "6ES7647-8B"),
> >> -  },
> >> -  },
> >> -  {
> >> -  .ident = "SIMATIC IPC277E",
> >> -  .matches = {
> >> -  DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
> >> -  DMI_MATCH(DMI_PRODUCT_VERSION,
> >> "6AV7882-0"),
> >> -  },
> >> -  },
> >> -  {
> >> -  .ident = "CONNECT X300",
> >> +  .callback = siemens_clk_is_critical,
> >> +  .ident = "SIEMENS AG",
> >>.matches = {
> >>DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
> >> -  DMI_MATCH(DMI_PRODUCT_VERSION,
> >> "A5E45074588"), },
> >>},
> >>  
> >> @@ -453,7 +457,7 @@ static int pmc_setup_clks(struct pci_dev *pdev,
> >> void __iomem *pmc_regmap, {
> >>struct platform_device *clkdev;
> >>struct pmc_clk_data *clk_data;
> >> -  const struct dmi_system_id *d =
> >> dmi_first_match(critclk_systems);
> >> +  const struct dmi_system_id *d;
> >>  
> >>clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
> >>if (!clk_data)
> >> @@ -461,9 +465,12 @@ static int pmc_setup_clks(struct pci_dev
> >> *pdev, void __iomem *pmc_regmap, 
> >>clk_data->base = pmc_regmap; /* offset is added by client
> >> */ clk_data->clks = pmc_data->clks;
> >> -  if (d) {
> >> -  clk_data->critical = true;
> >> -  pr_info("%s critclks quirk enabled\n", d->ident);
> >> +  if (dmi_check_system(critclk_systems)) {  
> > 
> > Had to switch

Re: [PATCH v2 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs

[Henning Schild]

Am Mon, 15 Mar 2021 10:57:10 +0100
schrieb Henning Schild :

> Siemens industrial PCs unfortunately can not always be properly
> identified the way we used to. An earlier commit introduced code that
> allows proper identification without looking at DMI strings that could
> differ based on product branding.
> Switch over to that proper way and revert commits that used to collect
> the machines based on unstable strings.
> 
> Fixes: 648e921888ad ("clk: x86: Stop marking clocks as
> CLK_IS_CRITICAL") Fixes: e8796c6c69d1 ("platform/x86: pmc_atom: Add
> Siemens CONNECT ...") Fixes: f110d252ae79 ("platform/x86: pmc_atom:
> Add Siemens SIMATIC ...") Fixes: ad0d315b4d4e ("platform/x86:
> pmc_atom: Add Siemens SIMATIC ...") Tested-by: Michael Haener
>  Signed-off-by: Henning Schild
>  ---
>  drivers/platform/x86/pmc_atom.c | 47
> +++-- 1 file changed, 27 insertions(+),
> 20 deletions(-)
> 
> diff --git a/drivers/platform/x86/pmc_atom.c
> b/drivers/platform/x86/pmc_atom.c index ca684ed760d1..38542d547f29
> 100644 --- a/drivers/platform/x86/pmc_atom.c
> +++ b/drivers/platform/x86/pmc_atom.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -362,6 +363,23 @@ static void pmc_dbgfs_register(struct pmc_dev
> *pmc) }
>  #endif /* CONFIG_DEBUG_FS */
>  
> +static bool pmc_clk_is_critical = true;
> +
> +static int siemens_clk_is_critical(const struct dmi_system_id *d)
> +{
> + u32 st_id;
> +
> + if (dmi_walk(simatic_ipc_find_dmi_entry_helper, _id))
> + goto out;
> +
> + if (st_id == SIMATIC_IPC_IPC227E || st_id ==
> SIMATIC_IPC_IPC277E)
> + return 1;
> +
> +out:
> + pmc_clk_is_critical = false;
> + return 1;
> +}
> +
>  /*
>   * Some systems need one or more of their pmc_plt_clks to be
>   * marked as critical.
> @@ -424,24 +442,10 @@ static const struct dmi_system_id
> critclk_systems[] = { },
>   },
>   {
> - .ident = "SIMATIC IPC227E",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
> - DMI_MATCH(DMI_PRODUCT_VERSION, "6ES7647-8B"),
> - },
> - },
> - {
> - .ident = "SIMATIC IPC277E",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
> - DMI_MATCH(DMI_PRODUCT_VERSION, "6AV7882-0"),
> - },
> - },
> - {
> - .ident = "CONNECT X300",
> + .callback = siemens_clk_is_critical,
> + .ident = "SIEMENS AG",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
> - DMI_MATCH(DMI_PRODUCT_VERSION,
> "A5E45074588"), },
>   },
>  
> @@ -453,7 +457,7 @@ static int pmc_setup_clks(struct pci_dev *pdev,
> void __iomem *pmc_regmap, {
>   struct platform_device *clkdev;
>   struct pmc_clk_data *clk_data;
> - const struct dmi_system_id *d =
> dmi_first_match(critclk_systems);
> + const struct dmi_system_id *d;
>  
>   clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
>   if (!clk_data)
> @@ -461,9 +465,12 @@ static int pmc_setup_clks(struct pci_dev *pdev,
> void __iomem *pmc_regmap, 
>   clk_data->base = pmc_regmap; /* offset is added by client */
>   clk_data->clks = pmc_data->clks;
> - if (d) {
> - clk_data->critical = true;
> - pr_info("%s critclks quirk enabled\n", d->ident);
> + if (dmi_check_system(critclk_systems)) {

Had to switch to check_system to get the callback to work.

> + clk_data->critical = pmc_clk_is_critical;
> + if (clk_data->critical) {
> + d = dmi_first_match(critclk_systems);
> + pr_info("%s critclks quirk enabled\n",
> d->ident);

Now need a double match here just to print the ident. Not too happy
with that but proposing it like this to keep the ident printing.

I guess it could be improved by not printing the ident or having a
global variable and global callback to remember the ident to print
later. I would propose to not print the ident if the double-match does
not find traction.

Henning

> + }
>   }
>  
>   clkdev = platform_device_register_data(>dev,
> "clk-pmc-atom",

[PATCH v2 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

changes since v1:

- fixed lots of style issues found in v1
  - (debug) printing
  - header ordering
- fixed license issues GPLv2 and SPDX in all files
- module_platform_driver instead of __init __exit
- wdt simplifications cleanup
- lots of fixes in wdt driver, all that was found in v1
- fixed dmi length in dmi helper
- changed LED names to allowed ones
- move led driver to simple/
- switched pmc_atom to dmi callback with global variable

--

This series adds support for watchdogs and leds of several x86 devices
from Siemens.

It is structured with a platform driver that mainly does identification
of the machines. It might trigger loading of the actual device drivers
by attaching devices to the platform bus.

The identification is vendor specific, parsing a special binary DMI
entry. The implementation of that platform identification is applied on
pmc_atom clock quirks in the final patch.

It is all structured in a way that we can easily add more devices and
more platform drivers later. Internally we have some more code for
hardware monitoring, more leds, watchdogs etc. This will follow some
day.

Henning Schild (4):
  platform/x86: simatic-ipc: add main driver for Siemens devices
  leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
  watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
  platform/x86: pmc_atom: improve critclk_systems matching for Siemens
PCs

 drivers/leds/Kconfig  |   3 +
 drivers/leds/Makefile |   3 +
 drivers/leds/simple/Kconfig   |  11 +
 drivers/leds/simple/Makefile  |   2 +
 drivers/leds/simple/simatic-ipc-leds.c| 210 +
 drivers/platform/x86/Kconfig  |  12 +
 drivers/platform/x86/Makefile |   3 +
 drivers/platform/x86/pmc_atom.c   |  47 ++--
 drivers/platform/x86/simatic-ipc.c| 168 ++
 drivers/watchdog/Kconfig  |  11 +
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/simatic-ipc-wdt.c| 215 ++
 .../platform_data/x86/simatic-ipc-base.h  |  29 +++
 include/linux/platform_data/x86/simatic-ipc.h |  66 ++
 14 files changed, 761 insertions(+), 20 deletions(-)
 create mode 100644 drivers/leds/simple/Kconfig
 create mode 100644 drivers/leds/simple/Makefile
 create mode 100644 drivers/leds/simple/simatic-ipc-leds.c
 create mode 100644 drivers/platform/x86/simatic-ipc.c
 create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
 create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
 create mode 100644 include/linux/platform_data/x86/simatic-ipc.h

-- 
2.26.2

[PATCH v2 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

This mainly implements detection of these devices and will allow
secondary drivers to work on such machines.

The identification is DMI-based with a vendor specific way to tell them
apart in a reliable way.

Drivers for LEDs and Watchdogs will follow to make use of that platform
detection.

Signed-off-by: Henning Schild 
---
 drivers/platform/x86/Kconfig  |  12 ++
 drivers/platform/x86/Makefile |   3 +
 drivers/platform/x86/simatic-ipc.c| 168 ++
 .../platform_data/x86/simatic-ipc-base.h  |  29 +++
 include/linux/platform_data/x86/simatic-ipc.h |  66 +++
 5 files changed, 278 insertions(+)
 create mode 100644 drivers/platform/x86/simatic-ipc.c
 create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
 create mode 100644 include/linux/platform_data/x86/simatic-ipc.h

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ad4e630e73e2..44f8e82e1fd9 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1284,6 +1284,18 @@ config INTEL_TELEMETRY
  directly via debugfs files. Various tools may use
  this interface for SoC state monitoring.
 
+config SIEMENS_SIMATIC_IPC
+   tristate "Siemens Simatic IPC Class driver"
+   depends on PCI
+   help
+ This Simatic IPC class driver is the central of several drivers. It
+ is mainly used for system identification, after which drivers in other
+ classes will take care of driving specifics of those machines.
+ i.e. LEDs and watchdog.
+
+ To compile this driver as a module, choose M here: the module
+ will be called simatic-ipc.
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 60d554073749..26cdebf2e701 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -138,3 +138,6 @@ obj-$(CONFIG_INTEL_TELEMETRY)   += 
intel_telemetry_core.o \
   intel_telemetry_pltdrv.o \
   intel_telemetry_debugfs.o
 obj-$(CONFIG_PMC_ATOM) += pmc_atom.o
+
+# Siemens Simatic Industrial PCs
+obj-$(CONFIG_SIEMENS_SIMATIC_IPC)  += simatic-ipc.o
diff --git a/drivers/platform/x86/simatic-ipc.c 
b/drivers/platform/x86/simatic-ipc.c
new file mode 100644
index ..7c32c12ad32d
--- /dev/null
+++ b/drivers/platform/x86/simatic-ipc.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC platform driver
+ *
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ *  Henning Schild 
+ *  Jan Kiszka 
+ *  Gerd Haeussler 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct platform_device *ipc_led_platform_device;
+static struct platform_device *ipc_wdt_platform_device;
+
+static const struct dmi_system_id simatic_ipc_whitelist[] = {
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
+   },
+   },
+   {}
+};
+
+static struct simatic_ipc_platform platform_data;
+
+static struct {
+   u32 station_id;
+   u8 led_mode;
+   u8 wdt_mode;
+} device_modes[] = {
+   {SIMATIC_IPC_IPC127E, SIMATIC_IPC_DEVICE_127E, SIMATIC_IPC_DEVICE_NONE},
+   {SIMATIC_IPC_IPC227D, SIMATIC_IPC_DEVICE_227D, SIMATIC_IPC_DEVICE_NONE},
+   {SIMATIC_IPC_IPC227E, SIMATIC_IPC_DEVICE_427E, SIMATIC_IPC_DEVICE_227E},
+   {SIMATIC_IPC_IPC277E, SIMATIC_IPC_DEVICE_NONE, SIMATIC_IPC_DEVICE_227E},
+   {SIMATIC_IPC_IPC427D, SIMATIC_IPC_DEVICE_427E, SIMATIC_IPC_DEVICE_NONE},
+   {SIMATIC_IPC_IPC427E, SIMATIC_IPC_DEVICE_427E, SIMATIC_IPC_DEVICE_427E},
+   {SIMATIC_IPC_IPC477E, SIMATIC_IPC_DEVICE_NONE, SIMATIC_IPC_DEVICE_427E},
+};
+
+static int register_platform_devices(u32 station_id)
+{
+   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
+   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;
+   int i;
+
+   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
+
+   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
+   if (device_modes[i].station_id == station_id) {
+   ledmode = device_modes[i].led_mode;
+   wdtmode = device_modes[i].wdt_mode;
+   break;
+   }
+   }
+
+   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
+   platform_data.devmode = ledmode;
+   ipc_led_platform_device =
+   platform_device_register_data(NULL,
+   KBUILD_MODNAME "_leds", PLATFORM_DEVID_NONE,
+   _data,
+   sizeof(struct simatic_ipc_platform));
+   if (IS_ERR(ipc_led_platform_device))
+   return PTR_ERR(ipc_led_platform_device);
+
+ 

[PATCH v2 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.

Signed-off-by: Henning Schild 
---
 drivers/watchdog/Kconfig   |  11 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/simatic-ipc-wdt.c | 215 +
 3 files changed, 227 insertions(+)
 create mode 100644 drivers/watchdog/simatic-ipc-wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1fe0042a48d2..948497eb4bef 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1575,6 +1575,17 @@ config NIC7018_WDT
  To compile this driver as a module, choose M here: the module will be
  called nic7018_wdt.
 
+config SIEMENS_SIMATIC_IPC_WDT
+   tristate "Siemens Simatic IPC Watchdog"
+   depends on SIEMENS_SIMATIC_IPC
+   select WATCHDOG_CORE
+   help
+ This driver adds support for several watchdogs found in Industrial
+ PCs from Siemens.
+
+ To compile this driver as a module, choose M here: the module will be
+ called simatic-ipc-wdt.
+
 # M68K Architecture
 
 config M54xx_WATCHDOG
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f3a6540e725e..7f5c73ec058c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
 obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
 obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
 obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
+obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
 
 # M68K Architecture
 obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
diff --git a/drivers/watchdog/simatic-ipc-wdt.c 
b/drivers/watchdog/simatic-ipc-wdt.c
new file mode 100644
index ..f0f948968db3
--- /dev/null
+++ b/drivers/watchdog/simatic-ipc-wdt.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC driver for Watchdogs
+ *
+ * Copyright (c) Siemens AG, 2020-2021
+ *
+ * Authors:
+ *  Gerd Haeussler 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WD_ENABLE_IOADR0x62
+#define WD_TRIGGER_IOADR   0x66
+#define GPIO_COMMUNITY0_PORT_ID0xaf
+#define PAD_CFG_DW0_GPP_A_23   0x4b8
+#define SAFE_EN_N_427E 0x01
+#define SAFE_EN_N_227E 0x04
+#define WD_ENABLED 0x01
+#define WD_TRIGGERED   0x80
+#define WD_MACROMODE   0x02
+
+#define TIMEOUT_MIN2
+#define TIMEOUT_DEF64
+#define TIMEOUT_MAX64
+
+#define GP_STATUS_REG_227E 0x404D  /* IO PORT for SAFE_EN_N on 227E */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static struct resource gp_status_reg_227e_res =
+   DEFINE_RES_IO_NAMED(GP_STATUS_REG_227E, SZ_1, KBUILD_MODNAME);
+
+static struct resource io_resource =
+   DEFINE_RES_IO_NAMED(WD_ENABLE_IOADR, SZ_1,
+   KBUILD_MODNAME " WD_ENABLE_IOADR");
+
+/* the actual start will be discovered with pci, 0 is a placeholder */
+static struct resource mem_resource =
+   DEFINE_RES_MEM_NAMED(0, SZ_4, "WD_RESET_BASE_ADR");
+
+static u32 wd_timeout_table[] = {2, 4, 6, 8, 16, 32, 48, 64 };
+static void __iomem *wd_reset_base_addr;
+
+static int wd_start(struct watchdog_device *wdd)
+{
+   outb(inb(WD_ENABLE_IOADR) | WD_ENABLED, WD_ENABLE_IOADR);
+   return 0;
+}
+
+static int wd_stop(struct watchdog_device *wdd)
+{
+   outb(inb(WD_ENABLE_IOADR) & ~WD_ENABLED, WD_ENABLE_IOADR);
+   return 0;
+}
+
+static int wd_ping(struct watchdog_device *wdd)
+{
+   inb(WD_TRIGGER_IOADR);
+   return 0;
+}
+
+static int wd_set_timeout(struct watchdog_device *wdd, unsigned int t)
+{
+   int timeout_idx = find_closest(t, wd_timeout_table,
+  ARRAY_SIZE(wd_timeout_table));
+
+   outb((inb(WD_ENABLE_IOADR) & 0xc7) | timeout_idx << 3, WD_ENABLE_IOADR);
+   wdd->timeout = wd_timeout_table[timeout_idx];
+   return 0;
+}
+
+static const struct watchdog_info wdt_ident = {
+   .options= WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING |
+ WDIOF_SETTIMEOUT,
+   .identity   = KBUILD_MODNAME,
+};
+
+static const struct watchdog_ops wdt_ops = {
+   .owner  = THIS_MODULE,
+   .start  = wd_start,
+   .stop   = wd_stop,
+   .ping   = wd_ping,
+   .set_timeout= wd_set_timeout,
+};
+
+static void wd_secondary_enable(u32 wdtmode)
+{
+   u16 resetbit;
+
+   /* set safe_en_n so we are not just WDIOF_ALARMONLY */
+   if (wdtmod

[PATCH v2 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs

[Henning Schild]

Siemens industrial PCs unfortunately can not always be properly
identified the way we used to. An earlier commit introduced code that
allows proper identification without looking at DMI strings that could
differ based on product branding.
Switch over to that proper way and revert commits that used to collect
the machines based on unstable strings.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Fixes: e8796c6c69d1 ("platform/x86: pmc_atom: Add Siemens CONNECT ...")
Fixes: f110d252ae79 ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Fixes: ad0d315b4d4e ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Tested-by: Michael Haener 
Signed-off-by: Henning Schild 
---
 drivers/platform/x86/pmc_atom.c | 47 +++--
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
index ca684ed760d1..38542d547f29 100644
--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -362,6 +363,23 @@ static void pmc_dbgfs_register(struct pmc_dev *pmc)
 }
 #endif /* CONFIG_DEBUG_FS */
 
+static bool pmc_clk_is_critical = true;
+
+static int siemens_clk_is_critical(const struct dmi_system_id *d)
+{
+   u32 st_id;
+
+   if (dmi_walk(simatic_ipc_find_dmi_entry_helper, _id))
+   goto out;
+
+   if (st_id == SIMATIC_IPC_IPC227E || st_id == SIMATIC_IPC_IPC277E)
+   return 1;
+
+out:
+   pmc_clk_is_critical = false;
+   return 1;
+}
+
 /*
  * Some systems need one or more of their pmc_plt_clks to be
  * marked as critical.
@@ -424,24 +442,10 @@ static const struct dmi_system_id critclk_systems[] = {
},
},
{
-   .ident = "SIMATIC IPC227E",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "6ES7647-8B"),
-   },
-   },
-   {
-   .ident = "SIMATIC IPC277E",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "6AV7882-0"),
-   },
-   },
-   {
-   .ident = "CONNECT X300",
+   .callback = siemens_clk_is_critical,
+   .ident = "SIEMENS AG",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "A5E45074588"),
},
},
 
@@ -453,7 +457,7 @@ static int pmc_setup_clks(struct pci_dev *pdev, void 
__iomem *pmc_regmap,
 {
struct platform_device *clkdev;
struct pmc_clk_data *clk_data;
-   const struct dmi_system_id *d = dmi_first_match(critclk_systems);
+   const struct dmi_system_id *d;
 
clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
if (!clk_data)
@@ -461,9 +465,12 @@ static int pmc_setup_clks(struct pci_dev *pdev, void 
__iomem *pmc_regmap,
 
clk_data->base = pmc_regmap; /* offset is added by client */
clk_data->clks = pmc_data->clks;
-   if (d) {
-   clk_data->critical = true;
-   pr_info("%s critclks quirk enabled\n", d->ident);
+   if (dmi_check_system(critclk_systems)) {
+   clk_data->critical = pmc_clk_is_critical;
+   if (clk_data->critical) {
+   d = dmi_first_match(critclk_systems);
+   pr_info("%s critclks quirk enabled\n", d->ident);
+   }
}
 
clkdev = platform_device_register_data(>dev, "clk-pmc-atom",
-- 
2.26.2

[PATCH v2 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.

Signed-off-by: Henning Schild 
---
 drivers/leds/Kconfig   |   3 +
 drivers/leds/Makefile  |   3 +
 drivers/leds/simple/Kconfig|  11 ++
 drivers/leds/simple/Makefile   |   2 +
 drivers/leds/simple/simatic-ipc-leds.c | 210 +
 5 files changed, 229 insertions(+)
 create mode 100644 drivers/leds/simple/Kconfig
 create mode 100644 drivers/leds/simple/Makefile
 create mode 100644 drivers/leds/simple/simatic-ipc-leds.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b6742b4231bf..5c8558a4fa60 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -937,4 +937,7 @@ source "drivers/leds/trigger/Kconfig"
 comment "LED Blink"
 source "drivers/leds/blink/Kconfig"
 
+comment "Simple LED drivers"
+source "drivers/leds/simple/Kconfig"
+
 endif # NEW_LEDS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 2a698df9da57..2de7fdd8d629 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -111,3 +111,6 @@ obj-$(CONFIG_LEDS_TRIGGERS) += trigger/
 
 # LED Blink
 obj-$(CONFIG_LEDS_BLINK)+= blink/
+
+# Simple LED drivers
+obj-y  += simple/
diff --git a/drivers/leds/simple/Kconfig b/drivers/leds/simple/Kconfig
new file mode 100644
index ..9f6a68336659
--- /dev/null
+++ b/drivers/leds/simple/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config LEDS_SIEMENS_SIMATIC_IPC
+   tristate "LED driver for Siemens Simatic IPCs"
+   depends on LEDS_CLASS
+   depends on SIEMENS_SIMATIC_IPC
+   help
+ This option enables support for the LEDs of several Industrial PCs
+ from Siemens.
+
+ To compile this driver as a module, choose M here: the module
+ will be called simatic-ipc-leds.
diff --git a/drivers/leds/simple/Makefile b/drivers/leds/simple/Makefile
new file mode 100644
index ..8481f1e9e360
--- /dev/null
+++ b/drivers/leds/simple/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_LEDS_SIEMENS_SIMATIC_IPC) += simatic-ipc-leds.o
diff --git a/drivers/leds/simple/simatic-ipc-leds.c 
b/drivers/leds/simple/simatic-ipc-leds.c
new file mode 100644
index ..0f7e6320e10d
--- /dev/null
+++ b/drivers/leds/simple/simatic-ipc-leds.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC driver for LEDs
+ *
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ *  Henning Schild 
+ *  Jan Kiszka 
+ *  Gerd Haeussler 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SIMATIC_IPC_LED_PORT_BASE  0x404E
+
+struct simatic_ipc_led {
+   unsigned int value; /* mask for io and offset for mem */
+   char name[32];
+   struct led_classdev cdev;
+};
+
+static struct simatic_ipc_led simatic_ipc_leds_io[] = {
+   {1 << 15, "simatic-ipc:green:" LED_FUNCTION_STATUS "-1" },
+   {1 << 7,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-1" },
+   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_STATUS "-2" },
+   {1 << 6,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-2" },
+   {1 << 13, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3" },
+   {1 << 5,  "simatic-ipc:yellow:" LED_FUNCTION_STATUS "-3" },
+   {0, ""},
+};
+
+/* the actual start will be discovered with pci, 0 is a placeholder */
+struct resource simatic_ipc_led_mem_res =
+   DEFINE_RES_MEM_NAMED(0, SZ_4K, KBUILD_MODNAME);
+
+static void *simatic_ipc_led_memory;
+
+static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
+   {0x500 + 0x1A0, "simatic-ipc:red:" LED_FUNCTION_STATUS "-1"},
+   {0x500 + 0x1A8, "simatic-ipc:green:" LED_FUNCTION_STATUS "-1"},
+   {0x500 + 0x1C8, "simatic-ipc:red:" LED_FUNCTION_STATUS "-2"},
+   {0x500 + 0x1D0, "simatic-ipc:green:" LED_FUNCTION_STATUS "-2"},
+   {0x500 + 0x1E0, "simatic-ipc:red:" LED_FUNCTION_STATUS "-3"},
+   {0x500 + 0x198, "simatic-ipc:green:" LED_FUNCTION_STATUS "-3"},
+   {0, ""},
+};
+
+static struct resource simatic_ipc_led_io_res =
+   DEFINE_RES_IO_NAMED(SIMATIC_IPC_LED_PORT_BASE, SZ_1, KBUILD_MODNAME);
+
+static DEFINE_SPINLOCK(reg_lock);
+
+static void simatic_ipc_led_set_io(struct led_classdev *led_cd,
+  enum led_brightness brightness)
+{
+   struct simatic_ipc_led *led =
+   container_of(led_cd, struct simatic_ipc_led, cdev);
+   unsigned long flags;
+   u

Re: [PATCH v1 3/7] PCI: New Primary to Sideband (P2SB) bridge support library

[Henning Schild]

Am Mon, 8 Mar 2021 14:20:16 +0200
schrieb Andy Shevchenko :

> From: Jonathan Yong 
> 
> There is already one and at least one more user is coming which
> requires an access to Primary to Sideband bridge (P2SB) in order to
> get IO or MMIO bar hidden by BIOS. Create a library to access P2SB
> for x86 devices.
> 
> Signed-off-by: Jonathan Yong 
> Co-developed-by: Andy Shevchenko 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/pci/Kconfig  |  8 
>  drivers/pci/Makefile |  1 +
>  drivers/pci/pci-p2sb.c   | 83
>  include/linux/pci-p2sb.h |
> 28 ++ 4 files changed, 120 insertions(+)
>  create mode 100644 drivers/pci/pci-p2sb.c
>  create mode 100644 include/linux/pci-p2sb.h
> 
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 0c473d75e625..740e5b30d6fd 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -252,6 +252,14 @@ config PCIE_BUS_PEER2PEER
>  
>  endchoice
>  
> +config PCI_P2SB
> + bool "Primary to Sideband (P2SB) bridge access support"
> + depends on PCI && X86
> + help
> +   The Primary to Sideband bridge is an interface to some PCI
> +   devices connected through it. In particular, SPI NOR
> +   controller in Intel Apollo Lake SoC is one of such devices.
> +
>  source "drivers/pci/hotplug/Kconfig"
>  source "drivers/pci/controller/Kconfig"
>  source "drivers/pci/endpoint/Kconfig"
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index d62c4ac4ae1b..eee8d5dda7d9 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCI_IOV)   += iov.o
>  obj-$(CONFIG_PCI_BRIDGE_EMUL)+= pci-bridge-emul.o
>  obj-$(CONFIG_PCI_LABEL)  += pci-label.o
>  obj-$(CONFIG_X86_INTEL_MID)  += pci-mid.o
> +obj-$(CONFIG_PCI_P2SB)   += pci-p2sb.o
>  obj-$(CONFIG_PCI_SYSCALL)+= syscall.o
>  obj-$(CONFIG_PCI_STUB)   += pci-stub.o
>  obj-$(CONFIG_PCI_PF_STUB)+= pci-pf-stub.o
> diff --git a/drivers/pci/pci-p2sb.c b/drivers/pci/pci-p2sb.c
> new file mode 100644
> index ..68d7dad48cdb
> --- /dev/null
> +++ b/drivers/pci/pci-p2sb.c
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Primary to Sideband bridge (P2SB) access support
> + *
> + * Copyright (c) 2017, 2021 Intel Corporation.
> + *
> + * Authors: Andy Shevchenko 
> + *   Jonathan Yong 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "pci.h"
> +
> +#define P2SBC_HIDE_BYTE  0xe1
> +#define P2SBC_HIDE_BIT   BIT(0)
> +
> +static const struct x86_cpu_id p2sb_cpu_ids[] = {
> + X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT,
> PCI_DEVFN(13, 0)),
> + {}
> +};
> +
> +static int pci_p2sb_devfn(unsigned int *devfn)
> +{
> + const struct x86_cpu_id *id;
> +
> + id = x86_match_cpu(p2sb_cpu_ids);
> + if (!id)
> + return -ENODEV;
> +
> + *devfn = (unsigned int)id->driver_data;
> + return 0;
> +}
> +
> +/**
> + * pci_p2sb_bar - Get Primary to Sideband bridge (P2SB) device BAR
> + * @pdev:PCI device to get a PCI bus to communicate with
> + * @devfn:   PCI slot and function to communicate with
> + * @mem: memory resource to be filled in

Do we really need that many arguments to it?

Before i had, in a platform driver that never had its own pci_dev or bus

  res->start = simatic_ipc_get_membase0(PCI_DEVFN(13, 0));
  if (res-start == 0)
return -ENODEV;

So helper only asked for the devfn, returned base and no dedicated
error code.

With this i need

  struct pci_bus *bus = pci_find_bus(0, 0);
  struct pci_dev *pci_dev = bus->self;
  unsigned int magic_i_do_not_want =  PCI_DEVFN(13, 0);

> + * The BIOS prevents the P2SB device from being enumerated by the PCI
> + * subsystem, so we need to unhide and hide it back to lookup the
> BAR.
> + *
> + * Caller must provide a valid pointer to @mem.
> + *
> + * Locking is handled by pci_rescan_remove_lock mutex.
> + *
> + * Return:
> + * 0 on success or appropriate errno value on error.
> + */
> +int pci_p2sb_bar(struct pci_dev *pdev, unsigned int devfn, struct
> resource *mem) +{
> + struct pci_bus *bus = pdev->bus;

if (!pdev)
bus = pci_find_bus(0, 0);

Or can we drop the whole arg?

> + unsigned int df;
> + int ret;
> +
> + /* Get devfn for P2SB device itself */
> + ret = pci_p2sb_devfn();
> + if (ret)
> + return ret;

if (!devfn)
devfn = df;

I guess that second devfn is for devices behind that bridge. So
unhiding it might reveal several devices? But when caring about that
p2sb do i really need to know its devfn. If so i would like to get

EXPORT_SYMBOL(pci_p2sb_devfn);

regards,
Henning

> +
> + pci_lock_rescan_remove();
> +
> + /* Unhide the P2SB device */
> + pci_bus_write_config_byte(bus, df, P2SBC_HIDE_BYTE, 0);
> +
> + /* Read the first BAR of the device in question */
> + 

Re: [rfc, PATCH v1 0/7] PCI: introduce p2sb helper

[Henning Schild]

Am Mon, 8 Mar 2021 14:20:13 +0200
schrieb Andy Shevchenko :

> There are a few users and even at least one more is coming
> that would like to utilize p2sb mechanisms like hide/unhide
> a device from PCI configuration space.

Tried this for my usecase and can confirm it to work as expected.

Tested-by: Henning Schild 

Henning

> Here is the series to deduplicate existing users and provide
> a generic way for new comers.
> 
> It also includes a patch to enable GPIO controllers on Apollo Lake
> when it's used with ABL bootloader w/o ACPI support.
> 
> Please, comment on the approach and individual patches.
> 
> (Since it's cross subsystem, the PCI seems like a main one and
>  I think it makes sense to route it thru it with immutable tag
>  or branch provided for the others).
> 
> Andy Shevchenko (5):
>   PCI: Introduce pci_bus_*() printing macros when device is not
> available
>   PCI: Convert __pci_read_base() to __pci_bus_read_base()
>   mfd: lpc_ich: Factor out lpc_ich_enable_spi_write()
>   mfd: lpc_ich: Switch to generic pci_p2sb_bar()
>   i2c: i801: convert to use common P2SB accessor
> 
> Jonathan Yong (1):
>   PCI: New Primary to Sideband (P2SB) bridge support library
> 
> Tan Jui Nee (1):
>   mfd: lpc_ich: Add support for pinctrl in non-ACPI system
> 
>  drivers/i2c/busses/Kconfig|   1 +
>  drivers/i2c/busses/i2c-i801.c |  40 +++---
>  drivers/mfd/Kconfig   |   1 +
>  drivers/mfd/lpc_ich.c | 135
> +- drivers/pci/Kconfig   |
> 8 ++ drivers/pci/Makefile  |   1 +
>  drivers/pci/pci-p2sb.c|  89 ++
>  drivers/pci/pci.h |  13 +++-
>  drivers/pci/probe.c   |  81 ++--
>  include/linux/pci-p2sb.h  |  28 +++
>  include/linux/pci.h   |   9 +++
>  11 files changed, 313 insertions(+), 93 deletions(-)
>  create mode 100644 drivers/pci/pci-p2sb.c
>  create mode 100644 include/linux/pci-p2sb.h
> 

Re: [PATCH v1 3/7] PCI: New Primary to Sideband (P2SB) bridge support library

[Henning Schild]

Am Mon, 8 Mar 2021 19:42:21 -0600
schrieb Bjorn Helgaas :

> On Mon, Mar 08, 2021 at 09:16:50PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 08, 2021 at 12:52:12PM -0600, Bjorn Helgaas wrote:  
> > > On Mon, Mar 08, 2021 at 02:20:16PM +0200, Andy Shevchenko wrote:  
> > > > From: Jonathan Yong 
> > > > 
> > > > There is already one and at least one more user is coming which
> > > > requires an access to Primary to Sideband bridge (P2SB) in
> > > > order to get IO or MMIO bar hidden by BIOS. Create a library to
> > > > access P2SB for x86 devices.  
> > > 
> > > Can you include a spec reference?  
> > 
> > I'm not sure I have a public link to the spec. It's the 100 Series
> > PCH [1]. The document number to look for is 546955 [2] and there
> > actually a bit of information about this.  
> 
> This link, found by googling for "p2sb bridge", looks like it might
> have relevant public links:
> 
> https://lab.whitequark.org/notes/2017-11-08/accessing-intel-ich-pch-gpios/
> 
> I'd prefer if you could dig out the relevant sections because I really
> don't know how to identify them.
> 
> > > I'm trying to figure out why this
> > > belongs in drivers/pci/.  It looks very device-specific.  
> > 
> > Because it's all about access to PCI configuration spaces of the
> > (hidden) devices.  
> 
> The PCI core generally doesn't deal with device-specific config
> registers.
> 
> > [1]:
> > https://ark.intel.com/content/www/us/en/ark/products/series/98456/intel-100-series-desktop-chipsets.html
> > [2]:
> > https://medium.com/@jacksonchen_43335/bios-gpio-p2sb-70e9b829b403
> > 
> > ...
> >   
> > > > +config PCI_P2SB
> > > > +   bool "Primary to Sideband (P2SB) bridge access support"
> > > > +   depends on PCI && X86
> > > > +   help
> > > > + The Primary to Sideband bridge is an interface to
> > > > some PCI
> > > > + devices connected through it. In particular, SPI NOR
> > > > + controller in Intel Apollo Lake SoC is one of such
> > > > devices.  
> > > 
> > > This doesn't sound like a "bridge".  If it's a bridge, what's on
> > > the primary (upstream) side?  What's on the secondary side?  What
> > > resources are passed through the bridge, i.e., what transactions
> > > does it transfer from one side to the other?  
> > 
> > It's a confusion terminology here. It's a Bridge according to the
> > spec, but it is *not* a PCI Bridge as you may had a first
> > impression.  
> 
> The code suggests that a register on this device controls whether a
> different device is visible in config space.  I think it will be
> better if we can describe what's happening.
> 
> > ...
> >   
> > > > +   /* Unhide the P2SB device */
> > > > +   pci_bus_write_config_byte(bus, df, P2SBC_HIDE_BYTE, 0);
> > > > +
> > > > +   /* Read the first BAR of the device in question */
> > > > +   __pci_bus_read_base(bus, devfn, pci_bar_unknown, mem,
> > > > PCI_BASE_ADDRESS_0, true);  
> > > 
> > > I don't get this.  Apparently this normally hidden device is
> > > consuming PCI address space.  The PCI core needs to know about
> > > this.  If it doesn't, the PCI core may assign this space to
> > > another device.  
> > 
> > Right, it returns all 1:s to any request so PCI core *thinks* it's
> > plugged off (like D3cold or so).  
> 
> I'm asking about the MMIO address space.  The BAR is a register in
> config space.  AFAICT, clearing P2SBC_HIDE_BYTE makes that BAR
> visible.  The BAR describes a region of PCI address space.  It looks
> like setting P2SBC_HIDE_BIT makes the BAR disappear from config space,
> but it sounds like the PCI address space *described* by the BAR is
> still claimed by the device.  If the device didn't respond to that
> MMIO space, you would have no reason to read the BAR at all.
> 
> So what keeps the PCI core from assigning that MMIO space to another
> device?

The device will respond to MMIO while being hidden. I am afraid nothing
stops a collision, except for the assumption that the BIOS is always
right and PCI devices never get remapped. But just guessing here.

I have seen devices with coreboot having the P2SB visible, and most
likely relocatable. Making it visible in Linux and not hiding it again
might work, but probably only as long as Linux will not relocate it.
Which i am afraid might seriously upset the BIOS, depending on what a
device does with those GPIOs and which parts are implemented in the
BIOS.

regards,
Henning

> This all sounds quite irregular from the point of view of the PCI
> core.  If a device responds to address space that is not described by
> a standard PCI BAR, or by an EA capability, or by one of the legacy
> VGA or IDE exceptions, we have a problem.  That space must be
> described *somehow* in a generic way, e.g., ACPI or similar.
> 
> What happens if CONFIG_PCI_P2SB is unset?  The device doesn't know
> that, and if it is still consuming MMIO address space that we don't
> know about, that's a problem.
> 
> > > > +   /* Hide the P2SB device */
> > > > + 

Re: [PATCH 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

Am Wed, 3 Mar 2021 15:21:05 +0100
schrieb Henning Schild :

> Hi, 
> 
> thanks for the fast and thorough review!
> 
> Am Tue, 2 Mar 2021 10:38:19 -0800
> schrieb Guenter Roeck :
> 
> > On 3/2/21 8:33 AM, Henning Schild wrote:  
> > > From: Henning Schild 
> > > 
> > > This driver adds initial support for several devices from Siemens.
> > > It is based on a platform driver introduced in an earlier commit.
> > > 
> > > Signed-off-by: Gerd Haeussler 
> > > Signed-off-by: Henning Schild 
> > > ---
> > >  drivers/watchdog/Kconfig   |  11 ++
> > >  drivers/watchdog/Makefile  |   1 +
> > >  drivers/watchdog/simatic-ipc-wdt.c | 305
> > > + 3 files changed, 317 insertions(+)
> > >  create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
> > > 
> > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > > index 1fe0042a48d2..948497eb4bef 100644
> > > --- a/drivers/watchdog/Kconfig
> > > +++ b/drivers/watchdog/Kconfig
> > > @@ -1575,6 +1575,17 @@ config NIC7018_WDT
> > > To compile this driver as a module, choose M here: the
> > > module will be called nic7018_wdt.
> > >  
> > > +config SIEMENS_SIMATIC_IPC_WDT
> > > + tristate "Siemens Simatic IPC Watchdog"
> > > + depends on SIEMENS_SIMATIC_IPC
> > > + select WATCHDOG_CORE
> > > + help
> > > +   This driver adds support for several watchdogs found in
> > > Industrial
> > > +   PCs from Siemens.
> > > +
> > > +   To compile this driver as a module, choose M here: the
> > > module will be
> > > +   called simatic-ipc-wdt.
> > > +
> > >  # M68K Architecture
> > >  
> > >  config M54xx_WATCHDOG
> > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > > index f3a6540e725e..7f5c73ec058c 100644
> > > --- a/drivers/watchdog/Makefile
> > > +++ b/drivers/watchdog/Makefile
> > > @@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> > >  obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
> > >  obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
> > >  obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
> > > +obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
> > >  
> > >  # M68K Architecture
> > >  obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
> > > diff --git a/drivers/watchdog/simatic-ipc-wdt.c
> > > b/drivers/watchdog/simatic-ipc-wdt.c new file mode 100644
> > > index ..b5c8b7ceb404
> > > --- /dev/null
> > > +++ b/drivers/watchdog/simatic-ipc-wdt.c
> > > @@ -0,0 +1,305 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Siemens SIMATIC IPC driver for Watchdogs
> > > + *
> > > + * Copyright (c) Siemens AG, 2020-2021
> > > + *
> > > + * Authors:
> > > + *  Gerd Haeussler 
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > modify
> > > + * it under the terms of the GNU General Public License version 2
> > > as
> > > + * published by the Free Software Foundation.
> > 
> > Covered by SPDX-License-Identifier
> >   
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include > +#include 
> > > +#include 
> > 
> > Alphabetic order please
> >   
> > > +
> > > +#define WD_ENABLE_IOADR  0x62
> > > +#define WD_TRIGGER_IOADR 0x66
> > > +#define GPIO_COMMUNITY0_PORT_ID 0xaf
> > > +#define PAD_CFG_DW0_GPP_A_23 0x4b8
> > 
> > Please increase indentation and spare another tab
> >   
> > > +#define SAFE_EN_N_427E   0x01
> > > +#define SAFE_EN_N_227E   0x04
> > > +#define WD_ENABLED   0x01
> > > +
> > > +#define TIMEOUT_MIN  2
> > > +#define TIMEOUT_DEF  64
> > > +#define TIMEOUT_MAX  64
> > > +
> > > +#define GP_STATUS_REG_227E   0x404D  /* IO PORT for
> > > SAFE_EN_N on 227E */ +
> > > +static bool nowayout = WATCHDOG_NOWAYOUT;
> > > +module_param(nowayout, bool, );
> > > +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
> > > started (default="
> > > 

Re: [PATCH 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

Am Fri, 5 Mar 2021 19:44:57 +0200
schrieb Andy Shevchenko :

> On Fri, Mar 5, 2021 at 7:17 PM Andy Shevchenko
>  wrote:
> >
> > On Fri, Mar 5, 2021 at 6:47 PM Henning Schild
> >  wrote:  
> > > Am Fri, 5 Mar 2021 17:42:42 +0200
> > > schrieb Andy Shevchenko :  
> > > > On Thu, Mar 4, 2021 at 3:47 PM Hans de Goede
> > > >  wrote:  
> >
> > ...
> >  
> > > > [1]: https://gitlab.com/andy-shev/next/-/tree/p2sb  
> > >
> > > That is a little weird, might be a good idea to RFC reply to the
> > > cover letter of this one. To allow review and discussion in a
> > > central place.  
> >
> > I'm now rebasing it to be more presentable.
> > If you can test this approach and it works for you, I'll send a
> > formal RFC series.  
> 
> Okay, [1] now is in presentable shape, each patch with a proper commit
> message and authorship, also all patches are compiled without issues.

Thank you so much, i will base v2 on that and let you know how that
works.

regards,
Henning

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Sat, 6 Mar 2021 13:54:53 +0100
schrieb Henning Schild :

> Am Fri, 5 Mar 2021 19:25:55 +0100
> schrieb Henning Schild :
> 
> > Am Wed, 3 Mar 2021 21:56:15 +0100
> > schrieb Henning Schild :
> >   
> > > Am Wed, 3 Mar 2021 21:48:21 +0100
> > > schrieb Henning Schild :
> > > 
> > > > Am Wed, 3 Mar 2021 20:31:34 +0100
> > > > schrieb Pavel Machek :
> > > >   
> > > > > Hi!
> > > > > 
> > > > > > > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > > > > > > +   {1 << 15, "simatic-ipc:green:run-stop"},
> > > > > > > > +   {1 << 7,  "simatic-ipc:yellow:run-stop"},
> > > > > > > > +   {1 << 14, "simatic-ipc:red:error"},
> > > > > > > > +   {1 << 6,  "simatic-ipc:yellow:error"},
> > > > > > > > +   {1 << 13, "simatic-ipc:red:maint"},
> > > > > > > > +   {1 << 5,  "simatic-ipc:yellow:maint"},
> > > > > > > > +   {0, ""},
> > > > > > > > +};
> > > > > > > 
> > > > > > > Please use names consistent with other systems, this is
> > > > > > > user visible. If you have two-color power led, it should
> > > > > > > be :green:power... See include/dt-bindings/leds/common.h .
> > > > > > >  
> > > > > > 
> > > > > > Well we wanted to pick names that are printed on the devices
> > > > > > and would like to stick to those. Has been a discussion ...
> > > > > > Can we have symlinks to have multiple names per LED?
> > > > > >   
> > > > > 
> > > > > No symlinks. We plan to have command line tool to manipulate
> > > > > LEDs, aliases might be possible there.
> > > > 
> > > > Sounds like a future plan. sysfs and "cat" "echo" are mighty
> > > > tools and "everything is a file" is the best idea ever. So i
> > > > would say any aliasing should live in the kernel, but that is
> > > > just me. Tools will just get out of sync, be missing in busybox
> > > > or a random yocto ... or whichever distro you like.
> > > > On the other hand you have "complexity should be userland" ... i
> > > > do not have the answer.  
> > > 
> > > My personal horror would be systemd-ledd or some dracut snipet for
> > > initrd. But that would be a generic led class discussion ... that
> > > tool.
> > > 
> > > > > > How strong would you feel about us using our names?
> > > > > >  
> > > > > 
> > > > > Strongly. :-)
> > > > 
> > > > OK, will try to find a match where possible.   
> > > 
> > > Do we happen to have a description of the existing names, to find
> > > a fit for ours? In the header you pointed out i only found names
> > > without "meaning"
> > 
> > I had a closer look at the several LED_FUNCTION_ while i could
> > probably find a match for the names we had in mind ...
> > 
> > -   {1 << 14, "simatic-ipc:red:error"},
> > +   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_FAULT },
> > 
> > I still do not understand what those mean. Going over the kernel
> > sources many have only one single grep-hit in the tree.
> > LED_FUNCTION_ not having a single one in drivers/leds
> > Others are found in one dts and in that header ... 2 hits in the
> > tree, maybe i should add my favorite strings ;)
> > 
> > LED_FUNCTION_FLASH vs LED_FUNCTION_TORCH ...? Sound like timing, not
> > function.
> > 
> > Let us say i match the three "error", "run-stop", "maint" to
> > LED_FUNCTION_*
> > 
> > I would have a really hard time finding matches for other LEDs i did
> > not even propose. One example being disks ... many of them, would i
> > be allowed to 
> > 
> > LED_FUNCTION_DISK "0"
> > LED_FUNCTION_DISK "1"
> > ...
> > 
> > they would all have the same colors.
> > 
> > Maybe you explain the idea behind choosing only from that namespace?
> > My guess would be high-level software being able to toggle leds
> >

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Fri, 5 Mar 2021 19:25:55 +0100
schrieb Henning Schild :

> Am Wed, 3 Mar 2021 21:56:15 +0100
> schrieb Henning Schild :
> 
> > Am Wed, 3 Mar 2021 21:48:21 +0100
> > schrieb Henning Schild :
> >   
> > > Am Wed, 3 Mar 2021 20:31:34 +0100
> > > schrieb Pavel Machek :
> > > 
> > > > Hi!
> > > >   
> > > > > > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > > > > > + {1 << 15, "simatic-ipc:green:run-stop"},
> > > > > > > + {1 << 7,  "simatic-ipc:yellow:run-stop"},
> > > > > > > + {1 << 14, "simatic-ipc:red:error"},
> > > > > > > + {1 << 6,  "simatic-ipc:yellow:error"},
> > > > > > > + {1 << 13, "simatic-ipc:red:maint"},
> > > > > > > + {1 << 5,  "simatic-ipc:yellow:maint"},
> > > > > > > + {0, ""},
> > > > > > > +};  
> > > > > > 
> > > > > > Please use names consistent with other systems, this is user
> > > > > > visible. If you have two-color power led, it should be
> > > > > > :green:power... See include/dt-bindings/leds/common.h .
> > > > > >
> > > > > 
> > > > > Well we wanted to pick names that are printed on the devices
> > > > > and would like to stick to those. Has been a discussion ...
> > > > > Can we have symlinks to have multiple names per LED?
> > > > 
> > > > No symlinks. We plan to have command line tool to manipulate
> > > > LEDs, aliases might be possible there.  
> > > 
> > > Sounds like a future plan. sysfs and "cat" "echo" are mighty tools
> > > and "everything is a file" is the best idea ever. So i would say
> > > any aliasing should live in the kernel, but that is just me.
> > > Tools will just get out of sync, be missing in busybox or a
> > > random yocto ... or whichever distro you like.
> > > On the other hand you have "complexity should be userland" ... i
> > > do not have the answer.
> > 
> > My personal horror would be systemd-ledd or some dracut snipet for
> > initrd. But that would be a generic led class discussion ... that
> > tool.
> >   
> > > > > How strong would you feel about us using our names?
> > > > 
> > > > Strongly. :-)  
> > > 
> > > OK, will try to find a match where possible. 
> > 
> > Do we happen to have a description of the existing names, to find a
> > fit for ours? In the header you pointed out i only found names
> > without "meaning"  
> 
> I had a closer look at the several LED_FUNCTION_ while i could
> probably find a match for the names we had in mind ...
> 
> -   {1 << 14, "simatic-ipc:red:error"},
> +   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_FAULT },
> 
> I still do not understand what those mean. Going over the kernel
> sources many have only one single grep-hit in the tree.
> LED_FUNCTION_ not having a single one in drivers/leds
> Others are found in one dts and in that header ... 2 hits in the tree,
> maybe i should add my favorite strings ;)
> 
> LED_FUNCTION_FLASH vs LED_FUNCTION_TORCH ...? Sound like timing, not
> function.
> 
> Let us say i match the three "error", "run-stop", "maint" to
> LED_FUNCTION_*
> 
> I would have a really hard time finding matches for other LEDs i did
> not even propose. One example being disks ... many of them, would i be
> allowed to 
> 
> LED_FUNCTION_DISK "0"
> LED_FUNCTION_DISK "1"
> ...
> 
> they would all have the same colors.
> 
> Maybe you explain the idea behind choosing only from that namespace?
> My guess would be high-level software being able to toggle leds
> totally indep of the device it runs on. Such software would have to
> do some really nasty directory listing, name parsing, dealing with
> multiple hits. Does such generic software already exist, maybe that
> would help me understand my "mapping problems" ?
> 
> The current class encodes, color, function and name into "name".
> 
> Maybe i am all wrong and should go for
> 
> {1 << 14, "simatic-ipc-error:red:" LED_FUNCTION_STATUS }
> {1 << 15, "simatic-ipc-run-stop:green:" LED_FUNCTION_STATUS}
> {..., "simatic-ipc-hdd0:red:&q

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Wed, 3 Mar 2021 21:56:15 +0100
schrieb Henning Schild :

> Am Wed, 3 Mar 2021 21:48:21 +0100
> schrieb Henning Schild :
> 
> > Am Wed, 3 Mar 2021 20:31:34 +0100
> > schrieb Pavel Machek :
> >   
> > > Hi!
> > > 
> > > > > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > > > > +   {1 << 15, "simatic-ipc:green:run-stop"},
> > > > > > +   {1 << 7,  "simatic-ipc:yellow:run-stop"},
> > > > > > +   {1 << 14, "simatic-ipc:red:error"},
> > > > > > +   {1 << 6,  "simatic-ipc:yellow:error"},
> > > > > > +   {1 << 13, "simatic-ipc:red:maint"},
> > > > > > +   {1 << 5,  "simatic-ipc:yellow:maint"},
> > > > > > +   {0, ""},
> > > > > > +};
> > > > > 
> > > > > Please use names consistent with other systems, this is user
> > > > > visible. If you have two-color power led, it should be
> > > > > :green:power... See include/dt-bindings/leds/common.h .  
> > > > 
> > > > Well we wanted to pick names that are printed on the devices and
> > > > would like to stick to those. Has been a discussion ...
> > > > Can we have symlinks to have multiple names per LED?  
> > > 
> > > No symlinks. We plan to have command line tool to manipulate LEDs,
> > > aliases might be possible there.
> > 
> > Sounds like a future plan. sysfs and "cat" "echo" are mighty tools
> > and "everything is a file" is the best idea ever. So i would say any
> > aliasing should live in the kernel, but that is just me. Tools will
> > just get out of sync, be missing in busybox or a random yocto ... or
> > whichever distro you like.
> > On the other hand you have "complexity should be userland" ... i do
> > not have the answer.  
> 
> My personal horror would be systemd-ledd or some dracut snipet for
> initrd. But that would be a generic led class discussion ... that
> tool.
> 
> > > > How strong would you feel about us using our names?  
> > > 
> > > Strongly. :-)
> > 
> > OK, will try to find a match where possible.   
> 
> Do we happen to have a description of the existing names, to find a
> fit for ours? In the header you pointed out i only found names without
> "meaning"

I had a closer look at the several LED_FUNCTION_ while i could probably
find a match for the names we had in mind ...

-   {1 << 14, "simatic-ipc:red:error"},
+   {1 << 14, "simatic-ipc:red:" LED_FUNCTION_FAULT },

I still do not understand what those mean. Going over the kernel
sources many have only one single grep-hit in the tree.
LED_FUNCTION_ not having a single one in drivers/leds
Others are found in one dts and in that header ... 2 hits in the tree,
maybe i should add my favorite strings ;)

LED_FUNCTION_FLASH vs LED_FUNCTION_TORCH ...? Sound like timing, not
function.

Let us say i match the three "error", "run-stop", "maint" to
LED_FUNCTION_*

I would have a really hard time finding matches for other LEDs i did
not even propose. One example being disks ... many of them, would i be
allowed to 

LED_FUNCTION_DISK "0"
LED_FUNCTION_DISK "1"
...

they would all have the same colors.

Maybe you explain the idea behind choosing only from that namespace? My
guess would be high-level software being able to toggle leds totally
indep of the device it runs on. Such software would have to do some
really nasty directory listing, name parsing, dealing with multiple
hits. Does such generic software already exist, maybe that would help
me understand my "mapping problems" ?

The current class encodes, color, function and name into "name".

Maybe i am all wrong and should go for

{1 << 14, "simatic-ipc-error:red:" LED_FUNCTION_STATUS }
{1 << 15, "simatic-ipc-run-stop:green:" LED_FUNCTION_STATUS}
{..., "simatic-ipc-hdd0:red:" LED_FUNCTION_DISK }
{..., "simatic-ipc-hdd1:red:" LED_FUNCTION_DISK }

so appending my wanted name to the name before the first :, and use
functions i "understand" after the second :

regards,
Henning


> regards,
> Henning
> 
> >   
> > > Do you have a picture how the leds look like?
> > 
> > I could even find chassis photos in our internal review but that
> > would be too much.
> > 
> > Our idea is probably the same as yours. We want the same names
> > across all devices. But we struggle with colors because on some
> > boxes we have red+green, while other offer yellow ... implemented
> > in HW and messing with red+green in some cases.
> > 
> > But so far we only looked at Siemens devices and thought we could
> > get our own "namespace".
> > 
> > To be honest i could not even tell how our names map on the known
> > ones, but we will do our best to find a match. They all are
> > "high-level" so "power" and other basic things are not exposed.
> > 
> > regards,
> > Henning
> >
> > > Best regards,
> > >   Pavel
> >   
> 

Re: [PATCH 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

Am Fri, 5 Mar 2021 17:42:42 +0200
schrieb Andy Shevchenko :

> On Thu, Mar 4, 2021 at 3:47 PM Hans de Goede 
> wrote:
> > On 3/4/21 11:11 AM, Andy Shevchenko wrote:  
> > > On Thu, Mar 4, 2021 at 8:36 AM Henning Schild
> > >  wrote:  
> 
> ...
> 
> > >> +u32 simatic_ipc_get_membase0(unsigned int p2sb)
> > >> +{
> > >> +   u32 bar0 = 0;  
> > >  
> > >> +#ifdef CONFIG_PCI  
> > >
> > > It's ugly besides the fact that you have a dependency.
> > >  
> > >> +   struct pci_bus *bus;  
> > >
> > > Missed blank line.
> > >  
> > >> +   /*
> > >> +* The GPIO memory is bar0 of the hidden P2SB device.
> > >> Unhide the device
> > >> +* to have a quick look at it, before we hide it again.
> > >> +* Also grab the pci rescan lock so that device does not
> > >> get discovered
> > >> +* and remapped while it is visible.
> > >> +* This code is inspired by drivers/mfd/lpc_ich.c
> > >> +*/
> > >> +   bus = pci_find_bus(0, 0);
> > >> +   pci_lock_rescan_remove();
> > >> +   pci_bus_write_config_byte(bus, p2sb, 0xE1, 0x0);
> > >> +   pci_bus_read_config_dword(bus, p2sb, PCI_BASE_ADDRESS_0,
> > >> ); +
> > >> +   bar0 &= ~0xf;
> > >> +   pci_bus_write_config_byte(bus, p2sb, 0xE1, 0x1);
> > >> +   pci_unlock_rescan_remove();
> > >> +#endif /* CONFIG_PCI */
> > >> +   return bar0;
> > >> +}
> > >> +EXPORT_SYMBOL(simatic_ipc_get_membase0);  
> > >
> > > Oy vey! I know what this is and let's do it differently. I have
> > > some (relatively old) patch series I can send you privately for
> > > testing.  
> >
> > This bit stood out the most to me too, it would be good if we can
> > this fixed in some cleaner work. So I'm curious how things will
> > look with Andy's work integrated.
> >
> > Also I don't think this should be exported. Instead this (or its
> > replacement) should be used to get the address for an IOMEM
> > resource to add the platform devices when they are instantiated.
> > Then the platform-dev drivers can just use the regular functions to
> > get their resources instead of relying on this module.  
> 
> I have published a WIP branch [1]. I have no means to test (I don't
> know what hardware at hand I can use right now), but I made it compile
> after 4 years of gathering dust...
> Feel free to give any kind of comments or share your ideas on how it
> can be improved (the above idea on IOMEM resource is interesting, but
> devices are PCI, not sure how this can be done).
> 
> [1]: https://gitlab.com/andy-shev/next/-/tree/p2sb

That is a little weird, might be a good idea to RFC reply to the cover
letter of this one. To allow review and discussion in a central place.

Henning

Re: [PATCH 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

Am Fri, 5 Mar 2021 17:46:08 +0200
schrieb Andy Shevchenko :

> On Thu, Mar 4, 2021 at 9:52 PM Henning Schild
>  wrote:
> > Am Thu, 4 Mar 2021 12:11:12 +0200
> > schrieb Andy Shevchenko :  
> > > On Thu, Mar 4, 2021 at 8:36 AM Henning Schild
> > >  wrote:  
> 
> ...
> 
> > > Check for the rest of the series as well (basically this is the
> > > rule of thumb to recheck entire code for the comment you have got
> > > at any single place of it).  
> >
> > For some code Gerd is the author, and i am the co-Author. We even
> > have Jan in the mix at places. At least in copyright headers.
> >
> > I will remain the committer for the three of us. And since i do not
> > know exactly what the problem is i will add only my Signed-off to
> > avoid confusion.
> >
> > Please speak up it that would be wrong as well and point me to the
> > docs i missed. Or tell me how it should be done.  
> 
> Then make sure that you have From line with the Author (`git commit
> --amend --author="..."`) and add your Co-developed-by tag.
> 
> ...
> 
> > > > +   int i;
> > > > +   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
> > > > +   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;  
> > >
> > > Reversed xmas tree order?  
> >
> > I do not get this, it is almost easter egg order time. Please
> > explain.  
> 
> Longer lines
> usually go
> first.

Henning

see
i

> See above :-)
> 

Re: [PATCH 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

Am Thu, 4 Mar 2021 12:11:12 +0200
schrieb Andy Shevchenko :

> On Thu, Mar 4, 2021 at 8:36 AM Henning Schild
>  wrote:
> >
> > From: Henning Schild 
> >
> > This mainly implements detection of these devices and will allow
> > secondary drivers to work on such machines.
> >
> > The identification is DMI-based with a vendor specific way to tell
> > them apart in a reliable way.
> >
> > Drivers for LEDs and Watchdogs will follow to make use of that
> > platform detection.  
> 
> > Signed-off-by: Gerd Haeussler 
> > Signed-off-by: Henning Schild   
> 
> The order is wrong taking into account the From line in the body. So,
> it's not clear who is the author, who is a co-developer, and who is
> the committer (one person may utilize few roles).
> Check for the rest of the series as well (basically this is the rule
> of thumb to recheck entire code for the comment you have got at any
> single place of it).

For some code Gerd is the author, and i am the co-Author. We even have
Jan in the mix at places. At least in copyright headers.

I will remain the committer for the three of us. And since i do not
know exactly what the problem is i will add only my Signed-off to avoid
confusion.

Please speak up it that would be wrong as well and point me to the docs
i missed. Or tell me how it should be done. 

> ...
> 
> > +config SIEMENS_SIMATIC_IPC
> > +   tristate "Siemens Simatic IPC Class driver"
> > +   depends on PCI
> > +   help
> > + This Simatic IPC class driver is the central of several
> > drivers. It
> > + is mainly used for system identification, after which
> > drivers in other
> > + classes will take care of driving specifics of those
> > machines.
> > + i.e. leds and watchdogs  
> 
> LEDs
> watchdog. (missed period and singular form)
> 
> Module name?
> 
> >  endif # X86_PLATFORM_DEVICES  
> 
> Not sure about the ordering of the section in Kconfig, but it is up to
> maintainers.
> 
> ...
> 
> > +# Siemens Simatic Industrial PCs
> > +obj-$(CONFIG_SIEMENS_SIMATIC_IPC)  += simatic-ipc.o  
> 
> Ditto.

I will check both again if a find a pattern, otherwise will wait for
maintainers to complain and hopefully suggest.

> ...
> 
> > + * Siemens SIMATIC IPC driver for LEDs  
> 
> It seems to be used in patch 4 which is not LED related. Also, why is
> it here if it's for LEDs?
> 
> ...
> 
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.  
> 
> Replace with SPDX
> 
> ...
> 
> > +#include 
> > +#include 
> > +#include   
> 
> Ordered?
> 
> > +#include   
> 
> ...
> 
> > +static int register_platform_devices(u32 station_id)
> > +{
> > +   int i;
> > +   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
> > +   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;  
> 
> Reversed xmas tree order?

I do not get this, it is almost easter egg order time. Please explain.

> > +   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
> > +   if (device_modes[i].station_id == station_id) {
> > +   ledmode = device_modes[i].led_mode;
> > +   wdtmode = device_modes[i].wdt_mode;
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
> > +   platform_data.devmode = ledmode;  
> 
> > +   ipc_led_platform_device =
> > platform_device_register_data
> > +   (NULL, KBUILD_MODNAME "_leds",
> > PLATFORM_DEVID_NONE,
> > +_data, sizeof(struct
> > simatic_ipc_platform));  
> 
> Strange indentation (second line).
> 
> > +   if (IS_ERR(ipc_led_platform_device))
> > +   return PTR_ERR(ipc_led_platform_device);  
> 
> > +   pr_debug(KBUILD_MODNAME ": device=%s created\n",
> > +ipc_led_platform_device->name);  
> 
> Utilize pr_fmt() instead of adding prefixes like this.
> 
> > +   }  
> 
> > +   if (wdtmode != SIMATIC_IPC_DEVICE_NONE) {
> > +   platform_data.devmode = wdtmode;
> > +   ipc_wdt_platform_device =
> > platform_device_register_data
> > +   (NULL, KBUILD_MO

Re: [PATCH 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

Am Thu, 4 Mar 2021 12:20:22 +0200
schrieb Andy Shevchenko :

> On Thu, Mar 4, 2021 at 12:19 PM Andy Shevchenko
>  wrote:
> > On Thu, Mar 4, 2021 at 9:29 AM Henning Schild
> >  wrote:  
> 
> > I have given a few comments here and there, so please check the
> > entire series and address them in _all_ similar locations. As I
> > have noticed, I have different approach about P2SB code, I have to
> > give the series a dust and see if you can utilize it.
> >
> > I would like to be Cc'ed on the next version.  
> 
> One more thing, is it Apollo Lake based?

Not sure i can answer that, or what you even refer to. The whole series
is about a range of devices, some even have sub-models with differing
CPUs and Lakes

regards,
Henning

Re: [PATCH 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

Thanks Andy,

Am Thu, 4 Mar 2021 12:19:44 +0200
schrieb Andy Shevchenko :

> On Thu, Mar 4, 2021 at 9:29 AM Henning Schild
>  wrote:
> 
> > This series adds support for watchdogs and leds of several x86
> > devices from Siemens.
> >
> > It is structured with a platform driver that mainly does
> > identification of the machines. It might trigger loading of the
> > actual device drivers by attaching devices to the platform bus.
> >
> > The identification is vendor specific, parsing a special binary DMI
> > entry. The implementation of that platform identification is
> > applied on pmc_atom clock quirks in the final patch.
> >
> > It is all structured in a way that we can easily add more devices
> > and more platform drivers later. Internally we have some more code
> > for hardware monitoring, more leds, watchdogs etc. This will follow
> > some day.
> >
> > But the idea here is to share early, and hopefully not fail early.  
> 
> I have given a few comments here and there, so please check the entire
> series and address them in _all_ similar locations. As I have noticed,
> I have different approach about P2SB code, I have to give the series a
> dust and see if you can utilize it.

You did find some things that others found as well. SPDX vs blabla,
header ordering, some other style.
Some things are already done and will be in v2.

Other findings are new, and we will look into them. The only thing that
did stick out is P2SB, also was a point in internal pre-review.
Let us see what you have, i can include a patch of yours into the q.
But i am kind of afraid once it is there, several existing users should
be touched with it, and this series would come later. Or this series
comes first and you come later and clean up our "mess". Not sure i
would want to take over all P2SB unhiders, but with you on board it
will work.

> I would like to be Cc'ed on the next version.

Sure thing.

regards,
Henning


> 

Re: [PATCH 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

Am Thu, 4 Mar 2021 10:27:07 +0200
schrieb Andy Shevchenko :

> On Tuesday, March 2, 2021, Henning Schild 
> wrote:
> 
> > From: Henning Schild 
> >
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.
> >
> >  
> 
> Is it ACPI based? Why it can not provide WDAT table instead?

Yes it is. We strongly urged the BIOS guys to look into that for future
products and BIOS updates for current products. But for existing
products they will not add "features". One fear is breaking Windows
where custom drivers have been the way they did it so far.

So we are dealing with legacy here, that is why. Hope that is not a
show-stopper.

Maybe we can carry ACPI quirk snippets instead, did not yet look into
this. And i am not sure which version would be easier to maintain and
more acceptable to the kernel.

regards,
Henning

> 
> > Signed-off-by: Gerd Haeussler 
> > Signed-off-by: Henning Schild 
> > ---
> >  drivers/watchdog/Kconfig   |  11 ++
> >  drivers/watchdog/Makefile  |   1 +
> >  drivers/watchdog/simatic-ipc-wdt.c | 305
> > + 3 files changed, 317 insertions(+)
> >  create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 1fe0042a48d2..948497eb4bef 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -1575,6 +1575,17 @@ config NIC7018_WDT
> >   To compile this driver as a module, choose M here: the
> > module will be
> >   called nic7018_wdt.
> >
> > +config SIEMENS_SIMATIC_IPC_WDT
> > +   tristate "Siemens Simatic IPC Watchdog"
> > +   depends on SIEMENS_SIMATIC_IPC
> > +   select WATCHDOG_CORE
> > +   help
> > + This driver adds support for several watchdogs found in
> > Industrial
> > + PCs from Siemens.
> > +
> > + To compile this driver as a module, choose M here: the
> > module will be
> > + called simatic-ipc-wdt.
> > +
> >  # M68K Architecture
> >
> >  config M54xx_WATCHDOG
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index f3a6540e725e..7f5c73ec058c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> >  obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
> >  obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
> >  obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
> > +obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
> >
> >  # M68K Architecture
> >  obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
> > diff --git a/drivers/watchdog/simatic-ipc-wdt.c
> > b/drivers/watchdog/simatic-ipc-wdt.c
> > new file mode 100644
> > index ..b5c8b7ceb404
> > --- /dev/null
> > +++ b/drivers/watchdog/simatic-ipc-wdt.c
> > @@ -0,0 +1,305 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Siemens SIMATIC IPC driver for Watchdogs
> > + *
> > + * Copyright (c) Siemens AG, 2020-2021
> > + *
> > + * Authors:
> > + *  Gerd Haeussler 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define WD_ENABLE_IOADR0x62
> > +#define WD_TRIGGER_IOADR   0x66
> > +#define GPIO_COMMUNITY0_PORT_ID 0xaf
> > +#define PAD_CFG_DW0_GPP_A_23   0x4b8
> > +#define SAFE_EN_N_427E 0x01
> > +#define SAFE_EN_N_227E 0x04
> > +#define WD_ENABLED 0x01
> > +
> > +#define TIMEOUT_MIN2
> > +#define TIMEOUT_DEF64
> > +#define TIMEOUT_MAX64
> > +
> > +#define GP_STATUS_REG_227E 0x404D  /* IO PORT for SAFE_EN_N on
> > 227E */ +
> > +static bool nowayout = WATCHDOG_NOWAYOUT;
> > +module_param(nowayout, bool, );
> > +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> > (default="
> > +__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > +
> > +static DEFINE_SPINLOCK(io_lock);   /* the lock for io
> > o

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Wed, 3 Mar 2021 21:48:21 +0100
schrieb Henning Schild :

> Am Wed, 3 Mar 2021 20:31:34 +0100
> schrieb Pavel Machek :
> 
> > Hi!
> >   
> > > > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > > > + {1 << 15, "simatic-ipc:green:run-stop"},
> > > > > + {1 << 7,  "simatic-ipc:yellow:run-stop"},
> > > > > + {1 << 14, "simatic-ipc:red:error"},
> > > > > + {1 << 6,  "simatic-ipc:yellow:error"},
> > > > > + {1 << 13, "simatic-ipc:red:maint"},
> > > > > + {1 << 5,  "simatic-ipc:yellow:maint"},
> > > > > + {0, ""},
> > > > > +};  
> > > > 
> > > > Please use names consistent with other systems, this is user
> > > > visible. If you have two-color power led, it should be
> > > > :green:power... See include/dt-bindings/leds/common.h .
> > > 
> > > Well we wanted to pick names that are printed on the devices and
> > > would like to stick to those. Has been a discussion ...
> > > Can we have symlinks to have multiple names per LED?
> > 
> > No symlinks. We plan to have command line tool to manipulate LEDs,
> > aliases might be possible there.  
> 
> Sounds like a future plan. sysfs and "cat" "echo" are mighty tools and
> "everything is a file" is the best idea ever. So i would say any
> aliasing should live in the kernel, but that is just me. Tools will
> just get out of sync, be missing in busybox or a random yocto ... or
> whichever distro you like.
> On the other hand you have "complexity should be userland" ... i do
> not have the answer.

My personal horror would be systemd-ledd or some dracut snipet for
initrd. But that would be a generic led class discussion ... that tool.

> > > How strong would you feel about us using our names?
> > 
> > Strongly. :-)  
> 
> OK, will try to find a match where possible. 

Do we happen to have a description of the existing names, to find a fit
for ours? In the header you pointed out i only found names without
"meaning"

regards,
Henning

> 
> > Do you have a picture how the leds look like?  
> 
> I could even find chassis photos in our internal review but that would
> be too much.
> 
> Our idea is probably the same as yours. We want the same names across
> all devices. But we struggle with colors because on some boxes we have
> red+green, while other offer yellow ... implemented in HW and messing
> with red+green in some cases.
> 
> But so far we only looked at Siemens devices and thought we could get
> our own "namespace".
> 
> To be honest i could not even tell how our names map on the known
> ones, but we will do our best to find a match. They all are
> "high-level" so "power" and other basic things are not exposed.
> 
> regards,
> Henning
>  
> > Best regards,
> > Pavel  
> 

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Wed, 3 Mar 2021 20:31:34 +0100
schrieb Pavel Machek :

> Hi!
> 
> > > > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > > > +   {1 << 15, "simatic-ipc:green:run-stop"},
> > > > +   {1 << 7,  "simatic-ipc:yellow:run-stop"},
> > > > +   {1 << 14, "simatic-ipc:red:error"},
> > > > +   {1 << 6,  "simatic-ipc:yellow:error"},
> > > > +   {1 << 13, "simatic-ipc:red:maint"},
> > > > +   {1 << 5,  "simatic-ipc:yellow:maint"},
> > > > +   {0, ""},
> > > > +};
> > > 
> > > Please use names consistent with other systems, this is user
> > > visible. If you have two-color power led, it should be
> > > :green:power... See include/dt-bindings/leds/common.h .  
> > 
> > Well we wanted to pick names that are printed on the devices and
> > would like to stick to those. Has been a discussion ...
> > Can we have symlinks to have multiple names per LED?  
> 
> No symlinks. We plan to have command line tool to manipulate LEDs,
> aliases might be possible there.

Sounds like a future plan. sysfs and "cat" "echo" are mighty tools and
"everything is a file" is the best idea ever. So i would say any
aliasing should live in the kernel, but that is just me. Tools will
just get out of sync, be missing in busybox or a random yocto ... or
whichever distro you like.
On the other hand you have "complexity should be userland" ... i do not
have the answer.

> > How strong would you feel about us using our names?  
> 
> Strongly. :-)

OK, will try to find a match where possible. 

> Do you have a picture how the leds look like?

I could even find chassis photos in our internal review but that would
be too much.

Our idea is probably the same as yours. We want the same names across
all devices. But we struggle with colors because on some boxes we have
red+green, while other offer yellow ... implemented in HW and messing
with red+green in some cases.

But so far we only looked at Siemens devices and thought we could get
our own "namespace".

To be honest i could not even tell how our names map on the known ones,
but we will do our best to find a match. They all are "high-level" so
"power" and other basic things are not exposed.

regards,
Henning
 
> Best regards,
>   Pavel

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Wed, 3 Mar 2021 18:40:40 +0100
schrieb Pavel Machek :

> Hi!
> 
> > > > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > > > index 2a698df9da57..c15e1e3c5958 100644
> > > > --- a/drivers/leds/Makefile
> > > > +++ b/drivers/leds/Makefile
> > > > @@ -93,6 +93,7 @@ obj-$(CONFIG_LEDS_TURRIS_OMNIA)
> > > > += leds-turris-omnia.o
> > > > obj-$(CONFIG_LEDS_WM831X_STATUS)+= leds-wm831x-status.o
> > > > obj-$(CONFIG_LEDS_WM8350)   += leds-wm8350.o
> > > > obj-$(CONFIG_LEDS_WRAP) += leds-wrap.o
> > > > +obj-$(CONFIG_LEDS_SIEMENS_SIMATIC_IPC) +=
> > > > simatic-ipc-leds.o
> > > 
> > > Let's put this into drivers/leds/simple. You'll have to create
> > > it.  
> > 
> > Can you please go into detail why? We plan to add more devices in
> > the future, which might in fact make this a little less simple. But
> > we can discuss that when the time is right and start with simple.  
> 
> There's already way too many drivers in the directory, and your driver
> is very different from drivers for camera flash (for example).

Understood, the whole Makefile Kconfig thingy?

Henning

> Best regards,
>   Pavel

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Am Tue, 2 Mar 2021 21:54:52 +0100
schrieb Pavel Machek :

> Hi!
> 
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.  
> 
> Ok.
> 
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 2a698df9da57..c15e1e3c5958 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -93,6 +93,7 @@ obj-$(CONFIG_LEDS_TURRIS_OMNIA)   +=
> > leds-turris-omnia.o obj-$(CONFIG_LEDS_WM831X_STATUS)+=
> > leds-wm831x-status.o obj-$(CONFIG_LEDS_WM8350)  +=
> > leds-wm8350.o obj-$(CONFIG_LEDS_WRAP)   +=
> > leds-wrap.o +obj-$(CONFIG_LEDS_SIEMENS_SIMATIC_IPC) +=
> > simatic-ipc-leds.o  
> 
> Let's put this into drivers/leds/simple. You'll have to create it.

Can you please go into detail why? We plan to add more devices in the
future, which might in fact make this a little less simple. But we can
discuss that when the time is right and start with simple.

regards,
Henning

> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.
> > + */  
> 
> Remove?
> 
> > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > +   {1 << 15, "simatic-ipc:green:run-stop"},
> > +   {1 << 7,  "simatic-ipc:yellow:run-stop"},
> > +   {1 << 14, "simatic-ipc:red:error"},
> > +   {1 << 6,  "simatic-ipc:yellow:error"},
> > +   {1 << 13, "simatic-ipc:red:maint"},
> > +   {1 << 5,  "simatic-ipc:yellow:maint"},
> > +   {0, ""},
> > +};  
> 
> Please use names consistent with other systems, this is user
> visible. If you have two-color power led, it should be
> :green:power... See include/dt-bindings/leds/common.h .
> 
> Please avoid // comments in the code.
> 
> > +module_init(simatic_ipc_led_init_module);
> > +module_exit(simatic_ipc_led_exit_module);  
> 
> No need for such verbosity for functions that are static.
> 
> > +MODULE_LICENSE("GPL");  
> 
> GPL v2?
> 
> Best regards,
>   Pavel
> 

Re: [PATCH 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

Hi, 

thanks for the fast and thorough review!

Am Tue, 2 Mar 2021 10:38:19 -0800
schrieb Guenter Roeck :

> On 3/2/21 8:33 AM, Henning Schild wrote:
> > From: Henning Schild 
> > 
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.
> > 
> > Signed-off-by: Gerd Haeussler 
> > Signed-off-by: Henning Schild 
> > ---
> >  drivers/watchdog/Kconfig   |  11 ++
> >  drivers/watchdog/Makefile  |   1 +
> >  drivers/watchdog/simatic-ipc-wdt.c | 305
> > + 3 files changed, 317 insertions(+)
> >  create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
> > 
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 1fe0042a48d2..948497eb4bef 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -1575,6 +1575,17 @@ config NIC7018_WDT
> >   To compile this driver as a module, choose M here: the
> > module will be called nic7018_wdt.
> >  
> > +config SIEMENS_SIMATIC_IPC_WDT
> > +   tristate "Siemens Simatic IPC Watchdog"
> > +   depends on SIEMENS_SIMATIC_IPC
> > +   select WATCHDOG_CORE
> > +   help
> > + This driver adds support for several watchdogs found in
> > Industrial
> > + PCs from Siemens.
> > +
> > + To compile this driver as a module, choose M here: the
> > module will be
> > + called simatic-ipc-wdt.
> > +
> >  # M68K Architecture
> >  
> >  config M54xx_WATCHDOG
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index f3a6540e725e..7f5c73ec058c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> >  obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
> >  obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
> >  obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
> > +obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
> >  
> >  # M68K Architecture
> >  obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
> > diff --git a/drivers/watchdog/simatic-ipc-wdt.c
> > b/drivers/watchdog/simatic-ipc-wdt.c new file mode 100644
> > index ..b5c8b7ceb404
> > --- /dev/null
> > +++ b/drivers/watchdog/simatic-ipc-wdt.c
> > @@ -0,0 +1,305 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Siemens SIMATIC IPC driver for Watchdogs
> > + *
> > + * Copyright (c) Siemens AG, 2020-2021
> > + *
> > + * Authors:
> > + *  Gerd Haeussler 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.  
> 
> Covered by SPDX-License-Identifier
> 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include > +#include 
> > +#include   
> 
> Alphabetic order please
> 
> > +
> > +#define WD_ENABLE_IOADR0x62
> > +#define WD_TRIGGER_IOADR   0x66
> > +#define GPIO_COMMUNITY0_PORT_ID 0xaf
> > +#define PAD_CFG_DW0_GPP_A_23   0x4b8  
> 
> Please increase indentation and spare another tab
> 
> > +#define SAFE_EN_N_427E 0x01
> > +#define SAFE_EN_N_227E 0x04
> > +#define WD_ENABLED 0x01
> > +
> > +#define TIMEOUT_MIN2
> > +#define TIMEOUT_DEF64
> > +#define TIMEOUT_MAX64
> > +
> > +#define GP_STATUS_REG_227E 0x404D  /* IO PORT for
> > SAFE_EN_N on 227E */ +
> > +static bool nowayout = WATCHDOG_NOWAYOUT;
> > +module_param(nowayout, bool, );
> > +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
> > started (default="
> > +__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > +
> > +static DEFINE_SPINLOCK(io_lock);   /* the lock for io
> > operations */ +static struct watchdog_device wdd;
> > +  
> 
> Having two variables named 'wdd' is confusing. Please chose another
> name.
> 
> > +static struct resource gp_status_reg_227e_res =
> > +   DEFINE_RES_IO_NAMED(GP_STATUS_REG_227E, SZ_1,
> > KBUILD_MODNAME); +
> > +static struct resource io_resource =
> > +   DEFINE_RES_IO_NAMED(WD_ENABLE_IOADR, SZ_1,
> > +   KBUILD_MODNAME " WD_ENABLE_IOADR");
> > +
>

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

Hi Pavel,

thanks for looking into this.

Am Tue, 2 Mar 2021 21:54:52 +0100
schrieb Pavel Machek :

> Hi!
> 
> > This driver adds initial support for several devices from Siemens.
> > It is based on a platform driver introduced in an earlier commit.  
> 
> Ok.
> 
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 2a698df9da57..c15e1e3c5958 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -93,6 +93,7 @@ obj-$(CONFIG_LEDS_TURRIS_OMNIA)   +=
> > leds-turris-omnia.o obj-$(CONFIG_LEDS_WM831X_STATUS)+=
> > leds-wm831x-status.o obj-$(CONFIG_LEDS_WM8350)  +=
> > leds-wm8350.o obj-$(CONFIG_LEDS_WRAP)   +=
> > leds-wrap.o +obj-$(CONFIG_LEDS_SIEMENS_SIMATIC_IPC) +=
> > simatic-ipc-leds.o  
> 
> Let's put this into drivers/leds/simple. You'll have to create it.

Ok will do

> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.
> > + */  
> 
> Remove?

Sure, was found in wdt as well. Thx

> > +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > +   {1 << 15, "simatic-ipc:green:run-stop"},
> > +   {1 << 7,  "simatic-ipc:yellow:run-stop"},
> > +   {1 << 14, "simatic-ipc:red:error"},
> > +   {1 << 6,  "simatic-ipc:yellow:error"},
> > +   {1 << 13, "simatic-ipc:red:maint"},
> > +   {1 << 5,  "simatic-ipc:yellow:maint"},
> > +   {0, ""},
> > +};  
> 
> Please use names consistent with other systems, this is user
> visible. If you have two-color power led, it should be
> :green:power... See include/dt-bindings/leds/common.h .

Well we wanted to pick names that are printed on the devices and would
like to stick to those. Has been a discussion ...
Can we have symlinks to have multiple names per LED?

How strong would you feel about us using our names?

> Please avoid // comments in the code.

Ok

> > +module_init(simatic_ipc_led_init_module);
> > +module_exit(simatic_ipc_led_exit_module);  
> 
> No need for such verbosity for functions that are static.
> 
> > +MODULE_LICENSE("GPL");  
> 
> GPL v2?

Will do.

Stay tuned for v2.

regards,
Henning


> Best regards,
>   Pavel
> 

[PATCH 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs

[Henning Schild]

From: Henning Schild 

Siemens industrial PCs unfortunately can not always be properly
identified the way we used to. An earlier commit introduced code that
allows proper identification without looking at DMI strings that could
differ based on product branding.
Switch over to that proper way and revert commits that used to collect
the machines based on unstable strings.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Fixes: e8796c6c69d1 ("platform/x86: pmc_atom: Add Siemens CONNECT ...")
Fixes: f110d252ae79 ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Fixes: ad0d315b4d4e ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Tested-by: Michael Haener 
Signed-off-by: Henning Schild 
---
 drivers/platform/x86/pmc_atom.c | 39 ++---
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
index ca684ed760d1..03344f5502ad 100644
--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -424,30 +425,31 @@ static const struct dmi_system_id critclk_systems[] = {
},
},
{
-   .ident = "SIMATIC IPC227E",
+   .ident = "SIEMENS AG",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "6ES7647-8B"),
-   },
-   },
-   {
-   .ident = "SIMATIC IPC277E",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "6AV7882-0"),
-   },
-   },
-   {
-   .ident = "CONNECT X300",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "A5E45074588"),
},
},
 
{ /*sentinel*/ }
 };
 
+static int pmc_clk_is_critical(const struct dmi_system_id *d)
+{
+   int ret = true;
+   u32 station_id;
+
+   if (!strcmp(d->ident, "SIEMENS AG")) {
+   if (dmi_walk(simatic_ipc_find_dmi_entry_helper, _id))
+   ret = false;
+   else
+   ret = (station_id == SIMATIC_IPC_IPC227E ||
+  station_id == SIMATIC_IPC_IPC277E);
+   }
+
+   return ret;
+}
+
 static int pmc_setup_clks(struct pci_dev *pdev, void __iomem *pmc_regmap,
  const struct pmc_data *pmc_data)
 {
@@ -462,8 +464,9 @@ static int pmc_setup_clks(struct pci_dev *pdev, void 
__iomem *pmc_regmap,
clk_data->base = pmc_regmap; /* offset is added by client */
clk_data->clks = pmc_data->clks;
if (d) {
-   clk_data->critical = true;
-   pr_info("%s critclks quirk enabled\n", d->ident);
+   clk_data->critical = pmc_clk_is_critical(d);
+   if (clk_data->critical)
+   pr_info("%s critclks quirk enabled\n", d->ident);
}
 
clkdev = platform_device_register_data(>dev, "clk-pmc-atom",
-- 
2.26.2

[PATCH 0/4] add device drivers for Siemens Industrial PCs

[Henning Schild]

From: Henning Schild 

This series adds support for watchdogs and leds of several x86 devices
from Siemens.

It is structured with a platform driver that mainly does identification
of the machines. It might trigger loading of the actual device drivers
by attaching devices to the platform bus.

The identification is vendor specific, parsing a special binary DMI
entry. The implementation of that platform identification is applied on
pmc_atom clock quirks in the final patch.

It is all structured in a way that we can easily add more devices and
more platform drivers later. Internally we have some more code for
hardware monitoring, more leds, watchdogs etc. This will follow some
day.

But the idea here is to share early, and hopefully not fail early.

Henning Schild (4):
  platform/x86: simatic-ipc: add main driver for Siemens devices
  leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
  watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs
  platform/x86: pmc_atom: improve critclk_systems matching for Siemens
PCs

 drivers/leds/Kconfig  |  11 +
 drivers/leds/Makefile |   1 +
 drivers/leds/simatic-ipc-leds.c   | 224 +
 drivers/platform/x86/Kconfig  |   9 +
 drivers/platform/x86/Makefile |   3 +
 drivers/platform/x86/pmc_atom.c   |  39 +--
 drivers/platform/x86/simatic-ipc.c| 166 ++
 drivers/watchdog/Kconfig  |  11 +
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/simatic-ipc-wdt.c| 305 ++
 .../platform_data/x86/simatic-ipc-base.h  |  33 ++
 include/linux/platform_data/x86/simatic-ipc.h |  68 
 12 files changed, 853 insertions(+), 18 deletions(-)
 create mode 100644 drivers/leds/simatic-ipc-leds.c
 create mode 100644 drivers/platform/x86/simatic-ipc.c
 create mode 100644 drivers/watchdog/simatic-ipc-wdt.c
 create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
 create mode 100644 include/linux/platform_data/x86/simatic-ipc.h

-- 
2.26.2

[PATCH 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs

[Henning Schild]

From: Henning Schild 

This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.

Signed-off-by: Gerd Haeussler 
Signed-off-by: Henning Schild 
---
 drivers/watchdog/Kconfig   |  11 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/simatic-ipc-wdt.c | 305 +
 3 files changed, 317 insertions(+)
 create mode 100644 drivers/watchdog/simatic-ipc-wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1fe0042a48d2..948497eb4bef 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1575,6 +1575,17 @@ config NIC7018_WDT
  To compile this driver as a module, choose M here: the module will be
  called nic7018_wdt.
 
+config SIEMENS_SIMATIC_IPC_WDT
+   tristate "Siemens Simatic IPC Watchdog"
+   depends on SIEMENS_SIMATIC_IPC
+   select WATCHDOG_CORE
+   help
+ This driver adds support for several watchdogs found in Industrial
+ PCs from Siemens.
+
+ To compile this driver as a module, choose M here: the module will be
+ called simatic-ipc-wdt.
+
 # M68K Architecture
 
 config M54xx_WATCHDOG
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f3a6540e725e..7f5c73ec058c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
 obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
 obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
 obj-$(CONFIG_KEEMBAY_WATCHDOG) += keembay_wdt.o
+obj-$(CONFIG_SIEMENS_SIMATIC_IPC_WDT) += simatic-ipc-wdt.o
 
 # M68K Architecture
 obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
diff --git a/drivers/watchdog/simatic-ipc-wdt.c 
b/drivers/watchdog/simatic-ipc-wdt.c
new file mode 100644
index ..b5c8b7ceb404
--- /dev/null
+++ b/drivers/watchdog/simatic-ipc-wdt.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC driver for Watchdogs
+ *
+ * Copyright (c) Siemens AG, 2020-2021
+ *
+ * Authors:
+ *  Gerd Haeussler 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WD_ENABLE_IOADR0x62
+#define WD_TRIGGER_IOADR   0x66
+#define GPIO_COMMUNITY0_PORT_ID 0xaf
+#define PAD_CFG_DW0_GPP_A_23   0x4b8
+#define SAFE_EN_N_427E 0x01
+#define SAFE_EN_N_227E 0x04
+#define WD_ENABLED 0x01
+
+#define TIMEOUT_MIN2
+#define TIMEOUT_DEF64
+#define TIMEOUT_MAX64
+
+#define GP_STATUS_REG_227E 0x404D  /* IO PORT for SAFE_EN_N on 227E */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static DEFINE_SPINLOCK(io_lock);   /* the lock for io operations */
+static struct watchdog_device wdd;
+
+static struct resource gp_status_reg_227e_res =
+   DEFINE_RES_IO_NAMED(GP_STATUS_REG_227E, SZ_1, KBUILD_MODNAME);
+
+static struct resource io_resource =
+   DEFINE_RES_IO_NAMED(WD_ENABLE_IOADR, SZ_1,
+   KBUILD_MODNAME " WD_ENABLE_IOADR");
+
+/* the actual start will be discovered with pci, 0 is a placeholder */
+static struct resource mem_resource =
+   DEFINE_RES_MEM_NAMED(0, SZ_4, "WD_RESET_BASE_ADR");
+
+static u32 wd_timeout_table[] = {2, 4, 6, 8, 16, 32, 48, 64 };
+static void __iomem *wd_reset_base_addr;
+
+static int get_timeout_idx(u32 timeout)
+{
+   int i;
+
+   i = ARRAY_SIZE(wd_timeout_table) - 1;
+   for (; i >= 0; i--) {
+   if (timeout >= wd_timeout_table[i])
+   break;
+   }
+
+   return i;
+}
+
+static int wd_start(struct watchdog_device *wdd)
+{
+   u8 regval;
+
+   spin_lock(_lock);
+
+   regval = inb(WD_ENABLE_IOADR);
+   regval |= WD_ENABLED;
+   outb(regval, WD_ENABLE_IOADR);
+
+   spin_unlock(_lock);
+
+   return 0;
+}
+
+static int wd_stop(struct watchdog_device *wdd)
+{
+   u8 regval;
+
+   spin_lock(_lock);
+
+   regval = inb(WD_ENABLE_IOADR);
+   regval &= ~WD_ENABLED;
+   outb(regval, WD_ENABLE_IOADR);
+
+   spin_unlock(_lock);
+
+   return 0;
+}
+
+static int wd_ping(struct watchdog_device *wdd)
+{
+   inb(WD_TRIGGER_IOADR);
+   return 0;
+}
+
+static int wd_set_timeout(struct watchdog_device *wdd, unsigned int t)
+{
+   u8 regval;
+   int timeout_idx = get_timeout_idx(t);
+
+   spin_lock(_lock);
+
+   regval = inb(WD_ENABLE_IOADR) & 0xc7;
+   regval |= timeout_idx << 3;
+   outb(regval, WD_ENABLE_IOADR);

[PATCH 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Henning Schild]

From: Henning Schild 

This mainly implements detection of these devices and will allow
secondary drivers to work on such machines.

The identification is DMI-based with a vendor specific way to tell them
apart in a reliable way.

Drivers for LEDs and Watchdogs will follow to make use of that platform
detection.

Signed-off-by: Gerd Haeussler 
Signed-off-by: Henning Schild 
---
 drivers/platform/x86/Kconfig  |   9 +
 drivers/platform/x86/Makefile |   3 +
 drivers/platform/x86/simatic-ipc.c| 166 ++
 .../platform_data/x86/simatic-ipc-base.h  |  33 
 include/linux/platform_data/x86/simatic-ipc.h |  68 +++
 5 files changed, 279 insertions(+)
 create mode 100644 drivers/platform/x86/simatic-ipc.c
 create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h
 create mode 100644 include/linux/platform_data/x86/simatic-ipc.h

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ad4e630e73e2..bb9e282d89cf 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1284,6 +1284,15 @@ config INTEL_TELEMETRY
  directly via debugfs files. Various tools may use
  this interface for SoC state monitoring.
 
+config SIEMENS_SIMATIC_IPC
+   tristate "Siemens Simatic IPC Class driver"
+   depends on PCI
+   help
+ This Simatic IPC class driver is the central of several drivers. It
+ is mainly used for system identification, after which drivers in other
+ classes will take care of driving specifics of those machines.
+ i.e. leds and watchdogs
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 60d554073749..26cdebf2e701 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -138,3 +138,6 @@ obj-$(CONFIG_INTEL_TELEMETRY)   += 
intel_telemetry_core.o \
   intel_telemetry_pltdrv.o \
   intel_telemetry_debugfs.o
 obj-$(CONFIG_PMC_ATOM) += pmc_atom.o
+
+# Siemens Simatic Industrial PCs
+obj-$(CONFIG_SIEMENS_SIMATIC_IPC)  += simatic-ipc.o
diff --git a/drivers/platform/x86/simatic-ipc.c 
b/drivers/platform/x86/simatic-ipc.c
new file mode 100644
index ..6adcdac1a0d7
--- /dev/null
+++ b/drivers/platform/x86/simatic-ipc.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC driver for LEDs
+ *
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ *  Henning Schild 
+ *  Jan Kiszka 
+ *  Gerd Haeussler 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static struct platform_device *ipc_led_platform_device;
+static struct platform_device *ipc_wdt_platform_device;
+
+static const struct dmi_system_id simatic_ipc_whitelist[] = {
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
+   },
+   },
+   {}
+};
+
+static struct simatic_ipc_platform platform_data;
+
+static struct {
+   u32 station_id;
+   u8 led_mode;
+   u8 wdt_mode;
+} device_modes[] = {
+   { SIMATIC_IPC_IPC127E, SIMATIC_IPC_DEVICE_127E, 
SIMATIC_IPC_DEVICE_NONE},
+   { SIMATIC_IPC_IPC227D, SIMATIC_IPC_DEVICE_227D, 
SIMATIC_IPC_DEVICE_NONE},
+   { SIMATIC_IPC_IPC227E, SIMATIC_IPC_DEVICE_427E, 
SIMATIC_IPC_DEVICE_227E},
+   { SIMATIC_IPC_IPC277E, SIMATIC_IPC_DEVICE_NONE, 
SIMATIC_IPC_DEVICE_227E},
+   { SIMATIC_IPC_IPC427D, SIMATIC_IPC_DEVICE_427E, 
SIMATIC_IPC_DEVICE_NONE},
+   { SIMATIC_IPC_IPC427E, SIMATIC_IPC_DEVICE_427E, 
SIMATIC_IPC_DEVICE_427E},
+   { SIMATIC_IPC_IPC477E, SIMATIC_IPC_DEVICE_NONE, 
SIMATIC_IPC_DEVICE_427E},
+};
+
+static int register_platform_devices(u32 station_id)
+{
+   int i;
+   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
+   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;
+
+   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
+
+   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
+   if (device_modes[i].station_id == station_id) {
+   ledmode = device_modes[i].led_mode;
+   wdtmode = device_modes[i].wdt_mode;
+   break;
+   }
+   }
+
+   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
+   platform_data.devmode = ledmode;
+   ipc_led_platform_device = platform_device_register_data
+   (NULL, KBUILD_MODNAME "_leds", PLATFORM_DEVID_NONE,
+_data, sizeof(struct simatic_ipc_platform));
+   if (IS_ERR(ipc_led_platform_device))
+   return PTR_ERR(ipc_led_platform_device);
+
+ 

[PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Henning Schild]

From: Henning Schild 

This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.

Signed-off-by: Gerd Haeussler 
Signed-off-by: Henning Schild 
---
 drivers/leds/Kconfig|  11 ++
 drivers/leds/Makefile   |   1 +
 drivers/leds/simatic-ipc-leds.c | 224 
 3 files changed, 236 insertions(+)
 create mode 100644 drivers/leds/simatic-ipc-leds.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b6742b4231bf..3ee6fc613a0a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -928,6 +928,17 @@ config LEDS_ACER_A500
  This option enables support for the Power Button LED of
  Acer Iconia Tab A500.
 
+config LEDS_SIEMENS_SIMATIC_IPC
+   tristate "LED driver for Siemens Simatic IPCs"
+   depends on LEDS_CLASS
+   depends on SIEMENS_SIMATIC_IPC
+   help
+ This option enables support for the LEDs of several Industrial PCs
+ from Siemens.
+
+ To compile this driver as a module, choose M here: the module
+ will be called simatic-ipc-leds.
+
 comment "Flash and Torch LED drivers"
 source "drivers/leds/flash/Kconfig"
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 2a698df9da57..c15e1e3c5958 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_LEDS_TURRIS_OMNIA)   += 
leds-turris-omnia.o
 obj-$(CONFIG_LEDS_WM831X_STATUS)   += leds-wm831x-status.o
 obj-$(CONFIG_LEDS_WM8350)  += leds-wm8350.o
 obj-$(CONFIG_LEDS_WRAP)+= leds-wrap.o
+obj-$(CONFIG_LEDS_SIEMENS_SIMATIC_IPC) += simatic-ipc-leds.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_CR0014114)   += leds-cr0014114.o
diff --git a/drivers/leds/simatic-ipc-leds.c b/drivers/leds/simatic-ipc-leds.c
new file mode 100644
index ..760aef1d4ae1
--- /dev/null
+++ b/drivers/leds/simatic-ipc-leds.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Siemens SIMATIC IPC driver for LEDs
+ *
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ *  Henning Schild 
+ *  Jan Kiszka 
+ *  Gerd Haeussler 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SIMATIC_IPC_LED_PORT_BASE  0x404E
+
+struct simatic_ipc_led {
+   unsigned int value; /* mask for io and offset for mem */
+   char name[32];
+   struct led_classdev cdev;
+};
+
+static struct simatic_ipc_led simatic_ipc_leds_io[] = {
+   {1 << 15, "simatic-ipc:green:run-stop"},
+   {1 << 7,  "simatic-ipc:yellow:run-stop"},
+   {1 << 14, "simatic-ipc:red:error"},
+   {1 << 6,  "simatic-ipc:yellow:error"},
+   {1 << 13, "simatic-ipc:red:maint"},
+   {1 << 5,  "simatic-ipc:yellow:maint"},
+   {0, ""},
+};
+
+/* the actual start will be discovered with pci, 0 is a placeholder */
+struct resource simatic_ipc_led_mem_res =
+   DEFINE_RES_MEM_NAMED(0, SZ_4K, KBUILD_MODNAME);
+
+static void *simatic_ipc_led_memory;
+
+static struct simatic_ipc_led simatic_ipc_leds_mem[] = {
+   {0x500 + 0x1A0, "simatic-ipc:red:run-stop"},
+   {0x500 + 0x1A8, "simatic-ipc:green:run-stop"},
+   {0x500 + 0x1C8, "simatic-ipc:red:error"},
+   {0x500 + 0x1D0, "simatic-ipc:green:error"},
+   {0x500 + 0x1E0, "simatic-ipc:red:maint"},
+   {0x500 + 0x198, "simatic-ipc:green:maint"},
+   {0, ""},
+};
+
+static struct resource simatic_ipc_led_io_res =
+   DEFINE_RES_IO_NAMED(SIMATIC_IPC_LED_PORT_BASE, SZ_1, KBUILD_MODNAME);
+
+static DEFINE_SPINLOCK(reg_lock);
+
+static void simatic_ipc_led_set_io(struct led_classdev *led_cd,
+  enum led_brightness brightness)
+{
+   struct simatic_ipc_led *led =
+   container_of(led_cd, struct simatic_ipc_led, cdev);
+   unsigned long flags;
+   unsigned int val;
+
+   spin_lock_irqsave(_lock, flags);
+
+   val = inw(SIMATIC_IPC_LED_PORT_BASE);
+   if (brightness == LED_OFF)
+   outw(val | led->value, SIMATIC_IPC_LED_PORT_BASE);
+   else
+   outw(val & ~led->value, SIMATIC_IPC_LED_PORT_BASE);
+
+   spin_unlock_irqrestore(_lock, flags);
+}
+
+static enum led_brightness simatic_ipc_led_get_io(struct led_classdev *led_cd)
+{
+   struct simatic_ipc_led *led =
+   container_of(led_cd, struct simatic_ipc_led, cdev);
+
+   return inw(SIMATIC_IPC_LED_PORT_BASE) & led->value ?
+   LED_OFF : led_cd->max_brightness;
+}
+
+static 

Re: [PATCH v2 2/3] rtc: rx6110: add ACPI bindings to I2C

[Henning Schild]

We are trying to reach out to Epson to find valid IDs, but will do that
off-list for now.

In the meantime we will propose just the I2C patches, without ACPI.

We have Werner Zeh here, who pushed the coreboot change. In coreboot
nobody objected, maybe they have not been aware of the processes or it
was missed in their review.

Werner i think the coreboot change should be reverted so it does not
enter a release and will become legacy that needs to be supported. Let
us revisit it once we have the proper IDs. If that fails we have to
look into the other options that Andy proposed. There is no point
having the coreboot support without the Linux-user ... 

regards,
Henning

Am Tue, 17 Nov 2020 13:41:08 +0200
schrieb Andy Shevchenko :

> +Cc: Simon
> 
> Simon, this is an issue with ACPI IDs and I think JFYI would be an
> interesting topic since this may happen in the future in U-Boot or
> other projects. Also, you may know people from coreboot to figure out
> what to do with this case and how to prevent something similar from
> happening in the future.
> 
> On Tue, Nov 17, 2020 at 1:33 PM Andy Shevchenko
>  wrote:
> >
> > On Tue, Nov 17, 2020 at 11:51 AM johannes-h...@siemens.com
> >  wrote:  
> > >
> > > Hello Val,
> > >
> > > my name is Johannes Hahn from Siemens AG in Germany.
> > > Our product Open Controller II (OCII)[1] uses the Realtime Clock
> > > RX6110SA from SEIKO EPSON.  
> >
> > Nice to hear from you!
> >  
> > > Currently there is a merge request ongoing for the Linux Kernel
> > > master branch[2] which adds I²C and ACPI support to your original
> > > driver implementation.
> > >
> > > Simultaneously there is an already merged patch-set for
> > > coreboot[3] available creating the ACPI (SSDT) table entries for
> > > the RX6110SA.  
> >
> > Thanks for pointers, I commented there. The ACPI ID change must be
> > reverted! 
> > > The OCII uses coreboot for firmware initialization.
> > >
> > > During the merge request the eligible objection arose that the
> > > ACPI ID used in the Linux driver patch is not conforming the ACPI
> > > Specification. Indeed it does not. But when searching for a
> > > product identifier of RX6110SA I was not able to find a
> > > sufficient one with respect to the ACPI Specification (see [4]
> > > chapter 6.1.5 _HID (Hardware ID),[5]).  
> >
> > Unfortunately many vendors, even being registered in the ACPI/PNP
> > registry, are still neglecting the process.
> >  
> > > According to the fact that there are other Linux RTC drivers on
> > > the Kernel mainline[6] which support ACPI matching that also do
> > > not have ACPI Specification compatible IDs we used that as an
> > > example for our first patch attempt.  
> >
> > I answered this in previous mail.
> >  
> > > A PNP ID for SEIKO EPSON is already registered at UEFI
> > > database[7].
> > >
> > > What I kindly ask your for is an ACPI Specification conforming
> > > Product Identifier for the RX6110SA RTC ? According to [5] this
> > > Product Identifier should be "... always four-character
> > > hexadecimal numbers (0-9 and A-F)".
> > >
> > > In case you do not know it our can not acquire/create one could
> > > you please redirect me to someone from SEIKO EPSON who can help
> > > me with that demand ?  
> >
> > So, to be on the constructive page (I thought initially you are
> > from G company, but anyway) you may do the following:
> >
> > - (for prototyping only) you may use the PRP0001 approach,
> > described in [8]
> > - you may issue an ID under your (Siemens) vendor ID
> > - you may insist G company to issue the ID under their vendor space
> > (thru coreboot)
> > - (the best option) to communicate to Seiko Epson to get official ID
> > from them for this component (and ID mustn't abuse 6.1.5)
> >
> > Unfortunately I have no contacts there, but I think the best effort
> > is to contact their support and at the same time ask ASWG [9] how to
> > proceed. I Cc'ed this to ACPI people in Linux kernel, maybe they can
> > help.
> >
> > Of course you have choice to push bad ID forward and use precedence
> > (like many other companies, even Intel in past, do with firmwares
> > and Linux kernel is full of badly formed IDs), but since the change
> > is not existed in read devices I would really like to see proper
> > process to be followed.
> >
> > In the Linux kernel I'm in principle trying to prevent bad IDs from
> > happening as much as I can.
> >  
> > > [1]:
> > > (https://mall.industry.siemens.com/mall/en/WW/Catalog/Product/6ES7677-2DB42-0GB0)
> > > [2]: https://lkml.org/lkml/2020/11/12/561 [3]:
> > > https://review.coreboot.org/c/coreboot/+/47235 [4]:
> > > https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> > > [5]: https://www.uefi.org/PNP_ACPI_Registry [6]:
> > > https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-ds1307.c#L1142
> > > [7]: https://www.uefi.org/PNP_ID_List?search=SEIKO+EPSON  
> >
> > [8]:
> > 

Re: [PATCH v2 2/3] rtc: rx6110: add ACPI bindings to I2C

[Henning Schild]

Am Mon, 16 Nov 2020 16:46:31 +0200
schrieb Andy Shevchenko :

> On Thu, Nov 12, 2020 at 02:07:33PM +0100, Claudius Heine wrote:
> > From: Johannes Hahn 
> > 
> > This allows the RX6110 driver to be automatically assigned to the
> > right device on the I2C bus.  
> 
> Before adding new ACPI ID, can you provide an evidence (either from
> vendor of the component, or a real snapshot of DSDT from device on
> market) that this is real ID?
> 
> Before that happens, NAK.
> 
> P.S. Seems to me that this is kinda cargo cult patch because proposed
> ID is against ACPI and PNP registry and ACPI specification.

In fact we pushed it in coreboot and Linux at the same time.

https://review.coreboot.org/c/coreboot/+/47235

That is the evidence. But in case this is wrong we can probably still
change coreboot, even though the patches have been merged there already.

Maybe you can go into detail where you see the violations and maybe
even suggest fixes that come to mind.

Henning

Re: [PATCH 0/2] Adding I2C support to RX6110 RTC

[Henning Schild]

Am Fri, 6 Nov 2020 08:59:08 +0100
schrieb Alexandre Belloni :

> On 06/11/2020 08:40:34+0100, Henning Schild wrote:
> > Hi,
> > 
> > Am Thu, 5 Nov 2020 23:14:51 +0100
> > schrieb Alexandre Belloni :
> >   
> > > Hello Claudius!
> > > 
> > > It has been a while ;)
> > > 
> > > On 04/11/2020 11:26:27+0100, Claudius Heine wrote:  
> > > > Hi,
> > > > 
> > > > this patch introduces I2C support to the RX6110 RTC driver and
> > > > also adds an ACPI identifier to it.
> > > > 
> > > > Since we are also pushing the coreboot changes for the ACPI
> > > > table upstream in parallel, we are free to name this ACPI entry
> > > > however we like it seems. So any feedback on that would be
> > > > welcome ;) 
> > > 
> > > I don't care too much about ACPI so if you are really looking for
> > > advice there, I guess you should ask seom of the ACPI guys (but I
> > > guess you are free to choose whatever you want).
> > >   
> > 
> > This is the coreboot stuff currently under review.
> > 
> > https://review.coreboot.org/c/coreboot/+/47235
> >   
> 
> I can't really comment on the patch, however another part is worrying:
> if VLF is set, coreboot is resetting the time to a valid value (user
> defined or the build date). This is nasty because this hides the event
> from the kernel and ulimately, userspace has no way of knowing whether
> the RTC date is the real date or just a dummy date.

Is that worrying problem part of the patch, or just a general
observation looking at their driver?

I think in the patches we should focus on whether I2C and ACPI support
should be added, and how.

Henning

Re: [PATCH 0/2] Adding I2C support to RX6110 RTC

[Henning Schild]

Hi,

Am Thu, 5 Nov 2020 23:14:51 +0100
schrieb Alexandre Belloni :

> Hello Claudius!
> 
> It has been a while ;)
> 
> On 04/11/2020 11:26:27+0100, Claudius Heine wrote:
> > Hi,
> > 
> > this patch introduces I2C support to the RX6110 RTC driver and also
> > adds an ACPI identifier to it.
> > 
> > Since we are also pushing the coreboot changes for the ACPI table
> > upstream in parallel, we are free to name this ACPI entry however we
> > like it seems. So any feedback on that would be welcome ;)
> >   
> 
> I don't care too much about ACPI so if you are really looking for
> advice there, I guess you should ask seom of the ACPI guys (but I
> guess you are free to choose whatever you want).
> 

This is the coreboot stuff currently under review.

https://review.coreboot.org/c/coreboot/+/47235

Henning

Re: [PATCH v2] scripts: builddeb: allow customization of "Depends:" fields

[Henning Schild]

Hi,

this is a simpler version that allows just the customization of
"Depends:", as requested by Ben.

It addresses the security issues Jim mentioned by not using eval
anymore.

Henning

Am Mon, 4 Dec 2017 17:48:08 +0100
schrieb Henning Schild <henning.sch...@siemens.com>:

> The debian packages coming out of "make *deb-pkg" lack the "Depends:"
> field. If one tries to install a fresh system with such a
> "linux-image" debootstrap or multistrap might try to install the
> kernel before its deps and the package hooks will fail.
> 
> Different debian-based distros use different values for the missing
> fields. And the values differ between distro versions as well. So
> hardcoding is not possible.
> 
> This patch introduces an option variable for every debian package
> built by builddeb. That allows advanced users to specify additional
> dependencies for all packages. All the new variables are optional.
> 
> Signed-off-by: Henning Schild <henning.sch...@siemens.com>
> ---
>  scripts/package/builddeb | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index b4f0f2b3f8d2..079bd4c4aea9 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -288,6 +288,7 @@ if [ "$ARCH" = "um" ]; then
>  
>  Package: $packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE
>  Description: User Mode Linux kernel, version $version
>   User-mode Linux is a port of the Linux kernel to its own system call
>   interface.  It provides a kind of virtual machine, which runs Linux
> @@ -304,6 +305,7 @@ else
>  
>  Package: $packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE
>  Description: Linux kernel, version $version
>   This package contains the Linux kernel, modules and corresponding
> other files, version: $version.
> @@ -335,6 +337,7 @@ cat <> debian/control
>  
>  Package: $kernel_headers_packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE_HEADERS
>  Description: Linux kernel headers for $KERNELRELEASE on
> \${kernel:debarch} This package provides kernel header files for
> $KERNELRELEASE on \${kernel:debarch} .
> @@ -347,6 +350,7 @@ Package: $libc_headers_packagename
>  Section: devel
>  Provides: linux-kernel-headers
>  Architecture: any
> +Depends: $KDEB_DEP_LIBC_HEADERS
>  Description: Linux support headers for userspace development
>   This package provides userspaces headers from the Linux kernel.
> These headers are used by the installed headers for GNU glibc and
> other system libraries. @@ -375,6 +379,7 @@ if [ -n "$BUILD_DEBUG"
> ] ; then 
>  Package: $dbg_packagename
>  Section: debug
> +Depends: $KDEB_DEP_IMAGE_DBG
>  Architecture: any
>  Description: Linux kernel debugging symbols for $version
>   This package will come in handy if you need to debug the kernel. It
> provides

Re: [PATCH v2] scripts: builddeb: allow customization of "Depends:" fields

[Henning Schild]

Hi,

this is a simpler version that allows just the customization of
"Depends:", as requested by Ben.

It addresses the security issues Jim mentioned by not using eval
anymore.

Henning

Am Mon, 4 Dec 2017 17:48:08 +0100
schrieb Henning Schild :

> The debian packages coming out of "make *deb-pkg" lack the "Depends:"
> field. If one tries to install a fresh system with such a
> "linux-image" debootstrap or multistrap might try to install the
> kernel before its deps and the package hooks will fail.
> 
> Different debian-based distros use different values for the missing
> fields. And the values differ between distro versions as well. So
> hardcoding is not possible.
> 
> This patch introduces an option variable for every debian package
> built by builddeb. That allows advanced users to specify additional
> dependencies for all packages. All the new variables are optional.
> 
> Signed-off-by: Henning Schild 
> ---
>  scripts/package/builddeb | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index b4f0f2b3f8d2..079bd4c4aea9 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -288,6 +288,7 @@ if [ "$ARCH" = "um" ]; then
>  
>  Package: $packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE
>  Description: User Mode Linux kernel, version $version
>   User-mode Linux is a port of the Linux kernel to its own system call
>   interface.  It provides a kind of virtual machine, which runs Linux
> @@ -304,6 +305,7 @@ else
>  
>  Package: $packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE
>  Description: Linux kernel, version $version
>   This package contains the Linux kernel, modules and corresponding
> other files, version: $version.
> @@ -335,6 +337,7 @@ cat <> debian/control
>  
>  Package: $kernel_headers_packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE_HEADERS
>  Description: Linux kernel headers for $KERNELRELEASE on
> \${kernel:debarch} This package provides kernel header files for
> $KERNELRELEASE on \${kernel:debarch} .
> @@ -347,6 +350,7 @@ Package: $libc_headers_packagename
>  Section: devel
>  Provides: linux-kernel-headers
>  Architecture: any
> +Depends: $KDEB_DEP_LIBC_HEADERS
>  Description: Linux support headers for userspace development
>   This package provides userspaces headers from the Linux kernel.
> These headers are used by the installed headers for GNU glibc and
> other system libraries. @@ -375,6 +379,7 @@ if [ -n "$BUILD_DEBUG"
> ] ; then 
>  Package: $dbg_packagename
>  Section: debug
> +Depends: $KDEB_DEP_IMAGE_DBG
>  Architecture: any
>  Description: Linux kernel debugging symbols for $version
>   This package will come in handy if you need to debug the kernel. It
> provides

[PATCH v2] scripts: builddeb: allow customization of "Depends:" fields

[Henning Schild]

The debian packages coming out of "make *deb-pkg" lack the "Depends:"
field. If one tries to install a fresh system with such a "linux-image"
debootstrap or multistrap might try to install the kernel before its
deps and the package hooks will fail.

Different debian-based distros use different values for the missing
fields. And the values differ between distro versions as well. So
hardcoding is not possible.

This patch introduces an option variable for every debian package built
by builddeb. That allows advanced users to specify additional
dependencies for all packages. All the new variables are optional.

Signed-off-by: Henning Schild <henning.sch...@siemens.com>
---
 scripts/package/builddeb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index b4f0f2b3f8d2..079bd4c4aea9 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -288,6 +288,7 @@ if [ "$ARCH" = "um" ]; then
 
 Package: $packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE
 Description: User Mode Linux kernel, version $version
  User-mode Linux is a port of the Linux kernel to its own system call
  interface.  It provides a kind of virtual machine, which runs Linux
@@ -304,6 +305,7 @@ else
 
 Package: $packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE
 Description: Linux kernel, version $version
  This package contains the Linux kernel, modules and corresponding other
  files, version: $version.
@@ -335,6 +337,7 @@ cat <> debian/control
 
 Package: $kernel_headers_packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE_HEADERS
 Description: Linux kernel headers for $KERNELRELEASE on \${kernel:debarch}
  This package provides kernel header files for $KERNELRELEASE on 
\${kernel:debarch}
  .
@@ -347,6 +350,7 @@ Package: $libc_headers_packagename
 Section: devel
 Provides: linux-kernel-headers
 Architecture: any
+Depends: $KDEB_DEP_LIBC_HEADERS
 Description: Linux support headers for userspace development
  This package provides userspaces headers from the Linux kernel.  These headers
  are used by the installed headers for GNU glibc and other system libraries.
@@ -375,6 +379,7 @@ if [ -n "$BUILD_DEBUG" ] ; then
 
 Package: $dbg_packagename
 Section: debug
+Depends: $KDEB_DEP_IMAGE_DBG
 Architecture: any
 Description: Linux kernel debugging symbols for $version
  This package will come in handy if you need to debug the kernel. It provides
-- 
2.13.6

[PATCH v2] scripts: builddeb: allow customization of "Depends:" fields

[Henning Schild]

The debian packages coming out of "make *deb-pkg" lack the "Depends:"
field. If one tries to install a fresh system with such a "linux-image"
debootstrap or multistrap might try to install the kernel before its
deps and the package hooks will fail.

Different debian-based distros use different values for the missing
fields. And the values differ between distro versions as well. So
hardcoding is not possible.

This patch introduces an option variable for every debian package built
by builddeb. That allows advanced users to specify additional
dependencies for all packages. All the new variables are optional.

Signed-off-by: Henning Schild 
---
 scripts/package/builddeb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index b4f0f2b3f8d2..079bd4c4aea9 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -288,6 +288,7 @@ if [ "$ARCH" = "um" ]; then
 
 Package: $packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE
 Description: User Mode Linux kernel, version $version
  User-mode Linux is a port of the Linux kernel to its own system call
  interface.  It provides a kind of virtual machine, which runs Linux
@@ -304,6 +305,7 @@ else
 
 Package: $packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE
 Description: Linux kernel, version $version
  This package contains the Linux kernel, modules and corresponding other
  files, version: $version.
@@ -335,6 +337,7 @@ cat <> debian/control
 
 Package: $kernel_headers_packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE_HEADERS
 Description: Linux kernel headers for $KERNELRELEASE on \${kernel:debarch}
  This package provides kernel header files for $KERNELRELEASE on 
\${kernel:debarch}
  .
@@ -347,6 +350,7 @@ Package: $libc_headers_packagename
 Section: devel
 Provides: linux-kernel-headers
 Architecture: any
+Depends: $KDEB_DEP_LIBC_HEADERS
 Description: Linux support headers for userspace development
  This package provides userspaces headers from the Linux kernel.  These headers
  are used by the installed headers for GNU glibc and other system libraries.
@@ -375,6 +379,7 @@ if [ -n "$BUILD_DEBUG" ] ; then
 
 Package: $dbg_packagename
 Section: debug
+Depends: $KDEB_DEP_IMAGE_DBG
 Architecture: any
 Description: Linux kernel debugging symbols for $version
  This package will come in handy if you need to debug the kernel. It provides
-- 
2.13.6

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Fri, 1 Dec 2017 18:47:38 +
schrieb Ben Hutchings <b...@decadent.org.uk>:

> On Fri, 2017-12-01 at 19:34 +0100, Henning Schild wrote:
> > Am Fri, 1 Dec 2017 16:51:12 +
> > schrieb Ben Hutchings <b...@decadent.org.uk>:
> >   
> > > On Fri, 2017-12-01 at 15:56 +, Henning Schild wrote:  
> > > > The debian packages coming out of "make *deb-pkg" lack some
> > > > critical information in the control-files e.g. the "Depends:"
> > > > field. If one tries to install a fresh system with such a
> > > > "linux-image" debootstrap or multistrap might try to install
> > > > the kernel before its deps and the package hooks will fail.
> > > 
> > > I assume you're talking about those hook scripts being run while
> > > the packages they belong to are only unpacked?  I hadn't thought
> > > about this issue, but it seems to me that those hook scripts
> > > generally ought to be fixed to handle this case properly.  Most
> > > of the packages installing hook scripts for kernel packages are
> > > not going to be dependencies of linux-image packages, so it will
> > > never be safe for them to assume their package has been fully
> > > installed.  
> > 
> > Yes these hook scripts fail when installing the kernel on another
> > system. Indeed we seem to have a case where packages installed on
> > the build-machine cause install-time deps for the package.  
> 
> Can you give an example?  I don't see how that would happen.

Scripts in /etc/kernel/ will end up as hooks for the kernel-package, if
you do not set KDEB_HOOKDIR. Looking at an example system that pulls in
things like "pm-utils, grub-pc .. initramfs". With this mechanism any
package placing a hook in /etc/kernel can influence the deps. I guess
in practice that is prevented with policies on what these scripts are
allowed to do.

> > In my case the build-machine is pretty minimal but i still want
> > some of that i.e. initramfs.
> >   
> > > > Different debian-based distros use different values for the
> > > > missing fields. And the values differ between distro versions
> > > > as well. So hardcoding of e.g. "Depends" is not possible.
> > > 
> > > The dependencies also depend on the kernel configuration.  (And a
> > > custom kernel built with 'make deb-pkg' often won't have any
> > > dependencies outside of essential packages.)  
> > 
> > In fact it does not have any at the moment, there is no essential.
> > Or maybe that is hidden in debian-magic.  
> [...]
> 
> Essential packages are always installed, which means there is no need
> to declare a dependency on them (in fact it is discouraged):
> https://www.debian.org/doc/debian-policy/#dependencies

Ok, i will need to double-check how multistrap deals with those.

Henning

> Ben.
> 

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Fri, 1 Dec 2017 18:47:38 +
schrieb Ben Hutchings :

> On Fri, 2017-12-01 at 19:34 +0100, Henning Schild wrote:
> > Am Fri, 1 Dec 2017 16:51:12 +
> > schrieb Ben Hutchings :
> >   
> > > On Fri, 2017-12-01 at 15:56 +, Henning Schild wrote:  
> > > > The debian packages coming out of "make *deb-pkg" lack some
> > > > critical information in the control-files e.g. the "Depends:"
> > > > field. If one tries to install a fresh system with such a
> > > > "linux-image" debootstrap or multistrap might try to install
> > > > the kernel before its deps and the package hooks will fail.
> > > 
> > > I assume you're talking about those hook scripts being run while
> > > the packages they belong to are only unpacked?  I hadn't thought
> > > about this issue, but it seems to me that those hook scripts
> > > generally ought to be fixed to handle this case properly.  Most
> > > of the packages installing hook scripts for kernel packages are
> > > not going to be dependencies of linux-image packages, so it will
> > > never be safe for them to assume their package has been fully
> > > installed.  
> > 
> > Yes these hook scripts fail when installing the kernel on another
> > system. Indeed we seem to have a case where packages installed on
> > the build-machine cause install-time deps for the package.  
> 
> Can you give an example?  I don't see how that would happen.

Scripts in /etc/kernel/ will end up as hooks for the kernel-package, if
you do not set KDEB_HOOKDIR. Looking at an example system that pulls in
things like "pm-utils, grub-pc .. initramfs". With this mechanism any
package placing a hook in /etc/kernel can influence the deps. I guess
in practice that is prevented with policies on what these scripts are
allowed to do.

> > In my case the build-machine is pretty minimal but i still want
> > some of that i.e. initramfs.
> >   
> > > > Different debian-based distros use different values for the
> > > > missing fields. And the values differ between distro versions
> > > > as well. So hardcoding of e.g. "Depends" is not possible.
> > > 
> > > The dependencies also depend on the kernel configuration.  (And a
> > > custom kernel built with 'make deb-pkg' often won't have any
> > > dependencies outside of essential packages.)  
> > 
> > In fact it does not have any at the moment, there is no essential.
> > Or maybe that is hidden in debian-magic.  
> [...]
> 
> Essential packages are always installed, which means there is no need
> to declare a dependency on them (in fact it is discouraged):
> https://www.debian.org/doc/debian-policy/#dependencies

Ok, i will need to double-check how multistrap deals with those.

Henning

> Ben.
> 

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Fri, 1 Dec 2017 16:51:12 +
schrieb Ben Hutchings <b...@decadent.org.uk>:

> On Fri, 2017-12-01 at 15:56 +, Henning Schild wrote:
> > The debian packages coming out of "make *deb-pkg" lack some critical
> > information in the control-files e.g. the "Depends:" field. If one
> > tries to install a fresh system with such a "linux-image"
> > debootstrap or multistrap might try to install the kernel before
> > its deps and the package hooks will fail.  
> 
> I assume you're talking about those hook scripts being run while the
> packages they belong to are only unpacked?  I hadn't thought about
> this issue, but it seems to me that those hook scripts generally
> ought to be fixed to handle this case properly.  Most of the packages
> installing hook scripts for kernel packages are not going to be
> dependencies of linux-image packages, so it will never be safe for
> them to assume their package has been fully installed.

Yes these hook scripts fail when installing the kernel on another
system. Indeed we seem to have a case where packages installed on the
build-machine cause install-time deps for the package.
In my case the build-machine is pretty minimal but i still want some of
that i.e. initramfs.

> > Different debian-based distros use different values for the missing
> > fields. And the values differ between distro versions as well. So
> > hardcoding of e.g. "Depends" is not possible.  
> 
> The dependencies also depend on the kernel configuration.  (And a
> custom kernel built with 'make deb-pkg' often won't have any
> dependencies outside of essential packages.)

In fact it does not have any at the moment, there is no essential. Or
maybe that is hidden in debian-magic.

> > This patch introduces an option variable for every debian package
> > built by builddeb. That allows advanced users to pass additional
> > arguments to "dpkg-gencontrol" e.g. to set "Depends". All the new
> > variables are optional.  
> 
> This customisation mechanism seems too powerful to be maintainable. 
> There is a high risk that it would conflict with later improvements to
> builddeb, either resulting in regressions or blocking those
> improvements from being made.

Fair enough. But there needs to be a way to specifiy at least some
deps, inheriting them from the build-host would be wrong. I really just
care about deps but thought this powerful tool would be a good idea in
case anyone cares about suggest and recommend etc..

> > for example:
> > make \
> > KDEB_OPTS_IMAGE=\
> > "-DDepends='initramfs-tools | linux-initramfs-tool, kmod,
> > linux-base'" \  
> [...]
> 
> The maintainer scripts generated by builddeb currently don't run
> depmod or any of the script in linux-base.  So this seems like a bad
> example. However, the dependency on initramfs-tools is an important
> one that can't simply be inferred from the kernel configuration.

Adding a depmod hook would probably be another patch. Let us keep that
in mind.

> So I would support adding a means to append to the Depends field
> specifically.  Appending to the Breaks field may also be useful, as
> new kernel versions may break specific utilities or user-space
> drivers.

Ok, in that case i will come up with another patch introducing
KDEB_IMAGE_DEPENDS KDEB_HEADERS_DEPENDS etc. and maybe _BREAKS as well.

Those would be appended when the control-files are generated. i.e.

cat EOF...
Depends: foo bar $KDEB_IMAGE_DEPENDS
EOF

Henning
 
> Ben.
> 

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Fri, 1 Dec 2017 16:51:12 +
schrieb Ben Hutchings :

> On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:
> > The debian packages coming out of "make *deb-pkg" lack some critical
> > information in the control-files e.g. the "Depends:" field. If one
> > tries to install a fresh system with such a "linux-image"
> > debootstrap or multistrap might try to install the kernel before
> > its deps and the package hooks will fail.  
> 
> I assume you're talking about those hook scripts being run while the
> packages they belong to are only unpacked?  I hadn't thought about
> this issue, but it seems to me that those hook scripts generally
> ought to be fixed to handle this case properly.  Most of the packages
> installing hook scripts for kernel packages are not going to be
> dependencies of linux-image packages, so it will never be safe for
> them to assume their package has been fully installed.

Yes these hook scripts fail when installing the kernel on another
system. Indeed we seem to have a case where packages installed on the
build-machine cause install-time deps for the package.
In my case the build-machine is pretty minimal but i still want some of
that i.e. initramfs.

> > Different debian-based distros use different values for the missing
> > fields. And the values differ between distro versions as well. So
> > hardcoding of e.g. "Depends" is not possible.  
> 
> The dependencies also depend on the kernel configuration.  (And a
> custom kernel built with 'make deb-pkg' often won't have any
> dependencies outside of essential packages.)

In fact it does not have any at the moment, there is no essential. Or
maybe that is hidden in debian-magic.

> > This patch introduces an option variable for every debian package
> > built by builddeb. That allows advanced users to pass additional
> > arguments to "dpkg-gencontrol" e.g. to set "Depends". All the new
> > variables are optional.  
> 
> This customisation mechanism seems too powerful to be maintainable. 
> There is a high risk that it would conflict with later improvements to
> builddeb, either resulting in regressions or blocking those
> improvements from being made.

Fair enough. But there needs to be a way to specifiy at least some
deps, inheriting them from the build-host would be wrong. I really just
care about deps but thought this powerful tool would be a good idea in
case anyone cares about suggest and recommend etc..

> > for example:
> > make \
> > KDEB_OPTS_IMAGE=\
> > "-DDepends='initramfs-tools | linux-initramfs-tool, kmod,
> > linux-base'" \  
> [...]
> 
> The maintainer scripts generated by builddeb currently don't run
> depmod or any of the script in linux-base.  So this seems like a bad
> example. However, the dependency on initramfs-tools is an important
> one that can't simply be inferred from the kernel configuration.

Adding a depmod hook would probably be another patch. Let us keep that
in mind.

> So I would support adding a means to append to the Depends field
> specifically.  Appending to the Breaks field may also be useful, as
> new kernel versions may break specific utilities or user-space
> drivers.

Ok, in that case i will come up with another patch introducing
KDEB_IMAGE_DEPENDS KDEB_HEADERS_DEPENDS etc. and maybe _BREAKS as well.

Those would be appended when the control-files are generated. i.e.

cat EOF...
Depends: foo bar $KDEB_IMAGE_DEPENDS
EOF

Henning
 
> Ben.
> 

Re: [PATCH v2] docs: fix location of document that got moved

[Henning Schild]

Hi Alexander,

could you please have a look at that patch.

Henning

Am Wed, 20 Sep 2017 20:02:04 +0200
schrieb Henning Schild <henn...@hennsch.de>:

> commit 9d85025b0418 ("docs-rst: create an user's manual book")
> renamed  the document mentioned in the header. Adjust the link to
> point to the right place.
> 
> Signed-off-by: Henning Schild <henn...@hennsch.de>
> ---
>  fs/binfmt_misc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index ce7181ea60fa..b5f1ae5d3217 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,8 @@
>   * Copyright (C) 1997 Richard Günther
>   *
>   * binfmt_misc detects binaries via a magic or filename extension
> and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more
> details.
> + * a specified wrapper. See
> Documentation/admin-guide/binfmt-misc.rst for more
> + * details.
>   */
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Re: [PATCH v2] docs: fix location of document that got moved

[Henning Schild]

Hi Alexander,

could you please have a look at that patch.

Henning

Am Wed, 20 Sep 2017 20:02:04 +0200
schrieb Henning Schild :

> commit 9d85025b0418 ("docs-rst: create an user's manual book")
> renamed  the document mentioned in the header. Adjust the link to
> point to the right place.
> 
> Signed-off-by: Henning Schild 
> ---
>  fs/binfmt_misc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index ce7181ea60fa..b5f1ae5d3217 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,8 @@
>   * Copyright (C) 1997 Richard Günther
>   *
>   * binfmt_misc detects binaries via a magic or filename extension
> and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more
> details.
> + * a specified wrapper. See
> Documentation/admin-guide/binfmt-misc.rst for more
> + * details.
>   */
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Mon, 27 Nov 2017 16:57:58 -0700
schrieb Jim Davis <jim.ep...@gmail.com>:

> On Mon, Nov 27, 2017 at 9:13 AM, Henning Schild
> <henning.sch...@siemens.com> wrote:
> > The debian packages coming out of "make *deb-pkg" lack some critical
> > information in the control-files e.g. the "Depends:" field. If one
> > tries to install a fresh system with such a "linux-image"
> > debootstrap or multistrap might try to install the kernel before
> > its deps and the package hooks will fail.  
> 
> Has that shown up in practice?  The builddeb script goes back some
> years now...

Yes it has, i came across this issue with a multistrap-based installer.
The kernel got picked as one of the first packages. Without explicit
deps i can only assume that deboostrap should be affected as well.
Maybe it processes the package-tree in another order and happens to
work by chance.
My guess is that most people use the builddeb script to install
additional kernels on a running system, so the missing deps never
showed.

That said, the patch would allow for much more customization than just
adding deps. But others might want to customize the other fields as
well.

> > +   eval 'create_package "$kernel_headers_packagename" \
> > +   "$kernel_headers_dir"' "$KDEB_OPTS_IMAGE_HEADERS"  
> 
> eval in a shell script with arbitrary input can lead to shenanigans
> like
> 
> make bindeb-pkg KDEB_OPTS_IMAGE_HEADERS="; echo All your base"
> 
> and other potentially nastier things.  Probably not an issue for a
> typical kernel developer sitting in front of his or her laptop, but if
> I ran a big automated unattended build farm I might prefer a non-eval
> alternative.

True. As you said, that might not be an issue for most people. Let us
discuss the general approach first. If we agree on applying such a
patch and others also raise this issue we might find an implementation
without the eval.
That is a first shot that can handle the kinds of strings one might
want to pass to dpkg-gencontrol. (spaces, pipes and multiple options).

Henning

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Mon, 27 Nov 2017 16:57:58 -0700
schrieb Jim Davis :

> On Mon, Nov 27, 2017 at 9:13 AM, Henning Schild
>  wrote:
> > The debian packages coming out of "make *deb-pkg" lack some critical
> > information in the control-files e.g. the "Depends:" field. If one
> > tries to install a fresh system with such a "linux-image"
> > debootstrap or multistrap might try to install the kernel before
> > its deps and the package hooks will fail.  
> 
> Has that shown up in practice?  The builddeb script goes back some
> years now...

Yes it has, i came across this issue with a multistrap-based installer.
The kernel got picked as one of the first packages. Without explicit
deps i can only assume that deboostrap should be affected as well.
Maybe it processes the package-tree in another order and happens to
work by chance.
My guess is that most people use the builddeb script to install
additional kernels on a running system, so the missing deps never
showed.

That said, the patch would allow for much more customization than just
adding deps. But others might want to customize the other fields as
well.

> > +   eval 'create_package "$kernel_headers_packagename" \
> > +   "$kernel_headers_dir"' "$KDEB_OPTS_IMAGE_HEADERS"  
> 
> eval in a shell script with arbitrary input can lead to shenanigans
> like
> 
> make bindeb-pkg KDEB_OPTS_IMAGE_HEADERS="; echo All your base"
> 
> and other potentially nastier things.  Probably not an issue for a
> typical kernel developer sitting in front of his or her laptop, but if
> I ran a big automated unattended build farm I might prefer a non-eval
> alternative.

True. As you said, that might not be an issue for most people. Let us
discuss the general approach first. If we agree on applying such a
patch and others also raise this issue we might find an implementation
without the eval.
That is a first shot that can handle the kinds of strings one might
want to pass to dpkg-gencontrol. (spaces, pipes and multiple options).

Henning

[PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

The debian packages coming out of "make *deb-pkg" lack some critical
information in the control-files e.g. the "Depends:" field. If one
tries to install a fresh system with such a "linux-image" debootstrap or
multistrap might try to install the kernel before its deps and the
package hooks will fail.

Different debian-based distros use different values for the missing
fields. And the values differ between distro versions as well. So
hardcoding of e.g. "Depends" is not possible.

This patch introduces an option variable for every debian package built
by builddeb. That allows advanced users to pass additional arguments to
"dpkg-gencontrol" e.g. to set "Depends". All the new variables are
optional.

for example:
make \
KDEB_OPTS_IMAGE=\
"-DDepends='initramfs-tools | linux-initramfs-tool, kmod, linux-base'" \
KDEB_OPTS_LIBC_HEADERS="-DMaintainer='root@machine' -v42" \
bindeb-pkg

Signed-off-by: Henning Schild <henning.sch...@siemens.com>
Signed-off-by: Konrad Schwarz <konrad.schw...@siemens.com>
---
 scripts/package/builddeb | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index b4f0f2b3f8d2..037e722bbd8f 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -13,7 +13,10 @@
 set -e
 
 create_package() {
-   local pname="$1" pdir="$2"
+   local pname="$1"
+   shift
+   local pdir="$1"
+   shift
 
mkdir -m 755 -p "$pdir/DEBIAN"
mkdir -p "$pdir/usr/share/doc/$pname"
@@ -30,7 +33,8 @@ create_package() {
chmod -R a+rX "$pdir"
 
# Create the package
-   dpkg-gencontrol $forcearch -Vkernel:debarch="${debarch}" -p$pname 
-P"$pdir"
+   dpkg-gencontrol $forcearch -Vkernel:debarch="${debarch}" -p$pname \
+   -P"$pdir" "$@"
dpkg --build "$pdir" ..
 }
 
@@ -353,11 +357,13 @@ Description: Linux support headers for userspace 
development
 EOF
 
 if [ "$ARCH" != "um" ]; then
-   create_package "$kernel_headers_packagename" "$kernel_headers_dir"
-   create_package "$libc_headers_packagename" "$libc_headers_dir"
+   eval 'create_package "$kernel_headers_packagename" \
+   "$kernel_headers_dir"' "$KDEB_OPTS_IMAGE_HEADERS"
+   eval 'create_package "$libc_headers_packagename" \
+   "$libc_headers_dir"' "$KDEB_OPTS_LIBC_HEADERS"
 fi
 
-create_package "$packagename" "$tmpdir"
+eval 'create_package "$packagename" "$tmpdir"' "$KDEB_OPTS_IMAGE"
 
 if [ -n "$BUILD_DEBUG" ] ; then
# Build debug package
@@ -381,7 +387,8 @@ Description: Linux kernel debugging symbols for $version
  all the necessary debug symbols for the kernel and its modules.
 EOF
 
-   create_package "$dbg_packagename" "$dbg_dir"
+   eval 'create_package "$dbg_packagename" "$dbg_dir" \
+   ' "$KDEB_OPTS_IMAGE_DBG"
 fi
 
 if [ "x$1" = "xdeb-pkg" ]
-- 
2.13.6

[PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

The debian packages coming out of "make *deb-pkg" lack some critical
information in the control-files e.g. the "Depends:" field. If one
tries to install a fresh system with such a "linux-image" debootstrap or
multistrap might try to install the kernel before its deps and the
package hooks will fail.

Different debian-based distros use different values for the missing
fields. And the values differ between distro versions as well. So
hardcoding of e.g. "Depends" is not possible.

This patch introduces an option variable for every debian package built
by builddeb. That allows advanced users to pass additional arguments to
"dpkg-gencontrol" e.g. to set "Depends". All the new variables are
optional.

for example:
make \
KDEB_OPTS_IMAGE=\
"-DDepends='initramfs-tools | linux-initramfs-tool, kmod, linux-base'" \
KDEB_OPTS_LIBC_HEADERS="-DMaintainer='root@machine' -v42" \
bindeb-pkg

Signed-off-by: Henning Schild 
Signed-off-by: Konrad Schwarz 
---
 scripts/package/builddeb | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index b4f0f2b3f8d2..037e722bbd8f 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -13,7 +13,10 @@
 set -e
 
 create_package() {
-   local pname="$1" pdir="$2"
+   local pname="$1"
+   shift
+   local pdir="$1"
+   shift
 
mkdir -m 755 -p "$pdir/DEBIAN"
mkdir -p "$pdir/usr/share/doc/$pname"
@@ -30,7 +33,8 @@ create_package() {
chmod -R a+rX "$pdir"
 
# Create the package
-   dpkg-gencontrol $forcearch -Vkernel:debarch="${debarch}" -p$pname 
-P"$pdir"
+   dpkg-gencontrol $forcearch -Vkernel:debarch="${debarch}" -p$pname \
+   -P"$pdir" "$@"
dpkg --build "$pdir" ..
 }
 
@@ -353,11 +357,13 @@ Description: Linux support headers for userspace 
development
 EOF
 
 if [ "$ARCH" != "um" ]; then
-   create_package "$kernel_headers_packagename" "$kernel_headers_dir"
-   create_package "$libc_headers_packagename" "$libc_headers_dir"
+   eval 'create_package "$kernel_headers_packagename" \
+   "$kernel_headers_dir"' "$KDEB_OPTS_IMAGE_HEADERS"
+   eval 'create_package "$libc_headers_packagename" \
+   "$libc_headers_dir"' "$KDEB_OPTS_LIBC_HEADERS"
 fi
 
-create_package "$packagename" "$tmpdir"
+eval 'create_package "$packagename" "$tmpdir"' "$KDEB_OPTS_IMAGE"
 
 if [ -n "$BUILD_DEBUG" ] ; then
# Build debug package
@@ -381,7 +387,8 @@ Description: Linux kernel debugging symbols for $version
  all the necessary debug symbols for the kernel and its modules.
 EOF
 
-   create_package "$dbg_packagename" "$dbg_dir"
+   eval 'create_package "$dbg_packagename" "$dbg_dir" \
+   ' "$KDEB_OPTS_IMAGE_DBG"
 fi
 
 if [ "x$1" = "xdeb-pkg" ]
-- 
2.13.6

Re: [PATCH v2] docs: fix location of document that got moved

[Henning Schild]

Adding kernel-janitors to the list, maybe some of you will pick it up.

Henning

Am Wed, 20 Sep 2017 20:02:04 +0200
schrieb Henning Schild <henn...@hennsch.de>:

> commit 9d85025b0418 ("docs-rst: create an user's manual book")
> renamed  the document mentioned in the header. Adjust the link to
> point to the right place.
> 
> Signed-off-by: Henning Schild <henn...@hennsch.de>
> ---
>  fs/binfmt_misc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index ce7181ea60fa..b5f1ae5d3217 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,8 @@
>   * Copyright (C) 1997 Richard Günther
>   *
>   * binfmt_misc detects binaries via a magic or filename extension
> and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more
> details.
> + * a specified wrapper. See
> Documentation/admin-guide/binfmt-misc.rst for more
> + * details.
>   */
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Re: [PATCH v2] docs: fix location of document that got moved

[Henning Schild]

Adding kernel-janitors to the list, maybe some of you will pick it up.

Henning

Am Wed, 20 Sep 2017 20:02:04 +0200
schrieb Henning Schild :

> commit 9d85025b0418 ("docs-rst: create an user's manual book")
> renamed  the document mentioned in the header. Adjust the link to
> point to the right place.
> 
> Signed-off-by: Henning Schild 
> ---
>  fs/binfmt_misc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index ce7181ea60fa..b5f1ae5d3217 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,8 @@
>   * Copyright (C) 1997 Richard Günther
>   *
>   * binfmt_misc detects binaries via a magic or filename extension
> and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more
> details.
> + * a specified wrapper. See
> Documentation/admin-guide/binfmt-misc.rst for more
> + * details.
>   */
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

[PATCH v2] docs: fix location of document that got moved

[Henning Schild]

commit 9d85025b0418 ("docs-rst: create an user's manual book") renamed  the
document mentioned in the header. Adjust the link to point to the right
place.

Signed-off-by: Henning Schild <henn...@hennsch.de>
---
 fs/binfmt_misc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index ce7181ea60fa..b5f1ae5d3217 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -4,7 +4,8 @@
  * Copyright (C) 1997 Richard Günther
  *
  * binfmt_misc detects binaries via a magic or filename extension and invokes
- * a specified wrapper. See Documentation/binfmt_misc.txt for more details.
+ * a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more
+ * details.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.13.5

[PATCH v2] docs: fix location of document that got moved

[Henning Schild]

commit 9d85025b0418 ("docs-rst: create an user's manual book") renamed  the
document mentioned in the header. Adjust the link to point to the right
place.

Signed-off-by: Henning Schild 
---
 fs/binfmt_misc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index ce7181ea60fa..b5f1ae5d3217 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -4,7 +4,8 @@
  * Copyright (C) 1997 Richard Günther
  *
  * binfmt_misc detects binaries via a magic or filename extension and invokes
- * a specified wrapper. See Documentation/binfmt_misc.txt for more details.
+ * a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more
+ * details.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.13.5

Re: [PATCH] docs: fix location of document that got moved

[Henning Schild]

Ping

Am Fri,  1 Sep 2017 21:57:21 +0200
schrieb Henning Schild <henn...@hennsch.de>:

> 9d85025b0418 renamed the document mentioned in the header. Adjust the
> link to point to the right place.
> 
> Signed-off-by: Henning Schild <henn...@hennsch.de>
> ---
>  fs/binfmt_misc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index f4718098ac31..b0cc07fbadef 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,8 @@
>   * Copyright (C) 1997 Richard Günther
>   *
>   * binfmt_misc detects binaries via a magic or filename extension
> and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more
> details.
> + * a specified wrapper. See
> Documentation/admin-guide/binfmt-misc.rst for more
> + * details.
>   */
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Re: [PATCH] docs: fix location of document that got moved

[Henning Schild]

Ping

Am Fri,  1 Sep 2017 21:57:21 +0200
schrieb Henning Schild :

> 9d85025b0418 renamed the document mentioned in the header. Adjust the
> link to point to the right place.
> 
> Signed-off-by: Henning Schild 
> ---
>  fs/binfmt_misc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index f4718098ac31..b0cc07fbadef 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,8 @@
>   * Copyright (C) 1997 Richard Günther
>   *
>   * binfmt_misc detects binaries via a magic or filename extension
> and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more
> details.
> + * a specified wrapper. See
> Documentation/admin-guide/binfmt-misc.rst for more
> + * details.
>   */
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

[PATCH] docs: fix location of document that got moved

[Henning Schild]

9d85025b0418 renamed the document mentioned in the header. Adjust the
link to point to the right place.

Signed-off-by: Henning Schild <henn...@hennsch.de>
---
 fs/binfmt_misc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index f4718098ac31..b0cc07fbadef 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -4,7 +4,8 @@
  * Copyright (C) 1997 Richard Günther
  *
  * binfmt_misc detects binaries via a magic or filename extension and invokes
- * a specified wrapper. See Documentation/binfmt_misc.txt for more details.
+ * a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more
+ * details.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.13.5

[PATCH] docs: fix location of document that got moved

[Henning Schild]

9d85025b0418 renamed the document mentioned in the header. Adjust the
link to point to the right place.

Signed-off-by: Henning Schild 
---
 fs/binfmt_misc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index f4718098ac31..b0cc07fbadef 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -4,7 +4,8 @@
  * Copyright (C) 1997 Richard Günther
  *
  * binfmt_misc detects binaries via a magic or filename extension and invokes
- * a specified wrapper. See Documentation/binfmt_misc.txt for more details.
+ * a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more
+ * details.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.13.5

Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR

[Henning Schild]

On Mon, 30 Jan 2017 11:20:25 +0100
Thomas Gleixner <t...@linutronix.de> wrote:

> Henning,
> 
> On Fri, 27 Jan 2017, Henning Schild wrote:
> > 
> > did you by any chance look into TSC synchronization by adjusting the
> > absolute value (MSR_IA32_TSC) as well? As far as i have seen Linux
> > did that a long time ago and eventually it was stopped because it
> > caused more harm than good.  
> 
> I was involved in both developing the TSC sync patches and ripping
> them out again.
> 
> The problem with writing TSC directly is that you really _CANNOT_
> reliably handle run-time differences and SMI/NMI induced deltas. With
> the adjust MRS it's a halfways sane thing to do, except for the
> brokeness of that botch job vs. the TSC deadline timer.
> 
> > The ADJUST MSR offers an easy way to synchronize, still taking care
> > of all the special cases resulted in an 8-patch series. Synching
> > without that using the absolute value is likely much harder, but
> > that series might be a good foundation.  
> 
> I'm not even thinking about bringing the pure TSC based sync back.
> 
> > The big question is whether we can rely on all future CPUs to 
> > support that MSR. Do "new MSRs" disappear again at some point? If we
> > can not rely on the ADJUST MSR, now might be a good time to revisit
> > the idea of synching the absolute values.  
> 
> There is nothing you can ever be sure about, but I doubt that the
> ADJUST MSR is going to vanish.

That sounds very much like i expected. But assuming the MSR has come to
stay, the problem should be solved for recent kernels and Intel-CPUs.

The AMD-Manual from 12/16 does not mention that MSR. I do not have
access to an AMD machine. But i can only assume that bigger machines
also suffer from async TSCs and basically all fall back to HPET.

> > I remember having read somewhere that this series might get
> > backported to longterm kernels, what is the status on that?  
> 
> No idea.
> 
> Thanks,

Thanks a lot!
Henning

Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR

[Henning Schild]

On Mon, 30 Jan 2017 11:20:25 +0100
Thomas Gleixner  wrote:

> Henning,
> 
> On Fri, 27 Jan 2017, Henning Schild wrote:
> > 
> > did you by any chance look into TSC synchronization by adjusting the
> > absolute value (MSR_IA32_TSC) as well? As far as i have seen Linux
> > did that a long time ago and eventually it was stopped because it
> > caused more harm than good.  
> 
> I was involved in both developing the TSC sync patches and ripping
> them out again.
> 
> The problem with writing TSC directly is that you really _CANNOT_
> reliably handle run-time differences and SMI/NMI induced deltas. With
> the adjust MRS it's a halfways sane thing to do, except for the
> brokeness of that botch job vs. the TSC deadline timer.
> 
> > The ADJUST MSR offers an easy way to synchronize, still taking care
> > of all the special cases resulted in an 8-patch series. Synching
> > without that using the absolute value is likely much harder, but
> > that series might be a good foundation.  
> 
> I'm not even thinking about bringing the pure TSC based sync back.
> 
> > The big question is whether we can rely on all future CPUs to 
> > support that MSR. Do "new MSRs" disappear again at some point? If we
> > can not rely on the ADJUST MSR, now might be a good time to revisit
> > the idea of synching the absolute values.  
> 
> There is nothing you can ever be sure about, but I doubt that the
> ADJUST MSR is going to vanish.

That sounds very much like i expected. But assuming the MSR has come to
stay, the problem should be solved for recent kernels and Intel-CPUs.

The AMD-Manual from 12/16 does not mention that MSR. I do not have
access to an AMD machine. But i can only assume that bigger machines
also suffer from async TSCs and basically all fall back to HPET.

> > I remember having read somewhere that this series might get
> > backported to longterm kernels, what is the status on that?  
> 
> No idea.
> 
> Thanks,

Thanks a lot!
Henning

Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR

[Henning Schild]

Thomas,

did you by any chance look into TSC synchronization by adjusting the
absolute value (MSR_IA32_TSC) as well? As far as i have seen Linux did
that a long time ago and eventually it was stopped because it caused
more harm than good.
https://github.com/torvalds/linux/commit/95492e4646e5de8b43d9a7908d6177fb737b61f0

Before your series the whole TSC code was not touched in a long time,
with a few attempts to introduce synchronization over the years.
i.e.
https://lkml.org/lkml/2015/11/9/639
which turned out to be the BIOS messing with the ADJUST MSR

The ADJUST MSR offers an easy way to synchronize, still taking care of
all the special cases resulted in an 8-patch series. Synching without
that using the absolute value is likely much harder, but that series
might be a good foundation.

The big question is whether we can rely on all future CPUs to 
support that MSR. Do "new MSRs" disappear again at some point? If we
can not rely on the ADJUST MSR, now might be a good time to revisit the
idea of synching the absolute values.

I remember having read somewhere that this series might get backported
to longterm kernels, what is the status on that?

regards,
Henning

On Sat, 19 Nov 2016 13:47:36 +
Thomas Gleixner  wrote:

> The TSC_ADJUST MSR shows whether the TSC has been modified. This is
> helpful in a two aspects:
> 
> 1) It allows to detect BIOS wreckage, where SMM code tries to 'hide'
> the cycles spent by storing the TSC value at SMM entry and restoring
> it at SMM exit. On affected machines the TSCs run slowly out of sync
> up to the point where the clocksource watchdog (if available) detects
> it.
> 
>The TSC_ADJUST MSR allows to detect the TSC modification before
> that and eventually restore it. This is also important for SoCs which
> have no watchdog clocksource and therefore TSC wreckage cannot be
> detected and acted upon.
> 
> 2) All threads in a package are required to have the same TSC_ADJUST
>value. Broken BIOSes break that and as a result the TSC
> synchronization check fails.
> 
>The TSC_ADJUST MSR allows to detect the deviation when a CPU comes
>online. If detected set it to the value of an already online CPU
> in the same package. This also allows to reduce the number of sync
> tests because with that in place the test is only required for the
> first CPU in a package.
> 
>In principle all CPUs in a system should have the same TSC_ADJUST
> value even across packages, but with physical CPU hotplug this
> assumption is not true because the TSC starts with power on, so
> physical hotplug has to do some trickery to bring the TSC into sync
> with already running packages, which requires to use an TSC_ADJUST
> value different from CPUs which got powered earlier.
> 
>A final enhancement is the opportunity to compensate for unsynced
> TSCs accross nodes at boot time and make the TSC usable that way. It
> won't help for TSCs which run apart due to frequency skew between
> packages, but this gets detected by the clocksource watchdog later.
> 
> The first step toward this is to store the TSC_ADJUST value of a
> starting CPU and compare it with the value of an already online CPU
> in the same package. If they differ, emit a warning and adjust it to
> the reference value. The !SMP version just stores the boot value for
> later verification.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/include/asm/tsc.h |6 +++
>  arch/x86/kernel/Makefile   |2 -
>  arch/x86/kernel/tsc.c  |2 +
>  arch/x86/kernel/tsc_sync.c |   88
> + 4 files changed, 97
> insertions(+), 1 deletion(-)
> 
> --- a/arch/x86/include/asm/tsc.h
> +++ b/arch/x86/include/asm/tsc.h
> @@ -48,6 +48,12 @@ extern int tsc_clocksource_reliable;
>  extern void check_tsc_sync_source(int cpu);
>  extern void check_tsc_sync_target(void);
>  
> +#ifdef CONFIG_X86_TSC
> +extern void tsc_store_and_check_tsc_adjust(void);
> +#else
> +static inline void tsc_store_and_check_tsc_adjust(void) { }
> +#endif
> +
>  extern int notsc_setup(char *);
>  extern void tsc_save_sched_clock_state(void);
>  extern void tsc_restore_sched_clock_state(void);
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -75,7 +75,7 @@ apm-y   := apm_32.o
>  obj-$(CONFIG_APM)+= apm.o
>  obj-$(CONFIG_SMP)+= smp.o
>  obj-$(CONFIG_SMP)+= smpboot.o
> -obj-$(CONFIG_SMP)+= tsc_sync.o
> +obj-$(CONFIG_X86_TSC)+= tsc_sync.o
>  obj-$(CONFIG_SMP)+= setup_percpu.o
>  obj-$(CONFIG_X86_MPPARSE)+= mpparse.o
>  obj-y+= apic/
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -1365,6 +1365,8 @@ void __init tsc_init(void)
>  
>   if (unsynchronized_tsc())
>   mark_tsc_unstable("TSCs unsynchronized");
> + else
> + tsc_store_and_check_tsc_adjust();
>  
>   

Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR

[Henning Schild]

Thomas,

did you by any chance look into TSC synchronization by adjusting the
absolute value (MSR_IA32_TSC) as well? As far as i have seen Linux did
that a long time ago and eventually it was stopped because it caused
more harm than good.
https://github.com/torvalds/linux/commit/95492e4646e5de8b43d9a7908d6177fb737b61f0

Before your series the whole TSC code was not touched in a long time,
with a few attempts to introduce synchronization over the years.
i.e.
https://lkml.org/lkml/2015/11/9/639
which turned out to be the BIOS messing with the ADJUST MSR

The ADJUST MSR offers an easy way to synchronize, still taking care of
all the special cases resulted in an 8-patch series. Synching without
that using the absolute value is likely much harder, but that series
might be a good foundation.

The big question is whether we can rely on all future CPUs to 
support that MSR. Do "new MSRs" disappear again at some point? If we
can not rely on the ADJUST MSR, now might be a good time to revisit the
idea of synching the absolute values.

I remember having read somewhere that this series might get backported
to longterm kernels, what is the status on that?

regards,
Henning

On Sat, 19 Nov 2016 13:47:36 +
Thomas Gleixner  wrote:

> The TSC_ADJUST MSR shows whether the TSC has been modified. This is
> helpful in a two aspects:
> 
> 1) It allows to detect BIOS wreckage, where SMM code tries to 'hide'
> the cycles spent by storing the TSC value at SMM entry and restoring
> it at SMM exit. On affected machines the TSCs run slowly out of sync
> up to the point where the clocksource watchdog (if available) detects
> it.
> 
>The TSC_ADJUST MSR allows to detect the TSC modification before
> that and eventually restore it. This is also important for SoCs which
> have no watchdog clocksource and therefore TSC wreckage cannot be
> detected and acted upon.
> 
> 2) All threads in a package are required to have the same TSC_ADJUST
>value. Broken BIOSes break that and as a result the TSC
> synchronization check fails.
> 
>The TSC_ADJUST MSR allows to detect the deviation when a CPU comes
>online. If detected set it to the value of an already online CPU
> in the same package. This also allows to reduce the number of sync
> tests because with that in place the test is only required for the
> first CPU in a package.
> 
>In principle all CPUs in a system should have the same TSC_ADJUST
> value even across packages, but with physical CPU hotplug this
> assumption is not true because the TSC starts with power on, so
> physical hotplug has to do some trickery to bring the TSC into sync
> with already running packages, which requires to use an TSC_ADJUST
> value different from CPUs which got powered earlier.
> 
>A final enhancement is the opportunity to compensate for unsynced
> TSCs accross nodes at boot time and make the TSC usable that way. It
> won't help for TSCs which run apart due to frequency skew between
> packages, but this gets detected by the clocksource watchdog later.
> 
> The first step toward this is to store the TSC_ADJUST value of a
> starting CPU and compare it with the value of an already online CPU
> in the same package. If they differ, emit a warning and adjust it to
> the reference value. The !SMP version just stores the boot value for
> later verification.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/include/asm/tsc.h |6 +++
>  arch/x86/kernel/Makefile   |2 -
>  arch/x86/kernel/tsc.c  |2 +
>  arch/x86/kernel/tsc_sync.c |   88
> + 4 files changed, 97
> insertions(+), 1 deletion(-)
> 
> --- a/arch/x86/include/asm/tsc.h
> +++ b/arch/x86/include/asm/tsc.h
> @@ -48,6 +48,12 @@ extern int tsc_clocksource_reliable;
>  extern void check_tsc_sync_source(int cpu);
>  extern void check_tsc_sync_target(void);
>  
> +#ifdef CONFIG_X86_TSC
> +extern void tsc_store_and_check_tsc_adjust(void);
> +#else
> +static inline void tsc_store_and_check_tsc_adjust(void) { }
> +#endif
> +
>  extern int notsc_setup(char *);
>  extern void tsc_save_sched_clock_state(void);
>  extern void tsc_restore_sched_clock_state(void);
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -75,7 +75,7 @@ apm-y   := apm_32.o
>  obj-$(CONFIG_APM)+= apm.o
>  obj-$(CONFIG_SMP)+= smp.o
>  obj-$(CONFIG_SMP)+= smpboot.o
> -obj-$(CONFIG_SMP)+= tsc_sync.o
> +obj-$(CONFIG_X86_TSC)+= tsc_sync.o
>  obj-$(CONFIG_SMP)+= setup_percpu.o
>  obj-$(CONFIG_X86_MPPARSE)+= mpparse.o
>  obj-y+= apic/
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -1365,6 +1365,8 @@ void __init tsc_init(void)
>  
>   if (unsynchronized_tsc())
>   mark_tsc_unstable("TSCs unsynchronized");
> + else
> + tsc_store_and_check_tsc_adjust();
>  
>   check_system_tsc_reliable();
>  
> ---