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 X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E585C433E2 for ; Thu, 17 Sep 2020 12:28:33 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 52C5B2087D for ; Thu, 17 Sep 2020 12:28:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yqw+NVW9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="Rh/QMCIT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52C5B2087D Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nY1cFjvuI16hTVN+yLAGPh181TSdHLSRquYKxZmbp/Y=; b=yqw+NVW96fleJU9gHiOzudtHc +u3jtbBNp/0o2ROpRCyjkEZosyA/yR6tnW8j65MloYtkeoH7spse5cnmL/onGu6TWWFpSJQJZ5Et0 qKTiEPZCz/o7QPduoWVnnvjboUqzMbYJX6eHqpYiF9KNmbsNv1sJt+wxY9dovCQYjxyd+CtyfcOQc Dp3S6UmSuXM6kJrYooMn+Qoq8drC1Wzx4ZKfLCdQgX72ZybnJCbY5OxJFXinwot9frpaehtdUgAMz jV6+ehCm5Tq5A9Qokv2seuLGx6lRXtkFx5ZjzrgrkB6zKPwnhFInzBLb9h5sL9CD4CDJpzeUCOohg 7jJEZ5TdA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIt0K-0003lV-7d; Thu, 17 Sep 2020 12:27:12 +0000 Received: from lelv0142.ext.ti.com ([198.47.23.249]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIt0H-0003kS-6g for linux-arm-kernel@lists.infradead.org; Thu, 17 Sep 2020 12:27:10 +0000 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 08HCR44A044284; Thu, 17 Sep 2020 07:27:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1600345624; bh=h6OSpodV87NvHPxkIpIpIZPach27yXLw2FWSGojvvF4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Rh/QMCITmgUxEIqK/aTN6LkyK3HkutT6/qo58DtuiVyZlg2I4qZ3DOUwxnh3ulGBD 8idi+DOxwRqf6GWUkk8SOYZsXXOx5RIcaMr2A9wqqbayfO6Ve/WANjJA8RzKBqYVMr oi/iwBZkcRPonwNq549pe7ATCZmWJpDVtKj/nmfA= Received: from DLEE109.ent.ti.com (dlee109.ent.ti.com [157.170.170.41]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 08HCR3Q6129725 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 17 Sep 2020 07:27:03 -0500 Received: from DLEE112.ent.ti.com (157.170.170.23) by DLEE109.ent.ti.com (157.170.170.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Thu, 17 Sep 2020 07:27:03 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Thu, 17 Sep 2020 07:27:03 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 08HCR3Em125110; Thu, 17 Sep 2020 07:27:03 -0500 Date: Thu, 17 Sep 2020 07:27:03 -0500 From: Nishanth Menon To: Peter Rosin Subject: Re: [PATCH v3 1/6] dt-bindings: mux-j7200-wiz: Add lane function defines Message-ID: <20200917122703.ojuzn6b3tvqbnssc@akan> References: <20200915112038.30219-1-rogerq@ti.com> <20200915112038.30219-2-rogerq@ti.com> <20200916154536.m552ft2jzfsaeokr@akan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200917_082709_359982_0C755D9E X-CRM114-Status: GOOD ( 17.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, nsekhar@ti.com, linux-kernel@vger.kernel.org, kishon@ti.com, t-kristo@ti.com, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, Roger Quadros Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11:45-20200917, Peter Rosin wrote: [...] > > >> Should not the defines start with J7200_WIZ? SERDES0 seems like a too > >> generic prefix, at least to me. > > > > Thanks, good point. I am not sure if WIZ should even be used.. It is > > a TI internal prefix for various serdes solutions, but I agree that > > SERDES0 is too generic a terminology. That said, we should cleanup > > include/dt-bindings/mux/mux-j721e-wiz.h as well, prior to introducing > > j7200 changes. > > Right. As maintainer for the directory in question, I should have > been on Cc for that series too, but it appears I wasn't. Hence, I yes, you should have been. The following commit introduced it. commit b766e3b0d5f6 ("arm64: dts: ti: k3-j721e-main: Add system controller node and SERDES lane mux") > didn't notice that file until now when I went looking for it. Why > wasn't I on Cc? Got through the SoC tree - an oversight on our part[1] and should'nt have, Apologies on the bad call. I would like to propose the following: a) The header should be renamed to be something more human friendly. b) The header should be renamed to be something TI specific and NOT per TI SoC. c) The macros need renaming to be less generic as it stands right now. If you ack the changes, I am guessing that the changes will impact dts a lot and would rather take the cleanups through SoC tree to maintain bisectability? OR I can pick on an immutable tag from you with just the header file change and pick on the dts - but I doubt that would be bisectable. Just worried that I have picked a bunch of cleanups already on the dts for 5.10, and would like to avoid a merge conflict. your thoughts? [1] https://lore.kernel.org/linux-devicetree/20200709231933.GA1083562@bogus/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel