From: Boris Brezillon <email@example.com> To: Ezequiel Garcia <firstname.lastname@example.org> Cc: Helen Koike <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Mauro Carvalho Chehab <email@example.com>, firstname.lastname@example.org Subject: Re: [PATCH] media: vimc: fix component match compare Date: Tue, 21 May 2019 20:53:37 +0200 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue, 21 May 2019 15:39:00 -0300 Ezequiel Garcia <email@example.com> wrote: > On Tue, 2019-05-21 at 14:55 +0200, Boris Brezillon wrote: > > On Fri, 17 May 2019 14:20:11 -0300 > > Helen Koike <firstname.lastname@example.org> wrote: > > > > > If the system has other devices being registered in the component > > > framework, the compare function will be called with a device that > > > doesn't belong to vimc. > > > This device is not necessarily a platform_device, nor have a > > > platform_data (which causes a NULL pointer dereference error) and if it > > > does have a pdata, it is not necessarily type of struct vimc_platform_data. > > > So casting to any of these types is wrong. > > > > > > Instead of expecting a given pdev with a given pdata, just expect for > > > the device it self. vimc-core is the one who creates them, we know in > > > advance exactly which object to expect in the match. > > > > > > Fixes: 4a29b7090749 ("[media] vimc: Subdevices as modules") > > > > Oh, and you forgot to add > > > > Cc: <email@example.com> > > > > Although it's not really documented (not in process/stable-rules > at least) that a "Fixes" tag alone would be automatically picked by > the stable team, it has been the case for me since always, > as I've never Cced stable explicitly. > It's probably the case thanks to Sascha's auto-select tool, but I do think it's better to be explicit about what you want: there are some cases where a patch fixes a bug, but the user doesn't want this patch to be backported because it's not been tested or older kernels, is too complex to be backported as is or is not important enough (typos).
prev parent reply index Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-17 17:20 Helen Koike 2019-05-21 12:53 ` Boris Brezillon 2019-05-21 12:55 ` Boris Brezillon 2019-05-21 18:39 ` Ezequiel Garcia 2019-05-21 18:53 ` Boris Brezillon [this message]
Reply instructions: You may reply publically 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Linux-Media Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-media/0 linux-media/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-media linux-media/ https://lore.kernel.org/linux-media \ email@example.com firstname.lastname@example.org public-inbox-index linux-media Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-media AGPL code for this site: git clone https://public-inbox.org/ public-inbox