From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78195C7EE2A for ; Mon, 5 Jun 2023 04:48:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232082AbjFEEsX (ORCPT ); Mon, 5 Jun 2023 00:48:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232808AbjFEEsV (ORCPT ); Mon, 5 Jun 2023 00:48:21 -0400 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D7C73E3; Sun, 4 Jun 2023 21:48:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id E2A4F80C1; Mon, 5 Jun 2023 04:48:17 +0000 (UTC) Date: Mon, 5 Jun 2023 07:48:16 +0300 From: Tony Lindgren To: Francesco Dolcini Cc: Nishanth Menon , Vignesh Raghavendra , Francesco Dolcini , Tero Kristo , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Conor Dooley Subject: Re: [PATCH v2 1/5] dt-bindings: arm: ti: add toradex,verdin-am62 et al. Message-ID: <20230605044816.GU14287@atomide.com> References: <20230601131332.26877-1-francesco@dolcini.it> <20230601131332.26877-2-francesco@dolcini.it> <20230602072045.GO14287@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org * Francesco Dolcini [230602 08:18]: > On Fri, Jun 02, 2023 at 10:20:45AM +0300, Tony Lindgren wrote: > > Hi, > > > > * Francesco Dolcini [230601 13:15]: > > > From: Francesco Dolcini > > > > > > Add toradex,verdin-am62 for Toradex Verdin AM62 SoM, its > > > nonwifi and wifi variants and the carrier boards (Dahlia, > > > Verdin Development Board and Yavia) they may be mated in. > > > > Looks like you have wifi on sdio, there should be no need for separate > > compatible properties. The sdio wifi will try to probe and will just bail > > out if no wifi is populated. > > > > If however the non-wifi variants are recycling the sdio pins for something > > else, then it's it's a different story. In that case you want either > > seprate compatible properties, or want to use dts fragments possibly. > > This is exactly the case, the wifi/non-wifi variant are re-using pins. > > I provided a more verbose explanation on that on a previous discussion > https://lore.kernel.org/all/ZG5jYV%2FNfGJvYkma@francesco-nb.int.toradex.com/ Ok thanks for the information. Regards, Tony