Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp446890imm; Wed, 29 Aug 2018 04:08:47 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdbi9KV4NpGTKaC6tjdm/2f5vxWzlgDsQRIC9rV4ns2Hxa1mtIDuixJ2I607ukmqeFZ3KZhz X-Received: by 2002:a17:902:25ab:: with SMTP id y40-v6mr5399825pla.120.1535540927568; Wed, 29 Aug 2018 04:08:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535540927; cv=none; d=google.com; s=arc-20160816; b=dNxFwsYn0tOj33PPf9CXMGZKmmeFiPV3/8vf2t3OCmWOtrXJDl2M9cUNytCSkJqgb0 9uvDHNUZzmga9SD93XOSa4GuHPQ/iR22I/iptiS5Ks7EKH1V/0ltkZVCmQ6kxIdmP0Ft G/l1El9iUUdVk1m5hwIygjAPdINSKIoIySTcrgfsT2lRqRsKVZtE90UocwkFf9Kf9ZQ4 iL5A9yEcqBuJrH9M0Zncm+aKFnG7+QJQQLniCPr3tYrgVOa49gTOD7UA52aa2uI6NUlS i5rgaqpIiUjxbdzbyeDaHG7ulwZbTNyFlkdyPzmSz1dtdl65JHbg3vJWPScFI7zI4+U2 nbjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=gCGrJfGs/KArDA/1ky5LpRNg2ENZ6dxDV54fp6Cn07Y=; b=YeansO94nlNir1wpYL2S2OuOt3QDz75tTRvzYKQ40GDWWtaKi4wYthg6ogXgvzWwXj +QieryM1VGGnhlbq3hZIomgnqoDsvNU6d02e9o5xnY/jq8+CW6YbkdNRzN+VtCXf8/h8 otKkFs6K+lE+KaBVOtrPm6jwbnLR3bPhQc84191/rD/E2IDr2YOMq2tntT1RYK3iZRlU WiB804Et6dftxOxQkns/K1/hDTC1/HHU8GU7TPsEUe8AobhbvpyE4gCO7NJcCBZfya9x foejBovarFMRkF6opK+9+ozbG790cg+wPATSPFo+dDzsYRPwpYjyLj8vsTtssrc0zyGe dlhw== 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=iki.fi Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si3511699pld.36.2018.08.29.04.08.30; Wed, 29 Aug 2018 04:08:47 -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=iki.fi Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728255AbeH2PDp (ORCPT + 99 others); Wed, 29 Aug 2018 11:03:45 -0400 Received: from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:52182 "EHLO hillosipuli.retiisi.org.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727099AbeH2PDp (ORCPT ); Wed, 29 Aug 2018 11:03:45 -0400 Received: from valkosipuli.localdomain (valkosipuli.retiisi.org.uk [IPv6:2001:1bc8:1a6:d3d5::80:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id A77E8634C83; Wed, 29 Aug 2018 14:07:21 +0300 (EEST) Received: from sakke by valkosipuli.localdomain with local (Exim 4.89) (envelope-from ) id 1fuyJl-0000pp-9u; Wed, 29 Aug 2018 14:07:21 +0300 Date: Wed, 29 Aug 2018 14:07:21 +0300 From: Sakari Ailus To: Philippe De Muyter Cc: Hans Verkuil , Luca Ceresoli , linux-media@vger.kernel.org, Leon Luo , Mauro Carvalho Chehab , Sakari Ailus , linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com Subject: Re: [PATCH 3/7] media: imx274: don't hard-code the subdev name to DRIVER_NAME Message-ID: <20180829110721.zlpqfmusaw4nh7et@valkosipuli.retiisi.org.uk> References: <20180824163525.12694-1-luca@lucaceresoli.net> <20180824163525.12694-4-luca@lucaceresoli.net> <20180825144915.tq7m5jlikwndndzq@valkosipuli.retiisi.org.uk> <799f4d1a-b91d-0404-7ef0-965d123319da@lucaceresoli.net> <113d3e05-9331-bd54-0e49-46c5e132339f@xs4all.nl> <20180828160255.GA9763@frolo.macqel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180828160255.GA9763@frolo.macqel> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Philippe, On Tue, Aug 28, 2018 at 06:02:55PM +0200, Philippe De Muyter wrote: > Hi Hans, Sakari and Luca > > On Tue, Aug 28, 2018 at 11:22:28AM +0200, Hans Verkuil wrote: > > On 26/08/18 22:41, Luca Ceresoli wrote: > > > Hi Sakari, > > > > > > On 25/08/2018 16:49, Sakari Ailus wrote: > > >> Hi Luca, > > >> > > >> On Fri, Aug 24, 2018 at 06:35:21PM +0200, Luca Ceresoli wrote: > > >>> Forcibly setting the subdev name to DRIVER_NAME (i.e. "IMX274") makes > > >>> it non-unique and less informative. > > >>> > > >>> Let the driver use the default name from i2c, e.g. "IMX274 2-001a". > > >>> > > >>> Signed-off-by: Luca Ceresoli > > >>> --- > > >>> drivers/media/i2c/imx274.c | 1 - > > >>> 1 file changed, 1 deletion(-) > > >>> > > >>> diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c > > >>> index 9b524de08470..570706695ca7 100644 > > >>> --- a/drivers/media/i2c/imx274.c > > >>> +++ b/drivers/media/i2c/imx274.c > > >>> @@ -1885,7 +1885,6 @@ static int imx274_probe(struct i2c_client *client, > > >>> imx274->client = client; > > >>> sd = &imx274->sd; > > >>> v4l2_i2c_subdev_init(sd, client, &imx274_subdev_ops); > > >>> - strlcpy(sd->name, DRIVER_NAME, sizeof(sd->name)); > > >>> sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS; > > >>> > > >>> /* initialize subdev media pad */ > > >> > > >> This ends up changing the entity as well as the sub-device name which may > > >> well break applications. > > > > > > Right, unfortunately. > > > > > >> On the other hand, you currently can't have more > > >> than one of these devices on a media device complex due to the name being > > >> specific to a driver, not the device. > > >> > > >> An option avoiding that would be to let the user choose by e.g. through a > > >> Kconfig option would avoid having to address that, but I really hate adding > > >> such options. > > > > > > I agree adding a Kconfig option just for this would be very annoying. > > > However I think the issue affects a few other drivers (sr030pc30.c and > > > s5c73m3-core.c apparently), thus maybe one option could serve them all. > > > > > >> I wonder what others think. If anyone ever needs to add another on a board > > >> so that it ends up being the part of the same media device complex > > >> (likely), then changing the name now rather than later would be the least > > >> pain. In this case I'd be leaning (slightly) towards accepting the patch > > >> and hoping there wouldn't be any fallout... I don't see any board (DT) > > >> containing imx274, at least not in the upstream kernel. > > > > > > I'll be OK with either decision. Should we keep it as is, then I think a > > > comment before that line would be appropriate to clarify it's not > > > correct but it is kept for backward userspace compatibility. This would > > > help avoid new driver writers doing the same mistake, and prevent other > > > people to send another patch like mine. > > > > In this end, this is a driver bug. I would just fix this, but add a comment > > that states the old name and why it was changed. No need for a dev_info > > IMHO. > > > > It would be nice if you can check if the same mistake is made in other drivers, > > and update those as well. It's easier if this is all done at the same time. > > > > Then we should probably also apply the following patch I submitted : > > "media: v4l2-common: v4l2_spi_subdev_init : generate unique name" > https://patchwork.kernel.org/patch/10553035/ > > and perhaps > > "media: v4l2-common: simplify v4l2_i2c_subdev_init name generation" > https://patchwork.kernel.org/patch/10553037/ The problem with this patch is that the existing naming scheme is very similar while the new one offers no tangible benefits apart from being in line with the rest of the kernel. That's still not a benefit for uAPI: changing the name is certain to break user space applications. I posted another patch on which I'm somewhat uncertain applying it would be only a good thing: But it would fix an actual bug. I maintain that the information (device name as it's seen by the rest of the system) would be good to have in device properties; Hans posted a patchset on that some time ago. -- Regards, Sakari Ailus e-mail: sakari.ailus@iki.fi