Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp416645ybh; Thu, 12 Mar 2020 04:31:49 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuMziTgfPXPzNUKMg4rXmVMgRTWbT75Jy79mI4tbEp8vyV2EJCWrD+tR7MYWOcLBbNGBJIY X-Received: by 2002:aca:4710:: with SMTP id u16mr2137982oia.108.1584012709259; Thu, 12 Mar 2020 04:31:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584012709; cv=none; d=google.com; s=arc-20160816; b=hQIItY8RPbYH89ceTnwnXSqETsby0MwXMtIput3XkzN2A7GWbPusRcTPZ/fkMi0ymK m+EfoaZzND6CZkgovc/toRlm2bY9rd4aSRNiBjk2sLj/QJ/Y6zX1B4JHfFba6VHwwlPu cvwK6hdzrT6pjZnTjk7YWanKrfouOVDuhBcRdj7hGgmJjSCQHZIrcoCP+qSqk5ob+o6Y Zk2T0zSdxvRMYhte9CP75VI46ImLHtCidf48YywbExGAsgW9fJYAEz4JWMmnU253kZjR fhU0MA51KHIZnXR7t2gkGC0vAG2iJeHsc/R3GN+Gdp4xD8sZ7cjWdTa5vl4sqvpgY+BH jqyA== 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; bh=yL/Ub2070SgByHB17weMkrAALt1OABv256VyMR7DQ1E=; b=NkzWyNyy+ajjaTbuuLvvjF7GLEVt+i8cqrTrZ1aWvSfq1SJwkofmxcPcsZ05JTGUxJ M3sRe+yu/VSkbgv6T8KXYAwd0n4e8jwDFOOvaErCr/1pAbg27M4tAefg/XCjAZywmgkY 8XMcacT02oFPFZs97std4NZDHD2eqPFUQBjY1Kg4j93648fGCSRRbvtVEnVmgzspnnAe iCcWSjvCuyckCg8b+8igPVDroaTYa2lDLEdsKFAoxuSYH074lrI+L3OIlnrcn+XBy9Qd nevYZLHSCCwP0OKEIyZFSGcpyyfrs87xkMy4pAYEs2zJULEKQvzaoV6D+Uz+oO7FGhUB Ziuw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z23si2484452oid.34.2020.03.12.04.31.35; Thu, 12 Mar 2020 04:31:49 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726716AbgCLLap (ORCPT + 99 others); Thu, 12 Mar 2020 07:30:45 -0400 Received: from sauhun.de ([88.99.104.3]:41382 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725268AbgCLLap (ORCPT ); Thu, 12 Mar 2020 07:30:45 -0400 Received: from localhost (p54B331A0.dip0.t-ipconnect.de [84.179.49.160]) by pokefinder.org (Postfix) with ESMTPSA id 66DED2C1ECC; Thu, 12 Mar 2020 12:30:43 +0100 (CET) Date: Thu, 12 Mar 2020 12:30:43 +0100 From: Wolfram Sang To: Luca Ceresoli Cc: Geert Uytterhoeven , Wolfram Sang , Linux I2C , Linux-Renesas , linux-i3c@lists.infradead.org, Kieran Bingham , Niklas =?utf-8?Q?S=C3=B6derlund?= , Jacopo Mondi , Laurent Pinchart , Vladimir Zapolskiy , Linux Kernel Mailing List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Subject: Re: [RFC PATCH 7/7] i2c: core: hand over reserved devices when requesting ancillary addresses Message-ID: <20200312113042.GD1013@ninjato> References: <20200220172403.26062-1-wsa+renesas@sang-engineering.com> <20200220172403.26062-8-wsa+renesas@sang-engineering.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --rz+pwK2yUstbofK6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >> + strlcpy(reserved_client->name, I2C_DUMMY_DRV_NAME, siz= eof(client->name)); >=20 > Any strong reason for not giving the device a more informative name? Yes, sadly... > Reading "dummy" in several /sys/bus/i2c/devices/?-????/name files is not > helping. Using the 'name' string that is passed to > i2c_new_ancillary_device() would be way better, perhaps prefixed by > dev->name. But this opens the question of why not doing it in =2E.. I never liked the plain "dummy" name as well. However, because 'name' is what we need to bind to a driver we can't have a more descriptive or run-time generated name at that place. > i2c_new_dummy_device() as well, which currently receives no "name" > parameter. I thought about it but discarded the idea because then you still have no connection to the driver which created the dummy device. My favourite idea so far is to advertise i2c_new_ancillary_device() instead of i2c_new_dummy_device(), because there we already have access to the client structure. With that, we could add another link in sysfs to the main address and vice-versa. > Of course this is not strictly related to this patch and can be done in > a later step. Exactly. --rz+pwK2yUstbofK6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAl5qHWIACgkQFA3kzBSg KbYqEA//dr8XFHEYXWhQXqlofteHQgPuqLLgw5ruq9PvVCpv51Scsz/RjoUKvanT s3/CZjL+MvvHDvvpKjCpW6/ImDM2KSGalPy0ZAQ0GaOtS2aqaLvieLsnxGPF2FLl QLBufHNjG6DOkO6PrQ44SLRFvpKw2iBMihmGyJBRjWWMtPrpgw5fO0omoM3IogPj t+W0+Fou6p6dgiTYhGCIOYi8YHAHEZt+HPhBExDRHfbeF3K9IXGwA84m8uTCVEP6 2XZoR4mjO5fbXGMWp5uhB9EtXridUSmUTavnG/vOFki6i8Nw36bscICAgRVaHk3m nhK4s53VEt1EB8dyW61ZUAfBqwwCHKfbmRneKpDtytOi7PS2eHrSTC1hCioparvh ifGDynlbyaEbJtxmmp2ukgSxLiO9V3r4HgHnnU7L+yUMUApcVX6o7ftRgMjKK4oj rYOnylcJyC151MOY4T+2fSl9VCmkcBsz8K5LoU/iN0TF6/x0W3OQ6Nv1p+t1k2oe 105gZoZ/9d+7ja7MfJB23p0neb8SE0BVgkFtvLkJyvpyEw3f/JMdE1g3fjCAlb4u dB0enc8/ncA+yoGOTtN2ADXCPvteTcfK+GC9/Tlmd1HJwWlIWu24IVYJFAg6a4Ln HTILjLrr6L9HRNaemVxKdq1c/fTAPMFJB2ReDoHJokKjoTPULn0= =WKGM -----END PGP SIGNATURE----- --rz+pwK2yUstbofK6--