Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1469237pxb; Wed, 12 Jan 2022 15:49:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJwCg03iOD/kk+ItLyvIGdxOwuIy0fHsf2XdHsj3hqce4LhpkeWgCVLtcodL1HVIvicnXZjd X-Received: by 2002:aa7:cada:: with SMTP id l26mr1872855edt.376.1642031376614; Wed, 12 Jan 2022 15:49:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642031376; cv=none; d=google.com; s=arc-20160816; b=mRMz5PKp6wWWyKP7lSsvYw9sti+MX2MIUk6mrZQuueFB2srCWMfLtUkcZSkDsHKpTk IcDT7M/KWNAIQFiXQ6FM0xsEfA9N1o5I1cDHv3df+KBUygyH1hq1acZAS5/YxLbh7vkf UHlqnUr9G42UPOroT9jiZPh9sMaXJHeHg2GBjzT2sPu2ZmK47t0R5P1WcVFDfQ2T27Gf lfSP0E12dcomZYsNPmRdedzQgr6UI7Lwp6dZjSQ3HnKePoG0aQoUoB6fT6Fv6Djp1HNc oxMzT/7ksx1Nt1Xzl2Ubw2nU7zxmF02MlNYpyoDt+MCmxQLroURZ5rQNQ3JvoYjkNMOD Duqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=f5tu4Iro6u7pGSZAXtr0uEZQIc0eZ2WxOCo/dF+vnvI=; b=JicoZPBcuIL8SK+Hcpy8m1HiphkbQQPNgBM1vAsHUPhznPBOAKZR4EW6IAo1ky4RjC t0NlAb0BCEDB6ZjIXuSYlWpCMzS4tAf0LGsY1YwhhRVAQB3BG7+OYQ9kRtiP03ydcTU7 SZ6mFZfWPRrC5zLVMcHgQD+7hnZSRcQZBWdRz5MRzzPIASsol1IoceUDbKDNbQ9y9Lpp lSH+r/5P/iUycCl5LrqRp8X/B9YWePaoPHK42HKix2cySSo8GCu8Y+J1zv+DG9Q+BBK1 A/dLkfnIaXJsk3jfaasuKlA3KIoHdHHL+MPL13RtHSWU2343xhxYwJjEL6cNg8n0iPHU OAtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=I5IBb8wM; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g25si662262edq.416.2022.01.12.15.49.20; Wed, 12 Jan 2022 15:49:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=I5IBb8wM; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343984AbiALRs4 (ORCPT + 71 others); Wed, 12 Jan 2022 12:48:56 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:45578 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240668AbiALRsx (ORCPT ); Wed, 12 Jan 2022 12:48:53 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E36BCB81EA6; Wed, 12 Jan 2022 17:48:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8ADA2C36AE5; Wed, 12 Jan 2022 17:48:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642009730; bh=v5HVJMOt7K5cfz9ChUmoP+h6WJ8BSd2gVzVjKi67/bs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I5IBb8wMr1OFJJp1W4xiBKrGiLlzko0I4nZKxuwBG2kwloTU3de7Oz94htQwZBPr8 midFS13nAQX6Fs4UhOwPEDWTfK3m//xboWTelsPoUzvmjVnw9K46ZScJcMUUQytTur 7BunIoxoYHeHz3gAtPMyPmjMdrnivJ/PN5GYKIYXs6s6USAb1V/37faYc+sPS2afL5 CqFVDc8M5gI7eCI2dRDH7JnnKzHJTXdSGAokYiV0Zo58OAa8yhIaoDyWhDmGiNgESi 6OU0gIiFdHdDPRihZPjIdDbuzH9Rru5AYGe8XFWwDECAlPy1P1bWERHxc8HWk2dJEO 9TKEzmzEjOrAw== Received: by pali.im (Postfix) id 2CEB5768; Wed, 12 Jan 2022 18:48:48 +0100 (CET) Date: Wed, 12 Jan 2022 18:48:48 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: =?utf-8?B?SsOpcsO0bWU=?= Pouiller Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org, Kalle Valo , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , "David S . Miller" , devicetree@vger.kernel.org, Rob Herring , linux-mmc@vger.kernel.org, Ulf Hansson Subject: Re: [PATCH v9 08/24] wfx: add bus_sdio.c Message-ID: <20220112174848.db5osolurllpc7du@pali> References: <20220111171424.862764-1-Jerome.Pouiller@silabs.com> <42104281.b1Mx7tgHyx@pc-42> <20220112114332.jadw527pe7r2j4vv@pali> <2680707.qJCEgCfB62@pc-42> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2680707.qJCEgCfB62@pc-42> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Wednesday 12 January 2022 17:45:45 Jérôme Pouiller wrote: > On Wednesday 12 January 2022 12:43:32 CET Pali Rohár wrote: > > > > On Wednesday 12 January 2022 12:18:58 Jérôme Pouiller wrote: > > > On Wednesday 12 January 2022 11:58:59 CET Pali Rohár wrote: > > > > On Tuesday 11 January 2022 18:14:08 Jerome Pouiller wrote: > > > > > +static const struct sdio_device_id wfx_sdio_ids[] = { > > > > > + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) }, > > > > > + { }, > > > > > +}; > > > > > > > > Hello! Is this table still required? > > > > > > As far as I understand, if the driver does not provide an id_table, the > > > probe function won't be never called (see sdio_match_device()). > > > > > > Since, we rely on the device tree, we could replace SDIO_VENDOR_ID_SILABS > > > and SDIO_DEVICE_ID_SILABS_WF200 by SDIO_ANY_ID. However, it does not hurt > > > to add an extra filter here. > > > > Now when this particular id is not required, I'm thinking if it is still > > required and it is a good idea to define these SDIO_VENDOR_ID_SILABS > > macros into kernel include files. As it would mean that other broken > > SDIO devices could define these bogus numbers too... And having them in > > common kernel includes files can cause issues... e.g. other developers > > could think that it is correct to use them as they are defined in common > > header files. But as these numbers are not reliable (other broken cards > > may have same ids as wf200) and their usage may cause issues in future. > > In order to make SDIO_VENDOR_ID_SILABS less official, do you prefer to > define it in wfx/bus_sdio.c instead of mmc/sdio_ids.h? > > Or even not defined at all like: > > static const struct sdio_device_id wfx_sdio_ids[] = { > /* WF200 does not have official VID/PID */ > { SDIO_DEVICE(0x0000, 0x1000) }, > { }, > }; This has advantage that it is explicitly visible that this device does not use any officially assigned ids. > > > -- > Jérôme Pouiller > >