Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp491028pxb; Wed, 6 Oct 2021 09:10:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSuLv+/29CTNF/FT+RFkBzMICovHeCvZwshod1nCbOsr7RG4ia0d4WAF0bcm6sHSltkg4P X-Received: by 2002:aa7:d7c7:: with SMTP id e7mr36605984eds.110.1633536604816; Wed, 06 Oct 2021 09:10:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633536604; cv=none; d=google.com; s=arc-20160816; b=D4xudYvRLWajCRx6W2l+21oaVbUezR9zQhCZvnVLIFAG1GgmEI9J8+ieNxF6Ol4mfm iTP8W1pIqisYuzJVlYHPuOKi6oVd/4GR+gILpNICMh4UglNDJwne8Bj9B1dD/pTQf5j8 7VMZtlKEzP+GDCrWy4G/KnJXNvberVmV/JhSsD7016rQCgeh8tO71GpyHQzx5kWGzb94 AHs4K5CoGgLzfIeYNBc6ZJQ9TWPXS/eixz9EI1dB3XTyBdRngly42N7PXD65wm9jTrDd GjyNd2g8JtP+gUGi6peQUg1LVmlwicxR7aUNtjGVNaRR/J1XoKxjBjUYtM2Vs5ATw2sl jzjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=0+AHrKjUrqqKOfTDfGPnmTK6+erIbei8vMytiUDV6cw=; b=enoU9h4Yg50x5tCzR615R1fNhhfWx+0V6fvWeny7HAhAtLzOMt8zCX1Bt93258Cwv0 gW+naa20skcB+9ZYVpY1VOux2HJB/LeAJRY+HODbHq4Qc8oofU1zZw2XV294Kqh49I6V JvzHxlYi424LtjEN3/2BFHSaCfgatL60pJvAUxaphxHYcqZA1kxfnTzkbEtnbd9/ed1R XT6Isp+w28tDhUJjaT4tpBlYjyNLd1EWVhMN/7fH6K4NuCQQfRyO+d6E7lNiZHwmevgJ LcbwXdJHOfrAd1ghx9DEyzb/5dClQifIeCSuqqfIMqeULX5UKAtiBEn0W1Li5NwjcM5s fmLQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id fx1si28062006ejb.310.2021.10.06.09.09.40; Wed, 06 Oct 2021 09:10:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238124AbhJFQIU (ORCPT + 99 others); Wed, 6 Oct 2021 12:08:20 -0400 Received: from mga14.intel.com ([192.55.52.115]:28648 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232071AbhJFQIP (ORCPT ); Wed, 6 Oct 2021 12:08:15 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10129"; a="226340677" X-IronPort-AV: E=Sophos;i="5.85,352,1624345200"; d="scan'208";a="226340677" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2021 09:01:52 -0700 X-IronPort-AV: E=Sophos;i="5.85,352,1624345200"; d="scan'208";a="439942003" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2021 09:01:51 -0700 Received: from andy by smile with local (Exim 4.95) (envelope-from ) id 1mY9Ma-009FT7-5E; Wed, 06 Oct 2021 19:01:48 +0300 Date: Wed, 6 Oct 2021 19:01:48 +0300 From: Andy Shevchenko To: Daniel Palmer Cc: Greg Kroah-Hartman , linux-serial@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH] serial: 8250_dw: Mark acpi match table as maybe unused Message-ID: References: <20210930124950.3069638-1-daniel@0x0f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 05, 2021 at 09:41:33PM +0900, Daniel Palmer wrote: > On Tue, 5 Oct 2021 at 21:14, Andy Shevchenko > wrote: ... > > > For what it's worth I think the OF ids are a bit wasteful. > > > > Exactly my point, but fixing one driver of zillions does not solve the issue > > in general. > > I looked into making OF ids smaller globally. There seems to be 64 > bytes wasted from the start for the name and type fields as nothing > uses them as far as I can tell. > Then you have the array for the compatible string which is currently > 128 bytes but the longest compatible string in the kernel is less than > 64 from what I can tell. > I understand that it's for future proofing etc. Adding a few hacks to > my kernel to remove the unused fields and reduce the size of the > compatible string saved a few tens of K. > Which isn't a lot but might be the difference between the kernel > fitting in a tiny SPI NOR partition or not. What can you try is to somehow cut the sections during linking phase if you know, that OF=n, or ACPI=n. Not sure how it would work, because basically we will need to replace them with stubs to prevent drivers from crashing. Nevertheless, One terminator entry is much better than full bloated ID table(s)! ... > Anyhow, thankyou for the interesting discussion. I'll just leave this > in my tree for now so I don't have to see the warning. You're welcome! FWIW, I have sent my version of the patch, you are in Cc list there, can you test and confirm that warning is gone for you? -- With Best Regards, Andy Shevchenko