All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tanwar, Rahul" <rahul.tanwar@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: linus.walleij@linaro.org, robh+dt@kernel.org,
	mark.rutland@arm.com, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	robh@kernel.org, qi-ming.wu@intel.com, yixin.zhu@linux.intel.com,
	cheol.yong.kim@intel.com
Subject: Re: [PATCH v4 1/2] pinctrl: Add pinmux & GPIO controller driver for a new SoC
Date: Thu, 7 Nov 2019 17:36:08 +0800	[thread overview]
Message-ID: <59074c5d-fb80-cfbf-b54b-10d9fd14eac0@linux.intel.com> (raw)
In-Reply-To: <20191107090712.GV32742@smile.fi.intel.com>


Hi Andy,

On 7/11/2019 5:07 PM, Andy Shevchenko wrote:
> On Thu, Nov 07, 2019 at 03:36:44PM +0800, Rahul Tanwar wrote:
> +static void eqbr_gpio_mask_ack_irq(struct irq_data *d)
>> +{
>> +	eqbr_gpio_disable_irq(d);
>> +	eqbr_gpio_ack_irq(d);
> Potential race?
>
>> +}
>> +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;
>> +
>> +	func = pinmux_generic_get_function(pctldev, selector);
>> +	if (!func)
>> +		return -EINVAL;
>> +
>> +	grp = pinctrl_generic_get_group(pctldev, group);
>> +	if (!grp)
>> +		return -EINVAL;
>> +
>> +	pinmux = grp->data;
>> +	for (i = 0; i < grp->num_pins; i++)
>> +		eqbr_set_pin_mux(pctl, pinmux[i], grp->pins[i]);
> What if in the middle of the loop mux of one of the pins be changed by parallel
> thread?

These are all ops called back from the core pinctrl framework.
My understanding is that multi-threading serialization is provided by the
pinctrl framework using mutex's. Drivers don't have to worry about that.
Drivers only have to worry about multi-core serialization. I checked
many other existing pinctrl drivers & all of them seem to use spin lock
only for register accesses (not for serializing the ops itself).

Is this understanding incorrect ?


>
>> +	/* 0 mux is reserved for GPIO */
> Perhaps
>
> #define EQBR_GPIO_MODE	0
>
> ?

I had first used #define for this but removed it based on Rob Herring
review feedback. I will add it back here but keep it as 0 in dt bindings..

>> +	return eqbr_set_pin_mux(pctl, 0, pin);
>> +}
>> +	for (i = 0; i < npins; i++) {
>> +		ret = eqbr_pinconf_set(pctldev, pins[i], configs, num_configs);
>> +		if (ret)
>> +			return ret;
> What if in the middle of the loop settings of one of the pins be changed by
> parallel thread?

Same comments as above..

>
>> +		group.pins = devm_kcalloc(dev, group.num_pins,
>> +					  sizeof(*(group.pins)), GFP_KERNEL);
>> +		pinmux = devm_kcalloc(dev, group.num_pins,
>> +				      sizeof(*pinmux), GFP_KERNEL);
> These can be rearranged.

Lost you here. Please elaborate more on what you mean by rearranging. Thanks.

Regards,
Rahul



  reply	other threads:[~2019-11-07  9:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07  7:36 [PATCH v4 0/2] pinctrl: Add new pinctrl/GPIO driver Rahul Tanwar
2019-11-07  7:36 ` [PATCH v4 1/2] pinctrl: Add pinmux & GPIO controller driver for a new SoC Rahul Tanwar
2019-11-07  9:07   ` Andy Shevchenko
2019-11-07  9:36     ` Tanwar, Rahul [this message]
2019-11-07  7:36 ` [PATCH v4 2/2] dt-bindings: pinctrl: intel: Add for " Rahul Tanwar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59074c5d-fb80-cfbf-b54b-10d9fd14eac0@linux.intel.com \
    --to=rahul.tanwar@linux.intel.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=cheol.yong.kim@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=qi-ming.wu@intel.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=yixin.zhu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.