[PATCH platform 0/2] platform/x86: mlx-platform: Fix item counter assignment
Fix array names to match assignments for data items and data items counter for power and fan attributes. Patch #1: Provide fixes for system types MSN2700, MSN24xx. Patch #1: Provide fixes for system type MSN2700/ComEx. Vadim Pasternak (2): platform/x86: mlx-platform: Fix item counter assignment for MSN2700, MSN24xx systems platform/x86: mlx-platform: Fix item counter assignment for MSN2700/ComEx system drivers/platform/x86/mlx-platform.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.11.0
[PATCH platform 1/2] platform/x86: mlx-platform: Fix item counter assignment for MSN2700, MSN24xx systems
Fix array names to match assignments for data items and data items
counter in 'mlxplat_mlxcpld_default_items' structure for:
.data = mlxplat_mlxcpld_default_pwr_items_data,
.count = ARRAY_SIZE(mlxplat_mlxcpld_pwr),
and
.data = mlxplat_mlxcpld_default_fan_items_data,
.count = ARRAY_SIZE(mlxplat_mlxcpld_fan),
Replace:
- 'mlxplat_mlxcpld_pwr' by 'mlxplat_mlxcpld_default_pwr_items_data' for
ARRAY_SIZE() calculation.
- 'mlxplat_mlxcpld_fan' by 'mlxplat_mlxcpld_default_fan_items_data'
for ARRAY_SIZE() calculation.
Fixes: c6acad68eb2d ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap
interface")
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 6a634b72bfc2..b30ebd17f3de 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -456,7 +456,7 @@ static struct mlxreg_core_item
mlxplat_mlxcpld_default_items[] = {
.aggr_mask = MLXPLAT_CPLD_AGGR_PWR_MASK_DEF,
.reg = MLXPLAT_CPLD_LPC_REG_PWR_OFFSET,
.mask = MLXPLAT_CPLD_PWR_MASK,
- .count = ARRAY_SIZE(mlxplat_mlxcpld_pwr),
+ .count = ARRAY_SIZE(mlxplat_mlxcpld_default_pwr_items_data),
.inversed = 0,
.health = false,
},
@@ -465,7 +465,7 @@ static struct mlxreg_core_item
mlxplat_mlxcpld_default_items[] = {
.aggr_mask = MLXPLAT_CPLD_AGGR_FAN_MASK_DEF,
.reg = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
.mask = MLXPLAT_CPLD_FAN_MASK,
- .count = ARRAY_SIZE(mlxplat_mlxcpld_fan),
+ .count = ARRAY_SIZE(mlxplat_mlxcpld_default_fan_items_data),
.inversed = 1,
.health = false,
},
--
2.11.0
[PATCH platform 2/2] platform/x86: mlx-platform: Fix item counter assignment for MSN2700/ComEx system
Fix array names to match assignments for data items and data items
counter in 'mlxplat_mlxcpld_comex_items' structure for:
.data = mlxplat_mlxcpld_default_pwr_items_data,
.count = ARRAY_SIZE(mlxplat_mlxcpld_pwr),
and
.data = mlxplat_mlxcpld_default_fan_items_data,
.count = ARRAY_SIZE(mlxplat_mlxcpld_fan),
Replace:
- 'mlxplat_mlxcpld_pwr' by 'mlxplat_mlxcpld_default_pwr_items_data' for
ARRAY_SIZE() calculation.
- 'mlxplat_mlxcpld_fan' by 'mlxplat_mlxcpld_default_fan_items_data'
for ARRAY_SIZE() calculation.
Fixes: bdd6e155e0d6 ("platform/x86: mlx-platform: Add support for new system
type")
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index b30ebd17f3de..8bce3da32a42 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -495,7 +495,7 @@ static struct mlxreg_core_item
mlxplat_mlxcpld_comex_items[] = {
.aggr_mask = MLXPLAT_CPLD_AGGR_MASK_CARRIER,
.reg = MLXPLAT_CPLD_LPC_REG_PWR_OFFSET,
.mask = MLXPLAT_CPLD_PWR_MASK,
- .count = ARRAY_SIZE(mlxplat_mlxcpld_pwr),
+ .count = ARRAY_SIZE(mlxplat_mlxcpld_default_pwr_items_data),
.inversed = 0,
.health = false,
},
@@ -504,7 +504,7 @@ static struct mlxreg_core_item
mlxplat_mlxcpld_comex_items[] = {
.aggr_mask = MLXPLAT_CPLD_AGGR_MASK_CARRIER,
.reg = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
.mask = MLXPLAT_CPLD_FAN_MASK,
- .count = ARRAY_SIZE(mlxplat_mlxcpld_fan),
+ .count = ARRAY_SIZE(mlxplat_mlxcpld_default_fan_items_data),
.inversed = 1,
.health = false,
},
--
2.11.0
RE: [PATCH] platform/x86: mlx-platform: remove an unused variable
> -Original Message-
> From: Hans de Goede
> Sent: Monday, December 07, 2020 3:54 PM
> To: Arnd Bergmann ; Vadim Pasternak
> ; Mark Gross ; Nathan
> Chancellor ; Nick Desaulniers
>
> Cc: Arnd Bergmann ; Andy Shevchenko
> ; Michael Shych
> ; platform-driver-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; clang-built-li...@googlegroups.com
> Subject: Re: [PATCH] platform/x86: mlx-platform: remove an unused variable
>
> Hi,
>
> On 12/3/20 11:30 PM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The only reference to the mlxplat_mlxcpld_psu[] array got removed, so
> > there is now a warning from clang:
> >
> > drivers/platform/x86/mlx-platform.c:322:30: error: variable
> > 'mlxplat_mlxcpld_psu' is not needed and will not be emitted
> > [-Werror,-Wunneeded-internal-declaration]
> > static struct i2c_board_info mlxplat_mlxcpld_psu[] = {
> >
> > Remove the array as well and adapt the ARRAY_SIZE() call accordingly.
> >
> > Fixes: 912b341585e3 ("platform/x86: mlx-platform: Remove PSU EEPROM
> > from MSN274x platform configuration")
> > Signed-off-by: Arnd Bergmann
>
> Thank you for your patch.
>
> Note that there are 4 more cases where the foo1 and foo2 in:
> .data = foo1 and .count = ARRAY_SIZE(foo2) are not the same.
>
> There are 2 cases where .count is set to ARRAY_SIZE(mlxplat_mlxcpld_pwr)
> instead of to ARRAY_SIZE(mlxplat_mlxcpld_default_pwr_items_data)
>
> and there are 2 cases where .count is set to ARRAY_SIZE(mlxplat_mlxcpld_fan)
> instead of to ARRAY_SIZE(mlxplat_mlxcpld_default_fan_items_data)
>
> If one of the MLX people can provide a patch fixing this then that would be
> great.
Hi,
I'll provide a patch.
Thanks,
Vadim.
>
> ###
>
> I've applied this patch to my review-hans branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-
> x86.git/log/?h=review-hans
>
> Note it will show up in my review-hans branch once I've pushed my local
> branch there, which might take a while.
>
> Once I've run some tests on this branch the patches there will be added to the
> platform-drivers-x86/for-next branch and eventually will be included in the
> pdx86 pull-request to Linus for the next merge-window.
>
> Regards,
>
> Hans
>
>
>
>
>
> > ---
> > drivers/platform/x86/mlx-platform.c | 13 ++---
> > 1 file changed, 2 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/platform/x86/mlx-platform.c
> > b/drivers/platform/x86/mlx-platform.c
> > index 598f44558764..6a634b72bfc2 100644
> > --- a/drivers/platform/x86/mlx-platform.c
> > +++ b/drivers/platform/x86/mlx-platform.c
> > @@ -319,15 +319,6 @@ static struct i2c_mux_reg_platform_data
> > mlxplat_extended_mux_data[] = { };
> >
> > /* Platform hotplug devices */
> > -static struct i2c_board_info mlxplat_mlxcpld_psu[] = {
> > - {
> > - I2C_BOARD_INFO("24c02", 0x51),
> > - },
> > - {
> > - I2C_BOARD_INFO("24c02", 0x50),
> > - },
> > -};
> > -
> > static struct i2c_board_info mlxplat_mlxcpld_pwr[] = {
> > {
> > I2C_BOARD_INFO("dps460", 0x59),
> > @@ -456,7 +447,7 @@ static struct mlxreg_core_item
> mlxplat_mlxcpld_default_items[] = {
> > .aggr_mask = MLXPLAT_CPLD_AGGR_PSU_MASK_DEF,
> > .reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
> > .mask = MLXPLAT_CPLD_PSU_MASK,
> > - .count = ARRAY_SIZE(mlxplat_mlxcpld_psu),
> > + .count =
> ARRAY_SIZE(mlxplat_mlxcpld_default_psu_items_data),
> > .inversed = 1,
> > .health = false,
> > },
> > @@ -495,7 +486,7 @@ static struct mlxreg_core_item
> mlxplat_mlxcpld_comex_items[] = {
> > .aggr_mask = MLXPLAT_CPLD_AGGR_MASK_CARRIER,
> > .reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
> > .mask = MLXPLAT_CPLD_PSU_MASK,
> > - .count = ARRAY_SIZE(mlxplat_mlxcpld_psu),
> > + .count =
> ARRAY_SIZE(mlxplat_mlxcpld_default_psu_items_data),
> > .inversed = 1,
> > .health = false,
> > },
> >
RE: [PATCH] platform/x86: mlx-platform: remove an unused variable
> -Original Message-
> From: Arnd Bergmann
> Sent: Friday, December 04, 2020 12:31 AM
> To: Vadim Pasternak ; Hans de Goede
> ; Mark Gross ; Nathan
> Chancellor ; Nick Desaulniers
>
> Cc: Arnd Bergmann ; Andy Shevchenko
> ; Michael Shych
> ; platform-driver-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; clang-built-li...@googlegroups.com
> Subject: [PATCH] platform/x86: mlx-platform: remove an unused variable
>
> From: Arnd Bergmann
Acked-by: Vadim Pasternak
>
> The only reference to the mlxplat_mlxcpld_psu[] array got removed, so there is
> now a warning from clang:
>
> drivers/platform/x86/mlx-platform.c:322:30: error: variable
> 'mlxplat_mlxcpld_psu' is not needed and will not be emitted [-Werror,-
> Wunneeded-internal-declaration]
> static struct i2c_board_info mlxplat_mlxcpld_psu[] = {
>
> Remove the array as well and adapt the ARRAY_SIZE() call accordingly.
>
> Fixes: 912b341585e3 ("platform/x86: mlx-platform: Remove PSU EEPROM from
> MSN274x platform configuration")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/platform/x86/mlx-platform.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/platform/x86/mlx-platform.c b/drivers/platform/x86/mlx-
> platform.c
> index 598f44558764..6a634b72bfc2 100644
> --- a/drivers/platform/x86/mlx-platform.c
> +++ b/drivers/platform/x86/mlx-platform.c
> @@ -319,15 +319,6 @@ static struct i2c_mux_reg_platform_data
> mlxplat_extended_mux_data[] = { };
>
> /* Platform hotplug devices */
> -static struct i2c_board_info mlxplat_mlxcpld_psu[] = {
> - {
> - I2C_BOARD_INFO("24c02", 0x51),
> - },
> - {
> - I2C_BOARD_INFO("24c02", 0x50),
> - },
> -};
> -
> static struct i2c_board_info mlxplat_mlxcpld_pwr[] = {
> {
> I2C_BOARD_INFO("dps460", 0x59),
> @@ -456,7 +447,7 @@ static struct mlxreg_core_item
> mlxplat_mlxcpld_default_items[] = {
> .aggr_mask = MLXPLAT_CPLD_AGGR_PSU_MASK_DEF,
> .reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
> .mask = MLXPLAT_CPLD_PSU_MASK,
> - .count = ARRAY_SIZE(mlxplat_mlxcpld_psu),
> + .count =
> ARRAY_SIZE(mlxplat_mlxcpld_default_psu_items_data),
> .inversed = 1,
> .health = false,
> },
> @@ -495,7 +486,7 @@ static struct mlxreg_core_item
> mlxplat_mlxcpld_comex_items[] = {
> .aggr_mask = MLXPLAT_CPLD_AGGR_MASK_CARRIER,
> .reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
> .mask = MLXPLAT_CPLD_PSU_MASK,
> - .count = ARRAY_SIZE(mlxplat_mlxcpld_psu),
> + .count =
> ARRAY_SIZE(mlxplat_mlxcpld_default_psu_items_data),
> .inversed = 1,
> .health = false,
> },
> --
> 2.27.0
[PATCH platform 0/2] platform/x86: mlx-platform: Remove PSU EEPROM configuration
Remove PSU EEPROM configuration for systems MSN2700, MSN2100, MSN274x to support the requirement of power unit replacement by "off the shelf" device, matching electrical required parameters. Such device can be equipped with different EEPROM types or even could be not equipped with EEPROM. Patch set contains two bug fixes: - For MSN2700 and MSN2100 system types. - For MSN274x system types. Vadim Pasternak (2): platform/x86: mlx-platform: Remove PSU EEPROM from default platform configuration platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration drivers/platform/x86/mlx-platform.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) -- 2.11.0
[PATCH platform 2/2] platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration
Remove PSU EEPROM configuration for systems class equipped with
Mellanox chip Spectrum and ATOM CPU - system types MSN274x. Till now
all the systems from this class used few types of power units, all
equipped with EEPROM device with address space two bytes. Thus, all
these devices have been handled by EEPROM driver "24c02".
There is a new requirement is to support power unit replacement by "off
the shelf" device, matching electrical required parameters. Such device
can be equipped with different EEPROM type, which could be one byte
address space addressing or even could be not equipped with EEPROM.
In such case "24c02" will not work.
Fixes: ef08e14a3 ("platform/x86: mlx-platform: Add support for new msn274x
system type")
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 623e7f737d4a..598f44558764 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -601,15 +601,13 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_msn274x_psu_items_data[] = {
.label = "psu1",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(0),
- .hpdev.brdinfo = _mlxcpld_psu[0],
- .hpdev.nr = MLXPLAT_CPLD_PSU_MSN_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
{
.label = "psu2",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(1),
- .hpdev.brdinfo = _mlxcpld_psu[1],
- .hpdev.nr = MLXPLAT_CPLD_PSU_MSN_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
};
--
2.11.0
[PATCH platform 1/2] platform/x86: mlx-platform: Remove PSU EEPROM from default platform configuration
Remove PSU EEPROM configuration for systems class equipped with
Mellanox chip Spectrum and Celeron CPU - system types MSN2700, MSN2100.
Till now all the systems from this class used few types of power units,
all equipped with EEPROM device with address space two bytes. Thus, all
these devices have been handled by EEPROM driver "24c02".
There is a new requirement is to support power unit replacement by "off
the shelf" device, matching electrical required parameters. Such device
can be equipped with different EEPROM type, which could be one byte
address space addressing or even could be not equipped with EEPROM.
In such case "24c02" will not work.
Fixes: c6acad68e ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap
interface")
Fixes: ba814fdd0 ("platform/x86: mlx-platform: Use defines for bus assignment")
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 986ad3dda1c1..623e7f737d4a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -383,15 +383,13 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_psu_items_data[] = {
.label = "psu1",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(0),
- .hpdev.brdinfo = _mlxcpld_psu[0],
- .hpdev.nr = MLXPLAT_CPLD_PSU_DEFAULT_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
{
.label = "psu2",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(1),
- .hpdev.brdinfo = _mlxcpld_psu[1],
- .hpdev.nr = MLXPLAT_CPLD_PSU_DEFAULT_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
};
--
2.11.0
RE: [PATCH v1] platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver
> -Original Message- > From: Shravan Kumar Ramani > Sent: Monday, July 27, 2020 12:02 PM > To: Andy Shevchenko ; Darren Hart > ; Vadim Pasternak > Cc: Shravan Ramani ; Jiri Pirko > ; platform-driver-...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH v1] platform/mellanox: mlxbf-pmc: Add Mellanox BlueField > PMC driver > > The performance modules in BlueField are present in several hardware blocks > and each block provides access to these stats either through counters that can > be programmed to monitor supported events or through memory-mapped > registers that hold the relevant information. > The hardware blocks that include a performance module are: > * Tile (block containing 2 cores and a shared L2 cache) > * TRIO (PCIe root complex) > * MSS (Memory Sub-system containing the Memory Controller and L3 cache) > * GIC (Interrupt controller) > * SMMU (System Memory Management Unit) > The mlx_pmc driver provides access to all of these performance modules > through a hwmon sysfs interface. > > Signed-off-by: Shravan Kumar Ramani > Reviewed-by: Jiri Pirko Reviewed-by: Vadim Pasternak > --- > drivers/platform/mellanox/Kconfig | 10 + > drivers/platform/mellanox/Makefile|1 + > drivers/platform/mellanox/mlxbf-pmc.c | 1486 > + > 3 files changed, 1497 insertions(+) > create mode 100644 drivers/platform/mellanox/mlxbf-pmc.c > > diff --git a/drivers/platform/mellanox/Kconfig > b/drivers/platform/mellanox/Kconfig > index 916b39d..edd17e1 100644 > --- a/drivers/platform/mellanox/Kconfig > +++ b/drivers/platform/mellanox/Kconfig > @@ -56,4 +56,14 @@ config MLXBF_BOOTCTL > to the userspace tools, to be used in conjunction with the eMMC > device driver to do necessary initial swap of the boot partition. > > +config MLXBF_PMC > + tristate "Mellanox BlueField Performance Monitoring Counters driver" > + depends on ARM64 > + depends on HWMON > + depends on ACPI > + help > + Say y here to enable PMC support. The PMC driver provides access > + to performance monitoring counters within various blocks in the > + Mellanox BlueField SoC via a sysfs interface. > + > endif # MELLANOX_PLATFORM > diff --git a/drivers/platform/mellanox/Makefile > b/drivers/platform/mellanox/Makefile > index 499623c..000ddaa 100644 > --- a/drivers/platform/mellanox/Makefile > +++ b/drivers/platform/mellanox/Makefile > @@ -4,6 +4,7 @@ > # Mellanox Platform-Specific Drivers > # > obj-$(CONFIG_MLXBF_BOOTCTL) += mlxbf-bootctl.o > +obj-$(CONFIG_MLXBF_PMC) += mlxbf-pmc.o > obj-$(CONFIG_MLXBF_TMFIFO) += mlxbf-tmfifo.o > obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o > obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o > diff --git a/drivers/platform/mellanox/mlxbf-pmc.c > b/drivers/platform/mellanox/mlxbf-pmc.c > new file mode 100644 > index 000..07d6790 > --- /dev/null > +++ b/drivers/platform/mellanox/mlxbf-pmc.c > @@ -0,0 +1,1486 @@ > +// SPDX-License-Identifier: GPL-2.0-only OR Linux-OpenIB > +/* > + * Mellanox BlueField Performance Monitoring Counters driver > + * > + * This driver provides a sysfs interface for monitoring > + * performance statistics in BlueField SoC. > + * > + * Copyright (C) 2020 Mellanox Technologies Ltd. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define MLXBF_PMC_WRITE_REG_32 0x8209 #define > MLXBF_PMC_READ_REG_32 > +0x820A #define MLXBF_PMC_WRITE_REG_64 0x820B #define > +MLXBF_PMC_READ_REG_64 0x820C #define MLXBF_PMC_SIP_SVC_UID > +0x8200ff01 #define MLXBF_PMC_SIP_SVC_VERSION 0x8200ff03 #define > +MLXBF_PMC_SVC_REQ_MAJOR 0 #define MLXBF_PMC_SVC_MIN_MINOR 3 > + > +#define MLXBF_PMC_SMCCC_ACCESS_VIOLATION -4 > + > +#define MLXBF_PMC_EVENT_SET_BF1 0 > +#define MLXBF_PMC_EVENT_SET_BF2 1 > +#define MLXBF_PMC_EVENT_INFO_LEN 100 > + > +#define MLXBF_PMC_MAX_BLOCKS 30 > +#define MLXBF_PMC_MAX_ATTRS 30 > +#define MLXBF_PMC_INFO_SZ 4 > +#define MLXBF_PMC_REG_SIZE 8 > +#define MLXBF_PMC_L3C_REG_SIZE 4 > + > +#define MLXBF_PMC_TYPE_COUNTER 1 > +#define MLXBF_PMC_TYPE_REGISTER 0 > + > +#define MLXBF_PMC_PERFCTL 0 > +#define MLXBF_PMC_PERFEVT 1 > +#define MLXBF_PMC_PERFACC0 4 > + > +#define MLXBF_PMC_PERFMON_CONFIG_WR_R_B BIT(0) #define > +MLXBF_PMC_PERFMON_CONFIG_STROBE BIT(1) #define > +MLXBF_PMC_PERFMON_CONFIG_ADDR GENMASK_ULL(4, 2) #define > +MLXBF_PMC_PERFMON_CONFIG_WDATA GENMASK_ULL(60,
[PATCH platform-next v2 05/11] platform/mellanox: mlxreg-hotplug: Add environmental data to uevent
Send "udev" event with environmental data in order to allow handling
"ENV{}" variables in "udev" rules.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Comments pointed out by Andy:
- Add string_upper(), string_lower() helpers. Use string_upper() for
label conversion.
- Simplify code for event string construction.
---
drivers/platform/mellanox/mlxreg-hotplug.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index d9863e7fd491..b013445147dd 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -71,6 +72,23 @@ struct mlxreg_hotplug_priv_data {
u8 not_asserted;
};
+/* Environment variables array for udev. */
+static char *mlxreg_hotplug_udev_envp[] = { NULL, NULL };
+
+static int
+mlxreg_hotplug_udev_event_send(struct kobject *kobj,
+ struct mlxreg_core_data *data, bool action)
+{
+ char event_str[MLXREG_CORE_LABEL_MAX_SIZE + 2];
+ char label[MLXREG_CORE_LABEL_MAX_SIZE] = { 0 };
+
+ mlxreg_hotplug_udev_envp[0] = event_str;
+ string_upper(label, data->label);
+ snprintf(event_str, MLXREG_CORE_LABEL_MAX_SIZE, "%s=%d", label,
!!action);
+
+ return kobject_uevent_env(kobj, KOBJ_CHANGE, mlxreg_hotplug_udev_envp);
+}
+
static int mlxreg_hotplug_device_create(struct mlxreg_hotplug_priv_data *priv,
struct mlxreg_core_data *data)
{
@@ -78,7 +96,7 @@ static int mlxreg_hotplug_device_create(struct
mlxreg_hotplug_priv_data *priv,
struct i2c_client *client;
/* Notify user by sending hwmon uevent. */
- kobject_uevent(>hwmon->kobj, KOBJ_CHANGE);
+ mlxreg_hotplug_udev_event_send(>hwmon->kobj, data, true);
/*
* Return if adapter number is negative. It could be in case hotplug
@@ -118,7 +136,7 @@ mlxreg_hotplug_device_destroy(struct
mlxreg_hotplug_priv_data *priv,
struct mlxreg_core_data *data)
{
/* Notify user by sending hwmon uevent. */
- kobject_uevent(>hwmon->kobj, KOBJ_CHANGE);
+ mlxreg_hotplug_udev_event_send(>hwmon->kobj, data, false);
if (data->hpdev.client) {
i2c_unregister_device(data->hpdev.client);
--
2.11.0
[PATCH platform-next v2 08/11] platform/mellanox: mlxreg-io: Add support for complex attributes
Add support for attributes composed from few registers.
Such attributes could occupy from 2 to 4 sequential registers.
For word size register space complex attributes can occupy up to two
registers, for byte size - up to four. These attributes can carry, for
example, CPLD or FPGA versioning, power consuming info, etcetera.
Such registers contain read-only data.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Comments pointed out by Andy:
- Fix commit text.
- Fix few comments.
- Drop attribute validation for read-only access in mlxreg_io_get_reg().
This is redundant and wrong validation in attribute 'show' callback.
---
drivers/platform/mellanox/mlxreg-io.c | 45 +--
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
index acfaf64ffde6..7646708d57e4 100644
--- a/drivers/platform/mellanox/mlxreg-io.c
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -30,6 +30,7 @@
* @mlxreg_io_dev_attr: sysfs sensor device attribute array;
* @group: sysfs attribute group;
* @groups: list of sysfs attribute group for hwmon registration;
+ * @regsize: size of a register value;
*/
struct mlxreg_io_priv_data {
struct platform_device *pdev;
@@ -39,27 +40,30 @@ struct mlxreg_io_priv_data {
struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
struct attribute_group group;
const struct attribute_group *groups[2];
+ int regsize;
};
static int
mlxreg_io_get_reg(void *regmap, struct mlxreg_core_data *data, u32 in_val,
- bool rw_flag, u32 *regval)
+ bool rw_flag, int regsize, u32 *regval)
{
- int ret;
+ int i, val, ret;
ret = regmap_read(regmap, data->reg, regval);
if (ret)
goto access_error;
/*
-* There are three kinds of attributes: single bit, full register's
-* bits and bit sequence. For the first kind field mask indicates which
-* bits are not related and field bit is set zero. For the second kind
-* field mask is set to zero and field bit is set with all bits one.
-* No special handling for such kind of attributes - pass value as is.
-* For the third kind, field mask indicates which bits are related and
-* field bit is set to the first bit number (from 1 to 32) is the bit
-* sequence.
+* There are four kinds of attributes: single bit, full register's
+* bits, bit sequence, bits in few registers For the first kind field
+* mask indicates which bits are not related and field bit is set zero.
+* For the second kind field mask is set to zero and field bit is set
+* with all bits one. No special handling for such kind of attributes -
+* pass value as is. For the third kind, the field mask indicates which
+* bits are related and the field bit is set to the first bit number
+* (from 1 to 32) is the bit sequence. For the fourth kind - the number
+* of registers which should be read for getting an attribute are
+* specified through 'data->regnum' field.
*/
if (!data->bit) {
/* Single bit. */
@@ -83,6 +87,19 @@ mlxreg_io_get_reg(void *regmap, struct mlxreg_core_data
*data, u32 in_val,
/* Clear relevant bits and set them to new value. */
*regval = (*regval & ~data->mask) | in_val;
}
+ } else {
+ /*
+* Some attributes could occupied few registers in case regmap
+* bit size is 8 or 16. Compose such attributes from 'regnum'
+* registers. Such attributes contain read-only data.
+*/
+ for (i = 1; i < data->regnum; i++) {
+ ret = regmap_read(regmap, data->reg + i, );
+ if (ret)
+ goto access_error;
+
+ *regval |= rol32(val, regsize * i);
+ }
}
access_error:
@@ -99,7 +116,8 @@ mlxreg_io_attr_show(struct device *dev, struct
device_attribute *attr,
u32 regval = 0;
int ret;
- ret = mlxreg_io_get_reg(priv->pdata->regmap, data, 0, true, );
+ ret = mlxreg_io_get_reg(priv->pdata->regmap, data, 0, true,
+ priv->regsize, );
if (ret)
goto access_error;
@@ -128,7 +146,7 @@ mlxreg_io_attr_store(struct device *dev, struct
device_attribute *attr,
return ret;
ret = mlxreg_io_get_reg(priv->pdata->regmap, data, input_val, false,
- );
+ priv->regsize, );
if (ret)
goto access_error;
@@ -207,6 +225,9 @@ static int mlxreg_io_probe(struct platform_device *pdev)
}
priv->pd
[PATCH platform-next v2 06/11] platform_data/mlxreg: Add support for complex attributes
Add new field 'regnum' to the structure 'mlxreg_core_data' to specify
the number of registers occupied by multi-register attribute.
Signed-off-by: Vadim Pasternak
---
include/linux/platform_data/mlxreg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data/mlxreg.h
b/include/linux/platform_data/mlxreg.h
index b8da8aef2446..a2adc3ad45f2 100644
--- a/include/linux/platform_data/mlxreg.h
+++ b/include/linux/platform_data/mlxreg.h
@@ -80,6 +80,7 @@ struct mlxreg_hotplug_device {
* @hpdev - hotplug device data;
* @health_cntr: dynamic device health indication counter;
* @attached: true if device has been attached after good health indication;
+ * @regnum: number of registers occupied by multi-register attribute;
*/
struct mlxreg_core_data {
char label[MLXREG_CORE_LABEL_MAX_SIZE];
@@ -92,6 +93,7 @@ struct mlxreg_core_data {
struct mlxreg_hotplug_device hpdev;
u8 health_cntr;
bool attached;
+ u8 regnum;
};
/**
--
2.11.0
[PATCH platform-next v2 11/11] platform/x86: mlx-platform: Extend FAN platform data description
Extend FAN platform data with register presence field.
Add register present entry per rotor (tachometer) description tuple.
The purpose is to allow indication of FAN presence.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 034736cec9a6..90bc7969b199 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -1840,6 +1840,8 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(0),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
+
},
{
.label = "tacho2",
@@ -1847,6 +1849,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(1),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho3",
@@ -1854,6 +1857,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(2),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho4",
@@ -1861,6 +1865,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(3),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho5",
@@ -1868,6 +1873,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(4),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho6",
@@ -1875,6 +1881,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(5),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho7",
@@ -1882,6 +1889,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(6),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho8",
@@ -1889,6 +1897,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(7),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho9",
@@ -1896,6 +1905,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(0),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho10",
@@ -1903,6 +1913,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(1),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho11",
@@ -1910,6 +1921,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(2),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho12",
@@ -1917,6 +1929,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(3),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "conf",
--
2.11.0
[PATCH platform-next v2 01/11] lib/string_helpers: Introduce string_upper() and string_lower() helpers
Provide the helpers for string conversions to upper alnd lower cases.
Signed-off-by: Vadim Pasternak
---
include/linux/string_helpers.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/string_helpers.h b/include/linux/string_helpers.h
index c28955132234..86f150c2a6b6 100644
--- a/include/linux/string_helpers.h
+++ b/include/linux/string_helpers.h
@@ -2,6 +2,7 @@
#ifndef _LINUX_STRING_HELPERS_H_
#define _LINUX_STRING_HELPERS_H_
+#include
#include
struct file;
@@ -75,6 +76,20 @@ static inline int string_escape_str_any_np(const char *src,
char *dst,
return string_escape_str(src, dst, sz, ESCAPE_ANY_NP, only);
}
+static inline void string_upper(char *dst, const char *src)
+{
+ do {
+ *dst++ = toupper(*src);
+ } while (*src++);
+}
+
+static inline void string_lower(char *dst, const char *src)
+{
+ do {
+ *dst++ = tolower(*src);
+ } while (*src++);
+}
+
char *kstrdup_quotable(const char *src, gfp_t gfp);
char *kstrdup_quotable_cmdline(struct task_struct *task, gfp_t gfp);
char *kstrdup_quotable_file(struct file *file, gfp_t gfp);
--
2.11.0
[PATCH platform-next v2 00/11] platform/x86: Add new features for Mellanox systems
The patchset adds new features for the existing Mellanox systems. Patch #1 add string helpers for upper/lower conversion. Patch #2 add tests for these helpers. Patch #3 updates license for module 'mlxreg-hotplug'. Patch #4 allows to configure number of hotplug 'sysfs' attributes for the particular system class according to the hardware data for the specific system from this class, instead of configuring it up-to maximum number in the class. Patch #5 adds environmental data to hotplug 'uevent'. Patches #6-#7 add more definitions for system attributes. Patch #8 extends 'mlxreg-io' driver with complex attributes support. Patch #9 extends documentation with new attributes. Patches #10-#11 extend FAN platform data with register presence field. Vadim Pasternak (11): lib/string_helpers: Introduce string_upper() and string_lower() helpers lib/test-string_helpers.c: Add string_upper() and string_lower() tests platform/mellanox: mlxreg-hotplug: Modify module license platform/mellanox: mlxreg-hotplug: Use capability register for attribute creation platform/mellanox: mlxreg-hotplug: Add environmental data to uevent platform_data/mlxreg: Add support for complex attributes platform/x86: mlx-platform: Add more definitions for system attributes platform/mellanox: mlxreg-io: Add support for complex attributes Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces platform_data/mlxreg: Add presence register field for FAN devices platform/x86: mlx-platform: Extend FAN platform data description Documentation/ABI/stable/sysfs-driver-mlxreg-io | 17 +++ drivers/platform/mellanox/mlxreg-hotplug.c | 114 ++- drivers/platform/mellanox/mlxreg-io.c | 45 ++-- drivers/platform/x86/mlx-platform.c | 141 include/linux/platform_data/mlxreg.h| 4 + include/linux/string_helpers.h | 15 +++ lib/test-string_helpers.c | 67 +++ 7 files changed, 341 insertions(+), 62 deletions(-) -- 2.11.0
[PATCH platform-next v2 02/11] lib/test-string_helpers.c: Add string_upper() and string_lower() tests
Add few of simple tests for string_upper() and string_lower() helpers.
Signed-off-by: Vadim Pasternak
---
lib/test-string_helpers.c | 67 +++
1 file changed, 67 insertions(+)
diff --git a/lib/test-string_helpers.c b/lib/test-string_helpers.c
index 25b5cbfb7615..10360d4ea273 100644
--- a/lib/test-string_helpers.c
+++ b/lib/test-string_helpers.c
@@ -238,6 +238,28 @@ static const struct test_string_2 escape1[] __initconst =
{{
/* terminator */
}};
+static const struct test_string strings_upper[] __initconst = {
+ {
+ .in = "abcdefgh1234567890test",
+ .out = "ABCDEFGH1234567890TEST",
+ },
+ {
+ .in = "abCdeFgH1234567890TesT",
+ .out = "ABCDEFGH1234567890TEST",
+ },
+};
+
+static const struct test_string strings_lower[] __initconst = {
+ {
+ .in = "ABCDEFGH1234567890TEST",
+ .out = "abcdefgh1234567890test",
+ },
+ {
+ .in = "abCdeFgH1234567890TesT",
+ .out = "abcdefgh1234567890test",
+ },
+};
+
static __init const char *test_string_find_match(const struct test_string_2
*s2,
unsigned int flags)
{
@@ -390,6 +412,48 @@ static __init void test_string_get_size(void)
test_string_get_size_one(4096, U64_MAX, "75.6 ZB", "64.0 ZiB");
}
+static void __init test_string_upper_lower(void)
+{
+ char *dst;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(strings_upper); i++) {
+ const char *s = strings_upper[i].in;
+ int len = strlen(strings_upper[i].in) + 1;
+
+ dst = kmalloc(len, GFP_KERNEL);
+ if (!dst)
+ return;
+
+ string_upper(dst, s);
+ if (memcmp(dst, strings_upper[i].out, len)) {
+ pr_warn("Test 'string_upper' failed : expected %s, got
%s!\n",
+ strings_upper[i].out, dst);
+ kfree(dst);
+ return;
+ }
+ kfree(dst);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(strings_lower); i++) {
+ const char *s = strings_lower[i].in;
+ int len = strlen(strings_lower[i].in) + 1;
+
+ dst = kmalloc(len, GFP_KERNEL);
+ if (!dst)
+ return;
+
+ string_lower(dst, s);
+ if (memcmp(dst, strings_lower[i].out, len)) {
+ pr_warn("Test 'string_lower failed : : expected %s, got
%s!\n",
+ strings_lower[i].out, dst);
+ kfree(dst);
+ return;
+ }
+ kfree(dst);
+ }
+}
+
static int __init test_string_helpers_init(void)
{
unsigned int i;
@@ -411,6 +475,9 @@ static int __init test_string_helpers_init(void)
/* Test string_get_size() */
test_string_get_size();
+ /* Test string upper(), string_lower() */
+ test_string_upper_lower();
+
return -EINVAL;
}
module_init(test_string_helpers_init);
--
2.11.0
[PATCH platform-next v2 09/11] Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces
Add documentation for the new attributes for exposing CPLDs part numbers and CPLD minor versions. Signed-off-by: Vadim Pasternak --- v1->v2: Changes added by Vadim: - Update date and kernel version. --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index b0d90cc696a8..fd9a8045bb0c 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -206,3 +206,20 @@ Description: This file exposes the firmware version of burnable voltage regulator devices. The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version_min +Date: July 2020 +KernelVersion: 5.9 +Contact: Vadim Pasternak +Description: These files show with which CPLD part numbers and minor + versions have been burned CPLD devices equipped on a + system. + + The files are read only. -- 2.11.0
[PATCH platform-next v2 03/11] platform/mellanox: mlxreg-hotplug: Modify module license
Change module license to 'SPDX'.
Signed-off-by: Vadim Pasternak
---
drivers/platform/mellanox/mlxreg-hotplug.c | 32 +++---
1 file changed, 3 insertions(+), 29 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index ed48917af162..19af2897ef75 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -1,34 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (c) 2016-2018 Mellanox Technologies. All rights reserved.
- * Copyright (c) 2016-2018 Vadim Pasternak
+ * Mellanox hotplug driver
*
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- * 3. Neither the names of the copyright holders nor the names of its
- *contributors may be used to endorse or promote products derived from
- *this software without specific prior written permission.
- *
- * Alternatively, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") version 2 as published by the Free
- * Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
+ * Copyright (C) 2016-2020 Mellanox Technologies
*/
#include
--
2.11.0
[PATCH platform-next v2 04/11] platform/mellanox: mlxreg-hotplug: Use capability register for attribute creation
Create the 'sysfs' attributes according to configuration provided
through the capability register, which purpose is to indicate the
actual number of the components within the particular group.
Such components could be, for example the FAN or power supply units.
The motivation is to avoid adding a new code in the future in order to
distinct between the systems types supporting a different number of the
components like power supplies, FANs, ASICs, line cards.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Comments pointed out by Andy:
- Fix commit text.
- Modify loop over unmasked units - use for_each_set_bit().
---
drivers/platform/mellanox/mlxreg-hotplug.c | 60 --
1 file changed, 41 insertions(+), 19 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index 19af2897ef75..d9863e7fd491 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -173,17 +173,49 @@ static int mlxreg_hotplug_attr_init(struct
mlxreg_hotplug_priv_data *priv)
struct mlxreg_core_hotplug_platform_data *pdata;
struct mlxreg_core_item *item;
struct mlxreg_core_data *data;
- int num_attrs = 0, id = 0, i, j;
+ unsigned long mask;
+ u32 regval;
+ int num_attrs = 0, id = 0, i, j, k, ret;
pdata = dev_get_platdata(>pdev->dev);
item = pdata->items;
/* Go over all kinds of items - psu, pwr, fan. */
for (i = 0; i < pdata->counter; i++, item++) {
- num_attrs += item->count;
+ if (item->capability) {
+ /*
+* Read group capability register to get actual number
+* of interrupt capable components and set group mask
+* accordingly.
+*/
+ ret = regmap_read(priv->regmap, item->capability,
+ );
+ if (ret)
+ return ret;
+
+ item->mask = GENMASK((regval & item->mask) - 1, 0);
+ }
+
data = item->data;
- /* Go over all units within the item. */
- for (j = 0; j < item->count; j++, data++, id++) {
+
+ /* Go over all unmasked units within item. */
+ mask = item->mask;
+ k = 0;
+ for_each_set_bit(j, , item->count) {
+ if (data->capability) {
+ /*
+* Read capability register and skip non
+* relevant attributes.
+*/
+ ret = regmap_read(priv->regmap,
+ data->capability, );
+ if (ret)
+ return ret;
+ if (!(regval & data->bit)) {
+ data++;
+ continue;
+ }
+ }
PRIV_ATTR(id) = _DEV_ATTR(id).dev_attr.attr;
PRIV_ATTR(id)->name = devm_kasprintf(>pdev->dev,
GFP_KERNEL,
@@ -201,9 +233,13 @@ static int mlxreg_hotplug_attr_init(struct
mlxreg_hotplug_priv_data *priv)
PRIV_DEV_ATTR(id).dev_attr.show =
mlxreg_hotplug_attr_show;
PRIV_DEV_ATTR(id).nr = i;
- PRIV_DEV_ATTR(id).index = j;
+ PRIV_DEV_ATTR(id).index = k;
sysfs_attr_init(_DEV_ATTR(id).dev_attr.attr);
+ data++;
+ id++;
+ k++;
}
+ num_attrs += k;
}
priv->group.attrs = devm_kcalloc(>pdev->dev,
@@ -481,20 +517,6 @@ static int mlxreg_hotplug_set_irq(struct
mlxreg_hotplug_priv_data *priv)
item = pdata->items;
for (i = 0; i < pdata->counter; i++, item++) {
- if (item->capability) {
- /*
-* Read group capability register to get actual number
-* of interrupt capable components and set group mask
-* accordingly.
-*/
- ret = regmap_read(priv->regmap, item->capability,
- );
- if (ret)
- goto out;
-
- item->mask = GENMASK((regval & item->mask) - 1, 0);
-
[PATCH platform-next v2 10/11] platform_data/mlxreg: Add presence register field for FAN devices
Add new field 'reg_prsnt' to the structure 'mlxreg_core_data' to
provide the number FAN drawers equpped within the system. The purpose
is to allow mapping between FAN drawers and FAN rotors (tachometer),
since FAN drawer can be eqipped with a few rotors.
Signed-off-by: Vadim Pasternak
---
include/linux/platform_data/mlxreg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data/mlxreg.h
b/include/linux/platform_data/mlxreg.h
index a2adc3ad45f2..9cffa9a64ab3 100644
--- a/include/linux/platform_data/mlxreg.h
+++ b/include/linux/platform_data/mlxreg.h
@@ -75,6 +75,7 @@ struct mlxreg_hotplug_device {
* @mask: attribute access mask;
* @bit: attribute effective bit;
* @capability: attribute capability register;
+ * @reg_prsnt: attribute presence register;
* @mode: access mode;
* @np - pointer to node platform associated with attribute;
* @hpdev - hotplug device data;
@@ -88,6 +89,7 @@ struct mlxreg_core_data {
u32 mask;
u32 bit;
u32 capability;
+ u32 reg_prsnt;
umode_t mode;
struct device_node *np;
struct mlxreg_hotplug_device hpdev;
--
2.11.0
[PATCH platform-next v2 07/11] platform/x86: mlx-platform: Add more definitions for system attributes
Add new attributes for the all type systems specifying for each
equipped CPLD device, the CPLD part number and the CPLD minor version
of the device: 'cpld{n}_pn' and 'cpld{n}_version_min'.
This information is to be used for mathcing the current CPLD image and
for making decision if image upgrade is required for CPLD device.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 128
1 file changed, 128 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index c27548fd386a..034736cec9a6 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -26,6 +26,10 @@
#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
#define MLXPLAT_CPLD_LPC_REG_CPLD3_VER_OFFSET 0x02
#define MLXPLAT_CPLD_LPC_REG_CPLD4_VER_OFFSET 0x03
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET 0x04
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET 0x06
+#define MLXPLAT_CPLD_LPC_REG_CPLD3_PN_OFFSET 0x08
+#define MLXPLAT_CPLD_LPC_REG_CPLD4_PN_OFFSET 0x0a
#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_RST_CAUSE1_OFFSET 0x1e
#define MLXPLAT_CPLD_LPC_REG_RST_CAUSE2_OFFSET 0x1f
@@ -72,6 +76,10 @@
#define MLXPLAT_CPLD_LPC_REG_WD3_TMR_OFFSET0xd1
#define MLXPLAT_CPLD_LPC_REG_WD3_TLEFT_OFFSET 0xd2
#define MLXPLAT_CPLD_LPC_REG_WD3_ACT_OFFSET0xd3
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_MVER_OFFSET 0xde
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_MVER_OFFSET 0xdf
+#define MLXPLAT_CPLD_LPC_REG_CPLD3_MVER_OFFSET 0xe0
+#define MLXPLAT_CPLD_LPC_REG_CPLD4_MVER_OFFSET 0xe1
#define MLXPLAT_CPLD_LPC_REG_UFM_VERSION_OFFSET0xe2
#define MLXPLAT_CPLD_LPC_REG_PWM1_OFFSET 0xe3
#define MLXPLAT_CPLD_LPC_REG_TACHO1_OFFSET 0xe4
@@ -1304,6 +1312,32 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_regs_io_data[] = {
.mode = 0444,
},
{
+ .label = "cpld1_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld2_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld1_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
.label = "reset_long_pb",
.reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
.mask = GENMASK(7, 0) & ~BIT(0),
@@ -1410,6 +1444,32 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_msn21xx_regs_io_data[] = {
.mode = 0444,
},
{
+ .label = "cpld1_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld2_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld1_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
.label = "reset_long_pb",
.reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
.mask = GENMASK(7, 0) & ~BIT(0),
@@ -1528,6 +1588,58 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_ng_regs_io_data[] = {
.mode = 0444,
},
{
+ .label = "cpld1_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld2_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld3_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD3_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+
[PATCH platform-next v1 2/8] platform/mellanox: mlxreg-hotplug: Add environmental data to uevent
Send "udev" event with environmental data in order to allow handling
"ENV{}" variables in "udev" rules.
Signed-off-by: Vadim Pasternak
---
drivers/platform/mellanox/mlxreg-hotplug.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index 832fcf282d45..5420d5bb0e6c 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -97,13 +97,36 @@ struct mlxreg_hotplug_priv_data {
u8 not_asserted;
};
+/* Environment variables array for udev. */
+static char *mlxreg_hotplug_udev_envp[] = { NULL, NULL };
+
+static int
+mlxreg_hotplug_udev_event_send(struct kobject *kobj,
+ struct mlxreg_core_data *data, bool action)
+{
+ char event_str[MLXREG_CORE_LABEL_MAX_SIZE + 2];
+ char label[MLXREG_CORE_LABEL_MAX_SIZE] = { 0 };
+ int i;
+
+ mlxreg_hotplug_udev_envp[0] = event_str;
+ for (i = 0; data->label[i]; i++)
+ label[i] = toupper(data->label[i]);
+
+ if (action)
+ snprintf(event_str, MLXREG_CORE_LABEL_MAX_SIZE, "%s=1", label);
+ else
+ snprintf(event_str, MLXREG_CORE_LABEL_MAX_SIZE, "%s=0", label);
+
+ return kobject_uevent_env(kobj, KOBJ_CHANGE, mlxreg_hotplug_udev_envp);
+}
+
static int mlxreg_hotplug_device_create(struct mlxreg_hotplug_priv_data *priv,
struct mlxreg_core_data *data)
{
struct mlxreg_core_hotplug_platform_data *pdata;
/* Notify user by sending hwmon uevent. */
- kobject_uevent(>hwmon->kobj, KOBJ_CHANGE);
+ mlxreg_hotplug_udev_event_send(>hwmon->kobj, data, true);
/*
* Return if adapter number is negative. It could be in case hotplug
@@ -141,7 +164,7 @@ mlxreg_hotplug_device_destroy(struct
mlxreg_hotplug_priv_data *priv,
struct mlxreg_core_data *data)
{
/* Notify user by sending hwmon uevent. */
- kobject_uevent(>hwmon->kobj, KOBJ_CHANGE);
+ mlxreg_hotplug_udev_event_send(>hwmon->kobj, data, false);
if (data->hpdev.client) {
i2c_unregister_device(data->hpdev.client);
--
2.11.0
[PATCH platform-next v1 7/8] platform_data/mlxreg: Add presence register field for FAN devices
Add new field 'reg_prsnt' to the structure 'mlxreg_core_data' to
provide the number FAN drawers equpped within the system. The purpose
is to allow mapping between FAN drawers and FAN rotors (tachometer),
since FAN drawer can be eqipped with a few rotors.
Signed-off-by: Vadim Pasternak
---
include/linux/platform_data/mlxreg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data/mlxreg.h
b/include/linux/platform_data/mlxreg.h
index a2adc3ad45f2..9cffa9a64ab3 100644
--- a/include/linux/platform_data/mlxreg.h
+++ b/include/linux/platform_data/mlxreg.h
@@ -75,6 +75,7 @@ struct mlxreg_hotplug_device {
* @mask: attribute access mask;
* @bit: attribute effective bit;
* @capability: attribute capability register;
+ * @reg_prsnt: attribute presence register;
* @mode: access mode;
* @np - pointer to node platform associated with attribute;
* @hpdev - hotplug device data;
@@ -88,6 +89,7 @@ struct mlxreg_core_data {
u32 mask;
u32 bit;
u32 capability;
+ u32 reg_prsnt;
umode_t mode;
struct device_node *np;
struct mlxreg_hotplug_device hpdev;
--
2.11.0
[PATCH platform-next v1 4/8] platform/x86: mlx-platform: Add more definitions for system attributes
Add new attributes for the all type systems specifying for each
equipped CPLD device, the CPLD part number and the CPLD minor version
of the device: 'cpld{n}_pn' and 'cpld{n}_version_min'.
This information is to be used for mathcing the current CPLD image and
for making decision if image upgrade is required for CPLD device.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 128
1 file changed, 128 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index c27548fd386a..034736cec9a6 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -26,6 +26,10 @@
#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
#define MLXPLAT_CPLD_LPC_REG_CPLD3_VER_OFFSET 0x02
#define MLXPLAT_CPLD_LPC_REG_CPLD4_VER_OFFSET 0x03
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET 0x04
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET 0x06
+#define MLXPLAT_CPLD_LPC_REG_CPLD3_PN_OFFSET 0x08
+#define MLXPLAT_CPLD_LPC_REG_CPLD4_PN_OFFSET 0x0a
#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_RST_CAUSE1_OFFSET 0x1e
#define MLXPLAT_CPLD_LPC_REG_RST_CAUSE2_OFFSET 0x1f
@@ -72,6 +76,10 @@
#define MLXPLAT_CPLD_LPC_REG_WD3_TMR_OFFSET0xd1
#define MLXPLAT_CPLD_LPC_REG_WD3_TLEFT_OFFSET 0xd2
#define MLXPLAT_CPLD_LPC_REG_WD3_ACT_OFFSET0xd3
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_MVER_OFFSET 0xde
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_MVER_OFFSET 0xdf
+#define MLXPLAT_CPLD_LPC_REG_CPLD3_MVER_OFFSET 0xe0
+#define MLXPLAT_CPLD_LPC_REG_CPLD4_MVER_OFFSET 0xe1
#define MLXPLAT_CPLD_LPC_REG_UFM_VERSION_OFFSET0xe2
#define MLXPLAT_CPLD_LPC_REG_PWM1_OFFSET 0xe3
#define MLXPLAT_CPLD_LPC_REG_TACHO1_OFFSET 0xe4
@@ -1304,6 +1312,32 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_regs_io_data[] = {
.mode = 0444,
},
{
+ .label = "cpld1_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld2_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld1_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
.label = "reset_long_pb",
.reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
.mask = GENMASK(7, 0) & ~BIT(0),
@@ -1410,6 +1444,32 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_msn21xx_regs_io_data[] = {
.mode = 0444,
},
{
+ .label = "cpld1_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld2_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld1_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version_min",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_MVER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
.label = "reset_long_pb",
.reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
.mask = GENMASK(7, 0) & ~BIT(0),
@@ -1528,6 +1588,58 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_ng_regs_io_data[] = {
.mode = 0444,
},
{
+ .label = "cpld1_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld2_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+ },
+ {
+ .label = "cpld3_pn",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD3_PN_OFFSET,
+ .bit = GENMASK(15, 0),
+ .mode = 0444,
+ .regnum = 2,
+
[PATCH platform-next v1 1/8] platform/mellanox: mlxreg-hotplug: Use capability register for attribute creation
Create the 'sysfs' attributes according to configuration provided
through the capability register, which purpose is to indicate the
actual number of the components within the particular group.
Such components could be, for example the FAN or power supply units.
The motivation is to avoid adding a new code in the future in order to
distinct between the systems types supported different number of the
components like power supplies, FANs, ASICs, line cards.
Signed-off-by: Vadim Pasternak
---
drivers/platform/mellanox/mlxreg-hotplug.c | 54 --
1 file changed, 36 insertions(+), 18 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index 77be37a1fbcf..832fcf282d45 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -196,17 +196,46 @@ static int mlxreg_hotplug_attr_init(struct
mlxreg_hotplug_priv_data *priv)
struct mlxreg_core_hotplug_platform_data *pdata;
struct mlxreg_core_item *item;
struct mlxreg_core_data *data;
- int num_attrs = 0, id = 0, i, j;
+ u32 regval;
+ int num_attrs = 0, id = 0, i, j, k, ret;
pdata = dev_get_platdata(>pdev->dev);
item = pdata->items;
/* Go over all kinds of items - psu, pwr, fan. */
for (i = 0; i < pdata->counter; i++, item++) {
- num_attrs += item->count;
+ if (item->capability) {
+ /*
+* Read group capability register to get actual number
+* of interrupt capable components and set group mask
+* accordingly.
+*/
+ ret = regmap_read(priv->regmap, item->capability,
+ );
+ if (ret)
+ return ret;
+
+ item->mask = GENMASK((regval & item->mask) - 1, 0);
+ }
+
data = item->data;
/* Go over all units within the item. */
- for (j = 0; j < item->count; j++, data++, id++) {
+ for (j = 0, k = 0; j < item->count; j++, data++) {
+ /* Skip if bit in mask is not set. */
+ if (!(item->mask & BIT(j)))
+ continue;
+ if (data->capability) {
+ /*
+* Read capability register and skip non
+* relevant attributes.
+*/
+ ret = regmap_read(priv->regmap,
+ data->capability, );
+ if (ret)
+ return ret;
+ if (!(regval & data->bit))
+ continue;
+ }
PRIV_ATTR(id) = _DEV_ATTR(id).dev_attr.attr;
PRIV_ATTR(id)->name = devm_kasprintf(>pdev->dev,
GFP_KERNEL,
@@ -224,9 +253,12 @@ static int mlxreg_hotplug_attr_init(struct
mlxreg_hotplug_priv_data *priv)
PRIV_DEV_ATTR(id).dev_attr.show =
mlxreg_hotplug_attr_show;
PRIV_DEV_ATTR(id).nr = i;
- PRIV_DEV_ATTR(id).index = j;
+ PRIV_DEV_ATTR(id).index = k;
sysfs_attr_init(_DEV_ATTR(id).dev_attr.attr);
+ id++;
+ k++;
}
+ num_attrs += k;
}
priv->group.attrs = devm_kcalloc(>pdev->dev,
@@ -504,20 +536,6 @@ static int mlxreg_hotplug_set_irq(struct
mlxreg_hotplug_priv_data *priv)
item = pdata->items;
for (i = 0; i < pdata->counter; i++, item++) {
- if (item->capability) {
- /*
-* Read group capability register to get actual number
-* of interrupt capable components and set group mask
-* accordingly.
-*/
- ret = regmap_read(priv->regmap, item->capability,
- );
- if (ret)
- goto out;
-
- item->mask = GENMASK((regval & item->mask) - 1, 0);
- }
-
/* Clear group presense event. */
ret = regmap_write(priv->regmap, item->reg +
MLXREG_HOTPLUG_EVENT_OFF, 0);
--
2.11.0
[PATCH platform-next v1 3/8] platform_data/mlxreg: Add support for complex attributes
Add new field 'regnum' to the structure 'mlxreg_core_data' to specify
the number of registers occupied by multi-register attribute.
Signed-off-by: Vadim Pasternak
---
include/linux/platform_data/mlxreg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data/mlxreg.h
b/include/linux/platform_data/mlxreg.h
index b8da8aef2446..a2adc3ad45f2 100644
--- a/include/linux/platform_data/mlxreg.h
+++ b/include/linux/platform_data/mlxreg.h
@@ -80,6 +80,7 @@ struct mlxreg_hotplug_device {
* @hpdev - hotplug device data;
* @health_cntr: dynamic device health indication counter;
* @attached: true if device has been attached after good health indication;
+ * @regnum: number of registers occupied by multi-register attribute;
*/
struct mlxreg_core_data {
char label[MLXREG_CORE_LABEL_MAX_SIZE];
@@ -92,6 +93,7 @@ struct mlxreg_core_data {
struct mlxreg_hotplug_device hpdev;
u8 health_cntr;
bool attached;
+ u8 regnum;
};
/**
--
2.11.0
[PATCH platform-next v1 5/8] platform/mellanox: mlxreg-io: Add support for complex attributes
Add support for attributes composed from few registers.
Such attributes could occupy from 2 to 4 sequential registers.
For word size register space complex attribute can occupy up to two
register, for byte size - up to four. These attributes can carry, for
example, CPLD or FPGA versioning, power consuming info, etcetera.
Such registers contain read only data.
Signed-off-by: Vadim Pasternak
---
drivers/platform/mellanox/mlxreg-io.c | 47 ++-
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
index acfaf64ffde6..93dbbe381bc4 100644
--- a/drivers/platform/mellanox/mlxreg-io.c
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -30,6 +30,7 @@
* @mlxreg_io_dev_attr: sysfs sensor device attribute array;
* @group: sysfs attribute group;
* @groups: list of sysfs attribute group for hwmon registration;
+ * @regsize: size of a register value;
*/
struct mlxreg_io_priv_data {
struct platform_device *pdev;
@@ -39,27 +40,30 @@ struct mlxreg_io_priv_data {
struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
struct attribute_group group;
const struct attribute_group *groups[2];
+ int regsize;
};
static int
mlxreg_io_get_reg(void *regmap, struct mlxreg_core_data *data, u32 in_val,
- bool rw_flag, u32 *regval)
+ bool rw_flag, int regsize, u32 *regval)
{
- int ret;
+ int i, val, ret;
ret = regmap_read(regmap, data->reg, regval);
if (ret)
goto access_error;
/*
-* There are three kinds of attributes: single bit, full register's
-* bits and bit sequence. For the first kind field mask indicates which
-* bits are not related and field bit is set zero. For the second kind
-* field mask is set to zero and field bit is set with all bits one.
-* No special handling for such kind of attributes - pass value as is.
-* For the third kind, field mask indicates which bits are related and
-* field bit is set to the first bit number (from 1 to 32) is the bit
-* sequence.
+* There are four kinds of attributes: single bit, full register's
+* bits, bit sequence, bits in few registers For the first kind field
+* mask indicates which bits are not related and field bit is set zero.
+* For the second kind field mask is set to zero and field bit is set
+* with all bits one. No special handling for such kind of attributes -
+* pass value as is. For the third kind, field mask indicates which
+* bits are related and field bit is set to the first bit number (from
+* 1 to 32) is the bit sequence. For the fourth kind - the number of
+* registers which should be read for getting an attribute are specified
+* through 'data->regnum' field.
*/
if (!data->bit) {
/* Single bit. */
@@ -83,6 +87,21 @@ mlxreg_io_get_reg(void *regmap, struct mlxreg_core_data
*data, u32 in_val,
/* Clear relevant bits and set them to new value. */
*regval = (*regval & ~data->mask) | in_val;
}
+ } else {
+ /*
+* Some attributes could occupied few registers in case regmap
+* bit size is 8 or 16. Compose such attribute from 'regnum'
+* registers. Such attributes contain read only data.
+*/
+ if (data->regnum > 1 && !rw_flag)
+ return -EINVAL;
+ for (i = 1; i < data->regnum; i++) {
+ ret = regmap_read(regmap, data->reg + i, );
+ if (ret)
+ goto access_error;
+
+ *regval |= rol32(val, regsize * i);
+ }
}
access_error:
@@ -99,7 +118,8 @@ mlxreg_io_attr_show(struct device *dev, struct
device_attribute *attr,
u32 regval = 0;
int ret;
- ret = mlxreg_io_get_reg(priv->pdata->regmap, data, 0, true, );
+ ret = mlxreg_io_get_reg(priv->pdata->regmap, data, 0, true,
+ priv->regsize, );
if (ret)
goto access_error;
@@ -128,7 +148,7 @@ mlxreg_io_attr_store(struct device *dev, struct
device_attribute *attr,
return ret;
ret = mlxreg_io_get_reg(priv->pdata->regmap, data, input_val, false,
- );
+ priv->regsize, );
if (ret)
goto access_error;
@@ -207,6 +227,9 @@ static int mlxreg_io_probe(struct platform_device *pdev)
}
priv->pdev = pdev;
+ priv->regsize = regmap_get_val_bytes(priv->pdata->regmap);
+ if (priv->regsize < 0)
+
[PATCH platform-next v1 6/8] Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces
Add documentation for the new attributes for exposing CPLDs part numbers and CPLD minor versions. Signed-off-by: Vadim Pasternak --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index b0d90cc696a8..1397f207523c 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -206,3 +206,20 @@ Description: This file exposes the firmware version of burnable voltage regulator devices. The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version_min +Date: June 2020 +KernelVersion: 5.8 +Contact: Vadim Pasternak +Description: These files show with which CPLD part numbers and minor + versions have been burned CPLD devices equipped on a + system. + + The files are read only. -- 2.11.0
[PATCH platform-next v1 0/8] platform/x86: Add new features for Mellanox systems
The patchset adds new features for the existing Mellanox systems. Patch #1 allows to configure number of hotplug 'sysfs' attributes for the particular system class according to the hardware data for the specific system from this class, instead of configuring it up-to maximum number in the class. Patch #2 adds environmental data to hotplug uevent. Patches #3-#4 adds more definitions for system attributes. Patch #5 extends 'mlxreg-io' driver with complex attributes support. Patches #6 extends documentation with new attributes. Patches #7-#8 extends FAN platform data with register presence field. Vadim Pasternak (8): platform/mellanox: mlxreg-hotplug: Use capability register for attribute creation platform/mellanox: mlxreg-hotplug: Add environmental data to uevent platform_data/mlxreg: Add support for complex attributes platform/x86: mlx-platform: Add more definitions for system attributes platform/mellanox: mlxreg-io: Add support for complex attributes Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces platform_data/mlxreg: Add presence register field for FAN devices platform/x86: mlx-platform: Extend FAN platform data description Documentation/ABI/stable/sysfs-driver-mlxreg-io | 17 +++ drivers/platform/mellanox/mlxreg-hotplug.c | 81 ++ drivers/platform/mellanox/mlxreg-io.c | 47 ++-- drivers/platform/x86/mlx-platform.c | 141 include/linux/platform_data/mlxreg.h| 4 + 5 files changed, 258 insertions(+), 32 deletions(-) -- 2.11.0
[PATCH platform-next v1 8/8] platform/x86: mlx-platform: Extend FAN platform data description
Extend FAN platform data with register presence field.
Add register present entry per rotor (tachometer) description tuple.
The purpose is to allow indication of FAN presence.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 034736cec9a6..90bc7969b199 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -1840,6 +1840,8 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(0),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
+
},
{
.label = "tacho2",
@@ -1847,6 +1849,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(1),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho3",
@@ -1854,6 +1857,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(2),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho4",
@@ -1861,6 +1865,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(3),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho5",
@@ -1868,6 +1873,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(4),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho6",
@@ -1875,6 +1881,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(5),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho7",
@@ -1882,6 +1889,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(6),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho8",
@@ -1889,6 +1897,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP1_OFFSET,
.bit = BIT(7),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho9",
@@ -1896,6 +1905,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(0),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho10",
@@ -1903,6 +1913,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(1),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho11",
@@ -1910,6 +1921,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(2),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "tacho12",
@@ -1917,6 +1929,7 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_fan_data[] = {
.mask = GENMASK(7, 0),
.capability = MLXPLAT_CPLD_LPC_REG_FAN_CAP2_OFFSET,
.bit = BIT(3),
+ .reg_prsnt = MLXPLAT_CPLD_LPC_REG_FAN_OFFSET,
},
{
.label = "conf",
--
2.11.0
RE: [PATCH v6 1/1] Add support for IPMB driver
> -Original Message-
> From: Asmaa Mnebhi
> Sent: Saturday, May 04, 2019 1:35 AM
> To: miny...@acm.org; w...@the-dreams.de; Vadim Pasternak
> ; Michael Shych
> Cc: Asmaa Mnebhi ; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org
> Subject: [PATCH v6 1/1] Add support for IPMB driver
>
> Support receiving IPMB requests on a Satellite MC from the BMC.
> Once a response is ready, this driver will send back a response to the BMC via
> the IPMB channel.
>
> Signed-off-by: Asmaa Mnebhi
Hi Asmaa,
Please, see small comment below (missed space).
I suggest to always have at the development stage
KASAN and UBSAN options available in kernel config
(in case you don't use them).
It can point out on some issues which easily can be
during code review.
For example, I used to have:
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
CONFIG_UBSAN=y
CONFIG_UBSAN_SANITIZE_ALL=y
CONFIG_UBSAN_NO_ALIGNMENT=y
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y
CONFIG_KASAN_OUTLINE=y
CONFIG_KASAN_STACK=1
CONFIG_TEST_KASAN=m
Looks fine for me otherwise.
Acked-by: Vadim Pasternak
> ---
> Documentation/IPMB.txt | 103 ++
> drivers/char/ipmi/Kconfig| 8 +
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/ipmb_dev_int.c | 397
> +++
> 4 files changed, 509 insertions(+)
> create mode 100644 Documentation/IPMB.txt create mode 100644
> drivers/char/ipmi/ipmb_dev_int.c
>
> diff --git a/Documentation/IPMB.txt b/Documentation/IPMB.txt new file mode
> 100644 index 000..cfd7494
> --- /dev/null
> +++ b/Documentation/IPMB.txt
> @@ -0,0 +1,103 @@
> +
> +IPMB Driver fro Satellite MC
> +
> +
> +The Intelligent Platform Management Bus, or IPMB is an I2C bus that
> +provides a standardized interconnection between different boards within
> +a chassis. This interconnection is between the baseboard management
> +(BMC) and chassis electronics.
> +IPMB is also associated with the messaging protocol through the IPMB
> +bus.
> +
> +The devices using the IPMB are usually management controllers that
> +perform management functions such as servicing the front panel
> +interface, monitoring the baseboard, hot-swapping disk drivers in the
> +system chassis, etc...
> +
> +When an IPMB is implemented in the system, the BMC serves as a
> +controller to give system software access to the IPMB. The BMC sends
> +IPMI requests to a device (usually a Satellite Management Controller or
> +Satellite MC) via IPMB and the device sends a response back to the BMC.
> +
> +For more information on IPMB and the format of an IPMB message, refer
> +to the IPMB and IPMI specifications.
> +
> +IPMB driver for Satellite MC
> +
> +
> +ipmb-dev-int - This is the driver needed on a Satellite MC to receive
> +IPMB messages from a BMC and send a response back.
> +This driver works hand with the i2c driver and a userspace program such
> +as OpenIPMI:
> +
> +1) It is an I2C slave backend driver. So, it defines a callback
> +function to set the Satellite MC as an I2C slave.
> +This callback function handles the received IPMI requests.
> +
> +2) It defines the read and write functions to enable a user space
> +program (such as OpenIPMI) to communicate with the kernel.
> +
> +
> +Load the IPMB driver
> +
> +
> +The driver needs to be loaded at boot time or manually first.
> +First, make sure you have the following in your config file:
> +CONFIG_IPMB_DEVICE_INTERFACE=y
> +
> +1) If you want the driver to be loaded at boot time:
> +
> +a) Add this entry to your ACPI table, under the appropriate SMBus:
> +
> +Device (SMB0) // Example SMBus host controller {
> + Name (_HID, "") // Vendor-Specific HID
> + Name (_UID, 0) // Unique ID of particular host controller
> + :
> + :
> +Device (IPMB)
> +{
> + Name (_HID, "IPMB0001") // IPMB device interface
> + Name (_UID, 0) // Unique device identifier
> +}
> +}
> +
> +b) Example for device tree:
> +
> + {
> + status = "okay";
> +
> + ipmb@10 {
> + compatible = "ipmb-dev";
> + reg = <0x10>;
> + };
> +};
> +
> +2) Manually from linux:
> +modprobe ipmb-dev-int
> +
> +
> +Instantiate the device
> +--
> +
> +After loading the driver, you can instantiate the device as described
> +in the document 'instantiating-devices'.
> +If you have multiple BMCs, each connected to your Satellite MC via a
> +different I2C bus, you can instantiate a device
RE: [PATCH v5 1/1] Add support for IPMB driver
> -Original Message- > From: Asmaa Mnebhi > Sent: Thursday, May 02, 2019 9:38 PM > To: miny...@acm.org; w...@the-dreams.de; Vadim Pasternak > ; Michael Shych > Cc: Asmaa Mnebhi ; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: [PATCH v5 1/1] Add support for IPMB driver > > Support receiving IPMB requests on a Satellite MC from the BMC. > Once a response is ready, this driver will send back a response to the BMC via > the IPMB channel. > > Signed-off-by: Asmaa Mnebhi > --- > Documentation/IPMB.txt | 64 +++ > drivers/char/ipmi/Kconfig| 8 + > drivers/char/ipmi/Makefile | 1 + > drivers/char/ipmi/ipmb_dev_int.c | 384 > +++ > 4 files changed, 457 insertions(+) > create mode 100644 Documentation/IPMB.txt create mode 100644 > drivers/char/ipmi/ipmb_dev_int.c > > diff --git a/Documentation/IPMB.txt b/Documentation/IPMB.txt new file mode > 100644 index 000..5416090d > --- /dev/null > +++ b/Documentation/IPMB.txt > @@ -0,0 +1,64 @@ > + > +IPMB Driver fro Satellite MC > + > + > +The Intelligent Platform Management Bus, or IPMB is an I2C bus that > +provides a standardized interconnection between different boards within > +a chassis. This interconnection is between the baseboard management > +(BMC) and chassis electronics. > +IPMB is also associated with the messaging protocol through the IPMB > +bus. > + > +The devices using the IPMB are usually management controllers that > +perform management functions such as servicing the front panel > +interface, monitoring the baseboard, hot-swapping disk drivers in the > +system chassis, etc... > + > +When an IPMB is implemented in the system, the BMC serves as a > +controller to give system software access to the IPMB. The BMC sends > +IPMI requests to a device (usually a Satellite Management Controller or > +Satellite MC) via IPMB and the device sends a response back to the BMC. > + > +For more information on IPMB and the format of an IPMB message, refer > +to the IPMB and IPMI specifications. > + > +IPMB driver for Satellite MC > + > + > +ipmb-dev-int - This is the driver needed on a Satellite MC to receive > +IPMB messages from a BMC and send a response back. > +This driver works hand with the i2c driver and a userspace program such > +as OpenIPMI: > + > +1) It is an I2C slave backend driver. So, it defines a callback > +function to set the Satellite MC as an I2C slave. > +This callback function handles the received IPMI requests. > + > +2) It defines the read and write functions to enable a user space > +program (such as OpenIPMI) to communicate with the kernel. > + > +Load the IPMB driver > + > + > +The driver needs to be loaded at boot time or manually first. > +Then, you can instantiate the device as described in the document > +'instantiating-devices'. > +If you have multiple BMCs, each connected to your Satellite MC via a > +different I2C bus, you can instantiate a device for each of those BMCs. > +The name of the instantiated device contains the I2C bus number > +associated with it as follows: > + > +BMC1 -- IPMB/I2C bus 1 -| /dev/ipmb-1 > + Satellite MC > +BMC1 -- IPMB/I2C bus 2 -| /dev/ipmb-2 > + > +For instance, you can instantiate the ipmb-dev-int device from user > +space at the 7 bit address 0x10 on bus 2: > + > + # echo ipmb-dev 0x10 > /sys/bus/i2c/devices/i2c-2/new_device > + > +This will create device file /dev/ipmb-2, which can be accessed by the > +user space program. The device needs to be instantiated before running > +the user space program. > diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig index > 94719fc..12fe8f2 100644 > --- a/drivers/char/ipmi/Kconfig > +++ b/drivers/char/ipmi/Kconfig > @@ -74,6 +74,14 @@ config IPMI_SSIF >have a driver that must be accessed over an I2C bus instead of a >standard interface. This module requires I2C support. > > +config IPMB_DEVICE_INTERFACE > + tristate 'IPMB Interface handler' > + depends on I2C && I2C_SLAVE > + help > + Provides a driver for a device (Satellite MC) to > + receive requests and send responses back to the BMC via > + the IPMB interface. This module requires I2C support. > + > config IPMI_POWERNV > depends on PPC_POWERNV > tristate 'POWERNV (OPAL firmware) IPMI interface' > diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile index > 3f06b20..0822adc 100644 > --- a/drive
RE: [PATCH v4 0/1] Add support for IPMB driver
[...] > > > > >>Better, if you can avoid cast. > > >>Would compiler warn if you use for example rol16(client->addr, 1) & > GENMASK(7, 0); or something like it? > > I thought it wouldn't be too much of an issue to use typecast here since > > other > existing ipmi drivers use typecasting: bt-bmc.c, kcs_bmc_aspeed.c, > kcs_bmc_npcm7xx.c all use (u8) typecasting. > > But if you really think it is worth it, I could do that. > > I just think it is not as straight forward to read this code as using a > > simple > typecast. Some might wonder why a GENMASK is needed in this case. > > Hi Asmaa, I will not insist in case it's OK with maintainers. [...]
RE: [PATCH v4 1/1] Add support for IPMB driver
> -Original Message- > From: Asmaa Mnebhi > Sent: Tuesday, April 30, 2019 8:59 PM > To: miny...@acm.org; w...@the-dreams.de; Vadim Pasternak > ; Michael Shych > Cc: Asmaa Mnebhi ; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: [PATCH v4 1/1] Add support for IPMB driver > > Support receiving IPMB requests on a Satellite MC from the BMC. > Once a response is ready, this driver will send back a response to the BMC via > the IPMB channel. > > Signed-off-by: Asmaa Mnebhi > --- > Documentation/IPMB.txt | 53 ++ > drivers/char/ipmi/Kconfig| 8 + > drivers/char/ipmi/Makefile | 1 + > drivers/char/ipmi/ipmb_dev_int.c | 381 > +++ > 4 files changed, 443 insertions(+) > create mode 100644 Documentation/IPMB.txt create mode 100644 > drivers/char/ipmi/ipmb_dev_int.c > > diff --git a/Documentation/IPMB.txt b/Documentation/IPMB.txt new file mode > 100644 index 000..cc5ce10 > --- /dev/null > +++ b/Documentation/IPMB.txt > @@ -0,0 +1,53 @@ > + > +IPMB Driver fro Satellite MC > + > + > +The Intelligent Platform Management Bus, or IPMB is an I2C bus that > +provides a standardized interconnection between different boards within > +a chassis. This interconnection is between the baseboard management > +(BMC) and chassis electronics. > +IPMB is also associated with the messagin protocol through the IPMB s/messagin/messaging > +bus. > + > +The devices using the IPMB are usually management controllers that > +perform management functions such as servicing the front panel > +interface, monitoring the baseboard, hot-swapping disk drivers in the > +system chassis, etc... > + > +When an IPMB is implemented in the system, the BMC serves as a > +controller to give system software access to the IPMB. The BMC sends > +IPMI requests to a device (usually a Satellite Management Controller or > +Satellite MC) via IPMB and the device sends a response back to the BMC. > + > +For more information on IPMB and the format of an IPMB message, refer > +to the IPMB and IPMI specifications. > + > +IPMB driver for Satellite MC > + > + > +ipmb-dev-int - This is the driver needed on a Satellite MC to receive > +IPMB messages from a BMC and send a response back. > +This driver works hand with the i2c driver and a userspace program such > +as OpenIPMI: > + > +1) It is an I2C slave backend driver. So, it defines a callback > +function to set the Satellite MC as an I2C slave. > +This callback function handles the received IPMI requests. > + > +2) It defines the read and write functions to enable a user space > +program (such as OpenIPMI) to communicate with the kernel. > + > +Load the IPMB driver > + > + > +The driver needs to be loaded at boot time or manually first. > +Then, you can instantiate the device as described in the document > +'instantiating-devices'. > +An example for instantiating the ipmb-dev-int driver from userspace at > +the 7 bit address 0x10 on bus 2: > + > + # echo ipmb-dev 0x10 > /sys/bus/i2c/devices/i2c-2/new_device > + > +The device needs to be instantiated before running the user space > +program. > diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig index > 94719fc..12fe8f2 100644 > --- a/drivers/char/ipmi/Kconfig > +++ b/drivers/char/ipmi/Kconfig > @@ -74,6 +74,14 @@ config IPMI_SSIF >have a driver that must be accessed over an I2C bus instead of a >standard interface. This module requires I2C support. > > +config IPMB_DEVICE_INTERFACE > + tristate 'IPMB Interface handler' > + depends on I2C && I2C_SLAVE > + help > + Provides a driver for a device (Satellite MC) to > + receive requests and send responses back to the BMC via > + the IPMB interface. This module requires I2C support. > + > config IPMI_POWERNV > depends on PPC_POWERNV > tristate 'POWERNV (OPAL firmware) IPMI interface' > diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile index > 3f06b20..0822adc 100644 > --- a/drivers/char/ipmi/Makefile > +++ b/drivers/char/ipmi/Makefile > @@ -26,3 +26,4 @@ obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o > obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o > obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o > obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o > +obj-$(CONFIG_IPMB_DEVICE_INTERFACE) += ipmb_dev_int.o > diff --git a/drivers/char/ipmi/ipmb_dev_int.c > b/drivers/char/ipmi/ipmb_dev_int.c > new file mode 100644 > index 000..bd71fea > --- /dev/null &
RE: [PATCH v4 0/1] Add support for IPMB driver
> -Original Message- > From: Asmaa Mnebhi > Sent: Tuesday, April 30, 2019 8:59 PM > To: miny...@acm.org; w...@the-dreams.de; Vadim Pasternak > ; Michael Shych > Cc: Asmaa Mnebhi ; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: [PATCH v4 0/1] Add support for IPMB driver > > Thank you for your feedback Vadim. I have addressed your comments. Hi Asmaa, Thank you for your comments and added doc. > > 1) You are correct. This driver is not specific to Mellanox so I have removed > the > Mellanox attribute. > > 2) I have added a documentation file called IPMB.txt which explains how this > module works and how it should be instantiated. It is very similar to the > existing > linux i2c-slave-eeprom module. > > The HW for my testing works as follows: > A BMC is connected to a Satellite MC via I2C (I2C is equivalent to IPMB). The > BMC initiates the IPMB requests and sends them via I2C. > Obviously the BMC needs its own driver to do this which I haven't included in > this > code. We have no intent of upstreaming that at the moment. I believe you are going to do it at some point, right? > This ipmb-dev-int driver is to be loaded and instantiated on the Satellite MC > to > be able to receive IPMB requests. These IPMB request messages will be picked > up by a user space program such (in my case it is OpenIPMI) to handle the > request and generate a response. > The response will be then passed from the user program back to kernel space. > Then this driver would send that response back to the BMC. > > 3) You asked the following: > > "Is it expected to be zero in vaid case?" > The 8 least significant bits of the sum is always expected to be 0 in the case > where the checksum is valid. I have added a comment for clarifications. > > "why do you need this cast?" > buf[++ipmb_dev_p->msg_idx]=(u8)(client->addr<<1) > This is because client->addr is of type unsigned short which is > 2 bytes so it is safer to typecast it to u8 (u8* buf) Better, if you can avoid cast. Would compiler warn if you use for example rol16(client->addr, 1) & GENMASK(7, 0); or something like it? > > "It could be only single ipmb-dev within the system? Couldn't it be few, like > master/slave for example?" > My understanding of your question is that: what if we have multiple instances > of > ipmb-dev-int, that we register it under different addresses? > This driver only works as a slave so it will only be instantiated once on the > Satellite MC under one slave address. I mentioned some config like: BMC1 (master) -- busA --| Satellite BMC2 (standby) -- busB --| Since this is not Mellanox specific driver, maybe it would be good to support multiple instances of it. > > Asmaa Mnebhi (1): > Add support for IPMB driver > > Documentation/IPMB.txt | 53 ++ > drivers/char/ipmi/Kconfig| 8 + > drivers/char/ipmi/Makefile | 1 + > drivers/char/ipmi/ipmb_dev_int.c | 381 > +++ > 4 files changed, 443 insertions(+) > create mode 100644 Documentation/IPMB.txt create mode 100644 > drivers/char/ipmi/ipmb_dev_int.c > > -- > 2.1.2
RE: [PATCH v3 1/1] Add support for IPMB driver
> -Original Message-
> From: Asmaa Mnebhi
> Sent: Tuesday, April 30, 2019 12:57 AM
> To: miny...@acm.org; w...@the-dreams.de; Vadim Pasternak
> ; Michael Shych
> Cc: Asmaa Mnebhi ; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org
> Subject: [PATCH v3 1/1] Add support for IPMB driver
>
> Support receiving IPMB requests on a Satellite MC from the BMC.
> Once a response is ready, this driver will send back a response to the BMC via
> the IPMB channel.
Hi Asmaa,
Few common questions.
You define this driver as "Mellanox BlueField IPMB driver".
What makes it Mellanox BlueField specific?
Which HW configuration you used for testing? Could
you please explain connectivity schema between main BMC and
satellite BMCs?
How this module is supposed to be activated?
Don't you need to add DTS/ACPI records?
Also few comments below.
>
> Signed-off-by: Asmaa Mnebhi
> ---
> drivers/char/ipmi/Kconfig| 8 +
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/ipmb_dev_int.c | 386
> +++
> 3 files changed, 395 insertions(+)
> create mode 100644 drivers/char/ipmi/ipmb_dev_int.c
>
> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig index
> 94719fc..12fe8f2 100644
> --- a/drivers/char/ipmi/Kconfig
> +++ b/drivers/char/ipmi/Kconfig
> @@ -74,6 +74,14 @@ config IPMI_SSIF
>have a driver that must be accessed over an I2C bus instead of a
>standard interface. This module requires I2C support.
>
> +config IPMB_DEVICE_INTERFACE
> + tristate 'IPMB Interface handler'
> + depends on I2C && I2C_SLAVE
> + help
> + Provides a driver for a device (Satellite MC) to
> + receive requests and send responses back to the BMC via
> + the IPMB interface. This module requires I2C support.
> +
> config IPMI_POWERNV
> depends on PPC_POWERNV
> tristate 'POWERNV (OPAL firmware) IPMI interface'
> diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile index
> 3f06b20..0822adc 100644
> --- a/drivers/char/ipmi/Makefile
> +++ b/drivers/char/ipmi/Makefile
> @@ -26,3 +26,4 @@ obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
> obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
> +obj-$(CONFIG_IPMB_DEVICE_INTERFACE) += ipmb_dev_int.o
> diff --git a/drivers/char/ipmi/ipmb_dev_int.c
> b/drivers/char/ipmi/ipmb_dev_int.c
> new file mode 100644
> index 000..63122c3
> --- /dev/null
> +++ b/drivers/char/ipmi/ipmb_dev_int.c
> @@ -0,0 +1,386 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Mellanox IPMB driver to receive a request and send a response
> + *
> + * Copyright (C) 2018 Mellanox Techologies, Ltd.
> + *
> + * This was inspired by Brendan Higgins' ipmi-bmc-bt-i2c driver.
> + */
> +
> +#define pr_fmt(fmt) "ipmb_dev_int: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_MSG_LEN 128
> +#define IPMB_REQUEST_LEN_MIN7
> +#define NETFN_RSP_BIT_MASK 0x4
> +#define REQUEST_QUEUE_MAX_LEN 256
> +
> +#define IPMB_MSG_LEN_IDX0
> +#define RQ_SA_8BIT_IDX 1
> +#define NETFN_LUN_IDX 2
> +
> +#define IPMB_MSG_PAYLOAD_LEN_MAX (MAX_MSG_LEN -
> IPMB_REQUEST_LEN_MIN - 1)
> +
> +struct ipmb_msg {
> + u8 len;
> + u8 rs_sa;
> + u8 netfn_rs_lun;
> + u8 checksum1;
> + u8 rq_sa;
> + u8 rq_seq_rq_lun;
> + u8 cmd;
> + u8 payload[IPMB_MSG_PAYLOAD_LEN_MAX];
> + /* checksum2 is included in payload */ } __packed;
> +
> +static u32 ipmb_msg_len(struct ipmb_msg *ipmb_msg) {
> + return ipmb_msg->len + 1;
> +}
Do you really need it as function?
> +
> +struct ipmb_request_elem {
> + struct list_head list;
> + struct ipmb_msg request;
> +};
> +
> +struct ipmb_dev {
> + struct i2c_client *client;
> + struct miscdevice miscdev;
> + struct ipmb_msg request;
> + struct list_head request_queue;
> + atomic_t request_queue_len;
> + struct ipmb_msg response;
Where you are using 'response' field?
> + size_t msg_idx;
> + spinlock_t lock;
> + wait_queue_head_t wait_queue;
> + struct mutex file_mutex;
> +};
> +
> +static int receive_ipmb_request(struct ipmb_dev *ipmb_dev_p,
> + bool non_blocking,
> + struct ipmb_msg *ipmb_request)
> +{
RE: [PATCH v1 bitops] bitops: Fix UBSAN undefined behavior warning for rotation right
> -Original Message-
> From: Andrew Morton
> Sent: Tuesday, April 09, 2019 1:52 AM
> To: Vadim Pasternak
> Cc: jacek.anaszew...@gmail.com; pa...@ucw.cz; linux-kernel@vger.kernel.org;
> linux-l...@vger.kernel.org; Ido Schimmel ; Andrey
> Ryabinin
> Subject: Re: [PATCH v1 bitops] bitops: Fix UBSAN undefined behavior warning
> for rotation right
>
> (resend, cc Andrey)
>
> On Sun, 7 Apr 2019 12:53:25 + Vadim Pasternak
> wrote:
>
> > The warning is caused by call to rorXX(), if the second parameters of
> > this function "shift" is zero. In such case UBSAN reports the warning
> > for the next expression: (word << (XX - shift), where XX is 64, 32,
> > 16, 8 for respectively ror64, ror32, ror16, ror8.
> > Fix adds validation of this parameter - in case it's equal zero, no
> > need to rotate, just original "word" is to be returned to caller.
> >
> > The UBSAN undefined behavior warning has been reported for call to
> > ror32():
> > [ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
> > [ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
>
> hm, do we care?
Hi Andrew,
Thank for reply.
We want to avoid UBSAN undefined behavior warning in case
"shift" parameter is not provided as a constant.
>
> > ...
> >
>
> > --- a/include/linux/bitops.h
> > +++ b/include/linux/bitops.h
> > @@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
> > */
> > static inline __u64 ror64(__u64 word, unsigned int shift) {
> > + if (!shift)
> > + return word;
> > +
> > return (word >> shift) | (word << (64 - shift)); }
>
> Is there any known architecture or compiler for which UL<<64 doesn't reliably
> produce zero? Is there any prospect that this will become a problem in the
> future?
I don't know about such architecture.
Do you think it could be modified only for ro8, ror16, ror32?
[PATCH v1 bitops] bitops: Fix UBSAN undefined behavior warning for rotation right
The warning is caused by call to rorXX(), if the second parameters of
this function "shift" is zero. In such case UBSAN reports the warning
for the next expression: (word << (XX - shift), where XX is
64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
Fix adds validation of this parameter - in case it's equal zero, no
need to rotate, just original "word" is to be returned to caller.
The UBSAN undefined behavior warning has been reported for call to
ror32():
[ 11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
[ 11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'
[ 11.441647] Hardware name: Mellanox Technologies Ltd. MSN3800/VMOD0007, BIOS
5.11 01/06/2019
[ 11.441650] Call Trace:
[ 11.441661] dump_stack+0x71/0xab
[ 11.441668] ubsan_epilogue+0x9/0x49
[ 11.441676] __ubsan_handle_shift_out_of_bounds+0x1ea/0x241
[ 11.441683] ? __ubsan_handle_load_invalid_value+0x137/0x137
[ 11.441691] ? __module_text_address+0x11/0x90
[ 11.441697] ? widen_string+0x27/0x140
[ 11.441704] ? regmap_readable+0x76/0xc0
[ 11.441709] ? regmap_readable+0x76/0xc0
[ 11.441718] ? mlxplat_mlxcpld_readable_reg+0x1f/0x30 [mlx_platform]
[ 11.441723] ? regmap_volatile+0x40/0xb0
[ 11.441729] ? mlxplat_mlxcpld_volatile_reg+0x1f/0x30 [mlx_platform]
[ 11.441735] ? _regmap_read+0x11c/0x210
[ 11.441741] ? __mutex_lock_slowpath+0x10/0x10
[ 11.441750] ? mlxreg_led_store_hw+0x191/0x270 [leds_mlxreg]
[ 11.441756] mlxreg_led_store_hw+0x191/0x270 [leds_mlxreg]
[ 11.441764] ? mlxreg_led_brightness_get+0x270/0x270 [leds_mlxreg]
[ 11.441769] ? del_timer+0xe0/0xe0
[ 11.441776] ? bust_spinlocks+0x90/0x90
[ 11.441784] led_blink_setup+0x47/0x1d0
[ 11.441792] timer_trig_activate+0x8f/0x175 [ledtrig_timer]
[ 11.441799] ? kvasprintf_const+0xb0/0xb0
[ 11.441805] ? led_delay_on_show+0x50/0x50 [ledtrig_timer]
[ 11.441810] ? _raw_write_lock_bh+0xe0/0xe0
[ 11.441815] ? _raw_read_lock_irqsave+0x80/0x80
[ 11.441822] led_trigger_set+0x2cf/0x4d0
[ 11.441829] ? led_trigger_show+0x1f0/0x1f0
[ 11.441834] ? __mutex_lock_slowpath+0x10/0x10
[ 11.441840] ? kernfs_get_active+0xb2/0x120
[ 11.441845] ? kernfs_get_parent+0x50/0x50
[ 11.441851] led_trigger_store+0xe7/0x130
[ 11.441858] kernfs_fop_write+0x19a/0x250
[ 11.441863] ? sysfs_kf_bin_read+0x120/0x120
[ 11.441869] vfs_write+0xf5/0x230
[ 11.441875] ksys_write+0xa1/0x120
[ 11.441881] ? __ia32_sys_read+0x50/0x50
[ 11.441888] ? __do_page_fault+0x3e4/0x640
[ 11.441895] do_syscall_64+0x73/0x160
[ 11.441900] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 11.441905] RIP: 0033:0x7f955749f730
[ 11.441911] Code: 73 01 c3 48 8b 0d 68 d7 2b 00 f7 d8 64 89 01 48 83 c8 ff
c3 66 0f 1f 44 00 00 83 3d d9 2f 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 9b 01 00 48 89 04 24
[ 11.441914] RSP: 002b:7ffd4da04488 EFLAGS: 0246 ORIG_RAX:
0001
[ 11.441920] RAX: ffda RBX: 0006 RCX: 7f955749f730
[ 11.441923] RDX: 0006 RSI: 01a14408 RDI: 0001
[ 11.441926] RBP: 01a14408 R08: 7f955775f760 R09: 7f9557da9b40
[ 11.441929] R10: 0097 R11: 0246 R12: 0006
[ 11.441932] R13: 0001 R14: 7f955775e600 R15: 0006
Reported-by: Ido Schimmel
Signed-off-by: Vadim Pasternak
---
include/linux/bitops.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 602af23b98c7..02c00f3c8205 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
*/
static inline __u64 ror64(__u64 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (64 - shift));
}
@@ -90,6 +93,9 @@ static inline __u32 rol32(__u32 word, unsigned int shift)
*/
static inline __u32 ror32(__u32 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (32 - shift));
}
@@ -110,6 +116,9 @@ static inline __u16 rol16(__u16 word, unsigned int shift)
*/
static inline __u16 ror16(__u16 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (16 - shift));
}
@@ -130,6 +139,9 @@ static inline __u8 rol8(__u8 word, unsigned int shift)
*/
static inline __u8 ror8(__u8 word, unsigned int shift)
{
+ if (!shift)
+ return word;
+
return (word >> shift) | (word << (8 - shift));
}
--
2.11.0
RE: [PATCH v8 1/2] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
> -Original Message- > From: Liming Sun > Sent: Monday, January 28, 2019 7:28 PM > To: Rob Herring ; Mark Rutland > ; Arnd Bergmann ; David Woods > ; Andy Shevchenko ; Darren > Hart ; Vadim Pasternak > Cc: Liming Sun ; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org > Subject: [PATCH v8 1/2] platform/mellanox: Add TmFifo driver for Mellanox > BlueField Soc > > This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo > is a shared FIFO which enables external host machine to exchange data with the > SoC via USB or PCIe. The driver is based on virtio framework and has console > and network access enabled. > > Reviewed-by: David Woods > Signed-off-by: Liming Sun > --- > drivers/platform/mellanox/Kconfig | 13 +- > drivers/platform/mellanox/Makefile|1 + > drivers/platform/mellanox/mlxbf-tmfifo-regs.h | 67 ++ > drivers/platform/mellanox/mlxbf-tmfifo.c | 1289 > + > 4 files changed, 1369 insertions(+), 1 deletion(-) create mode 100644 > drivers/platform/mellanox/mlxbf-tmfifo-regs.h > create mode 100644 drivers/platform/mellanox/mlxbf-tmfifo.c > > diff --git a/drivers/platform/mellanox/Kconfig > b/drivers/platform/mellanox/Kconfig > index cd8a908..a565070 100644 > --- a/drivers/platform/mellanox/Kconfig > +++ b/drivers/platform/mellanox/Kconfig > @@ -5,7 +5,7 @@ > > menuconfig MELLANOX_PLATFORM > bool "Platform support for Mellanox hardware" > - depends on X86 || ARM || COMPILE_TEST > + depends on X86 || ARM || ARM64 || COMPILE_TEST > ---help--- > Say Y here to get to see options for platform support for > Mellanox systems. This option alone does not add any kernel code. > @@ -34,4 +34,15 @@ config MLXREG_IO > to system resets operation, system reset causes monitoring and some > kinds of mux selection. > > +config MLXBF_TMFIFO > + tristate "Mellanox BlueField SoC TmFifo platform driver" > + depends on ARM64 Why you make it dependent on ARM64? Should not it work on any host, x86? > + default m User who needs it should select this option. No need default 'm'. > + select VIRTIO_CONSOLE > + select VIRTIO_NET > + help > + Say y here to enable TmFifo support. The TmFifo driver provides > + platform driver support for the TmFifo which supports console > + and networking based on the virtio framework. > + > endif # MELLANOX_PLATFORM > diff --git a/drivers/platform/mellanox/Makefile > b/drivers/platform/mellanox/Makefile > index 57074d9c..f0c061d 100644 > --- a/drivers/platform/mellanox/Makefile > +++ b/drivers/platform/mellanox/Makefile > @@ -5,3 +5,4 @@ > # > obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o > obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o > +obj-$(CONFIG_MLXBF_TMFIFO) += mlxbf-tmfifo.o > diff --git a/drivers/platform/mellanox/mlxbf-tmfifo-regs.h > b/drivers/platform/mellanox/mlxbf-tmfifo-regs.h > new file mode 100644 > index 000..90c9c2cf > --- /dev/null > +++ b/drivers/platform/mellanox/mlxbf-tmfifo-regs.h > @@ -0,0 +1,67 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c) 2019, Mellanox Technologies. All rights reserved. > + */ > + > +#ifndef __MLXBF_TMFIFO_REGS_H__ > +#define __MLXBF_TMFIFO_REGS_H__ > + > +#include > + > +#define MLXBF_TMFIFO_TX_DATA 0x0 > + > +#define MLXBF_TMFIFO_TX_STS 0x8 > +#define MLXBF_TMFIFO_TX_STS__LENGTH 0x0001 #define > +MLXBF_TMFIFO_TX_STS__COUNT_SHIFT 0 #define > +MLXBF_TMFIFO_TX_STS__COUNT_WIDTH 9 #define > +MLXBF_TMFIFO_TX_STS__COUNT_RESET_VAL 0 #define > +MLXBF_TMFIFO_TX_STS__COUNT_RMASK 0x1ff #define > +MLXBF_TMFIFO_TX_STS__COUNT_MASK 0x1ff > + > +#define MLXBF_TMFIFO_TX_CTL 0x10 > +#define MLXBF_TMFIFO_TX_CTL__LENGTH 0x0001 #define > +MLXBF_TMFIFO_TX_CTL__LWM_SHIFT 0 #define > MLXBF_TMFIFO_TX_CTL__LWM_WIDTH > +8 #define MLXBF_TMFIFO_TX_CTL__LWM_RESET_VAL 128 #define > +MLXBF_TMFIFO_TX_CTL__LWM_RMASK 0xff #define > +MLXBF_TMFIFO_TX_CTL__LWM_MASK 0xff #define > +MLXBF_TMFIFO_TX_CTL__HWM_SHIFT 8 #define > MLXBF_TMFIFO_TX_CTL__HWM_WIDTH > +8 #define MLXBF_TMFIFO_TX_CTL__HWM_RESET_VAL 128 #define > +MLXBF_TMFIFO_TX_CTL__HWM_RMASK 0xff #define > +MLXBF_TMFIFO_TX_CTL__HWM_MASK 0xff00 #define > +MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_SHIFT 32 #define > +MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_WIDTH 9 #define > +MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RESET_VAL 256 #define > +MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK 0x1ff #define > +MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK 0x1ffULL > + > +#define MLXBF_TMFIFO_RX_DATA 0x0 > + >
RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
[...]
Please, be consistent with naming convention.
All the above should have same prefix as others routines.
>
> > +static ssize_t post_reset_wdog_store(struct device_driver *drv,
> > +const char *buf, size_t count) {
> > + int err;
> > + unsigned long watchdog;
> > +
> > + err = kstrtoul(buf, 10, );
> > + if (err)
> > + return err;
> > +
>
> > + if (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_POST_RESET_WDOG,
> > + watchdog) < 0)
> > + return -EINVAL;
>
> If that call returns an error it shouldn't be shadowed here.
>
> > +
> > + return count;
> > +}
> > +
> > +static ssize_t reset_action_show(struct device_driver *drv, char
> > +*buf) {
>
> > + return sprintf(buf, "%s\n", reset_action_to_string(
> > +
> > + mlxbf_bootctl_smc_call0(MLXBF_BOOTCTL_GET_RESET_ACTION)));
>
> Wouldn't be easy to parse this as
>
> int action = ...call0();
> return sprintf(...);
>
> ?
>
> (int is an arbitrary type here, choose one that suits)
>
> > +}
> > +
> > +static ssize_t reset_action_store(struct device_driver *drv,
> > + const char *buf, size_t count) {
> > + int action = reset_action_to_val(buf, count);
> > +
>
> > + if (action < 0 || action == MLXBF_BOOTCTL_NONE)
> > + return -EINVAL;
>
> Don't shadow an error.
>
> > +
> > + if (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_RESET_ACTION,
> action) < 0)
> > + return -EINVAL;
>
> Same.
>
> > +
> > + return count;
> > +}
> > +
> > +static ssize_t second_reset_action_show(struct device_driver *drv,
> > +char *buf) {
>
> > + return sprintf(buf, "%s\n", reset_action_to_string(
> > + mlxbf_bootctl_smc_call0(
> > + MLXBF_BOOTCTL_GET_SECOND_RESET_ACTION)));
>
> Use temp variable.
>
> > +}
> > +
> > +static ssize_t second_reset_action_store(struct device_driver *drv,
> > +const char *buf, size_t
> > +count) {
> > + int action = reset_action_to_val(buf, count);
> > +
> > + if (action < 0)
> > + return -EINVAL;
>
> Don't shadow an error.
>
> > +
> > + if
> (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_SECOND_RESET_ACTION,
> > + action) < 0)
> > + return -EINVAL;
>
> Same.
>
> > +
> > + return count;
> > +}
> > +
> > +static ssize_t lifecycle_state_show(struct device_driver *drv, char
> > +*buf) {
>
> > + int lc_state = mlxbf_bootctl_smc_call1(
> > + MLXBF_BOOTCTL_GET_TBB_FUSE_STATUS,
> > + MLXBF_BOOTCTL_FUSE_STATUS_LIFECYCLE);
>
> Split it as
>
> int ...;
>
> ... = call1();
> if (...)
>
> > +
> > + if (lc_state < 0)
> > + return -EINVAL;
>
> Don't shadow an error.
>
> > +
> > + lc_state &= (MLXBF_BOOTCTL_SB_MODE_TEST_MASK |
> > +MLXBF_BOOTCTL_SB_MODE_SECURE_MASK);
>
> Better to split like
>
> xxx =
> (A | B);
>
> > + /*
> > +* If the test bits are set, we specify that the current state may
> > be
> > +* due to using the test bits.
> > +*/
>
> > + if ((lc_state & MLXBF_BOOTCTL_SB_MODE_TEST_MASK) != 0) {
>
> ' != 0' is redundant.
>
> > +
> > + lc_state &= MLXBF_BOOTCTL_SB_MODE_SECURE_MASK;
> > +
>
> > + return sprintf(buf, "%s(test)\n",
> > +
> > + mlxbf_bootctl_lifecycle_states[lc_state]);
>
> One line?
>
> > + }
> > +
> > + return sprintf(buf, "%s\n",
> > +mlxbf_bootctl_lifecycle_states[lc_state]);
> > +}
> > +
> > +static ssize_t secure_boot_fuse_state_show(struct device_driver *drv,
> > +char *buf) {
> > + int key;
> > + int buf_len = 0;
> > + int upper_key_used = 0;
> > + int sb_key_state = mlxbf_bootctl_smc_call1(
> > + MLXBF_BOOTCTL_GET_TBB_FUSE_STATUS,
> > + MLXBF_BOOTCTL_FUSE_STATUS_KEYS);
> > +
> > + if (sb_key_state < 0)
> > + return -EINVAL;
> > +
>
> > + for (key = MLXBF_SB_KEY_NUM - 1; key >= 0; key--) {
>
> I'm not sure it's a good idea to put several lines in one sysfs attribute.
>
> > + int burnt = ((sb_key_state & (1 << key)) != 0);
>
> Redundant ' != 0', redundant parens.
>
> > + int valid = ((sb_key_state &
> > + (1 << (key + MLXBF_SB_KEY_NUM))) != 0);
>
> Same.
>
> > +
> > + buf_len += sprintf(buf + buf_len, "Ver%d:", key);
> > + if (upper_key_used) {
> > + if (burnt) {
> > + if (valid)
> > + buf_len += sprintf(buf + buf_len,
> > + "Used");
>
> Oh, why not just
>
> const char *status;
>
> if (...) {
> ...
> status =
RE: [PATCH] platform/x86: mlx-platform: Properly use mlxplat_mlxcpld_msn201x_items
> -Original Message-
> From: Nathan Chancellor
> Sent: Wednesday, September 26, 2018 8:21 AM
> To: Vadim Pasternak ; Darren Hart
> ; Andy Shevchenko
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; Nathan
> Chancellor
> Subject: [PATCH] platform/x86: mlx-platform: Properly use
> mlxplat_mlxcpld_msn201x_items
>
> Clang warns that mlxplat_mlxcpld_msn201x_items is not going to be emitted in
> the final assembly because it's only used in ARRAY_SIZE right now, which is a
> compile time evaluation since the array's size is known.
>
> drivers/platform/x86/mlx-platform.c:555:32: warning: variable
> 'mlxplat_mlxcpld_msn201x_items' is not needed and will not be emitted [-
> Wunneeded-internal-declaration] static struct mlxreg_core_item
> mlxplat_mlxcpld_msn201x_items[] = {
>^
> 1 warning generated.
>
> It appears this was a copy and paste mistake from when this item was first
> added. Use the definition in mlxplat_mlxcpld_msn201x_data so that Clang no
> longer warns.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/141
> Fixes: a49a41482f61 ("platform/x86: mlx-platform: Add support for new
> msn201x system type")
> Signed-off-by: Nathan Chancellor
> ---
Acked-by: Vadim Pasternak
> drivers/platform/x86/mlx-platform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/mlx-platform.c b/drivers/platform/x86/mlx-
> platform.c
> index d89936c93ba0..c2c3a1a19879 100644
> --- a/drivers/platform/x86/mlx-platform.c
> +++ b/drivers/platform/x86/mlx-platform.c
> @@ -575,7 +575,7 @@ static struct mlxreg_core_item
> mlxplat_mlxcpld_msn201x_items[] = {
>
> static
> struct mlxreg_core_hotplug_platform_data mlxplat_mlxcpld_msn201x_data = {
> - .items = mlxplat_mlxcpld_msn21xx_items,
> + .items = mlxplat_mlxcpld_msn201x_items,
> .counter = ARRAY_SIZE(mlxplat_mlxcpld_msn201x_items),
> .cell = MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET,
> .mask = MLXPLAT_CPLD_AGGR_MASK_DEF,
> --
> 2.19.0
RE: [PATCH] platform/x86: mlx-platform: Properly use mlxplat_mlxcpld_msn201x_items
> -Original Message-
> From: Nathan Chancellor
> Sent: Wednesday, September 26, 2018 8:21 AM
> To: Vadim Pasternak ; Darren Hart
> ; Andy Shevchenko
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; Nathan
> Chancellor
> Subject: [PATCH] platform/x86: mlx-platform: Properly use
> mlxplat_mlxcpld_msn201x_items
>
> Clang warns that mlxplat_mlxcpld_msn201x_items is not going to be emitted in
> the final assembly because it's only used in ARRAY_SIZE right now, which is a
> compile time evaluation since the array's size is known.
>
> drivers/platform/x86/mlx-platform.c:555:32: warning: variable
> 'mlxplat_mlxcpld_msn201x_items' is not needed and will not be emitted [-
> Wunneeded-internal-declaration] static struct mlxreg_core_item
> mlxplat_mlxcpld_msn201x_items[] = {
>^
> 1 warning generated.
>
> It appears this was a copy and paste mistake from when this item was first
> added. Use the definition in mlxplat_mlxcpld_msn201x_data so that Clang no
> longer warns.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/141
> Fixes: a49a41482f61 ("platform/x86: mlx-platform: Add support for new
> msn201x system type")
> Signed-off-by: Nathan Chancellor
> ---
Acked-by: Vadim Pasternak
> drivers/platform/x86/mlx-platform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/mlx-platform.c b/drivers/platform/x86/mlx-
> platform.c
> index d89936c93ba0..c2c3a1a19879 100644
> --- a/drivers/platform/x86/mlx-platform.c
> +++ b/drivers/platform/x86/mlx-platform.c
> @@ -575,7 +575,7 @@ static struct mlxreg_core_item
> mlxplat_mlxcpld_msn201x_items[] = {
>
> static
> struct mlxreg_core_hotplug_platform_data mlxplat_mlxcpld_msn201x_data = {
> - .items = mlxplat_mlxcpld_msn21xx_items,
> + .items = mlxplat_mlxcpld_msn201x_items,
> .counter = ARRAY_SIZE(mlxplat_mlxcpld_msn201x_items),
> .cell = MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET,
> .mask = MLXPLAT_CPLD_AGGR_MASK_DEF,
> --
> 2.19.0
RE: [PATCH] platform/mellanox: Use 2-factor allocator calls
> -Original Message-
> From: Kees Cook [mailto:keesc...@chromium.org]
> Sent: Wednesday, July 04, 2018 8:29 PM
> To: Darren Hart
> Cc: Vadim Pasternak ; Andy Shevchenko
> ; platform-driver-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] platform/mellanox: Use 2-factor allocator calls
>
> As already done treewide, switch from open-coded multiplication to using 2-
> factor allocation helpers.
>
> Signed-off-by: Kees Cook
Acked-by: Vadim Pasternak
> ---
> drivers/platform/mellanox/mlxreg-io.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/mellanox/mlxreg-io.c
> b/drivers/platform/mellanox/mlxreg-io.c
> index c192dfe6bd65..acfaf64ffde6 100644
> --- a/drivers/platform/mellanox/mlxreg-io.c
> +++ b/drivers/platform/mellanox/mlxreg-io.c
> @@ -152,8 +152,8 @@ static int mlxreg_io_attr_init(struct mlxreg_io_priv_data
> *priv) {
> int i;
>
> - priv->group.attrs = devm_kzalloc(>pdev->dev,
> - priv->pdata->counter *
> + priv->group.attrs = devm_kcalloc(>pdev->dev,
> + priv->pdata->counter,
>sizeof(struct attribute *),
>GFP_KERNEL);
> if (!priv->group.attrs)
> --
> 2.17.1
>
>
> --
> Kees Cook
> Pixel Security
RE: [PATCH] platform/mellanox: Use 2-factor allocator calls
> -Original Message-
> From: Kees Cook [mailto:keesc...@chromium.org]
> Sent: Wednesday, July 04, 2018 8:29 PM
> To: Darren Hart
> Cc: Vadim Pasternak ; Andy Shevchenko
> ; platform-driver-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] platform/mellanox: Use 2-factor allocator calls
>
> As already done treewide, switch from open-coded multiplication to using 2-
> factor allocation helpers.
>
> Signed-off-by: Kees Cook
Acked-by: Vadim Pasternak
> ---
> drivers/platform/mellanox/mlxreg-io.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/mellanox/mlxreg-io.c
> b/drivers/platform/mellanox/mlxreg-io.c
> index c192dfe6bd65..acfaf64ffde6 100644
> --- a/drivers/platform/mellanox/mlxreg-io.c
> +++ b/drivers/platform/mellanox/mlxreg-io.c
> @@ -152,8 +152,8 @@ static int mlxreg_io_attr_init(struct mlxreg_io_priv_data
> *priv) {
> int i;
>
> - priv->group.attrs = devm_kzalloc(>pdev->dev,
> - priv->pdata->counter *
> + priv->group.attrs = devm_kcalloc(>pdev->dev,
> + priv->pdata->counter,
>sizeof(struct attribute *),
>GFP_KERNEL);
> if (!priv->group.attrs)
> --
> 2.17.1
>
>
> --
> Kees Cook
> Pixel Security
RE: [PATCH v6 6/8] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Wednesday, June 20, 2018 3:20 AM > To: Randy Dunlap > Cc: Vadim Pasternak ; andy.shevche...@gmail.com; > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; platform-driver- > x...@vger.kernel.org; j...@resnulli.us; Michael Shych > ; ivec...@redhat.com > Subject: Re: [PATCH v6 6/8] platform/mellanox: Introduce support for Mellanox > register access driver > > On Sun, Jun 17, 2018 at 09:52:16AM -0700, Randy Dunlap wrote: > > On 06/17/2018 09:56 AM, Vadim Pasternak wrote: > > > diff --git a/drivers/platform/mellanox/Kconfig > > > b/drivers/platform/mellanox/Kconfig > ... > > > + space trough sysfs interface. The sets of registers for sysfs > > > +access > > > > through > > > > > + are defined per system type bases and includes the registers > > > +related > > > > and include the > > > > I've taken care of these, thanks Randy, and applied the series to my testing > queue. Once the builds complete, I'll move these to for-next. > > Vadim, I see you've already updated the kernel version in the sys > documentation > to 4.19, so I won't attempt to push these into the 4.18 RC cycle. > Hi Daren, Thank you very much. Yes, it's good to push into 4.19. Thanks, Vadim. > -- > Darren Hart > VMware Open Source Technology Center
RE: [PATCH v6 6/8] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Wednesday, June 20, 2018 3:20 AM > To: Randy Dunlap > Cc: Vadim Pasternak ; andy.shevche...@gmail.com; > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; platform-driver- > x...@vger.kernel.org; j...@resnulli.us; Michael Shych > ; ivec...@redhat.com > Subject: Re: [PATCH v6 6/8] platform/mellanox: Introduce support for Mellanox > register access driver > > On Sun, Jun 17, 2018 at 09:52:16AM -0700, Randy Dunlap wrote: > > On 06/17/2018 09:56 AM, Vadim Pasternak wrote: > > > diff --git a/drivers/platform/mellanox/Kconfig > > > b/drivers/platform/mellanox/Kconfig > ... > > > + space trough sysfs interface. The sets of registers for sysfs > > > +access > > > > through > > > > > + are defined per system type bases and includes the registers > > > +related > > > > and include the > > > > I've taken care of these, thanks Randy, and applied the series to my testing > queue. Once the builds complete, I'll move these to for-next. > > Vadim, I see you've already updated the kernel version in the sys > documentation > to 4.19, so I won't attempt to push these into the 4.18 RC cycle. > Hi Daren, Thank you very much. Yes, it's good to push into 4.19. Thanks, Vadim. > -- > Darren Hart > VMware Open Source Technology Center
[PATCH v6 6/8] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v5-v6:
Comments pointed out by Darren:
- Fix "filed" to "field" and "form" to "from".
- Drop redundant case for "full register" kind of attribute.
Since regmap_config structure includes the field with the number of
bits in a register address, it protects register from reading/writing
above this limit.
- Use len parameter, received from the user space in kstrtou32 to prevent
reading beyond the end of input buffer.
- Move comment to correct location in mlxreg_io_attr_store routine.
- Provide regval reading operation into a static local function.
v4-v5:
Comments pointed out by Darren:
- Add more comments.
- Add validation for the buffer length in attribute store method.
- Remove unnecessary check for input value in attribute store method.
- Change name val to input_value in order to improve code readability.
Changes added by Vadim:
- Extend logic in attribute show and store methods to cover all
configurations.
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
v1->v2:
Change added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 245 ++
3 files changed, 257 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..c192dfe
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static int
+mlxreg_io_get_reg(void *regmap, struct mlxreg_core_data *data, u32 in_val,
+ bool rw_flag, u32 *regval)
+{
+ int ret;
+
+ ret = regmap_read(regmap, data->reg, regval);
+ if (ret)
+ goto access_error;
+
+ /*
+* There are three kinds of att
[PATCH v6 6/8] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v5-v6:
Comments pointed out by Darren:
- Fix "filed" to "field" and "form" to "from".
- Drop redundant case for "full register" kind of attribute.
Since regmap_config structure includes the field with the number of
bits in a register address, it protects register from reading/writing
above this limit.
- Use len parameter, received from the user space in kstrtou32 to prevent
reading beyond the end of input buffer.
- Move comment to correct location in mlxreg_io_attr_store routine.
- Provide regval reading operation into a static local function.
v4-v5:
Comments pointed out by Darren:
- Add more comments.
- Add validation for the buffer length in attribute store method.
- Remove unnecessary check for input value in attribute store method.
- Change name val to input_value in order to improve code readability.
Changes added by Vadim:
- Extend logic in attribute show and store methods to cover all
configurations.
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
v1->v2:
Change added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 245 ++
3 files changed, 257 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..c192dfe
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static int
+mlxreg_io_get_reg(void *regmap, struct mlxreg_core_data *data, u32 in_val,
+ bool rw_flag, u32 *regval)
+{
+ int ret;
+
+ ret = regmap_read(regmap, data->reg, regval);
+ if (ret)
+ goto access_error;
+
+ /*
+* There are three kinds of att
[PATCH v6 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
Add documentation for mlxreg-io platform driver sysfs interfaces to allow user space access for system resets control, reset causes monitoring, programmable devices version reading and device selection control. Signed-off-by: Vadim Pasternak --- v5-v6: Changes added by Vadim: - Change kernel version from 4.18 to 4.19. v4-v5: Comments pointed out by Darren: - Rename cause to reset. - Extend explanation in doc file. Changes added by Vadim: - Add two new attributes. - Re-arrange in alphabetic order after changes. - Change date from May to June. v4: Comments pointed out by Greg: Add Documentation/ABI/ entries for the new sysfs files. --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 77 + 1 file changed, 77 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io new file mode 100644 index 000..815689b --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -0,0 +1,77 @@ +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + asic_health + +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: This file shows ASIC health status. The possible values are: + 0 - health failed, 2 - health OK, 3 - ASIC in booting state. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cpld1_version + cpld2_version + +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: These files show with which CPLD versions have been burned + on carrier and switch boards. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: This file allows iio devices selection. + + Attribute select_iio can be written with 0 or with 1. It + selects which one of iio devices can be accessed. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: These files allow asserting system power cycling, switching + power supply units on and off and system's main power domain + shutdown. + Expected behavior: + When pwr_cycle is written 1: auxiliary power domain will go + down and after short period (about 1 second) up. + When psu1_on or psu2_on is written 1, related unit will be + disconnected from the power source, when written 0 - connected. + If both are written 1 - power supplies main power domain will + go down. + When pwr_down is written 1, system's main power domain will go + down. + + The files are write only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + reset_aux_pwr_or_ref + reset_asic_thermal + reset_hotswap_or_wd + reset_fw_reset + reset_long_pb + reset_main_pwr_fail + reset_short_pb + reset_sw_reset +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: These files show the system reset cause, as following: power + auxiliary outage or power refresh, ASIC thermal shutdown, + hotswap or watchdog, firmware reset, long press power button, + short press power button, software reset. Value 1 in file means + this is reset cause, 0 - otherwise. Only one of the above + causes could be 1 at the same time, representing only last + reset cause. + + The files are read only. -- 2.1.4
[PATCH v6 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
Add documentation for mlxreg-io platform driver sysfs interfaces to allow user space access for system resets control, reset causes monitoring, programmable devices version reading and device selection control. Signed-off-by: Vadim Pasternak --- v5-v6: Changes added by Vadim: - Change kernel version from 4.18 to 4.19. v4-v5: Comments pointed out by Darren: - Rename cause to reset. - Extend explanation in doc file. Changes added by Vadim: - Add two new attributes. - Re-arrange in alphabetic order after changes. - Change date from May to June. v4: Comments pointed out by Greg: Add Documentation/ABI/ entries for the new sysfs files. --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 77 + 1 file changed, 77 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io new file mode 100644 index 000..815689b --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -0,0 +1,77 @@ +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + asic_health + +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: This file shows ASIC health status. The possible values are: + 0 - health failed, 2 - health OK, 3 - ASIC in booting state. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cpld1_version + cpld2_version + +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: These files show with which CPLD versions have been burned + on carrier and switch boards. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: This file allows iio devices selection. + + Attribute select_iio can be written with 0 or with 1. It + selects which one of iio devices can be accessed. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: These files allow asserting system power cycling, switching + power supply units on and off and system's main power domain + shutdown. + Expected behavior: + When pwr_cycle is written 1: auxiliary power domain will go + down and after short period (about 1 second) up. + When psu1_on or psu2_on is written 1, related unit will be + disconnected from the power source, when written 0 - connected. + If both are written 1 - power supplies main power domain will + go down. + When pwr_down is written 1, system's main power domain will go + down. + + The files are write only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + reset_aux_pwr_or_ref + reset_asic_thermal + reset_hotswap_or_wd + reset_fw_reset + reset_long_pb + reset_main_pwr_fail + reset_short_pb + reset_sw_reset +Date: June 2018 +KernelVersion: 4.19 +Contact: Vadim Pasternak +Description: These files show the system reset cause, as following: power + auxiliary outage or power refresh, ASIC thermal shutdown, + hotswap or watchdog, firmware reset, long press power button, + short press power button, software reset. Value 1 in file means + this is reset cause, 0 - otherwise. Only one of the above + causes could be 1 at the same time, representing only last + reset cause. + + The files are read only. -- 2.1.4
[PATCH v6 7/8] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
v4-v5:
Changes added by Vadim:
- Add two new attributes for ASIC health and main power domain shutdown.
---
drivers/platform/x86/mlx-platform.c | 175 +++-
1 file changed, 173 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..3a22750 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,15 +47,23 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_MASK_OFFSET0x41
+#define MLXPLAT_CPLD_LPC_REG_ASIC_HEALTH_OFFSET 0x50
#define MLXPLAT_CPLD_LPC_REG_PSU_OFFSET0x58
#define MLXPLAT_CPLD_LPC_REG_PSU_EVENT_OFFSET 0x59
#define MLXPLAT_CPLD_LPC_REG_PSU_MASK_OFFSET 0x5a
@@ -122,12 +130,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +823,111 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+
[PATCH v6 7/8] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
v4-v5:
Changes added by Vadim:
- Add two new attributes for ASIC health and main power domain shutdown.
---
drivers/platform/x86/mlx-platform.c | 175 +++-
1 file changed, 173 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..3a22750 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,15 +47,23 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_MASK_OFFSET0x41
+#define MLXPLAT_CPLD_LPC_REG_ASIC_HEALTH_OFFSET 0x50
#define MLXPLAT_CPLD_LPC_REG_PSU_OFFSET0x58
#define MLXPLAT_CPLD_LPC_REG_PSU_EVENT_OFFSET 0x59
#define MLXPLAT_CPLD_LPC_REG_PSU_MASK_OFFSET 0x5a
@@ -122,12 +130,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +823,111 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+
[PATCH v5 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
Add documentation for mlxreg-io platform driver sysfs interfaces to allow user space access for system resets control, reset causes monitoring, programmable devices version reading and device selection control. Signed-off-by: Vadim Pasternak --- v4: Comments pointed out by Greg: Add Documentation/ABI/ entries for the new sysfs files. v4-v5: Comments pointed out by Darren: - Rename cause to reset. - Extend explanation in doc file. Changes added by Vadim: - Add two new attributes. - Re-arrange in alphabetic order after changes. - Change date from May to June. --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 77 + 1 file changed, 77 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io new file mode 100644 index 000..7913a95 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -0,0 +1,77 @@ +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + asic_health + +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: This file shows ASIC health status. The possible values are: + 0 - health failed, 2 - health OK, 3 - ASIC in booting state. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cpld1_version + cpld2_version + +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show with which CPLD versions have been burned + on carrier and switch boards. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: This file allows iio devices selection. + + Attribute select_iio can be written with 0 or with 1. It + selects which one of iio devices can be accessed. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files allow asserting system power cycling, switching + power supply units on and off and system's main power domain + shutdown. + Expected behavior: + When pwr_cycle is written 1: auxiliary power domain will go + down and after short period (about 1 second) up. + When psu1_on or psu2_on is written 1, related unit will be + disconnected from the power source, when written 0 - connected. + If both are written 1 - power supplies main power domain will + go down. + When pwr_down is written 1, system's main power domain will go + down. + + The files are write only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + reset_aux_pwr_or_ref + reset_asic_thermal + reset_hotswap_or_wd + reset_fw_reset + reset_long_pb + reset_main_pwr_fail + reset_short_pb + reset_sw_reset +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show the system reset cause, as following: power + auxiliary outage or power refresh, ASIC thermal shutdown, + hotswap or watchdog, firmware reset, long press power button, + short press power button, software reset. Value 1 in file means + this is reset cause, 0 - otherwise. Only one of the above + causes could be 1 at the same time, representing only last + reset cause. + + The files are read only. -- 2.1.4
[PATCH v5 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
Add documentation for mlxreg-io platform driver sysfs interfaces to allow user space access for system resets control, reset causes monitoring, programmable devices version reading and device selection control. Signed-off-by: Vadim Pasternak --- v4: Comments pointed out by Greg: Add Documentation/ABI/ entries for the new sysfs files. v4-v5: Comments pointed out by Darren: - Rename cause to reset. - Extend explanation in doc file. Changes added by Vadim: - Add two new attributes. - Re-arrange in alphabetic order after changes. - Change date from May to June. --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 77 + 1 file changed, 77 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io new file mode 100644 index 000..7913a95 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -0,0 +1,77 @@ +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + asic_health + +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: This file shows ASIC health status. The possible values are: + 0 - health failed, 2 - health OK, 3 - ASIC in booting state. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cpld1_version + cpld2_version + +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show with which CPLD versions have been burned + on carrier and switch boards. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: This file allows iio devices selection. + + Attribute select_iio can be written with 0 or with 1. It + selects which one of iio devices can be accessed. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files allow asserting system power cycling, switching + power supply units on and off and system's main power domain + shutdown. + Expected behavior: + When pwr_cycle is written 1: auxiliary power domain will go + down and after short period (about 1 second) up. + When psu1_on or psu2_on is written 1, related unit will be + disconnected from the power source, when written 0 - connected. + If both are written 1 - power supplies main power domain will + go down. + When pwr_down is written 1, system's main power domain will go + down. + + The files are write only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + reset_aux_pwr_or_ref + reset_asic_thermal + reset_hotswap_or_wd + reset_fw_reset + reset_long_pb + reset_main_pwr_fail + reset_short_pb + reset_sw_reset +Date: June 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show the system reset cause, as following: power + auxiliary outage or power refresh, ASIC thermal shutdown, + hotswap or watchdog, firmware reset, long press power button, + short press power button, software reset. Value 1 in file means + this is reset cause, 0 - otherwise. Only one of the above + causes could be 1 at the same time, representing only last + reset cause. + + The files are read only. -- 2.1.4
[PATCH v5 6/8] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Change added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
v4-v5:
Comments pointed out by Darren:
- Add more comments.
- Add validation for the buffer length in attribute store method.
- Remove unnecessary check for input value in attribute store method.
- Change name val to input_value in order to improve code readability.
Changes added by Vadim:
- Extend logic in attribute show and store methods to cover all
configurations.
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 227 ++
3 files changed, 239 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..2d4867a
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ /*
+* There are three kinds of attributes: single bit, full register's
+* bits and bit sequence. For the first kind field mask indicates which
+* bits are not related and filed bit is set zero. For the second kind
+* field mask is set to zero and field bit is set with all bits one.
+* For the third kind, filed mask indicates which bits are related and
+* field bit is set to the first bi
[PATCH v5 6/8] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Change added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
v4-v5:
Comments pointed out by Darren:
- Add more comments.
- Add validation for the buffer length in attribute store method.
- Remove unnecessary check for input value in attribute store method.
- Change name val to input_value in order to improve code readability.
Changes added by Vadim:
- Extend logic in attribute show and store methods to cover all
configurations.
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 227 ++
3 files changed, 239 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..2d4867a
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ /*
+* There are three kinds of attributes: single bit, full register's
+* bits and bit sequence. For the first kind field mask indicates which
+* bits are not related and filed bit is set zero. For the second kind
+* field mask is set to zero and field bit is set with all bits one.
+* For the third kind, filed mask indicates which bits are related and
+* field bit is set to the first bi
[PATCH v5 7/8] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
v4-v5:
Changes added by Vadim:
- Add two new attributes for ASIC health and main power domain shutdown.
---
drivers/platform/x86/mlx-platform.c | 175 +++-
1 file changed, 173 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..3a22750 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,15 +47,23 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_MASK_OFFSET0x41
+#define MLXPLAT_CPLD_LPC_REG_ASIC_HEALTH_OFFSET 0x50
#define MLXPLAT_CPLD_LPC_REG_PSU_OFFSET0x58
#define MLXPLAT_CPLD_LPC_REG_PSU_EVENT_OFFSET 0x59
#define MLXPLAT_CPLD_LPC_REG_PSU_MASK_OFFSET 0x5a
@@ -122,12 +130,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +823,111 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+
[PATCH v5 7/8] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
v4-v5:
Changes added by Vadim:
- Add two new attributes for ASIC health and main power domain shutdown.
---
drivers/platform/x86/mlx-platform.c | 175 +++-
1 file changed, 173 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..3a22750 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,15 +47,23 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_MASK_OFFSET0x41
+#define MLXPLAT_CPLD_LPC_REG_ASIC_HEALTH_OFFSET 0x50
#define MLXPLAT_CPLD_LPC_REG_PSU_OFFSET0x58
#define MLXPLAT_CPLD_LPC_REG_PSU_EVENT_OFFSET 0x59
#define MLXPLAT_CPLD_LPC_REG_PSU_MASK_OFFSET 0x5a
@@ -122,12 +130,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +823,111 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "reset_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+
RE: [PATCH v4 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Tuesday, June 05, 2018 4:55 AM > To: Vadim Pasternak > Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us; > Michael Shych ; ivec...@redhat.com > Subject: Re: [PATCH v4 8/8] Documentation/ABI: Add documentation mlxreg-io > sysfs interfaces > > On Tue, May 29, 2018 at 08:59:07AM +, Vadim Pasternak wrote: > > Add documentation for mlxreg-io driver sysfs interfaces for user space > > access to system's power resets control, reset causes monitoring, > > programmable devices version reading and devices selection control. > > > > Signed-off-by: Vadim Pasternak > > Hi Vadim, > > You mentioned that these can vary by platform, I presume that means that any > given platform will present a subset of these attributes - but that all > possible > attributes are documented here. Is that correct? Hi Darren, Thank you for review. These are mostly all attributes, that should be exposed. I add two extra for the coming version. Maybe for the future system it could be slightly extended. Also we have writable attribute for BIOS flash boot selection, which I am still not sure we want expose. Thanks, Vadim. > > > --- > > v4: > > Comments pointed out by Greg: > > Add Documentation/ABI/ entries for the new sysfs files. > > --- > > Documentation/ABI/stable/sysfs-driver-mlxreg-io | 51 > > + > > 1 file changed, 51 insertions(+) > > create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io > > > > diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io > > b/Documentation/ABI/stable/sysfs-driver-mlxreg-io > > new file mode 100644 > > index 000..fcd659e > > --- /dev/null > > +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io > > @@ -0,0 +1,51 @@ > > +What: /sys/devices/platform/mlxplat/mlxreg- > io/hwmon/hwmon*/ > > + > cause_aux_pwr_or_ref > > + cause_asic_thermal > > + > cause_hotswap_or_wd > > + cause_fw_reset > > + cause_long_pb > > + cause_main_pwr_fail > > + cause_short_pb > > + cause_sw_reset > > These property names do not seem to follow any kind of logical pattern with > respect to abbreviation. Starting with "cause_" made me think they were event > generators at first... Of course, who wants to be able to generate an asic > thermal shutdown from sysfs... ;-) > > The only thing that might make more sense to *me* would be to replace > "cause" with "reset". Not required. I'll leave it to you, you may have good > reason for the names chosen. > > > +Date: May 2018 > > +KernelVersion: 4.18 > > +Contact: Vadim Pasternak > > +Description: These files show the system reset cause, as following: > > power > > + auxiliary outage or power refresh, ASIC thermal shutdown, > > + hotswap or watchdog, firmware reset, long press power > button, > > + short press power button, software reset. Value 1 in file means > > + this is reset cause, 0 - otherwise. Only one of the above > > + causes could be 1 at the same time, representing only last > > + reset cause. > > + > > + The files are read only. > > + > > +What: /sys/devices/platform/mlxplat/mlxreg- > io/hwmon/hwmon*/ > > + cpld1_version > > + cpld2_version > > +Date: May 2018 > > +KernelVersion: 4.18 > > +Contact: Vadim Pasternak > > +Description: These files show with which CPLD versions have been > > burned > > + on carrier and switch boards. > > + > > + The files are read only. > > + > > +What: /sys/devices/platform/mlxplat/mlxreg- > io/hwmon/hwmon*/select_iio > > +Date: May 2018 > > +KernelVersion: 4.18 > > +Contact: Vadim Pasternak > > +Description: This file allows iio devices selection. > > + > > + The file is read/write. > > + > > Some description is appropriate here for what values it accepts
RE: [PATCH v4 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Tuesday, June 05, 2018 4:55 AM > To: Vadim Pasternak > Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us; > Michael Shych ; ivec...@redhat.com > Subject: Re: [PATCH v4 8/8] Documentation/ABI: Add documentation mlxreg-io > sysfs interfaces > > On Tue, May 29, 2018 at 08:59:07AM +, Vadim Pasternak wrote: > > Add documentation for mlxreg-io driver sysfs interfaces for user space > > access to system's power resets control, reset causes monitoring, > > programmable devices version reading and devices selection control. > > > > Signed-off-by: Vadim Pasternak > > Hi Vadim, > > You mentioned that these can vary by platform, I presume that means that any > given platform will present a subset of these attributes - but that all > possible > attributes are documented here. Is that correct? Hi Darren, Thank you for review. These are mostly all attributes, that should be exposed. I add two extra for the coming version. Maybe for the future system it could be slightly extended. Also we have writable attribute for BIOS flash boot selection, which I am still not sure we want expose. Thanks, Vadim. > > > --- > > v4: > > Comments pointed out by Greg: > > Add Documentation/ABI/ entries for the new sysfs files. > > --- > > Documentation/ABI/stable/sysfs-driver-mlxreg-io | 51 > > + > > 1 file changed, 51 insertions(+) > > create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io > > > > diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io > > b/Documentation/ABI/stable/sysfs-driver-mlxreg-io > > new file mode 100644 > > index 000..fcd659e > > --- /dev/null > > +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io > > @@ -0,0 +1,51 @@ > > +What: /sys/devices/platform/mlxplat/mlxreg- > io/hwmon/hwmon*/ > > + > cause_aux_pwr_or_ref > > + cause_asic_thermal > > + > cause_hotswap_or_wd > > + cause_fw_reset > > + cause_long_pb > > + cause_main_pwr_fail > > + cause_short_pb > > + cause_sw_reset > > These property names do not seem to follow any kind of logical pattern with > respect to abbreviation. Starting with "cause_" made me think they were event > generators at first... Of course, who wants to be able to generate an asic > thermal shutdown from sysfs... ;-) > > The only thing that might make more sense to *me* would be to replace > "cause" with "reset". Not required. I'll leave it to you, you may have good > reason for the names chosen. > > > +Date: May 2018 > > +KernelVersion: 4.18 > > +Contact: Vadim Pasternak > > +Description: These files show the system reset cause, as following: > > power > > + auxiliary outage or power refresh, ASIC thermal shutdown, > > + hotswap or watchdog, firmware reset, long press power > button, > > + short press power button, software reset. Value 1 in file means > > + this is reset cause, 0 - otherwise. Only one of the above > > + causes could be 1 at the same time, representing only last > > + reset cause. > > + > > + The files are read only. > > + > > +What: /sys/devices/platform/mlxplat/mlxreg- > io/hwmon/hwmon*/ > > + cpld1_version > > + cpld2_version > > +Date: May 2018 > > +KernelVersion: 4.18 > > +Contact: Vadim Pasternak > > +Description: These files show with which CPLD versions have been > > burned > > + on carrier and switch boards. > > + > > + The files are read only. > > + > > +What: /sys/devices/platform/mlxplat/mlxreg- > io/hwmon/hwmon*/select_iio > > +Date: May 2018 > > +KernelVersion: 4.18 > > +Contact: Vadim Pasternak > > +Description: This file allows iio devices selection. > > + > > + The file is read/write. > > + > > Some description is appropriate here for what values it accepts
RE: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, June 01, 2018 7:53 PM > To: Greg KH > Cc: Vadim Pasternak ; andy.shevche...@gmail.com; > linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org; > j...@resnulli.us; Michael Shych ; > ivec...@redhat.com > Subject: Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox > register access driver > > On Sun, May 27, 2018 at 05:34:45PM +0200, Greg Kroah-Hartman wrote: > > On Sun, May 27, 2018 at 03:22:06PM +, Vadim Pasternak wrote: > > > > > > > > > > -Original Message- > > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > > Sent: Sunday, May 27, 2018 6:14 PM > > > > To: Vadim Pasternak > > > > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > > > > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; > > > > j...@resnulli.us; Michael Shych ; > > > > ivec...@redhat.com > > > > Subject: Re: [PATCH v3 6/7] platform/mellanox: Introduce support > > > > for Mellanox register access driver > > > > > > > > On Sun, May 27, 2018 at 04:47:43PM +, Vadim Pasternak wrote: > > > > > Introduce new Mellanox platform driver to allow access to > > > > > Mellanox programmable device register space trough sysfs interface. > > > > > The driver purpose is to provide sysfs interface for user space > > > > > for the registers essential for system control and monitoring. > > > > > The sets of registers for sysfs access are supposed to be > > > > > defined per system type bases and include the registers related > > > > > to system resets operation, system reset causes monitoring and some > kinds of mux selection. > > > > > > > > > > Signed-off-by: Vadim Pasternak > > > > > --- > > > > > v1->v2: > > > > > Changed added by Vadim: > > > > > - Change ---help--- to help in Kconfig, according to new > > > > > requirements; > > > > > v2->v3: > > > > > Comments pointed out by Darren: > > > > > - Remove conditional assignment per attribute mode type, because > mode > > > > >will guard against not permitted access. > > > > >Verified by Vadim. > > > > > --- > > > > > drivers/platform/mellanox/Kconfig | 11 ++ > > > > > drivers/platform/mellanox/Makefile| 1 + > > > > > drivers/platform/mellanox/mlxreg-io.c | 203 > > > > > ++ > > > > > 3 files changed, 215 insertions(+) create mode 100644 > > > > > drivers/platform/mellanox/mlxreg-io.c > > > > > > > > > > diff --git a/drivers/platform/mellanox/Kconfig > > > > > b/drivers/platform/mellanox/Kconfig > > > > > index 591bccd..ddfae9fc 100644 > > > > > --- a/drivers/platform/mellanox/Kconfig > > > > > +++ b/drivers/platform/mellanox/Kconfig > > > > > @@ -23,4 +23,15 @@ config MLXREG_HOTPLUG > > > > > This driver handles hot-plug events for the power suppliers, > > > > > power > > > > > cables and fans on the wide range Mellanox IB and Ethernet > > > > > systems. > > > > > > > > > > +config MLXREG_IO > > > > > + tristate "Mellanox platform register access driver support" > > > > > + depends on REGMAP > > > > > + depends on HWMON > > > > > + help > > > > > + This driver allows access to Mellanox programmable device > register > > > > > + space trough sysfs interface. The sets of registers for sysfs > access > > > > > + are defined per system type bases and includes the registers > related > > > > > + to system resets operation, system reset causes monitoring > and some > > > > > + kinds of mux selection. > > > > > > > > No Documentation/ABI/ entries for these new sysfs files? Not good > > > > :( > > > > > > > > > > Thanks Greg for your comment. > > > > > > Should I call doc file like: > > > Documentation/ABI/stable/sysfs-driver-mlxreg-io > > > ? > > > > What ever matches the naming scheme for the driver, yes. > > Vadim, I'm happy to help out with the docs if you like. > > Will you be able to document this in a static way, or is this likely to change > significantly from platform to platform? I ask because of the automated > attribute creation in the code. > > Hi Darren, Will be great if you can help. I actually already sent next version of patch with this file. It'll be not have significant differences between the different platforms. However it'll be not the same. I didn't mention I my file the systems for which the particular attributes are relevant. Thanks, Vadim. > -- > Darren Hart > VMware Open Source Technology Center
RE: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, June 01, 2018 7:53 PM > To: Greg KH > Cc: Vadim Pasternak ; andy.shevche...@gmail.com; > linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org; > j...@resnulli.us; Michael Shych ; > ivec...@redhat.com > Subject: Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox > register access driver > > On Sun, May 27, 2018 at 05:34:45PM +0200, Greg Kroah-Hartman wrote: > > On Sun, May 27, 2018 at 03:22:06PM +, Vadim Pasternak wrote: > > > > > > > > > > -Original Message- > > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > > Sent: Sunday, May 27, 2018 6:14 PM > > > > To: Vadim Pasternak > > > > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > > > > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; > > > > j...@resnulli.us; Michael Shych ; > > > > ivec...@redhat.com > > > > Subject: Re: [PATCH v3 6/7] platform/mellanox: Introduce support > > > > for Mellanox register access driver > > > > > > > > On Sun, May 27, 2018 at 04:47:43PM +, Vadim Pasternak wrote: > > > > > Introduce new Mellanox platform driver to allow access to > > > > > Mellanox programmable device register space trough sysfs interface. > > > > > The driver purpose is to provide sysfs interface for user space > > > > > for the registers essential for system control and monitoring. > > > > > The sets of registers for sysfs access are supposed to be > > > > > defined per system type bases and include the registers related > > > > > to system resets operation, system reset causes monitoring and some > kinds of mux selection. > > > > > > > > > > Signed-off-by: Vadim Pasternak > > > > > --- > > > > > v1->v2: > > > > > Changed added by Vadim: > > > > > - Change ---help--- to help in Kconfig, according to new > > > > > requirements; > > > > > v2->v3: > > > > > Comments pointed out by Darren: > > > > > - Remove conditional assignment per attribute mode type, because > mode > > > > >will guard against not permitted access. > > > > >Verified by Vadim. > > > > > --- > > > > > drivers/platform/mellanox/Kconfig | 11 ++ > > > > > drivers/platform/mellanox/Makefile| 1 + > > > > > drivers/platform/mellanox/mlxreg-io.c | 203 > > > > > ++ > > > > > 3 files changed, 215 insertions(+) create mode 100644 > > > > > drivers/platform/mellanox/mlxreg-io.c > > > > > > > > > > diff --git a/drivers/platform/mellanox/Kconfig > > > > > b/drivers/platform/mellanox/Kconfig > > > > > index 591bccd..ddfae9fc 100644 > > > > > --- a/drivers/platform/mellanox/Kconfig > > > > > +++ b/drivers/platform/mellanox/Kconfig > > > > > @@ -23,4 +23,15 @@ config MLXREG_HOTPLUG > > > > > This driver handles hot-plug events for the power suppliers, > > > > > power > > > > > cables and fans on the wide range Mellanox IB and Ethernet > > > > > systems. > > > > > > > > > > +config MLXREG_IO > > > > > + tristate "Mellanox platform register access driver support" > > > > > + depends on REGMAP > > > > > + depends on HWMON > > > > > + help > > > > > + This driver allows access to Mellanox programmable device > register > > > > > + space trough sysfs interface. The sets of registers for sysfs > access > > > > > + are defined per system type bases and includes the registers > related > > > > > + to system resets operation, system reset causes monitoring > and some > > > > > + kinds of mux selection. > > > > > > > > No Documentation/ABI/ entries for these new sysfs files? Not good > > > > :( > > > > > > > > > > Thanks Greg for your comment. > > > > > > Should I call doc file like: > > > Documentation/ABI/stable/sysfs-driver-mlxreg-io > > > ? > > > > What ever matches the naming scheme for the driver, yes. > > Vadim, I'm happy to help out with the docs if you like. > > Will you be able to document this in a static way, or is this likely to change > significantly from platform to platform? I ask because of the automated > attribute creation in the code. > > Hi Darren, Will be great if you can help. I actually already sent next version of patch with this file. It'll be not have significant differences between the different platforms. However it'll be not the same. I didn't mention I my file the systems for which the particular attributes are relevant. Thanks, Vadim. > -- > Darren Hart > VMware Open Source Technology Center
[PATCH v4 6/8] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Changed added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 203 ++
3 files changed, 215 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..b85452f
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ regval &= data->mask;
+
+ va
[PATCH v4 6/8] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Changed added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 203 ++
3 files changed, 215 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..b85452f
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ regval &= data->mask;
+
+ va
[PATCH v4 7/8] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 159 +++-
1 file changed, 157 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_hotswap_or_wd",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(6),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_asic_thermal",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENM
[PATCH v4 7/8] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 159 +++-
1 file changed, 157 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_hotswap_or_wd",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(6),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_asic_thermal",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENM
[PATCH v4 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
Add documentation for mlxreg-io driver sysfs interfaces for user space access to system's power resets control, reset causes monitoring, programmable devices version reading and devices selection control. Signed-off-by: Vadim Pasternak --- v4: Comments pointed out by Greg: Add Documentation/ABI/ entries for the new sysfs files. --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 51 + 1 file changed, 51 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io new file mode 100644 index 000..fcd659e --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -0,0 +1,51 @@ +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cause_aux_pwr_or_ref + cause_asic_thermal + cause_hotswap_or_wd + cause_fw_reset + cause_long_pb + cause_main_pwr_fail + cause_short_pb + cause_sw_reset +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show the system reset cause, as following: power + auxiliary outage or power refresh, ASIC thermal shutdown, + hotswap or watchdog, firmware reset, long press power button, + short press power button, software reset. Value 1 in file means + this is reset cause, 0 - otherwise. Only one of the above + causes could be 1 at the same time, representing only last + reset cause. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cpld1_version + cpld2_version +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show with which CPLD versions have been burned + on carrier and switch boards. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: This file allows iio devices selection. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files allow assert system's power cycling and PS units + on/off switching. + + The files are write only. -- 2.1.4
[PATCH v4 8/8] Documentation/ABI: Add documentation mlxreg-io sysfs interfaces
Add documentation for mlxreg-io driver sysfs interfaces for user space access to system's power resets control, reset causes monitoring, programmable devices version reading and devices selection control. Signed-off-by: Vadim Pasternak --- v4: Comments pointed out by Greg: Add Documentation/ABI/ entries for the new sysfs files. --- Documentation/ABI/stable/sysfs-driver-mlxreg-io | 51 + 1 file changed, 51 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-mlxreg-io diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io new file mode 100644 index 000..fcd659e --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -0,0 +1,51 @@ +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cause_aux_pwr_or_ref + cause_asic_thermal + cause_hotswap_or_wd + cause_fw_reset + cause_long_pb + cause_main_pwr_fail + cause_short_pb + cause_sw_reset +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show the system reset cause, as following: power + auxiliary outage or power refresh, ASIC thermal shutdown, + hotswap or watchdog, firmware reset, long press power button, + short press power button, software reset. Value 1 in file means + this is reset cause, 0 - otherwise. Only one of the above + causes could be 1 at the same time, representing only last + reset cause. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ + cpld1_version + cpld2_version +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files show with which CPLD versions have been burned + on carrier and switch boards. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: This file allows iio devices selection. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on + /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle +Date: May 2018 +KernelVersion: 4.18 +Contact: Vadim Pasternak +Description: These files allow assert system's power cycling and PS units + on/off switching. + + The files are write only. -- 2.1.4
RE: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Sunday, May 27, 2018 6:14 PM > To: Vadim Pasternak <vad...@mellanox.com> > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us; > Michael Shych <michae...@mellanox.com>; ivec...@redhat.com > Subject: Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox > register access driver > > On Sun, May 27, 2018 at 04:47:43PM +, Vadim Pasternak wrote: > > Introduce new Mellanox platform driver to allow access to Mellanox > > programmable device register space trough sysfs interface. > > The driver purpose is to provide sysfs interface for user space for > > the registers essential for system control and monitoring. > > The sets of registers for sysfs access are supposed to be defined per > > system type bases and include the registers related to system resets > > operation, system reset causes monitoring and some kinds of mux selection. > > > > Signed-off-by: Vadim Pasternak <vad...@mellanox.com> > > --- > > v1->v2: > > Changed added by Vadim: > > - Change ---help--- to help in Kconfig, according to new > > requirements; > > v2->v3: > > Comments pointed out by Darren: > > - Remove conditional assignment per attribute mode type, because mode > >will guard against not permitted access. > >Verified by Vadim. > > --- > > drivers/platform/mellanox/Kconfig | 11 ++ > > drivers/platform/mellanox/Makefile| 1 + > > drivers/platform/mellanox/mlxreg-io.c | 203 > > ++ > > 3 files changed, 215 insertions(+) > > create mode 100644 drivers/platform/mellanox/mlxreg-io.c > > > > diff --git a/drivers/platform/mellanox/Kconfig > > b/drivers/platform/mellanox/Kconfig > > index 591bccd..ddfae9fc 100644 > > --- a/drivers/platform/mellanox/Kconfig > > +++ b/drivers/platform/mellanox/Kconfig > > @@ -23,4 +23,15 @@ config MLXREG_HOTPLUG > > This driver handles hot-plug events for the power suppliers, power > > cables and fans on the wide range Mellanox IB and Ethernet systems. > > > > +config MLXREG_IO > > + tristate "Mellanox platform register access driver support" > > + depends on REGMAP > > + depends on HWMON > > + help > > + This driver allows access to Mellanox programmable device register > > + space trough sysfs interface. The sets of registers for sysfs access > > + are defined per system type bases and includes the registers related > > + to system resets operation, system reset causes monitoring and some > > + kinds of mux selection. > > No Documentation/ABI/ entries for these new sysfs files? Not good :( > Thanks Greg for your comment. Should I call doc file like: Documentation/ABI/stable/sysfs-driver-mlxreg-io ? > greg k-h
RE: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Sunday, May 27, 2018 6:14 PM > To: Vadim Pasternak > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us; > Michael Shych ; ivec...@redhat.com > Subject: Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox > register access driver > > On Sun, May 27, 2018 at 04:47:43PM +, Vadim Pasternak wrote: > > Introduce new Mellanox platform driver to allow access to Mellanox > > programmable device register space trough sysfs interface. > > The driver purpose is to provide sysfs interface for user space for > > the registers essential for system control and monitoring. > > The sets of registers for sysfs access are supposed to be defined per > > system type bases and include the registers related to system resets > > operation, system reset causes monitoring and some kinds of mux selection. > > > > Signed-off-by: Vadim Pasternak > > --- > > v1->v2: > > Changed added by Vadim: > > - Change ---help--- to help in Kconfig, according to new > > requirements; > > v2->v3: > > Comments pointed out by Darren: > > - Remove conditional assignment per attribute mode type, because mode > >will guard against not permitted access. > >Verified by Vadim. > > --- > > drivers/platform/mellanox/Kconfig | 11 ++ > > drivers/platform/mellanox/Makefile| 1 + > > drivers/platform/mellanox/mlxreg-io.c | 203 > > ++ > > 3 files changed, 215 insertions(+) > > create mode 100644 drivers/platform/mellanox/mlxreg-io.c > > > > diff --git a/drivers/platform/mellanox/Kconfig > > b/drivers/platform/mellanox/Kconfig > > index 591bccd..ddfae9fc 100644 > > --- a/drivers/platform/mellanox/Kconfig > > +++ b/drivers/platform/mellanox/Kconfig > > @@ -23,4 +23,15 @@ config MLXREG_HOTPLUG > > This driver handles hot-plug events for the power suppliers, power > > cables and fans on the wide range Mellanox IB and Ethernet systems. > > > > +config MLXREG_IO > > + tristate "Mellanox platform register access driver support" > > + depends on REGMAP > > + depends on HWMON > > + help > > + This driver allows access to Mellanox programmable device register > > + space trough sysfs interface. The sets of registers for sysfs access > > + are defined per system type bases and includes the registers related > > + to system resets operation, system reset causes monitoring and some > > + kinds of mux selection. > > No Documentation/ABI/ entries for these new sysfs files? Not good :( > Thanks Greg for your comment. Should I call doc file like: Documentation/ABI/stable/sysfs-driver-mlxreg-io ? > greg k-h
[PATCH v3 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
drivers/platform/x86/mlx-platform.c | 159 +++-
1 file changed, 157 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_hotswap_or_wd",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(6),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_asic_thermal",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask
[PATCH v3 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 159 +++-
1 file changed, 157 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_hotswap_or_wd",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(6),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_asic_thermal",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENM
[PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
v1->v2:
Changed added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 203 ++
3 files changed, 215 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..b85452f
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak <vad...@mellanox.com>
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto
[PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Changed added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
v2->v3:
Comments pointed out by Darren:
- Remove conditional assignment per attribute mode type, because mode
will guard against not permitted access.
Verified by Vadim.
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 203 ++
3 files changed, 215 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..b85452f
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ regval &= data->mask;
+
+ va
RE: [PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 25, 2018 3:31 AM
> To: Vadim Pasternak <vad...@mellanox.com>
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych <michae...@mellanox.com>; ivec...@redhat.com
> Subject: Re: [PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox
> register access driver
>
> On Mon, May 07, 2018 at 06:48:54AM +, Vadim Pasternak wrote:
> > Introduce new Mellanox platform driver to allow access to Mellanox
> > programmable device register space trough sysfs interface.
> > The driver purpose is to provide sysfs interface for user space for
> > the registers essential for system control and monitoring.
> > The sets of registers for sysfs access are supposed to be defined per
> > system type bases and include the registers related to system resets
> > operation, system reset causes monitoring and some kinds of mux selection.
> >
> > Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
> > ---
>
> One question on the attr init which I'm not familiar with... Andy, Greg - can
> you
> offer your opinion below...
>
> > +static int mlxreg_io_attr_init(struct mlxreg_io_priv_data *priv) {
> > + int i;
> > +
> > + priv->group.attrs = devm_kzalloc(>pdev->dev,
> > +priv->pdata->counter *
> > +sizeof(struct attribute *),
> > +GFP_KERNEL);
> > + if (!priv->group.attrs)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < priv->pdata->counter; i++) {
> > + priv->mlxreg_io_attr[i] =
> > + >mlxreg_io_dev_attr[i].dev_attr.attr;
> > +
> > + /* Set attribute name as a label. */
> > + priv->mlxreg_io_attr[i]->name =
> > + devm_kasprintf(>pdev->dev,
> GFP_KERNEL,
> > + priv->pdata->data[i].label);
> > +
> > + if (!priv->mlxreg_io_attr[i]->name) {
> > + dev_err(>pdev->dev, "Memory allocation failed
> for sysfs attribute %d.\n",
> > + i + 1);
> > + return -ENOMEM;
> > + }
> > +
> > + priv->mlxreg_io_dev_attr[i].dev_attr.attr.mode =
> > + priv->pdata->data[i].mode;
> > + switch (priv->pdata->data[i].mode) {
>
> This seemed a bit odd to me. Do we need to do this conditional assignment
> within the kernel, or can these just be assigned, and the mode will guard
> against
> the user being able to call store on a read only attr?
>
> > + case 0200:
> > + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> > + mlxreg_io_attr_store;
> > + break;
> > +
> > + case 0444:
> > + priv->mlxreg_io_dev_attr[i].dev_attr.show =
> > + mlxreg_io_attr_show;
> > + break;
> > +
> > + case 0644:
> > + priv->mlxreg_io_dev_attr[i].dev_attr.show =
> > + mlxreg_io_attr_show;
> > + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> > + mlxreg_io_attr_store;
> > + break;
>
> If this is necessary, we can simplify this by checking for the read mask and
> the
> write mask and setting each once - rather than duplicating this for r, w, and
> rw.
> As it is a 0400 would not assign the show function, even though it is
> readable by
> somebody.
Maybe I really can add something like
static struct device_attribute mlxreg_io_devattr_rw = {
.show = mlxreg_io_attr_show,
.store = mlxreg_io_attr_store,
};
And replace this whole switch statement just with:
memcpy(>mlxreg_io_dev_attr[i].dev_attr,
_io_devattr_rw, sizeof(struct device_attribute));
>
> --
> Darren Hart
> VMware Open Source Technology Center
RE: [PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox register access driver
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 25, 2018 3:31 AM
> To: Vadim Pasternak
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych ; ivec...@redhat.com
> Subject: Re: [PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox
> register access driver
>
> On Mon, May 07, 2018 at 06:48:54AM +, Vadim Pasternak wrote:
> > Introduce new Mellanox platform driver to allow access to Mellanox
> > programmable device register space trough sysfs interface.
> > The driver purpose is to provide sysfs interface for user space for
> > the registers essential for system control and monitoring.
> > The sets of registers for sysfs access are supposed to be defined per
> > system type bases and include the registers related to system resets
> > operation, system reset causes monitoring and some kinds of mux selection.
> >
> > Signed-off-by: Vadim Pasternak
> > ---
>
> One question on the attr init which I'm not familiar with... Andy, Greg - can
> you
> offer your opinion below...
>
> > +static int mlxreg_io_attr_init(struct mlxreg_io_priv_data *priv) {
> > + int i;
> > +
> > + priv->group.attrs = devm_kzalloc(>pdev->dev,
> > +priv->pdata->counter *
> > +sizeof(struct attribute *),
> > +GFP_KERNEL);
> > + if (!priv->group.attrs)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < priv->pdata->counter; i++) {
> > + priv->mlxreg_io_attr[i] =
> > + >mlxreg_io_dev_attr[i].dev_attr.attr;
> > +
> > + /* Set attribute name as a label. */
> > + priv->mlxreg_io_attr[i]->name =
> > + devm_kasprintf(>pdev->dev,
> GFP_KERNEL,
> > + priv->pdata->data[i].label);
> > +
> > + if (!priv->mlxreg_io_attr[i]->name) {
> > + dev_err(>pdev->dev, "Memory allocation failed
> for sysfs attribute %d.\n",
> > + i + 1);
> > + return -ENOMEM;
> > + }
> > +
> > + priv->mlxreg_io_dev_attr[i].dev_attr.attr.mode =
> > + priv->pdata->data[i].mode;
> > + switch (priv->pdata->data[i].mode) {
>
> This seemed a bit odd to me. Do we need to do this conditional assignment
> within the kernel, or can these just be assigned, and the mode will guard
> against
> the user being able to call store on a read only attr?
>
> > + case 0200:
> > + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> > + mlxreg_io_attr_store;
> > + break;
> > +
> > + case 0444:
> > + priv->mlxreg_io_dev_attr[i].dev_attr.show =
> > + mlxreg_io_attr_show;
> > + break;
> > +
> > + case 0644:
> > + priv->mlxreg_io_dev_attr[i].dev_attr.show =
> > + mlxreg_io_attr_show;
> > + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> > + mlxreg_io_attr_store;
> > + break;
>
> If this is necessary, we can simplify this by checking for the read mask and
> the
> write mask and setting each once - rather than duplicating this for r, w, and
> rw.
> As it is a 0400 would not assign the show function, even though it is
> readable by
> somebody.
Maybe I really can add something like
static struct device_attribute mlxreg_io_devattr_rw = {
.show = mlxreg_io_attr_show,
.store = mlxreg_io_attr_store,
};
And replace this whole switch statement just with:
memcpy(>mlxreg_io_dev_attr[i].dev_attr,
_io_devattr_rw, sizeof(struct device_attribute));
>
> --
> Darren Hart
> VMware Open Source Technology Center
RE: [PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 25, 2018 2:52 AM
> To: Vadim Pasternak <vad...@mellanox.com>
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych <michae...@mellanox.com>; ivec...@redhat.com
> Subject: Re: [PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle
> for hotplug work queue
>
> On Mon, May 07, 2018 at 06:48:51AM +, Vadim Pasternak wrote:
>
> Hi Vadim,
>
> > Add extra cycle for hotplug work queue to handle the case when a
> > signal is It adds missed logic for signal acknowledge, by adding an
> > extra run for received, but no specific signal assertion is detected.
> > Such case theoretically can happen for example in case several units
> > are removed or inserted at the same time. In this situation
> > acknowledge for some signal can be missed at signal top aggreagation
> > status level. The extra run will allow to handler to acknowledge the missed
> signal.
> >
>
> ...
>
> >
> > Fixes: 07b89c2b2a5e ("platform/x86: Introduce support for Mellanox
> > hotplug driver")
>
> This sha doesn't exist in mainline, I believe you are referring to:
>
> $ git l | grep "Introduce support for Mellanox hotplug"
> 304887041d95 platform/x86: Introduce support for Mellanox hotplug driver
>
> While this was introduced in 4.10. There have been many changes since then,
> with significant changes in the 4.17 cycle. I have not added the stable tag,
> please
> let me know if you think this should be pushed to stable, and which of the
> intervening patches you'd consider dependencies.
Hi Darren,
Thank you for review.
I think it's worth pushing to stable.
It doesn't depend one previous patches from the patchset, but possibly
this one, which just fixes few comments in mlxreg-hotplug:
platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private data
(commit 321089a4da2f6b20bb8af96354f76d260a4ca2c6 in testing branch).
Thanks,
Vadim.
>
> I've fixed the sha in the commit message, and queued for testing.
>
> Thanks,
>
> --
> Darren Hart
> VMware Open Source Technology Center
RE: [PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, May 25, 2018 2:52 AM
> To: Vadim Pasternak
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych ; ivec...@redhat.com
> Subject: Re: [PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle
> for hotplug work queue
>
> On Mon, May 07, 2018 at 06:48:51AM +, Vadim Pasternak wrote:
>
> Hi Vadim,
>
> > Add extra cycle for hotplug work queue to handle the case when a
> > signal is It adds missed logic for signal acknowledge, by adding an
> > extra run for received, but no specific signal assertion is detected.
> > Such case theoretically can happen for example in case several units
> > are removed or inserted at the same time. In this situation
> > acknowledge for some signal can be missed at signal top aggreagation
> > status level. The extra run will allow to handler to acknowledge the missed
> signal.
> >
>
> ...
>
> >
> > Fixes: 07b89c2b2a5e ("platform/x86: Introduce support for Mellanox
> > hotplug driver")
>
> This sha doesn't exist in mainline, I believe you are referring to:
>
> $ git l | grep "Introduce support for Mellanox hotplug"
> 304887041d95 platform/x86: Introduce support for Mellanox hotplug driver
>
> While this was introduced in 4.10. There have been many changes since then,
> with significant changes in the 4.17 cycle. I have not added the stable tag,
> please
> let me know if you think this should be pushed to stable, and which of the
> intervening patches you'd consider dependencies.
Hi Darren,
Thank you for review.
I think it's worth pushing to stable.
It doesn't depend one previous patches from the patchset, but possibly
this one, which just fixes few comments in mlxreg-hotplug:
platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private data
(commit 321089a4da2f6b20bb8af96354f76d260a4ca2c6 in testing branch).
Thanks,
Vadim.
>
> I've fixed the sha in the commit message, and queued for testing.
>
> Thanks,
>
> --
> Darren Hart
> VMware Open Source Technology Center
[PATCH v2 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
drivers/platform/x86/mlx-platform.c | 159 +++-
1 file changed, 157 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_hotswap_or_wd",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(6),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_asic_thermal",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask
[PATCH v2 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation
Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 159 +++-
1 file changed, 157 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET 0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET 0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
* @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+ struct platform_device *pdev_io_regs;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
};
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+ {
+ .label = "cpld1_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cpld2_version",
+ .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+ .bit = GENMASK(7, 0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_long_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(0),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_short_pb",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(1),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_aux_pwr_or_ref",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(2),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_main_pwr_fail",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(3),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_sw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(4),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_fw_reset",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(5),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_hotswap_or_wd",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENMASK(7, 0) & ~BIT(6),
+ .mode = 0444,
+ },
+ {
+ .label = "cause_asic_thermal",
+ .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+ .mask = GENM
[PATCH v2 4/7] platform: mellanox: add new ODM system types to mlx-platform
Add new ODM system types, matched according to DMI_BOARD_NAME. The
supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, VMOD0004, VMOD0005.
Patch does not introduce new systems, but allows to ODM companies to set
DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their own. It assumes that ODM
company can't change DMI_BOARD_NAME.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
v1->v2:
Comments pointed out by Darren:
- Modify commit message;
---
drivers/platform/x86/mlx-platform.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 7a0bd24..912f844 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -844,6 +844,36 @@ static const struct dmi_system_id mlxplat_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "SN34"),
},
},
+ {
+ .callback = mlxplat_dmi_default_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0001"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn21xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0002"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn274x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0003"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn201x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0004"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_qmb7xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0005"),
+ },
+ },
{ }
};
--
2.1.4
[PATCH v2 5/7] platform/x86: mlx-platform: Add LED platform driver activation
Add LED platform driver activation from mlx-platform. This LED driver uses
the same regmap infrastructure as others Mellanox platform drivers, so LED
specific registers description is added.
System LED configuration depends on system type. To support all the
relevant types per system type LED descriptions are defined for passing
to LED platform driver.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
v1->v2:
Fixes added by Vadim:
- Remove inline functions from mlxreg.h file;
---
drivers/platform/x86/mlx-platform.c | 259 +++-
1 file changed, 258 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 912f844..a0fd9aa 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,6 +47,11 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
+#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
+#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
+#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
+#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -84,6 +89,8 @@
#define MLXPLAT_CPLD_PWR_MASK GENMASK(1, 0)
#define MLXPLAT_CPLD_FAN_MASK GENMASK(3, 0)
#define MLXPLAT_CPLD_FAN_NG_MASK GENMASK(5, 0)
+#define MLXPLAT_CPLD_LED_LO_NIBBLE_MASKGENMASK(7, 4)
+#define MLXPLAT_CPLD_LED_HI_NIBBLE_MASKGENMASK(3, 0)
/* Default I2C parent bus number */
#define MLXPLAT_CPLD_PHYS_ADAPTER_DEF_NR 1
@@ -114,11 +121,13 @@
* @pdev_i2c - i2c controller platform device
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
+ * @pdev_led - led platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
+ struct platform_device *pdev_led;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -592,9 +601,227 @@ struct mlxreg_core_hotplug_platform_data
mlxplat_mlxcpld_default_ng_data = {
.mask_low = MLXPLAT_CPLD_LOW_AGGR_MASK_LOW,
};
+/* Platform led default data */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_led_data[] = {
+ {
+ .label = "status:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "status:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK
+ },
+ {
+ .label = "psu:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "psu:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan1:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan1:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan2:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan2:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan3:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan3:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan4:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan4:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+};
+
+static struct mlxreg_core_platform_data mlxplat_default_led_data = {
+ .data = mlxplat_mlxcpld_default_led_data,
+ .counter = ARRAY_SIZE(mlxplat_mlxcpld_default_led_data),
+};
+
+/* Platform led MSN2
[PATCH v2 4/7] platform: mellanox: add new ODM system types to mlx-platform
Add new ODM system types, matched according to DMI_BOARD_NAME. The
supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, VMOD0004, VMOD0005.
Patch does not introduce new systems, but allows to ODM companies to set
DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their own. It assumes that ODM
company can't change DMI_BOARD_NAME.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Comments pointed out by Darren:
- Modify commit message;
---
drivers/platform/x86/mlx-platform.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 7a0bd24..912f844 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -844,6 +844,36 @@ static const struct dmi_system_id mlxplat_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "SN34"),
},
},
+ {
+ .callback = mlxplat_dmi_default_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0001"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn21xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0002"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn274x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0003"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn201x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0004"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_qmb7xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0005"),
+ },
+ },
{ }
};
--
2.1.4
[PATCH v2 5/7] platform/x86: mlx-platform: Add LED platform driver activation
Add LED platform driver activation from mlx-platform. This LED driver uses
the same regmap infrastructure as others Mellanox platform drivers, so LED
specific registers description is added.
System LED configuration depends on system type. To support all the
relevant types per system type LED descriptions are defined for passing
to LED platform driver.
Signed-off-by: Vadim Pasternak
v1->v2:
Fixes added by Vadim:
- Remove inline functions from mlxreg.h file;
---
drivers/platform/x86/mlx-platform.c | 259 +++-
1 file changed, 258 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 912f844..a0fd9aa 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,6 +47,11 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET 0x20
+#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET 0x21
+#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET 0x22
+#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET 0x23
+#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET 0x24
#define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET 0x3a
#define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET 0x3b
#define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -84,6 +89,8 @@
#define MLXPLAT_CPLD_PWR_MASK GENMASK(1, 0)
#define MLXPLAT_CPLD_FAN_MASK GENMASK(3, 0)
#define MLXPLAT_CPLD_FAN_NG_MASK GENMASK(5, 0)
+#define MLXPLAT_CPLD_LED_LO_NIBBLE_MASKGENMASK(7, 4)
+#define MLXPLAT_CPLD_LED_HI_NIBBLE_MASKGENMASK(3, 0)
/* Default I2C parent bus number */
#define MLXPLAT_CPLD_PHYS_ADAPTER_DEF_NR 1
@@ -114,11 +121,13 @@
* @pdev_i2c - i2c controller platform device
* @pdev_mux - array of mux platform devices
* @pdev_hotplug - hotplug platform devices
+ * @pdev_led - led platform devices
*/
struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
+ struct platform_device *pdev_led;
};
/* Regions for LPC I2C controller and LPC base register space */
@@ -592,9 +601,227 @@ struct mlxreg_core_hotplug_platform_data
mlxplat_mlxcpld_default_ng_data = {
.mask_low = MLXPLAT_CPLD_LOW_AGGR_MASK_LOW,
};
+/* Platform led default data */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_led_data[] = {
+ {
+ .label = "status:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "status:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK
+ },
+ {
+ .label = "psu:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "psu:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan1:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan1:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan2:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan2:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan3:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan3:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+ },
+ {
+ .label = "fan4:green",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+ {
+ .label = "fan4:red",
+ .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+ .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+ },
+};
+
+static struct mlxreg_core_platform_data mlxplat_default_led_data = {
+ .data = mlxplat_mlxcpld_default_led_data,
+ .counter = ARRAY_SIZE(mlxplat_mlxcpld_default_led_data),
+};
+
+/* Platform led MSN21xx system family data
[PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
v1->v2:
Changed added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 221 ++
3 files changed, 233 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..f573b65
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak <vad...@mellanox.com>
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ regval &= data->mask;
+
+ val = !!val;
+ if (val)
+ regval |= ~data->mask;
+ else
+ regval &= da
[PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue
Add extra cycle for hotplug work queue to handle the case when a signal is
It adds missed logic for signal acknowledge, by adding an extra run for
received, but no specific signal assertion is detected. Such case
theoretically can happen for example in case several units are removed or
inserted at the same time. In this situation acknowledge for some signal
can be missed at signal top aggreagation status level. The extra run will
allow to handler to acknowledge the missed signal.
The interrupt handling flow performs the next steps:
(1)
Enter mlxreg_hotplug_work_handler due to signal assertion.
Aggregation status register is changed for example from 0xff to 0xfd
(event signal group related to bit 1).
(2)
Mask aggregation interrupts, read aggregation status register and save it
(0xfd) in aggr_cache, then traverse down to handle signal from groups
related to the changed bit.
(3)
Read and mask group related signal.
Acknowledge and unmask group related signal (acknowledge should clear
aggregation status register from 0xfd back to 0xff).
(4)
Re-schedule work queue for the immediate execution.
(5)
Enter mlxreg_hotplug_work_handler due to re-scheduling.
Aggregation status is changed from previous 0xfd to 0xff.
Go over steps (2) - (5) and in case no new signal assertion
is detected - unmask aggregation interrupts.
The possible race could happen in case new signal from the same group is
asserted after step (3) and prior step (5). In such case aggregation
status will change back from 0xff to 0xfd and the value read from the
aggregation status register will be the same as a value saved in
aggr_cache. As a result the handler will not traverse down and signal
will stay unhandled.
Example of faulty flow:
The signal routing flow is as following (f.e. for of FANi removing):
- FAN status and event registers related bit is changed;
-- intermediate aggregation status register is changed;
--- top aggregation status register is changed;
interrupt routed to CPU and interrupt handler is invoked.
When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
(a1) mask top aggregation interrupt mask register;
(a2) read top aggregation interrupt status register and test to which
underling group belongs a signal (FANs in this case and is changed
from 0xff to 0xfb and 0xfb is saved as a last status value);
(b1) mask FANs interrupt mask register;
(b2) read FANs status register and test which FAN has been changed
FAN3 in this example);
(c1) perform relevant action;
<--- (FAN2 is removed at this point)
(b3) clear FANs interrupt event register to acknowledge FAN3 signal;
(b4) unmask FANs interrupt mask register
(a3) unmask top aggregation interrupt mask register;
An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
It should set top aggregation interrupt status register bit 6 (0xfb).
In step (a2)
(a2) read top aggregation interrupt and comparing it with saved value
does not show change (same 0xfb) and after (a2) execution jumps to
(a3) and signal leaved unhandled
The fix will enforce handler to traverse down in case the signal is
received, but signal assertion is not detected.
Fixes: 07b89c2b2a5e ("platform/x86: Introduce support for Mellanox hotplug
driver")
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
V1->v2:
Comments pointed out by Darren:
- Modify commit message;
- Remove redundant check of aggr_asserted;
- Change bug fix reference from 1f976f6978bf, which just relocated driver
to 07b89c2b2a5e, which was initial driver commit.
---
drivers/platform/mellanox/mlxreg-hotplug.c | 48 +++---
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index b56953a..922913b 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -55,6 +55,7 @@
#define MLXREG_HOTPLUG_RST_CNTR3
#define MLXREG_HOTPLUG_ATTRS_MAX 24
+#define MLXREG_HOTPLUG_NOT_ASSERT 3
/**
* struct mlxreg_hotplug_priv_data - platform private data:
@@ -74,6 +75,7 @@
* @mask: top aggregation interrupt common mask;
* @aggr_cache: last value of aggregation register status;
* @after_probe: flag indication probing completion;
+ * @not_asserted: number of entries in workqueue with no signal assertion;
*/
struct mlxreg_hotplug_priv_data {
int irq;
@@ -93,6 +95,7 @@ struct mlxreg_hotplug_priv_data {
u32 mask;
u32 aggr_cache;
bool after_probe;
+ u8 not_asserted;
};
static int mlxreg_hotplug_device_create(struct mlxreg_hotplug_priv_data *priv,
@@ -410,6 +413,18 @@ static void mlxreg_hotplug_work_handler(struct work_struct
*work)
aggr_asserted = priv->aggr_cache ^ regval;
priv->aggr_cache = regval;
+ /*
+
[PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox register access driver
Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
v1->v2:
Changed added by Vadim:
- Change ---help--- to help in Kconfig, according to new requirements;
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 221 ++
3 files changed, 233 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..f573b65
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ regval &= data->mask;
+
+ val = !!val;
+ if (val)
+ regval |= ~data->mask;
+ else
+ regval &= data->mask;
+
+ ret = regmap_write(priv->pdata->regmap,
[PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue
Add extra cycle for hotplug work queue to handle the case when a signal is
It adds missed logic for signal acknowledge, by adding an extra run for
received, but no specific signal assertion is detected. Such case
theoretically can happen for example in case several units are removed or
inserted at the same time. In this situation acknowledge for some signal
can be missed at signal top aggreagation status level. The extra run will
allow to handler to acknowledge the missed signal.
The interrupt handling flow performs the next steps:
(1)
Enter mlxreg_hotplug_work_handler due to signal assertion.
Aggregation status register is changed for example from 0xff to 0xfd
(event signal group related to bit 1).
(2)
Mask aggregation interrupts, read aggregation status register and save it
(0xfd) in aggr_cache, then traverse down to handle signal from groups
related to the changed bit.
(3)
Read and mask group related signal.
Acknowledge and unmask group related signal (acknowledge should clear
aggregation status register from 0xfd back to 0xff).
(4)
Re-schedule work queue for the immediate execution.
(5)
Enter mlxreg_hotplug_work_handler due to re-scheduling.
Aggregation status is changed from previous 0xfd to 0xff.
Go over steps (2) - (5) and in case no new signal assertion
is detected - unmask aggregation interrupts.
The possible race could happen in case new signal from the same group is
asserted after step (3) and prior step (5). In such case aggregation
status will change back from 0xff to 0xfd and the value read from the
aggregation status register will be the same as a value saved in
aggr_cache. As a result the handler will not traverse down and signal
will stay unhandled.
Example of faulty flow:
The signal routing flow is as following (f.e. for of FANi removing):
- FAN status and event registers related bit is changed;
-- intermediate aggregation status register is changed;
--- top aggregation status register is changed;
interrupt routed to CPU and interrupt handler is invoked.
When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
(a1) mask top aggregation interrupt mask register;
(a2) read top aggregation interrupt status register and test to which
underling group belongs a signal (FANs in this case and is changed
from 0xff to 0xfb and 0xfb is saved as a last status value);
(b1) mask FANs interrupt mask register;
(b2) read FANs status register and test which FAN has been changed
FAN3 in this example);
(c1) perform relevant action;
<--- (FAN2 is removed at this point)
(b3) clear FANs interrupt event register to acknowledge FAN3 signal;
(b4) unmask FANs interrupt mask register
(a3) unmask top aggregation interrupt mask register;
An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
It should set top aggregation interrupt status register bit 6 (0xfb).
In step (a2)
(a2) read top aggregation interrupt and comparing it with saved value
does not show change (same 0xfb) and after (a2) execution jumps to
(a3) and signal leaved unhandled
The fix will enforce handler to traverse down in case the signal is
received, but signal assertion is not detected.
Fixes: 07b89c2b2a5e ("platform/x86: Introduce support for Mellanox hotplug
driver")
Signed-off-by: Vadim Pasternak
---
V1->v2:
Comments pointed out by Darren:
- Modify commit message;
- Remove redundant check of aggr_asserted;
- Change bug fix reference from 1f976f6978bf, which just relocated driver
to 07b89c2b2a5e, which was initial driver commit.
---
drivers/platform/mellanox/mlxreg-hotplug.c | 48 +++---
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c
b/drivers/platform/mellanox/mlxreg-hotplug.c
index b56953a..922913b 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -55,6 +55,7 @@
#define MLXREG_HOTPLUG_RST_CNTR3
#define MLXREG_HOTPLUG_ATTRS_MAX 24
+#define MLXREG_HOTPLUG_NOT_ASSERT 3
/**
* struct mlxreg_hotplug_priv_data - platform private data:
@@ -74,6 +75,7 @@
* @mask: top aggregation interrupt common mask;
* @aggr_cache: last value of aggregation register status;
* @after_probe: flag indication probing completion;
+ * @not_asserted: number of entries in workqueue with no signal assertion;
*/
struct mlxreg_hotplug_priv_data {
int irq;
@@ -93,6 +95,7 @@ struct mlxreg_hotplug_priv_data {
u32 mask;
u32 aggr_cache;
bool after_probe;
+ u8 not_asserted;
};
static int mlxreg_hotplug_device_create(struct mlxreg_hotplug_priv_data *priv,
@@ -410,6 +413,18 @@ static void mlxreg_hotplug_work_handler(struct work_struct
*work)
aggr_asserted = priv->aggr_cache ^ regval;
priv->aggr_cache = regval;
+ /*
+* Handler is invoked, but no
RE: [PATCH v1 4/7] platform: mellanox: add new ODM system types to mlx-platform
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, April 13, 2018 7:55 PM > To: Vadim Pasternak <vad...@mellanox.com> > Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us; > Michael Shych <michae...@mellanox.com>; ivec...@redhat.com > Subject: Re: [PATCH v1 4/7] platform: mellanox: add new ODM system types to > mlx-platform > > On Tue, Mar 27, 2018 at 10:02:04AM +, Vadim Pasternak wrote: > > Patch adds new ODM systems, matched according to DMI_BOARD_NAME. > > General nit. When writing your messages, please use the imperative (command) > form. Rather than: > > "Patch adds" or "It changes" use the same form you use in the subject lines: > > "Add new ODM systems", "Fix struct field documentation", etc. > > Again, I've been rewriting these, but as a regular contributor, this will help > reduce the overhead of reviewing your patches - good for you, good for me :-) > > > The supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, > VMOD0004, > > VMOD0005. It doesn't introduce new systems, but allows to ODM > > companies to set DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their > own. > > It assumes that ODM company can't change DMI_BOARD_NAME. > > You said "it assumes that ODM companies can't change DMI_BOARD_NAME". Is > that an assumption, or is that how ODMs work with Mellanox? Till now ODM companies didn't care about SMBIOS content. But now we have two, which want to overwrite BOARD_VENDOR and PRODUCT_NAME (and some other fields). System manufacturing for ODM is provided by Mellanox, so Mellanox production team is responsible for setting all these fields. Both don't care about BOARD_NAME and it has been closed with them, that content of this filed will be defined by Mellanox. > -- > Darren Hart > VMware Open Source Technology Center
RE: [PATCH v1 4/7] platform: mellanox: add new ODM system types to mlx-platform
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, April 13, 2018 7:55 PM > To: Vadim Pasternak > Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us; > Michael Shych ; ivec...@redhat.com > Subject: Re: [PATCH v1 4/7] platform: mellanox: add new ODM system types to > mlx-platform > > On Tue, Mar 27, 2018 at 10:02:04AM +, Vadim Pasternak wrote: > > Patch adds new ODM systems, matched according to DMI_BOARD_NAME. > > General nit. When writing your messages, please use the imperative (command) > form. Rather than: > > "Patch adds" or "It changes" use the same form you use in the subject lines: > > "Add new ODM systems", "Fix struct field documentation", etc. > > Again, I've been rewriting these, but as a regular contributor, this will help > reduce the overhead of reviewing your patches - good for you, good for me :-) > > > The supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, > VMOD0004, > > VMOD0005. It doesn't introduce new systems, but allows to ODM > > companies to set DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their > own. > > It assumes that ODM company can't change DMI_BOARD_NAME. > > You said "it assumes that ODM companies can't change DMI_BOARD_NAME". Is > that an assumption, or is that how ODMs work with Mellanox? Till now ODM companies didn't care about SMBIOS content. But now we have two, which want to overwrite BOARD_VENDOR and PRODUCT_NAME (and some other fields). System manufacturing for ODM is provided by Mellanox, so Mellanox production team is responsible for setting all these fields. Both don't care about BOARD_NAME and it has been closed with them, that content of this filed will be defined by Mellanox. > -- > Darren Hart > VMware Open Source Technology Center
RE: [PATCH v1 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, April 13, 2018 7:47 PM
> To: Vadim Pasternak <vad...@mellanox.com>
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych <michae...@mellanox.com>; ivec...@redhat.com
> Subject: Re: [PATCH v1 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle
> for hotplug work queue
>
> On Tue, Mar 27, 2018 at 10:02:03AM +, Vadim Pasternak wrote:
> > It adds missed logic for signal acknowledge, by adding an extra run
> > for work queue in case a signal is received, but no specific signal
> > assertion is detected. Such case theoretically can happen for example
> > in case several units are removed or inserted at the same time. In
> > this situation acknowledge for some signal can be missed at signal top
> > aggreagation status level.
>
> Why can they be missed? What does "signal top aggregation status level"
> mean? I'm asking to confirm that we are fixing this at the right place, and
> not
> just applying a suboptimal bandaid by running the workqueue more.
>
Hi Darren,
Thank for review.
It could happen within the next flow:
The signal routing flow is as following (f.e. for of FANi removing):
- FAN status and event registers related bit is changed;
-- intermediate aggregation status register is changed;
--- top aggregation status register is changed;
interrupt routed to CPU and interrupt handler is invoked.
When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
(a1) mask top aggregation interrupt mask register;
(a2) read top aggregation interrupt status register and test to which
underling group belongs a signal (FANs in this case and is changed
from 0xff to 0xfb and 0xfb is saved as a last status value);
(b1) mask FANs interrupt mask register;
(b2) read FANs status register and test which FAN has been changed (FAN3 in
this example);
(c1) perform relevant action;
<--- (FAN2 is removed at this point)
(b3) clear FANs interrupt event register to acknowledge FAN3 signal;
(b4) unmask FANs interrupt mask register
(a3) unmask top aggregation interrupt mask register;
An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
It should set top aggregation interrupt status register bit 6 (0xfb).
In step (a2)
(a2) read top aggregation interrupt and comparing it with saved value doesn't
show change (same 0xfb) and after (a2) execution jumps to (a3) and
signal leaved unhandled.
> ...
>
> >
> > Fixes: 1f976f6978bf ("platform/x86: Move Mellanox platform hotplug
> > driver to platform/mellanox")
>
> You didn't mention above how this commit caused this - how did moving the
> driver create this problem?
Actually I should reference to
07b89c2b2a5e ("platform/x86: Introduce support for Mellanox hotplug driver")
which was initial driver commit, before it has been relocated.
Does this need to go to stable? I'm assuming not as
> you've called it theoretical - not something you've observed in practice?
>
It's not necessary to go to stable.
> ...
>
> > static int mlxreg_hotplug_device_create(struct
> > mlxreg_hotplug_priv_data *priv, @@ -410,6 +413,18 @@ static void
> mlxreg_hotplug_work_handler(struct work_struct *work)
> > aggr_asserted = priv->aggr_cache ^ regval;
> > priv->aggr_cache = regval;
> >
> > + /*
> > +* Handler is invoked, but no assertion is detected at top aggregation
> > +* status level. Set aggr_asserted to mask value to allow handler extra
> > +* run over all relevant signals to recover any missed signal.
> > +*/
> > + if (priv->not_asserted == MLXREG_HOTPLUG_NOT_ASSERT) {
> > + priv->not_asserted = 0;
> > + aggr_asserted = pdata->mask;
> > + }
> > + if (!aggr_asserted)
>
> We seem to check aggr_asserted in several places in this routine now.
> Looks like something we could simplify. If you check it here, can you drop the
> check lower in the routine? Can you remove it from the for loop if conditional
> entirely? Please consider how to simplify.
OK, will review this code.
>
> --
> Darren Hart
> VMware Open Source Technology Center
RE: [PATCH v1 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, April 13, 2018 7:47 PM
> To: Vadim Pasternak
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych ; ivec...@redhat.com
> Subject: Re: [PATCH v1 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle
> for hotplug work queue
>
> On Tue, Mar 27, 2018 at 10:02:03AM +, Vadim Pasternak wrote:
> > It adds missed logic for signal acknowledge, by adding an extra run
> > for work queue in case a signal is received, but no specific signal
> > assertion is detected. Such case theoretically can happen for example
> > in case several units are removed or inserted at the same time. In
> > this situation acknowledge for some signal can be missed at signal top
> > aggreagation status level.
>
> Why can they be missed? What does "signal top aggregation status level"
> mean? I'm asking to confirm that we are fixing this at the right place, and
> not
> just applying a suboptimal bandaid by running the workqueue more.
>
Hi Darren,
Thank for review.
It could happen within the next flow:
The signal routing flow is as following (f.e. for of FANi removing):
- FAN status and event registers related bit is changed;
-- intermediate aggregation status register is changed;
--- top aggregation status register is changed;
interrupt routed to CPU and interrupt handler is invoked.
When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
(a1) mask top aggregation interrupt mask register;
(a2) read top aggregation interrupt status register and test to which
underling group belongs a signal (FANs in this case and is changed
from 0xff to 0xfb and 0xfb is saved as a last status value);
(b1) mask FANs interrupt mask register;
(b2) read FANs status register and test which FAN has been changed (FAN3 in
this example);
(c1) perform relevant action;
<--- (FAN2 is removed at this point)
(b3) clear FANs interrupt event register to acknowledge FAN3 signal;
(b4) unmask FANs interrupt mask register
(a3) unmask top aggregation interrupt mask register;
An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
It should set top aggregation interrupt status register bit 6 (0xfb).
In step (a2)
(a2) read top aggregation interrupt and comparing it with saved value doesn't
show change (same 0xfb) and after (a2) execution jumps to (a3) and
signal leaved unhandled.
> ...
>
> >
> > Fixes: 1f976f6978bf ("platform/x86: Move Mellanox platform hotplug
> > driver to platform/mellanox")
>
> You didn't mention above how this commit caused this - how did moving the
> driver create this problem?
Actually I should reference to
07b89c2b2a5e ("platform/x86: Introduce support for Mellanox hotplug driver")
which was initial driver commit, before it has been relocated.
Does this need to go to stable? I'm assuming not as
> you've called it theoretical - not something you've observed in practice?
>
It's not necessary to go to stable.
> ...
>
> > static int mlxreg_hotplug_device_create(struct
> > mlxreg_hotplug_priv_data *priv, @@ -410,6 +413,18 @@ static void
> mlxreg_hotplug_work_handler(struct work_struct *work)
> > aggr_asserted = priv->aggr_cache ^ regval;
> > priv->aggr_cache = regval;
> >
> > + /*
> > +* Handler is invoked, but no assertion is detected at top aggregation
> > +* status level. Set aggr_asserted to mask value to allow handler extra
> > +* run over all relevant signals to recover any missed signal.
> > +*/
> > + if (priv->not_asserted == MLXREG_HOTPLUG_NOT_ASSERT) {
> > + priv->not_asserted = 0;
> > + aggr_asserted = pdata->mask;
> > + }
> > + if (!aggr_asserted)
>
> We seem to check aggr_asserted in several places in this routine now.
> Looks like something we could simplify. If you check it here, can you drop the
> check lower in the routine? Can you remove it from the for loop if conditional
> entirely? Please consider how to simplify.
OK, will review this code.
>
> --
> Darren Hart
> VMware Open Source Technology Center
[PATCH v1 0/7] platform/x86: Mellanox add fixes and new features
This patcheset includes: Document fixes for mlxreg-hotplug driver and mlxreg header file. Fix for the race condition in mlxreg-hotplug driver. Adding support for ODM system types. Activation of Mellanox LED driver from mlx-platform. Introduction of new mlxreg-io driver. Activation of mlxreg-io driver from mlx-platform. Vadim Pasternak (7): platform_data/mlxreg: Document fixes for hotplug device platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private data platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue platform: mellanox: add new ODM system types to mlx-platform platform/x86: mlx-platform: Add LED platform driver activation platform/mellanox: Introduce support for Mellanox register access driver platform/x86: mlx-platform: Add mlxreg-io platform driver activation drivers/platform/mellanox/Kconfig | 11 + drivers/platform/mellanox/Makefile | 1 + drivers/platform/mellanox/mlxreg-hotplug.c | 23 +- drivers/platform/mellanox/mlxreg-io.c | 221 ++ drivers/platform/x86/mlx-platform.c| 447 + include/linux/platform_data/mlxreg.h | 66 - 6 files changed, 765 insertions(+), 4 deletions(-) create mode 100644 drivers/platform/mellanox/mlxreg-io.c -- 2.1.4
[PATCH v1 0/7] platform/x86: Mellanox add fixes and new features
This patcheset includes: Document fixes for mlxreg-hotplug driver and mlxreg header file. Fix for the race condition in mlxreg-hotplug driver. Adding support for ODM system types. Activation of Mellanox LED driver from mlx-platform. Introduction of new mlxreg-io driver. Activation of mlxreg-io driver from mlx-platform. Vadim Pasternak (7): platform_data/mlxreg: Document fixes for hotplug device platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private data platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue platform: mellanox: add new ODM system types to mlx-platform platform/x86: mlx-platform: Add LED platform driver activation platform/mellanox: Introduce support for Mellanox register access driver platform/x86: mlx-platform: Add mlxreg-io platform driver activation drivers/platform/mellanox/Kconfig | 11 + drivers/platform/mellanox/Makefile | 1 + drivers/platform/mellanox/mlxreg-hotplug.c | 23 +- drivers/platform/mellanox/mlxreg-io.c | 221 ++ drivers/platform/x86/mlx-platform.c| 447 + include/linux/platform_data/mlxreg.h | 66 - 6 files changed, 765 insertions(+), 4 deletions(-) create mode 100644 drivers/platform/mellanox/mlxreg-io.c -- 2.1.4
[PATCH v1 1/7] platform_data/mlxreg: Document fixes for hotplug device
Remove redunadant description of label in struct mlxreg_hotplug_device.
Change location of access_mode in struct mlxreg_hotplug_device.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
include/linux/platform_data/mlxreg.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/platform_data/mlxreg.h
b/include/linux/platform_data/mlxreg.h
index 2744cff..19f5cb61 100644
--- a/include/linux/platform_data/mlxreg.h
+++ b/include/linux/platform_data/mlxreg.h
@@ -58,11 +58,10 @@ struct mlxreg_hotplug_device {
* struct mlxreg_core_data - attributes control data:
*
* @label: attribute label;
- * @label: attribute register offset;
* @reg: attribute register;
* @mask: attribute access mask;
- * @mode: access mode;
* @bit: attribute effective bit;
+ * @mode: access mode;
* @np - pointer to node platform associated with attribute;
* @hpdev - hotplug device data;
* @health_cntr: dynamic device health indication counter;
--
2.1.4
[PATCH v1 1/7] platform_data/mlxreg: Document fixes for hotplug device
Remove redunadant description of label in struct mlxreg_hotplug_device.
Change location of access_mode in struct mlxreg_hotplug_device.
Signed-off-by: Vadim Pasternak
---
include/linux/platform_data/mlxreg.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/platform_data/mlxreg.h
b/include/linux/platform_data/mlxreg.h
index 2744cff..19f5cb61 100644
--- a/include/linux/platform_data/mlxreg.h
+++ b/include/linux/platform_data/mlxreg.h
@@ -58,11 +58,10 @@ struct mlxreg_hotplug_device {
* struct mlxreg_core_data - attributes control data:
*
* @label: attribute label;
- * @label: attribute register offset;
* @reg: attribute register;
* @mask: attribute access mask;
- * @mode: access mode;
* @bit: attribute effective bit;
+ * @mode: access mode;
* @np - pointer to node platform associated with attribute;
* @hpdev - hotplug device data;
* @health_cntr: dynamic device health indication counter;
--
2.1.4
[PATCH v1 4/7] platform: mellanox: add new ODM system types to mlx-platform
Patch adds new ODM systems, matched according to DMI_BOARD_NAME.
The supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, VMOD0004,
VMOD0005. It doesn't introduce new systems, but allows to
ODM companies to set DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on
their own. It assumes that ODM company can't change DMI_BOARD_NAME.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
drivers/platform/x86/mlx-platform.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 7a0bd24..912f844 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -844,6 +844,36 @@ static const struct dmi_system_id mlxplat_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "SN34"),
},
},
+ {
+ .callback = mlxplat_dmi_default_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0001"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn21xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0002"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn274x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0003"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn201x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0004"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_qmb7xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0005"),
+ },
+ },
{ }
};
--
2.1.4
[PATCH v1 4/7] platform: mellanox: add new ODM system types to mlx-platform
Patch adds new ODM systems, matched according to DMI_BOARD_NAME.
The supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, VMOD0004,
VMOD0005. It doesn't introduce new systems, but allows to
ODM companies to set DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on
their own. It assumes that ODM company can't change DMI_BOARD_NAME.
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 7a0bd24..912f844 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -844,6 +844,36 @@ static const struct dmi_system_id mlxplat_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "SN34"),
},
},
+ {
+ .callback = mlxplat_dmi_default_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0001"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn21xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0002"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn274x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0003"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_msn201x_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0004"),
+ },
+ },
+ {
+ .callback = mlxplat_dmi_qmb7xx_matched,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "VMOD0005"),
+ },
+ },
{ }
};
--
2.1.4
[PATCH v1 6/7] platform/mellanox: Introduce support for Mellanox register access driver
It introduces new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak <vad...@mellanox.com>
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 221 ++
3 files changed, 233 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..7fc266e 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ ---help---
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..f573b65
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak <vad...@mellanox.com>
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ regval &= data->mask;
+
+ val = !!val;
+ if (val)
+ regval |= ~data->mask;
+ else
+ regval &= data->mask;
+
+ ret = regmap_write(priv->pdata->regmap, data->reg, regval);
+ if (ret)
+
[PATCH v1 6/7] platform/mellanox: Introduce support for Mellanox register access driver
It introduces new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.
Signed-off-by: Vadim Pasternak
---
drivers/platform/mellanox/Kconfig | 11 ++
drivers/platform/mellanox/Makefile| 1 +
drivers/platform/mellanox/mlxreg-io.c | 221 ++
3 files changed, 233 insertions(+)
create mode 100644 drivers/platform/mellanox/mlxreg-io.c
diff --git a/drivers/platform/mellanox/Kconfig
b/drivers/platform/mellanox/Kconfig
index 591bccd..7fc266e 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
This driver handles hot-plug events for the power suppliers, power
cables and fans on the wide range Mellanox IB and Ethernet systems.
+config MLXREG_IO
+ tristate "Mellanox platform register access driver support"
+ depends on REGMAP
+ depends on HWMON
+ ---help---
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
# Mellanox Platform-Specific Drivers
#
obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..f573b65
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM 48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+ struct platform_device *pdev;
+ struct mlxreg_core_platform_data *pdata;
+ struct device *hwmon;
+ struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+ struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 regval = 0;
+ int ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ if (!data->bit)
+ regval = !!(regval & ~data->mask);
+
+ return sprintf(buf, "%u\n", regval);
+
+access_error:
+ return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+ int index = to_sensor_dev_attr(attr)->index;
+ struct mlxreg_core_data *data = priv->pdata->data + index;
+ u32 val, regval;
+ int ret;
+
+ ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+ if (ret)
+ return ret;
+
+ ret = regmap_read(priv->pdata->regmap, data->reg, );
+ if (ret)
+ goto access_error;
+
+ regval &= data->mask;
+
+ val = !!val;
+ if (val)
+ regval |= ~data->mask;
+ else
+ regval &= data->mask;
+
+ ret = regmap_write(priv->pdata->regmap, data->reg, regval);
+ if (ret)
+ goto access_error;
+
+ return
