lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61e076de-7b24-b71d-dd79-c1c506a0f1bf@linux.intel.com>
Date:   Tue, 5 Nov 2019 18:52:52 +0800
From:   "Tanwar, Rahul" <rahul.tanwar@...ux.intel.com>
To:     Andy Shevchenko <andriy.shevchenko@...el.com>
Cc:     linus.walleij@...aro.org, robh+dt@...nel.org, mark.rutland@....com,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, robh@...nel.org, qi-ming.wu@...el.com,
        yixin.zhu@...ux.intel.com, cheol.yong.kim@...el.com
Subject: Re: [PATCH v3 1/2] pinctrl: Add pinmux & GPIO controller driver for a
 new SoC


On 5/11/2019 5:49 PM, Andy Shevchenko wrote:
> On Tue, Nov 05, 2019 at 02:49:42PM +0800, Rahul Tanwar wrote:
>> Intel Lightning Mountain SoC has a pinmux controller & GPIO controller IP which
>> controls pin multiplexing & configuration including GPIO functions selection &
>> GPIO attributes configuration.
>>
>> This IP is not based on & does not have anything in common with Chassis
>> specification. The pinctrl drivers under pinctrl/intel/* are all based upon
>> Chassis spec compliant pinctrl IPs. So this driver doesn't fit & can not use
>> pinctrl framework under pinctrl/intel/* and it requires a separate new driver.
>>
>> Add a new GPIO & pin control framework based driver for this IP.
>> +static void eqbr_set_val(void __iomem *addr, u32 offset,
>> +			 u32 mask, u32 set, raw_spinlock_t *lock)
> This lock parameter is quite unusual. Can't you supply a pointer to a data
> structure which has lock along with MMIO address?

On second thoughts, i realize that this function can be totally avoided
since it just has two callers which can be further reduced to one caller.
I will remove this function and instead do reg update in the caller function
itself.


>> +static int gpiochip_setup(struct device *dev, struct eqbr_gpio_desc *desc)
>> +{
>> +	struct gpio_irq_chip *girq;
>> +	struct gpio_chip *gc;
>> +#if defined(CONFIG_OF_GPIO)
>> +	gc->of_node = desc->node;
>> +#endif
> Isn't it what GPIO library does for everybody?

We have 4 different of_node's for 4 different gpio_chips/banks. GPIO library
handles like below:

        if (chip->parent) {
                gdev->dev.parent = chip->parent;
                gdev->dev.of_node = chip->parent->of_node;
        }

#ifdef CONFIG_OF_GPIO
        /* If the gpiochip has an assigned OF node this takes precedence */
        if (chip->of_node)
                gdev->dev.of_node = chip->of_node;
        else
                chip->of_node = gdev->dev.of_node;
#endif

So i think we need to assign 4 of_node's to gpio_chip's in the driver.

