RE: [PATCH v1] platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver

2020-07-27 Thread Shravan Ramani


> -Original Message-
> From: Andy Shevchenko 
> Sent: Monday, July 27, 2020 4:24 PM
> To: Shravan Ramani 
> Cc: Andy Shevchenko ; Darren Hart
> ; Vadim Pasternak ; Jiri Pirko
> ; Platform Driver ;
> Linux Kernel Mailing List 
> Subject: Re: [PATCH v1] platform/mellanox: mlxbf-pmc: Add Mellanox BlueField
> PMC driver
> 
> On Mon, Jul 27, 2020 at 12:02 PM Shravan Kumar Ramani
>  wrote:
> >
> > 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.
> 
> Just brief comments:
> - consider to revisit header block to see what is really necessary and what 
> can
> be dropped
> - add comma to the arrays where last line is not a termination
> - look at match_string() / sysfs_match_string() API, I think they can be 
> utilised
> here
> - UUID manipulations (esp. with that GUID_INIT() against non-constant) seems
> too much, consider refactoring and cleaning up these pieces

Could you please elaborate on what approach you'd like me to take with the UUID 
manipulation?
I used the same approach as in drivers/platform/mellanox/mlxbf-bootctl.c which 
seemed like an appropriate example.
Any other pointers would be helpful.

Thanks for the feedback. Will address all the other comments in v2.

Regards,
Shravan

> - use kstroto*() API instead of sscanf. It has a range check
> 
> 
> --
> With Best Regards,
> Andy Shevchenko


RE: [PATCH v1 1/1] gpio: add driver for Mellanox BlueField GPIO controller

2019-02-19 Thread Shravan Ramani
Thank you for the feedback. Regarding the suggested use of regmap mmio, all of 
the registers being accessed here are 64-bit and the 
regmap_update_bits/regmap_read/regmap_write calls aren't very convenient to use 
in this case. All other comments have been addressed in v2.

Regards,
Shravan Kumar Ramani

-Original Message-
From: Bartosz Golaszewski  
Sent: Friday, February 15, 2019 3:48 AM
To: Shravan Ramani 
Cc: Linus Walleij ; linux-gpio 
; LKML 
Subject: Re: [PATCH v1 1/1] gpio: add driver for Mellanox BlueField GPIO 
controller

czw., 14 lut 2019 o 22:30 Shravan Kumar Ramani 
napisaƂ(a):
>
> This patch adds support for the GPIO controller used by Mellanox 
> BlueField SOCs.
>
> Reviewed-by: David Woods 
> Signed-off-by: Shravan Kumar Ramani 
> ---
>  drivers/gpio/Kconfig  |   7 ++
>  drivers/gpio/Makefile |   1 +
>  drivers/gpio/gpio-mlxbf.c | 287 
> ++
>  3 files changed, 295 insertions(+)
>  create mode 100644 drivers/gpio/gpio-mlxbf.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 
> b5a2845..2bebe92 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1292,6 +1292,13 @@ config GPIO_MERRIFIELD
> help
>   Say Y here to support Intel Merrifield GPIO.
>
> +config GPIO_MLXBF
> +   tristate "Mellanox BlueField SoC GPIO"
> +   depends on (MELLANOX_PLATFORM && ARM64 && ACPI) || COMPILE_TEST
> +   select GPIO_GENERIC

You're not really depending on it.

> +   help
> + Say Y here if you want GPIO support on Mellanox BlueField SoC.
> +
>  config GPIO_ML_IOH
> tristate "OKI SEMICONDUCTOR ML7213 IOH GPIO support"
> depends on X86 || COMPILE_TEST diff --git 
> a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 37628f8..8d54279 
> 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -83,6 +83,7 @@ obj-$(CONFIG_GPIO_MENZ127)+= gpio-menz127.o
>  obj-$(CONFIG_GPIO_MERRIFIELD)  += gpio-merrifield.o
>  obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
>  obj-$(CONFIG_GPIO_MC9S08DZ60)  += gpio-mc9s08dz60.o
> +obj-$(CONFIG_GPIO_MLXBF)   += gpio-mlxbf.o
>  obj-$(CONFIG_GPIO_ML_IOH)  += gpio-ml-ioh.o
>  obj-$(CONFIG_GPIO_MM_LANTIQ)   += gpio-mm-lantiq.o
>  obj-$(CONFIG_GPIO_MOCKUP)  += gpio-mockup.o
> diff --git a/drivers/gpio/gpio-mlxbf.c b/drivers/gpio/gpio-mlxbf.c new 
> file mode 100644 index 000..e5c50db
> --- /dev/null
> +++ b/drivers/gpio/gpio-mlxbf.c
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Number of pins on BlueField */
> +#define MLXBF_GPIO_NR 54
> +
> +/* Pad Electrical Controls. */
> +#define GPIO_PAD_CONTROL__FIRST_WORD 0x0700 #define 
> +GPIO_PAD_CONTROL_1__FIRST_WORD 0x0708 #define 
> +GPIO_PAD_CONTROL_2__FIRST_WORD 0x0710 #define 
> +GPIO_PAD_CONTROL_3__FIRST_WORD 0x0718
> +
> +#define GPIO_PIN_DIR_I 0x1040
> +#define GPIO_PIN_DIR_O 0x1048
> +#define GPIO_PIN_STATE 0x1000
> +#define GPIO_SCRATCHPAD 0x20
> +
> +#ifdef CONFIG_PM
> +struct bluefield_context_save_regs {
> +   u64 gpio_scratchpad;
> +   u64 gpio_pad_control[MLXBF_GPIO_NR];
> +   u64 gpio_pin_dir_i;
> +   u64 gpio_pin_dir_o;
> +};
> +#endif
> +
> +/* Device state structure. */
> +struct gpio_state {
> +   struct list_head node;

Why do you need that? You're not using it anywhere AFAICT.

> +   struct platform_device *pdev;

You're not using this either.

> +
> +   struct gpio_chip gc;
> +
> +   /* Must hold this lock to modify shared data. */
> +   spinlock_t lock;
> +
> +   /* Memory Address */
> +   void __iomem *dc_base;
> +
> +#ifdef CONFIG_PM
> +   struct bluefield_context_save_regs csave_regs; #endif };
> +
> +/* GPIO driver set input pins */
> +static int gpio_bf_set_input(struct gpio_chip *chip, unsigned int 
> +offset) {
> +   struct gpio_state *gs = gpiochip_get_data(chip);
> +   u64 in;
> +   u64 out;
> +
> +   if (offset > MLXBF_GPIO_NR - 1) {
> +   dev_err(chip->parent, "gpio input pins: Invalid offset %d\n",
> +   offset);
> +   return -EINVAL;
> +   }

You don't need that, the subsystem makes sure this doesn't happen.
Same elsewhere.

> +
> +   out = readq(gs->dc_base + GPIO_PIN_DIR_O);
> +   in = readq(gs->dc_base + GPIO_PIN_DIR_I);
> +
> +