mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
	Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	iommu@lists.linux-foundation.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 11/20] memory: tegra: Use of_device_get_match_data()
Date: Mon, 24 Sep 2018 21:39:43 +0300	[thread overview]
Message-ID: <dcf439a0-249c-ff9f-292d-c807a736672a@gmail.com> (raw)
In-Reply-To: <20180924101354.GH21032@ulmo>

On 9/24/18 1:13 PM, Thierry Reding wrote:
> On Mon, Sep 24, 2018 at 03:41:44AM +0300, Dmitry Osipenko wrote:
>> There is no need to match device with the DT node since it was already
>> matched, use of_device_get_match_data() helper to get the match-data.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>>  drivers/memory/tegra/mc.c | 10 ++--------
>>  1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
>> index 5454ffe5b2e0..cdc33f93cf7c 100644
>> --- a/drivers/memory/tegra/mc.c
>> +++ b/drivers/memory/tegra/mc.c
>> @@ -11,8 +11,7 @@
>>  #include <linux/interrupt.h>
>>  #include <linux/kernel.h>
>>  #include <linux/module.h>
>> -#include <linux/of.h>
>> -#include <linux/platform_device.h>
> 
> It's better not to remove these two because the code still uses
> functions declared in them. If ever we were going to remove code using
> linux/of_device.h and then remove the linux/of_device.h include, we'd
> break the build and have to reintroduce the includes.

That doesn't sound like a good argument. You're way too picky here ;)

> The same would happen if linux/of_device.h were ever to stop including
> linux/platform_device.h or linux/of.h. That may sound unlikely, but it
> has happened in the past with other includes. It can also happen that
> some restructuring takes place in some headers that is not so obvious
> and then things can still start falling apart miles away.

Restructuring will be somebody else problem. Not sure that we really
should care about it, I think it is unnecessary. But since you're
insisting..

  reply	other threads:[~2018-09-24 18:39 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-24  0:41 [PATCH v4 00/20] IOMMU: Tegra GART driver clean up and optimization Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 01/20] iommu/tegra: gart: Remove pr_fmt and clean up includes Dmitry Osipenko
2018-09-24 10:02   ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 02/20] iommu/tegra: gart: Clean up driver probe errors handling Dmitry Osipenko
2018-09-24 10:02   ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 03/20] iommu/tegra: gart: Ignore devices without IOMMU phandle in DT Dmitry Osipenko
2018-09-24 10:05   ` Thierry Reding
2018-09-24 18:41     ` Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 04/20] iommu: Introduce iotlb_sync_map callback Dmitry Osipenko
2018-09-24 10:06   ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 05/20] iommu/tegra: gart: Optimize mapping / unmapping performance Dmitry Osipenko
2018-09-24 10:07   ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 06/20] dt-bindings: memory: tegra: Squash tegra20-gart into tegra20-mc Dmitry Osipenko
2018-09-24  9:55   ` Thierry Reding
2018-09-27 18:41     ` Rob Herring
2018-09-27 18:41   ` Rob Herring
2018-09-24  0:41 ` [PATCH v4 07/20] ARM: dts: tegra20: Update Memory Controller node to the new binding Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 08/20] memory: tegra: Don't invoke Tegra30+ specific memory timing setup on Tegra20 Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 09/20] memory: tegra: Adapt to Tegra20 device-tree binding changes Dmitry Osipenko
2018-09-24 10:02   ` Thierry Reding
2018-09-24 13:22     ` Dmitry Osipenko
2018-09-25 12:16       ` Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 10/20] memory: tegra: Read client ID on GART page fault Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 11/20] memory: tegra: Use of_device_get_match_data() Dmitry Osipenko
2018-09-24 10:13   ` Thierry Reding
2018-09-24 18:39     ` Dmitry Osipenko [this message]
2018-09-25 10:00       ` Thierry Reding
2018-09-25 13:53         ` Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 12/20] iommu/tegra: gart: Integrate with Memory Controller driver Dmitry Osipenko
2018-09-24 10:23   ` Thierry Reding
2018-09-24 18:22     ` Dmitry Osipenko
2018-09-25 10:02       ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 13/20] iommu/tegra: gart: Fix spinlock recursion Dmitry Osipenko
2018-09-24 10:49   ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 14/20] iommu/tegra: gart: Fix NULL pointer dereference Dmitry Osipenko
2018-09-24 10:49   ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 15/20] iommu/tegra: gart: Allow only one active domain at a time Dmitry Osipenko
2018-09-24 10:50   ` Thierry Reding
2018-09-24  0:41 ` [PATCH v4 16/20] iommu/tegra: gart: Don't use managed resources Dmitry Osipenko
2018-09-24 10:52   ` Thierry Reding
2018-09-24 18:57     ` Dmitry Osipenko
2018-09-25 10:03       ` Thierry Reding
2018-09-25 13:41         ` Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 17/20] iommu/tegra: gart: Prepend error/debug messages with "GART:" Dmitry Osipenko
2018-09-24 10:57   ` Thierry Reding
2018-09-24 18:09     ` Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 18/20] iommu/tegra: gart: Don't detach devices from inactive domains Dmitry Osipenko
2018-09-24 11:00   ` Thierry Reding
2018-09-24 18:05     ` Dmitry Osipenko
2018-09-25 10:04       ` Thierry Reding
2018-09-25 13:41         ` Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 19/20] iommu/tegra: gart: Simplify clients-tracking code Dmitry Osipenko
2018-09-24 11:10   ` Thierry Reding
2018-09-24 17:50     ` Dmitry Osipenko
2018-09-25 10:09       ` Thierry Reding
2018-09-25 13:47         ` Dmitry Osipenko
2018-09-24  0:41 ` [PATCH v4 20/20] iommu/tegra: gart: Perform code refactoring Dmitry Osipenko
2018-09-24 11:34   ` Thierry Reding
2018-09-24 17:11     ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dcf439a0-249c-ff9f-292d-c807a736672a@gmail.com \
    --to=digetx@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome