Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1216072 > unrolled thread

Re: [PATCH 3/7] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

Started byMaxime Coquelin <maxime.coquelin@st.com>
First post2015-08-31 10:00 +0200
Last post2015-08-31 10:50 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 3/7] dmaengine: st_fdma: Add STMicroelectronics FDMA  engine driver support Maxime Coquelin <maxime.coquelin@st.com> - 2015-08-31 10:00 +0200
    Re: [PATCH 3/7] dmaengine: st_fdma: Add STMicroelectronics FDMA  engine driver support Paul Bolle <pebolle@tiscali.nl> - 2015-08-31 10:10 +0200
      Re: [PATCH 3/7] dmaengine: st_fdma: Add STMicroelectronics FDMA  engine driver support Maxime Coquelin <maxime.coquelin@st.com> - 2015-08-31 10:50 +0200

#1216072 — Re: [PATCH 3/7] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

FromMaxime Coquelin <maxime.coquelin@st.com>
Date2015-08-31 10:00 +0200
SubjectRe: [PATCH 3/7] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
Message-ID<q3sat-1r5-1@gated-at.bofh.it>
Hi Paul,

On 07/09/2015 10:17 AM, Paul Bolle wrote:
>> >+static int __exit st_fdma_remove(struct platform_device *pdev)
>> >+{
>> >+	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
>> >+
>> >+	wait_for_completion(&fdev->fw_ack);
>> >+
>> >+	st_fdma_clk_disable(fdev);
>> >+
>> >+	return 0;
>> >+}
> Since this driver is built-in only this means st_fdma_remove() can never
> be used, right?
>

It's not because a driver is built-in only that it does not need a 
remove callback.
An instance can be probed/removed any time via driver's bind/unbind 
SysFS entries.
Am I missing something?

Kind regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1216079

FromPaul Bolle <pebolle@tiscali.nl>
Date2015-08-31 10:10 +0200
Message-ID<q3sk9-1RI-7@gated-at.bofh.it>
In reply to#1216072
Hi Maxime,

On ma, 2015-08-31 at 09:49 +0200, Maxime Coquelin wrote:
> On 07/09/2015 10:17 AM, Paul Bolle wrote:
> > > > +static int __exit st_fdma_remove(struct platform_device *pdev)
> > > > +{
> > > > +	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
> > > > +
> > > > +	wait_for_completion(&fdev->fw_ack);
> > > > +
> > > > +	st_fdma_clk_disable(fdev);
> > > > +
> > > > +	return 0;
> > > > +}
> > Since this driver is built-in only this means st_fdma_remove() can 
> > never be used, right?

> It's not because a driver is built-in only that it does not need a 
> remove callback.
> An instance can be probed/removed any time via driver's bind/unbind 
> SysFS entries.
> Am I missing something?

(This discussion is moot because Peter already stated that a new version
will be modular.)

It follows from the __exit tag that st_fdma_remove() should never be
part of the kernel image (in this version of the patch), doesn't it?

(I don't know what happens in this situation if an unbind sysfs entry is
used to remove a driver. I've never tried that.)


Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1216109

FromMaxime Coquelin <maxime.coquelin@st.com>
Date2015-08-31 10:50 +0200
Message-ID<q3sWS-2B0-11@gated-at.bofh.it>
In reply to#1216079

On 08/31/2015 10:08 AM, Paul Bolle wrote:
> Hi Maxime,
>
> On ma, 2015-08-31 at 09:49 +0200, Maxime Coquelin wrote:
>> On 07/09/2015 10:17 AM, Paul Bolle wrote:
>>>>> +static int __exit st_fdma_remove(struct platform_device *pdev)
>>>>> +{
>>>>> +	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
>>>>> +
>>>>> +	wait_for_completion(&fdev->fw_ack);
>>>>> +
>>>>> +	st_fdma_clk_disable(fdev);
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>> Since this driver is built-in only this means st_fdma_remove() can
>>> never be used, right?
>> It's not because a driver is built-in only that it does not need a
>> remove callback.
>> An instance can be probed/removed any time via driver's bind/unbind
>> SysFS entries.
>> Am I missing something?
> (This discussion is moot because Peter already stated that a new version
> will be modular.)
>
> It follows from the __exit tag that st_fdma_remove() should never be
> part of the kernel image (in this version of the patch), doesn't it?
Yes, you are right.
The remove callback is relevant, but without the __exit tag.
>
> (I don't know what happens in this situation if an unbind sysfs entry is
> used to remove a driver. I've never tried that.)
>
>
Not checked whether the function is omitted when built-in, but in any 
case, I thnk remove callbacks should not be tagged with __exit.

Regards,
Maxime


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web