From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (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 E39DD13DBB6 for ; Wed, 24 Apr 2024 10:51:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713955922; cv=none; b=SZIr3xLdceupFDDvn1qo+X2jVfws2BoMa77K8BjDyUpW97pnGQbSbPBsw0Tre5lMmJsO4ev7cxGNJSWU49CIk0DnHgm+y3Mr3RdkLl7BKPBDirHuRvyEISIHQ4eYG3aVTqh453wU87uuWDmF6eNG6aZ/bMSawOQ+8lfX4Dd+Grc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713955922; c=relaxed/simple; bh=oEJnS67rUdPQroVoyX+dqXeH9nIPzaqkkQvNgVBBJdQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rAbwMlz+iIKa1R15hxzvI24ockMqf1AN8hyk4xwsC8Bea7VjjT930xnIU1PHmH3LIQZsGOFkU1EtH+trV65yzs/QI8sm14XHE2WcpF3zDw1xPbE9kFDtG/jAJ1q51Jfrl1kbJo8zfFlg5SHZOEW8kpSfzFjDlVE8v9lx0X71/y8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=nYtZzdaV; arc=none smtp.client-ip=95.215.58.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="nYtZzdaV" Message-ID: <365445ed-8f1d-4c05-90a4-e7867e67977a@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713955917; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=efh86KadtveKwdflYcTs9rm1RrY2uLyDFDzyIYk7Rgk=; b=nYtZzdaVHzAhegl6uBw6q0FR1RFmSoDrwoOcZbLWmXVt+xBTJowI/LGPcJMV/a9QNxdrXo /UKDDpvUaBEL2+FWVnEpYxpRBAsSGUoxMIB2LipsuOyzUlMb/prcCQ0nBUfpHW7ueRKLFD RxQIfj76x1ta8OBiRBFTZD941IbWZro= Date: Wed, 24 Apr 2024 18:51:47 +0800 Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2] software node: Implement device_get_match_data fwnode callback To: Dmitry Baryshkov Cc: Andy Shevchenko , dri-devel@lists.freedesktop.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Scally , Heikki Krogerus , Sakari Ailus , Greg Kroah-Hartman , "Rafael J. Wysocki" References: <20240422164658.217037-1-sui.jingfeng@linux.dev> <22979e28-ed48-467f-a5cf-82be57bcc2f7@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sui Jingfeng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Hi, On 2024/4/24 16:39, Dmitry Baryshkov wrote: > Ok, what is the_bug_ that is being fixed by this patch? I didn't have a way to use that driver under non DT environment, this is the bug. Note: I demanding full features. Both st7735r.c and repaper.c requires additional device property. - For st7735r.c: device_property_read_u32(dev, "rotation", &rotation); - For repaper.c: device_property_read_string(dev, "pervasive,thermal-zone", &thermal_zone) Under non DT environment, those device properties can not be read. Software node backend provided a way. Otherwise, the net results of the patch doesn't meet the description in the commit message. > If you check > the 'submitting-patches.rst', you'll find this phrase as a description > of the Fixes: tag. I have readthe 'submitting-patches.rst', the first sentence tell us that "A Fixes: tag indicates that the patch fixes an issue in a previous commit." So what's the problem? >>>> Hence, before my patch is applied, the two "Make driver OF-independent" patch >>>> have no effect. Using device_get_match_data() itself is exactly*same* with >>>> using of_device_get_match_data() as long as the .device_get_match_data hook is >>>> not implemented. > As far as I can see, repaper correctly handles the case by falling > back to the spi_id. So does st7735r.c. Yeah, this explicitly is the issue. Falling back to other means is robust design, but it explicitly says that the freshly addeddevice_get_match_data() don't works at all under non DT environment. This is the bug, so what's you concern? According to the commit message, the purpose of the introduction of thedevice_get_match_data() is to achieve OF independent. But as you said, it will fall back, then how does the goal "Make driver OF-independent" can be achieved by the patch itself? -- Best regards, Sui