From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D64229CA for ; Mon, 31 Jan 2022 13:25:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643635549; x=1675171549; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=PV2NMENejzNWL/eUmut4tFJ0nE85m4L6jACezcDdRYI=; b=ZD7uVo38BRZ2AeTJHkBsqwWJt1ypKa/Y4aH/5XKp/ONxqHjjvYFDV0dt H6vP8BWahbkV9l00KNtMcERcRXiSjw+oVsrwXrn8EGtdRYk5AVupZKfsX e+vaGtOOk/jrJlQIrSFJpkFms9Vn7ev6EJ49C/8n+ma3UTFmXcxY++1Tt C0bG+rgso+RqxGHaQvnJZIczKZd+cm0wl/XCGCv2FN8V2frALl/f8cjqi 88S4gTf5SHwiRd33RCsDYW+6MY46/dDPL87RcaqbcQgNRe6PdA2EuPCEE s4o5Pk3E3FUCycfjLjZGqhLFkZH4OJmdxiUYcSYIK03KzemGzurGcxTpC A==; X-IronPort-AV: E=McAfee;i="6200,9189,10243"; a="247412839" X-IronPort-AV: E=Sophos;i="5.88,331,1635231600"; d="scan'208";a="247412839" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 05:25:48 -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> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 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