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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 32287CD1288 for ; Wed, 3 Apr 2024 14:41:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=1bYJqKAPiUh2VegB39d8hugOHqoXa3QV4oPVa5+HYhc=; b=rCwaXtQhJa8rLi bD7OiTBar7MmcYGqGxTejtagDia4hRib+fCZoXwpyIOt/P7S3IOw+t6jd/FyBtvb9QyvjS2ZhYgaN EQ/1q4ktUb6fn6FFGwS9u88b9ho0W03q3+2IVIXYAM1xZ8kGAf/aW4iNmaBeVYOAwrdfhGtQx3r67 mvu+ePSxOZY34yLO300JplA3zHNfHE3Iigc8CAXBoh4NA57voGuCp4h2y8hUPO7rbGzJ1TA+623zR 35iVZWhlP+4ImmhLJoDe185Z8RJvOb7d0x1mEK32CE52+gBEv7MzUJrkSQc8iXTqaQ9EY4ZyuKO6L kmqYZBIaMXhkKrsBkRuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rs1o4-0000000GWv4-2k7f; Wed, 03 Apr 2024 14:41:40 +0000 Received: from mgamail.intel.com ([198.175.65.20]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rs1o1-0000000GWsU-0TxP for linux-arm-kernel@lists.infradead.org; Wed, 03 Apr 2024 14:41:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712155297; x=1743691297; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1DaGXx9siVBjJXZdLr/dlAMuD32pjEFC4WhTEPlNsNk=; b=FN2Dk0rC/jpbRtwK5b75A229zQTXdw+uQ53Z8LTNC665PwID+p7MtbJo u5QN6PA7sExMdhCATZNp8pCFBFmPPDlRS7WTyt4VoqDlyrdc2ZgmtMIj2 onvsTGeqqaycZ3ZjrAnqAefAyjrdmd9jwcpTbumzFf1vB2D1KA/NUIARS J6GR94nH0br0o4mQffn5Fp1chEW2M6jg/WIjMQIe7LmowYiuXTUPkTopY cR5gNpAJ5bKwNQ6uNpwMYwukHE/qzLU57Ad34vdCBevpzlpNphkzM/Auo THOoQweD1AsML0Af+wj0JQNnPjUajX34R9znTTIBzByqTu+05hAL4QHY1 w==; X-CSE-ConnectionGUID: ZfVhyeySS7q0p9lH0IRY0w== X-CSE-MsgGUID: re5rQQEXRTuIb2xSxeMPaw== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="7291702" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="7291702" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 07:41:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="915185310" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="915185310" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.54]) by fmsmga002.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 07:41:33 -0700 Received: from andy by smile with local (Exim 4.97) (envelope-from ) id 1rs1nu-0000000196t-1djl; Wed, 03 Apr 2024 17:41:30 +0300 Date: Wed, 3 Apr 2024 17:41:30 +0300 From: Andy Shevchenko To: Mark Brown Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Daniel Mack , Haojian Zhuang , Robert Jarzmik , Russell King , Arnd Bergmann Subject: Re: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h Message-ID: References: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com> <171167575036.187521.17547262230962160149.b4-ty@kernel.org> <0af775e1-f5f7-4ad4-b336-78834a9e0342@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0af775e1-f5f7-4ad4-b336-78834a9e0342@sirena.org.uk> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240403_074137_271756_A38A3808 X-CRM114-Status: GOOD ( 40.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, Apr 03, 2024 at 03:13:48PM +0100, Mark Brown wrote: > On Wed, Apr 03, 2024 at 04:41:40PM +0300, Andy Shevchenko wrote: > > On Wed, Apr 03, 2024 at 04:39:13PM +0300, Andy Shevchenko wrote: > > > On Wed, Apr 03, 2024 at 02:29:38PM +0100, Mark Brown wrote: > > > > > All the concerns I have with swnodes just being a more complex and less > > > > maintainable way of doing things still stand, I'm not clear that this is > > > > making anything better. > > > > As I explained before it's not less maintainable than device tree sources. > > > The only difference is that we don't have validation tool for in-kernel > > > tables. And I don't see why we need that. The data describes the platforms > > > and in the very same way may come to the driver from elsewhere. > > > How would you validate that? It the same as we trust firmware (boot loader) > > > or not. If we don't than how should we do at all? > > I don't think we should do this at all, all I see from these changes is > effort in reviewing them - as far as I can tell they are a solution in > search of a problem. DT has some support for validation of the > formatting of the data supplied by the board and offers the potential > for distributing the board description separately to the kernel. > > > > Can you point out what the exact aspect is most significant from C language > > > perspective that we miss after conversion? Type checking? Something else? > > You're changing the code from supplying data from the board description > via a simple C structure where the compiler offers at least some > validation and where we can just supply directly usable values to an > abstract data structure that's still encoded in C but has less > validation and requires a bunch of code to parse at runtime. Platform > data is unsurprisingly a good solution to the problem of supplying > platform data. Linus was long time ago against board files. Yet, we have a few old (kinda supported) boards left in the tree. The conversion makes the driver be prepared for the DT conversion when it happens. From maintenance perspective my patch reduced the code under the maintenance, which reduces time spent by both contributors and maintainers on this. AFAIU all what you are moaning about is type checking. Okay, I got it, but we have a lot of other places with similar approach done, e.g. GPIO_LOOKUP*() tables that basically gives something unconnected to the driver without any platform data being involved and you seems to be fine with that: $ git log --oneline --no-merges --grep 'Mark Brown' -- arch/ | grep 'GPIO desc' I randomly took this 366f36e2a ("ASoC: wm1250-ev1: Convert to GPIO descriptors"). Can you tell how it is different to my proposal? > > Also note, after hiding the data structures from that file we open > > the door for the much bigger cleanup, and I have patches already precooked > > (need a bit of time to test, though). > > Perhaps those will motivate a change, as things stand I've not seen what > you're proposing to do here. Okay, let me incorporate those into v3. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel