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 3C23EC433EF for ; Mon, 31 Jan 2022 13:25:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241889AbiAaNZw (ORCPT ); Mon, 31 Jan 2022 08:25:52 -0500 Received: from mga09.intel.com ([134.134.136.24]:53304 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232369AbiAaNZw (ORCPT ); Mon, 31 Jan 2022 08:25:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643635552; x=1675171552; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=PV2NMENejzNWL/eUmut4tFJ0nE85m4L6jACezcDdRYI=; b=BAgjqFXraVnm4S5ETe5f2/FhOeSUKQH/0lZ7JTxxkD65OugcKTYwFYNF 3M2VYv3OwDeOvKT6wjj9Y5wEqFNGKceTqiOAg0cbP+Bl1rXpe2PryPrxz xfx2f1SWr5KH9ZIQ1Zf2tu812F1LCYnUPLkyoLnZjRmMYOMRpxGVZgkur FV9COnv95F3ZptcS4BwbI8rr6AQr1HQQMPtfv/Bfg4QEPqT/K2uVJwfc2 /KnKaVRn4KlE/D5LzDMSGYjTqYQbkQYpetgcTW1q3JHSsg0qlBJo9FCte rLylGHfzHyrzRc/LJM1cJ6P41c6CLsgiLumDMzOovuwBGJuKDfRQ8ug0i w==; X-IronPort-AV: E=McAfee;i="6200,9189,10243"; a="247229308" X-IronPort-AV: E=Sophos;i="5.88,331,1635231600"; d="scan'208";a="247229308" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 05:25:49 -0800 X-IronPort-AV: E=Sophos;i="5.88,331,1635231600"; d="scan'208";a="481748551" Received: from smile.fi.intel.com ([10.237.72.61]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 05:25:45 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nEWfh-00GseD-PN; Mon, 31 Jan 2022 15:24:41 +0200 Date: Mon, 31 Jan 2022 15:24:41 +0200 From: Andy Shevchenko To: Javier Martinez Canillas Cc: Andy Shevchenko , linux-fbdev@vger.kernel.org, Michael Hennerich , Greg Kroah-Hartman , Helge Deller , linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Phillip Potter , Carlis , Lee Jones , Heiner Kallweit Subject: Re: [PATCH v1 1/4] fbtft: Unorphan the driver Message-ID: References: <6e74d4cc-655a-e38e-0856-a59e4e6deb36@redhat.com> <5a3fffc8-b2d8-6ac3-809e-e8e71b66a8ea@redhat.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-fbdev@vger.kernel.org On Mon, Jan 31, 2022 at 03:23:13PM +0200, Andy Shevchenko wrote: > On Mon, Jan 31, 2022 at 01:08:32PM +0100, Javier Martinez Canillas wrote: > > On 1/31/22 12:36, Andy Shevchenko wrote: ... > > I actually added this dependency deliberative. It's true that the driver is using > > the device properties API and so there isn't anything from the properties parsing > > point of view that depends on OF. And the original driver didn't depend on OF. > > > > But the original driver also only would had worked with Device Trees since the > > of_device_id table is the only one that contains the device specific data info. > > > > The i2c_device_id table only listed the devices supported to match, but then it > > would only had worked with the default values that are set by the driver. > > > > So in practice it *does* depend on OF. I'll be happy to drop that dependency if > > you provide an acpi_device_id table to match. > > The code is deceptive and you become to a wrong conclusion. No, the driver > does NOT depend on OF as a matter of fact. The tricky part is the PRP0001 > ACPI PNP ID that allows to reuse it on ACPI-based platforms. > > That said, please drop OF dependency. Side note: 72915994e028 ("video: ssd1307fb: Make use of device properties") -- With Best Regards, Andy Shevchenko