Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1296103ybm; Tue, 21 May 2019 11:41:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqyB5QVcz9GQAVRACnL7sf4FVZu/OoiN1/vkrZ9aXr3vxfXw3EN1YZ4g6MN2pUjP4/Bb2dPP X-Received: by 2002:a62:582:: with SMTP id 124mr90236253pff.209.1558464068661; Tue, 21 May 2019 11:41:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558464068; cv=none; d=google.com; s=arc-20160816; b=UUAPQ+IcF9gS+pYzV77p3kHObooMUdzvorU5QX4layO7jg5WkHIFmRUrp/JXwyK4Ip YM5UkNcU5PgLy8F3vBPyqjNGKEbBrobsonerkNk6SKTbrNBsEvpZ2EpKDQzkpEx2kz82 ZwUi5XvUTgBBgZtCtlJnYP2xS0YKmADeKSGMk/4asQtP1/8kGpcryCBBl3EB/HA3aytA BaYUC3orMMHlFi5Nkm3dW8KMskhQajQaYM2/QOZBbj+PnLRK3r8zJ7TUZmaQZ4Kjf0kl 4qRNdElCU23Iz6FJTuTiEVIBRtULsKWkuzPXjTBDUIu624UaLODa+DxlzRKi4KZokvqo DuNw== 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 :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id; bh=OtObwKQZNvZvYzHW8VfWuEj7/WiKt5X0yAgBCDpIbWo=; b=E2Lvk/yfHR32eMfMRAYq9EHI0jhFKGnlfvMB7+we9a3cyQLONfiCLshppBOhHl+zLH zSjBBH3WRW1W5wkGq66jgaZx+tmaJOrzZ3giTbdIfYe87ajj5BhN0QktXK+c51OxRbxK FAj6EEnHEkhC/d9N/SaqzZcUSytdEVz89tNkX4EvJJHOcpPfTOA6IdFDnMCfxAMKkGh1 5duBUM4tds85IlwDlWMZl8LTvOgFu7L9zMVRxC8swdYtujX0//f4ENGx4+00ZvDM5jYz xq3ikM1Tqdur4QragbIaQNLFKDAprbrw9x6S4kSZWIivCpMGM4LtwQ1KFXZ8JJSQsmhj g2bg== 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 d191si21040828pga.454.2019.05.21.11.40.53; Tue, 21 May 2019 11:41:08 -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 S1729272AbfEUSjJ (ORCPT + 99 others); Tue, 21 May 2019 14:39:09 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:49322 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727969AbfEUSjJ (ORCPT ); Tue, 21 May 2019 14:39:09 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 7B20F261254 Message-ID: <5f51eb6be411ae9afb08a9b315fe51e754dc0077.camel@collabora.com> Subject: Re: [PATCH] media: vimc: fix component match compare From: Ezequiel Garcia To: Boris Brezillon , Helen Koike Cc: 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 Date: Tue, 21 May 2019 15:39:00 -0300 In-Reply-To: <20190521145548.27844fa6@collabora.com> References: <20190517172011.13257-1-helen.koike@collabora.com> <20190521145548.27844fa6@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 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, 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.