Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1310514ybm; Tue, 21 May 2019 11:56:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqy/UihuxK1wPg8rj2pytw/RLpVuuxzIQwUJxXdRPw8smvMD1NV6/arvJbBcnsQXp0o81OsK X-Received: by 2002:a62:575b:: with SMTP id l88mr89331870pfb.143.1558465000478; Tue, 21 May 2019 11:56:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558465000; cv=none; d=google.com; s=arc-20160816; b=x8OOYUFPQXOAEHnVi+fgPm/5MVb3PHXd85EI9jOu471Nr+tK4g/N+mCtCIh9Gj4wAX fKW0t6HlDUzf3X25owvTrObKo4yHY1t1Ip3zz2k4Optr/YzgoF55qAtkfdWd+Tq5ppDc B88DymatZ8o6CqUQmgZM2C8XRT3aKzyV2VMVWPxC0YV0RL3J4S43m7nGpbcsmGSVjFK9 Z81H1LhlHyex9VkRS0kGigmvkh+6nyq8FAyaDvYZkwpwkla7qD3gJN5aeP9l1jnAh3U/ cjHSzbxKnqB5Qva45Q+UvvUyCacSoLlg89s2xCJ4M9l9j80dvU1Pz7jCp2bx4mb3HZNs JlNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=sEL6sSNIIEK99l5OLQoOeNNg9Xh75S7PXrPKfLbG00E=; b=d7Hs7ATmWYs5lR2/iUyivS5XJ92Qzpw+G06rArT0QFpoQTDEKanaYbCJEeFZVC5wuG soZMoWSMjY+s9ldA9AL+YsxEaWwOSs7mWJUk74cOonOdyi/soaL9DqHoROoGXlrBdSAT XA9blUECJG7zcMSvEDQxh2c/q0Otzp6Xup85T59IIYRJHk9fZOnHIvvcu1A4iRW3qCLQ reCGWBC5QloxKaed8V486sYt578oiJUKK6fhWdBaCggL+me1mgJ7eh2irt8/TigKUgQx vx/vJlx08JjPYPqLTeP7w/ridh1YBwhhqhMI3euHOZylkgGwkL534CMHly0TCt1e2nby WpBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p19si11276304plo.212.2019.05.21.11.56.23; Tue, 21 May 2019 11:56:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729302AbfEUSxm (ORCPT + 99 others); Tue, 21 May 2019 14:53:42 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:49376 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727990AbfEUSxm (ORCPT ); Tue, 21 May 2019 14:53:42 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id E2650261254; Tue, 21 May 2019 19:53:39 +0100 (BST) Date: Tue, 21 May 2019 20:53:37 +0200 From: Boris Brezillon To: Ezequiel Garcia Cc: Helen Koike , linux-media@vger.kernel.org, hverkuil-cisco@xs4all.nl, kernel@collabora.com, ezequiel.garcia@collabora.com, andrealmeid@collabora.com, Mauro Carvalho Chehab , linux-kernel@vger.kernel.org Subject: Re: [PATCH] media: vimc: fix component match compare Message-ID: <20190521205337.7fbe3139@collabora.com> In-Reply-To: <5f51eb6be411ae9afb08a9b315fe51e754dc0077.camel@collabora.com> References: <20190517172011.13257-1-helen.koike@collabora.com> <20190521145548.27844fa6@collabora.com> <5f51eb6be411ae9afb08a9b315fe51e754dc0077.camel@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 21 May 2019 15:39:00 -0300 Ezequiel Garcia wrote: > On Tue, 2019-05-21 at 14:55 +0200, Boris Brezillon wrote: > > On Fri, 17 May 2019 14:20:11 -0300 > > Helen Koike 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: > > > > 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).