linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Helen Koike <helen.koike@collabora.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Use Media Dev Allocator to fix vimc dev lifetime bugs
Date: Sun, 16 Jun 2019 21:45:06 +0300	[thread overview]
Message-ID: <20190616184506.GD5006@pendragon.ideasonboard.com> (raw)
In-Reply-To: <1c794ca1-5490-26a4-dc39-f86e05fadc46@linuxfoundation.org>

Hi Shuah,

On Fri, Jun 14, 2019 at 05:26:46PM -0600, Shuah Khan wrote:
> On 6/13/19 7:24 AM, Helen Koike wrote:
> > On 6/13/19 2:44 AM, Hans Verkuil wrote:
> >> On 5/24/19 5:31 AM, Shuah Khan wrote:
> >>> media_device is embedded in struct vimc_device and when vimc is removed
> >>> vimc_device and the embedded media_device goes with it, while the active
> >>> stream and vimc_capture continue to access it.
> >>>
> >>> Fix the media_device lifetime problem by changing vimc to create shared
> >>> media_device using Media Device Allocator API and vimc_capture getting
> >>> a reference to vimc module. With this change, vimc module can be removed
> >>> only when the references are gone. vimc can be removed after vimc_capture
> >>> is removed.
> >>>
> >>> Media Device Allocator API supports just USB devices. Enhance it
> >>> adding a genetic device allocate interface to support other media
> >>> drivers.
> >>>
> >>> The new interface takes pointer to struct device instead and creates
> >>> media device. This interface allows a group of drivers that have a
> >>> common root device to share media device resource and ensure media
> >>> device doesn't get deleted as long as one of the drivers holds its
> >>> reference.
> >>>
> >>> The new interface has been tested with vimc component driver to fix
> >>> panics when vimc module is removed while streaming is in progress.
> >>
> >> Helen, can you review this series? I'm not sure this is the right approach
> >> for a driver like vimc, and even if it is, then it is odd that vimc-capture
> >> is the only vimc module that's handled here.
> > 
> > Hi Hans,
> > 
> > Yes, I can take a look. Sorry, I've been a bit busy these days but I'll
> > try to take a look at this patch series (and the others) asap.
> > 
> > Helen
> > 
> >> My gut feeling is that this should be handled inside vimc directly and not
> >> using the media-dev-allocator.
> 
> Hi Hans and Helen,
> 
> I explored fixing the problem within vimc before I went down the path to
> use Media Device Allocator API. I do think that it is cleaner to go this
> way and easier to maintain.
> 
> vimc is a group pf component drivers that rely on the media device vimc
> in vimc and falls into the use-case Media Device Allocator API is added
> to address. The release and life-time management happens without vimc
> component drivers being changed other than using the API to get and put
> media device reference.

Our replies crossed each other, please see my reply to Hans. I would
just like to comment here that if having multiple kernel modules causes
issue, they can all be merged together. There's no need for vimc to be
handled through multiple modules (I actually think it's quite
counterproductive, it only makes it more complex, for no added value).

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2019-06-16 18:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24  3:31 [PATCH 0/2] Use Media Dev Allocator to fix vimc dev lifetime bugs Shuah Khan
2019-05-24  3:31 ` [PATCH 1/2] media: add generic device allocate interface to media-dev-allocator Shuah Khan
2019-05-24  3:31 ` [PATCH 2/2] vimc: fix BUG: unable to handle kernel NULL pointer dereference Shuah Khan
2019-06-13  5:44 ` [PATCH 0/2] Use Media Dev Allocator to fix vimc dev lifetime bugs Hans Verkuil
2019-06-13 13:24   ` Helen Koike
2019-06-14 23:26     ` Shuah Khan
2019-06-16 18:45       ` Laurent Pinchart [this message]
2019-06-28 16:41         ` Shuah Khan
2019-06-30 11:41           ` Laurent Pinchart
2019-07-03 16:17             ` Niklas Söderlund
2019-07-03 16:52               ` Shuah Khan
2019-07-03 23:25                 ` Laurent Pinchart
2019-07-03 23:42                   ` Shuah Khan
2019-06-16 18:43   ` Laurent Pinchart

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=20190616184506.GD5006@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=helen.koike@collabora.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).