>> +
>> +	if (!of_property_read_bool(desc->node, "interrupt-controller")) {
>> +		dev_info(dev, "gc %s: doesn't act as interrupt controller!\n",
>> +			 desc->name);
> Is it fatal or non-fatal?

It is not fatal. But i am totally missing your point. Is it about
dev_info() ? Can you please elaborate more ?


>> +		return 0;
> Ditto.
>
>> +	}
>> +}
>> +static int gpiolib_reg(struct eqbr_pinctrl_drv_data *drvdata)
>> +{
>> +	struct device_node *np;
>> +	struct eqbr_gpio_desc *desc;
> desc is very confusing here, since GPIO library uses this term for GPIO
> descriptors.

Agree, better to rename it to avoid confusion with GPIO descriptors.
I will rename it in v4. Thanks.

>> +	struct device *dev;
>> +	int i, ret;
>> +	struct resource res;
>> +
>> +		ret = bgpio_init(&desc->chip, dev, desc->bank->nr_pins/8,
> 'nr_pins / 8,'

Well noted.

>> +				 desc->membase + GPIO_IN,
>> +				 desc->membase + GPIO_OUTSET,
>> +				 desc->membase + GPIO_OUTCLR,
>> +				 desc->membase + GPIO_DIR,
>> +				 NULL,
>> +				 0);
>> +		if (ret) {
>> +			dev_err(dev, "unable to init generic GPIO\n");
>> +			return ret;
>> +		}
>> +	return 0;
>> +}
>> +static int eqbr_pinmux_set_mux(struct pinctrl_dev *pctldev,
>> +			       unsigned int selector, unsigned int group)
>> +{
>> +	struct eqbr_pinctrl_drv_data *pctl = pinctrl_dev_get_drvdata(pctldev);
>> +	struct function_desc *func;
>> +	struct group_desc *grp;
>> +	unsigned int *pinmux;
>> +	int i;
>
>> +	pinmux = grp->data;
>> +	for (i = 0; i < grp->num_pins; i++)
>> +		eqbr_set_pin_mux(pctl, pinmux[i], grp->pins[i]);
> Shouldn't be this part serialized?
>
> Same Q to all similar places. I guess I already mentioned this in previous
> review.

>From serialization, you mean locking..rt ? Yes, there is one writel()
statement inthis flow. I will add lock for that statement. Rechecked
the code again, i do notfind any other similar places.


>> +	return 0;
>> +}
>> +static int is_func_exist(struct eqbr_pmx_func *funcs, const char *name,
> Looks like it better to be boolean.

Well noted, will change in v4.

>> +			 unsigned int nr_funcs, unsigned int *idx)
>> +{
>> +	int i;
>> +
>> +	if (!funcs || !nr_funcs)
>> +		return 0;
>> +
>> +	for (i = 0; i < nr_funcs; i++) {
>> +
> Redundant blank line.

Well noted, will change in v4.

>> +		if (funcs[i].name && (strcmp(funcs[i].name, name) == 0) ) {
>> +			*idx = i;
>> +			return 1;
>> +		}
>> +	}
>> +
>> +	return 0;
>> +}
>> +static int funcs_utils(struct device *dev, struct eqbr_pmx_func *funcs,
>> +		       unsigned int *nr_funcs, funcs_util_ops op)
>> +{
>> +	struct device_node *node = dev->of_node;
>> +	struct device_node *np;
>> +	struct property *prop;
>> +	unsigned int fid;
>> +	const char *fn_name;
>> +	int i, j;
>> +
>> +	i = 0;
>> +	for_each_child_of_node(node, np) {
>> +		prop = of_find_property(np, "groups", NULL);
>> +		if (prop) {
> Why not
> 		if (!prop)
> 			continue;
> ?

Sure, i can change like that in v4.

>> +			if (of_property_read_string(np, "function",
>> +						    &fn_name)) {
> It's perfectly one line. Perhaps you may need to configure your text editor.

I am following strict 80 chars limit. This goes on to 81 chars. It's a bit
confusing on when to adhere to 80 chars limit and when to bypass it :)

>> +			}
>> +		}
>> +	}
>> +
>> +	return 0;
>> +}
>> +	for (i=0; i < nr_funcs; i++) {
> The better style is 'i = 0' and so on.
> Simple be consistent. Or do everywhere 'i=0; i<nr_func; i++', etc. But remember
> that this is for sure will be declined by most of the maintainers.

Sure, noted.

>> +	}
>>
>> +static int pinbank_init(struct device_node *np,
>> +			struct eqbr_pinctrl_drv_data *drvdata,
>> +			struct eqbr_pin_bank *bank, unsigned int id)
>> +{
>> +	struct device *dev = drvdata->dev;
>> +	struct of_phandle_args spec;
>> +
>> +	bank->membase = drvdata->membase + id * PAD_REG_OFF;
>> +
>> +	if (of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3, 0, &spec)) {
>> +		dev_err(dev, "gpio-range not available!\n");
>> +		return -EFAULT;
> Shadowing error code with actually unsuitable one.

Will change in v4. Thanks.

Regards,
Rahul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