Received: by 10.223.185.116 with SMTP id b49csp3743450wrg; Tue, 13 Feb 2018 07:07:32 -0800 (PST) X-Google-Smtp-Source: AH8x2277FruiGPnCmhYAk5wDu+PY8ZK3Xr6FEql05OOXFC2F1EPn+4osNn0SDbV7+mlPOFph0twt X-Received: by 2002:a17:902:8e83:: with SMTP id bg3-v6mr1432400plb.246.1518534452261; Tue, 13 Feb 2018 07:07:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518534452; cv=none; d=google.com; s=arc-20160816; b=Sz0gCUfCCVGGbf+3R/F7Mu3oHTbTdrx25m8rrz5YZyM9wgIjEhr8gaIW5GMyysGR0r CIIVvDWWiVjdy1EGfWZgkSeePD8Zeg2+Pn3NIj3h2HaEu7iVPdeKBIA1d1/L1XrCzeHu KmcyCjFYk5ulWzJ5Hi9TkQFAbukOhv+WHJcXf30FeFlNkrOrZPzkIyeU2EAaMT+JSX7v idyb1yLNJls95x8thL2dnSER+oo+lsxrnf4e4SPcsxssUGxnnUTWrqlI0vCI9R/F/N8W QFSzDNgP8dp95ef9fogR/9WeK4oXBMHq73y0uFXb129x0UsDaNoxwrvSUdsp0oCUH0W1 pn7Q== 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:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=mCj825H8RPZxBuhJPe4knMAi510p3vEfQ3KN+6eJsrc=; b=iJ5pBlKsqiLubwW3zC8EhXQjKIzmv1lMoPJRCh9gsmGpS3Pkb2AswW41qB7eCoiTbP bzHPh+5rzt8g6ofk6xbMER+W+cAuPwIaSPLcyjT3HNEh328uBQjcuZizc8aO60WhX2s1 i+pOoqGsQw+YcJ262gmpOCqxFobm6mcuQvuQseaqV/ZOkhFSRDSnR2QtqK2DhzgVYwT7 vOGNhyX0XKVzSewF7Rj3DajgUkfJFKSYXL9gZ1hOBClCyLBeJNNPmYLyNi6IeMkIw/aE XTdgzBalXwWxlUdEFxNhj8JCFv+U10f6QXFqKTDP8ZU7o5jc54lqSBh4RbQ+m0o8M5Mn gLsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sLjph6PQ; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 81si1413374pfh.38.2018.02.13.07.07.16; Tue, 13 Feb 2018 07:07:32 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sLjph6PQ; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965155AbeBMPGX (ORCPT + 99 others); Tue, 13 Feb 2018 10:06:23 -0500 Received: from mail-qt0-f173.google.com ([209.85.216.173]:43097 "EHLO mail-qt0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965037AbeBMPGV (ORCPT ); Tue, 13 Feb 2018 10:06:21 -0500 Received: by mail-qt0-f173.google.com with SMTP id d26so3901144qtk.10; Tue, 13 Feb 2018 07:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mCj825H8RPZxBuhJPe4knMAi510p3vEfQ3KN+6eJsrc=; b=sLjph6PQE/TRxTXMFAidALxBjEAgGQQ9KPD99HUDaw/nGCfgCU0OWu/XXL9jTUOKqg qx8ckUSZ2ZWBsGQ7ghYhHpogPJ8/hNCsO20Q9+veI9JLqKvd7wtxWDU2Q69SuFyIjndK WARqQLtPubFjkQC7hbvPiBX/BrNW/Wu3lVG0+owsInDx6Hoicnk5G0AGcbzGDvV400dE bnLbAjk/SyRVy328PUpmq7KnDiGc8+BuQg+S5VCIBrjExhFrXZFC3wf4wb/7uP9pEwaR Ys2E5UGz7DJuzW4h1WPTF9JCmBVLlCZjWwBxG17ZuuOtqbBPToddoJVwjn41B+8CEt40 l3PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mCj825H8RPZxBuhJPe4knMAi510p3vEfQ3KN+6eJsrc=; b=mZTVpjXy3f8ebC6pUadzPN7EfTB7HnEAhdlfHhfi54MNBWr2z3OlaeyQ7z12I6y1C9 bDObnAAqweWCCWXrxLhx1ZE8urgbC/Vr3aYCEYdxSEDE/O54LmNpqRWAXQty86tlMz+9 Z0aaEto2l/Ktz5oTLIT+1TAxnFxUxil5KulF+su1C8O6RDaXLSl3zy/YjWu9s+S/c3rb JX6b2FxU83fLN6InkrKitsTxNfkM0gP7wQEPPpQU3dJUS12X0ZLCAboIAw5zEmW2yEpH UgRZUVcQCI3gYn/gblUCEBtsFcZn21uJtFcU6YUUPgIK3N0ksY6+v2JbVegQsn3ZiiKS /63w== X-Gm-Message-State: APf1xPBafb0mjk4kpxufucYFE5FpdfN175sDRoTVI4/IlCt17hRzfVNM AvC0urUhOS5q6uA6GVt3zzJZUdfsLiK5yuh2RNE= X-Received: by 10.237.58.226 with SMTP id o89mr2330752qte.207.1518534380205; Tue, 13 Feb 2018 07:06:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.195.82 with HTTP; Tue, 13 Feb 2018 07:06:19 -0800 (PST) In-Reply-To: <20180213150004.5d2v7y7wwuure4io@pali> References: <20180127133209.28995-1-pali.rohar@gmail.com> <20180128144509.pobnj7cayc4psgrj@pali> <20180131120348.azy25aqvn5wrdkeh@pali> <20180212153012.vffvjmz26ifyxbj5@pali> <20180213150004.5d2v7y7wwuure4io@pali> From: Andy Shevchenko Date: Tue, 13 Feb 2018 17:06:19 +0200 Message-ID: Subject: Re: [PATCH v2] i2c: i801: Register optional lis3lv02d i2c device on Dell machines To: =?UTF-8?Q?Pali_Roh=C3=A1r?= Cc: Jean Delvare , Wolfram Sang , =?UTF-8?B?TWljaGHFgiBLxJlwaWXFhA==?= , Steven Honeyman , Valdis Kletnieks , Jochen Eisinger , Gabriele Mazzotta , Andy Lutomirski , Mario Limonciello , Alex Hung , Takashi Iwai , linux-i2c , Linux Kernel Mailing List , Platform Driver Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 13, 2018 at 5:00 PM, Pali Roh=C3=A1r wro= te: > On Tuesday 13 February 2018 16:55:00 Andy Shevchenko wrote: >> On Mon, Feb 12, 2018 at 5:30 PM, Pali Roh=C3=A1r = wrote: >> > On Wednesday 31 January 2018 14:27:51 Andy Shevchenko wrote: >> >> On Wed, Jan 31, 2018 at 2:03 PM, Pali Roh=C3=A1r wrote: >> >> > On Sunday 28 January 2018 17:00:35 Andy Shevchenko wrote: >> >> >> On Sun, Jan 28, 2018 at 4:45 PM, Pali Roh=C3=A1r wrote: >> >> >> >> >> > ACPI device name is SMO8800, SMO8810, ... Will that acpi_dev_pre= sent >> >> >> > function match only prefix and not exact string? >> >> >> >> >> >> OK, fair enough. >> >> >> >> >> >> Do we have more users of such pattern? >> >> > >> >> > I have not seen this ACPI pattern yet, so probably not. >> >> >> >> I see. So, my one concern is the implicit names of the devices. I >> >> would like rather to see >> >> >> >> ... acpi_device_id ... []=3D { >> >> {"SMO8800"}, >> >> {"SMO8810"}, >> >> ... >> >> {} >> >> }; >> > >> > Following table already exists in dell-smo8800.c file: >> > >> > static const struct acpi_device_id smo8800_ids[] =3D { >> > { "SMO8800", 0 }, >> > { "SMO8801", 0 }, >> > { "SMO8810", 0 }, >> > { "SMO8811", 0 }, >> > { "SMO8820", 0 }, >> > { "SMO8821", 0 }, >> > { "SMO8830", 0 }, >> > { "SMO8831", 0 }, >> > { "", 0 }, >> > }; >> > >> > MODULE_DEVICE_TABLE(acpi, smo8800_ids); >> > >> > Can we reuse it? >> >> > Maybe moving array smo8800_ids[] into some header file >> > (which one?) and statically inline it? >> >> Bad idea. >> >> > Or having it only in >> > dell-smo8800.c file and exporting its symbol? >> >> Even worse. >> >> > Or is there better idea? >> > >> > For sure I do not want to copy paste this table into another module an= d >> > maintaining two copies of this list. >> >> The copy is fine. Can you guarantee that those two lists would be >> always the same? I'm not. > > Me neither. > >> And besides that explicitly over implicitly is a really good thing. I >> would not like to grep for an ID followed by grepping include line and >> check each files to check if it uses it or not. > > So what do you suggest now? Copy'n'paste and maintain two lists. Yes, it's not the ideal, but working solution. You may put a comment before each list to explain what the second does and tell a contributor to look at it and update if needed. > Having one file where it would be defined is a bad idea for you. Not just "one file", but "one *header* file". Or "exporting a symbol" which is basically not supposed to be exported. ID tables are part of the actual drivers, neither headers, nor libraries. > And maintaining copy of same array in two different files in two > different subsystems is something which I cannot guarantee. > > Therefore the current patch is the best approach. I don't like it. I'll not take it, sorry. > No shared file with > shared array/table and also no copy of that array in two different > subsystems. --=20 With Best Regards, Andy Shevchenko