All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: <jiaxun.yang@flygoat.com>, Arnd Bergmann <arnd@arndb.de>,
	Bjorn Helgaas <bhelgaas@google.com>
Cc: <linux-mips@vger.kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Huacai Chen <chenhc@lemote.com>,
	Paul Burton <paulburton@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Kitt <steve@sk2.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Serge Semin <fancer.lancer@gmail.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Daniel Silsby <dansilsby@gmail.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Allison Randal <allison@lohutok.net>,
	Tiezhu Yang <yangtiezhu@loongson.cn>,
	Wei Xu <xuwei5@hisilicon.com>, <linux-kernel@vger.kernel.org>,
	Linuxarm <linuxarm@huawei.com>, Rob Herring <robh@kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 3/4] lib: logic_pio: Introduce MMIO_LOWER_RESERVED
Date: Mon, 27 Apr 2020 12:54:06 +0100	[thread overview]
Message-ID: <e6e3331f-283d-03e8-b23e-41870b547e34@huawei.com> (raw)
In-Reply-To: <42432F7C-D859-48B4-9547-A61BD22EFEEF@flygoat.com>

On 27/04/2020 12:03, Jiaxun Yang wrote:
> 
> 
> 于 2020年4月27日 GMT+08:00 下午6:43:09, John Garry <john.garry@huawei.com> 写到:
>> On 26/04/2020 12:47, Jiaxun Yang wrote:
>>> That would allow platforms reserve some lower address in PIO MMIO range
>>> to deal with legacy drivers with hardcoded I/O ports that can't be
>>> managed by logic_pio.
>>
>> Hi,
>>
>> Is there some reason why the logic_pio code cannot be improved to handle
>> these devices at these "fixed" addresses? Or do you have a plan to
>> improve it? We already support fixed bus address devices in the INDIRECT
>> IO region.
> 
> Hi,
> 
> The issue about "Fixed Address" is we can't control the ioport
> That driver used to operate devices.
> So any attempt to resolve it in logic_pio seems impossible.
> 
> Currently we have i8259, i8042, piix4_smbus, mc146818 rely on this assumption.

Right, and from glancing at a couple of drivers you mentioned, if we 
were to register a logic pio region for that legacy region, there does 
not seem to be an easy place to fixup to use logic pio addresses (for 
those devices). They use hardcoded values. However if all those drivers 
were mips specific, you could fixup those drivers to use logic_pio 
addresses today through some macro. But not sure on that.

So, going back to your change, I have a dilemma wondering whether you 
should still register a logic pio region for the legacy region instead 
of the carveout reservation, but ensure it is the first region 
registered, such that logic pio address base is 0 and no translation is 
required. At least then you have a region registered and it shows in 
/proc/ioports, but then this whole thing becomes a bit fragile.

Maybe Arnd or Bjorn have an opinion on this.

Thanks,
John


> 
> My plan is after getting this part merged, I'm going to work on a ISA Host bridge driver,
> then convert device drivers into logic_pio and Devicetree based driver step by step.
> 
> Finally when we nologner have any legacy driver, we can safely remove this reserved
> range.
> 
> Thanks.
> 
> 
>>
>> Carving out a region of IO space is less than ideal.
>>
>> Thanks,
>> John
>>
>>>
>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>>> ---
>>>    lib/logic_pio.c | 6 +++++-
>>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/logic_pio.c b/lib/logic_pio.c
>>> index f511a99bb389..57fff1cb7063 100644
>>> --- a/lib/logic_pio.c
>>> +++ b/lib/logic_pio.c
>>> @@ -20,6 +20,10 @@
>>>    static LIST_HEAD(io_range_list);
>>>    static DEFINE_MUTEX(io_range_mutex);
>>>    
>>> +#ifndef MMIO_LOWER_RESERVED
>>> +#define MMIO_LOWER_RESERVED	0
>>> +#endif
>>> +
>>>    /* Consider a kernel general helper for this */
>>>    #define in_range(b, first, len)        ((b) >= (first) && (b) < (first) + (len))
>>>    
>>> @@ -36,7 +40,7 @@ int logic_pio_register_range(struct logic_pio_hwaddr *new_range)
>>>    	struct logic_pio_hwaddr *range;
>>>    	resource_size_t start;
>>>    	resource_size_t end;
>>> -	resource_size_t mmio_end = 0;
>>> +	resource_size_t mmio_end = MMIO_LOWER_RESERVED;
>>>    	resource_size_t iio_sz = MMIO_UPPER_LIMIT;
>>>    	int ret = 0;
>>>    
>>>
>>
> 


WARNING: multiple messages have this Message-ID (diff)
From: John Garry <john.garry@huawei.com>
To: jiaxun.yang@flygoat.com, Arnd Bergmann <arnd@arndb.de>,
	Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-mips@vger.kernel.org,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Huacai Chen <chenhc@lemote.com>,
	Paul Burton <paulburton@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Kitt <steve@sk2.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Serge Semin <fancer.lancer@gmail.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Daniel Silsby <dansilsby@gmail.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Allison Randal <allison@lohutok.net>,
	Tiezhu Yang <yangtiezhu@loongson.cn>,
	Wei Xu <xuwei5@hisilicon.com>
Subject: Re: [PATCH 3/4] lib: logic_pio: Introduce MMIO_LOWER_RESERVED
Date: Mon, 27 Apr 2020 12:54:06 +0100	[thread overview]
Message-ID: <e6e3331f-283d-03e8-b23e-41870b547e34@huawei.com> (raw)
In-Reply-To: <42432F7C-D859-48B4-9547-A61BD22EFEEF@flygoat.com>

On 27/04/2020 12:03, Jiaxun Yang wrote:
> 
> 
> 于 2020年4月27日 GMT+08:00 下午6:43:09, John Garry <john.garry@huawei.com> 写到:
>> On 26/04/2020 12:47, Jiaxun Yang wrote:
>>> That would allow platforms reserve some lower address in PIO MMIO range
>>> to deal with legacy drivers with hardcoded I/O ports that can't be
>>> managed by logic_pio.
>>
>> Hi,
>>
>> Is there some reason why the logic_pio code cannot be improved to handle
>> these devices at these "fixed" addresses? Or do you have a plan to
>> improve it? We already support fixed bus address devices in the INDIRECT
>> IO region.
> 
> Hi,
> 
> The issue about "Fixed Address" is we can't control the ioport
> That driver used to operate devices.
> So any attempt to resolve it in logic_pio seems impossible.
> 
> Currently we have i8259, i8042, piix4_smbus, mc146818 rely on this assumption.

Right, and from glancing at a couple of drivers you mentioned, if we 
were to register a logic pio region for that legacy region, there does 
not seem to be an easy place to fixup to use logic pio addresses (for 
those devices). They use hardcoded values. However if all those drivers 
were mips specific, you could fixup those drivers to use logic_pio 
addresses today through some macro. But not sure on that.

So, going back to your change, I have a dilemma wondering whether you 
should still register a logic pio region for the legacy region instead 
of the carveout reservation, but ensure it is the first region 
registered, such that logic pio address base is 0 and no translation is 
required. At least then you have a region registered and it shows in 
/proc/ioports, but then this whole thing becomes a bit fragile.

Maybe Arnd or Bjorn have an opinion on this.

Thanks,
John


> 
> My plan is after getting this part merged, I'm going to work on a ISA Host bridge driver,
> then convert device drivers into logic_pio and Devicetree based driver step by step.
> 
> Finally when we nologner have any legacy driver, we can safely remove this reserved
> range.
> 
> Thanks.
> 
> 
>>
>> Carving out a region of IO space is less than ideal.
>>
>> Thanks,
>> John
>>
>>>
>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>>> ---
>>>    lib/logic_pio.c | 6 +++++-
>>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/logic_pio.c b/lib/logic_pio.c
>>> index f511a99bb389..57fff1cb7063 100644
>>> --- a/lib/logic_pio.c
>>> +++ b/lib/logic_pio.c
>>> @@ -20,6 +20,10 @@
>>>    static LIST_HEAD(io_range_list);
>>>    static DEFINE_MUTEX(io_range_mutex);
>>>    
>>> +#ifndef MMIO_LOWER_RESERVED
>>> +#define MMIO_LOWER_RESERVED	0
>>> +#endif
>>> +
>>>    /* Consider a kernel general helper for this */
>>>    #define in_range(b, first, len)        ((b) >= (first) && (b) < (first) + (len))
>>>    
>>> @@ -36,7 +40,7 @@ int logic_pio_register_range(struct logic_pio_hwaddr *new_range)
>>>    	struct logic_pio_hwaddr *range;
>>>    	resource_size_t start;
>>>    	resource_size_t end;
>>> -	resource_size_t mmio_end = 0;
>>> +	resource_size_t mmio_end = MMIO_LOWER_RESERVED;
>>>    	resource_size_t iio_sz = MMIO_UPPER_LIMIT;
>>>    	int ret = 0;
>>>    
>>>
>>
> 

WARNING: multiple messages have this Message-ID (diff)
From: John Garry <john.garry@huawei.com>
To: jiaxun.yang@flygoat.com, Arnd Bergmann <arnd@arndb.de>,
	Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-mips@vger.kernel.org,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Huacai Chen <chenhc@lemote.com>,
	Paul Burton <paulburton@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Kitt <steve@sk2.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Serge Semin <fancer.lancer@gmail.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Daniel Silsby <dansilsby@gmail.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Allison Randal <allison@lohutok.net>,
	Tiezhu Yang <yangtiezhu@loongson.cn>,
	Wei Xu <xuwei5@hisilicon.com>,
	linux-kernel@vger.kernel.org, Linuxarm <linuxarm@huawei.com>,
	Rob Herring <robh@kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 3/4] lib: logic_pio: Introduce MMIO_LOWER_RESERVED
Date: Mon, 27 Apr 2020 12:54:06 +0100	[thread overview]
Message-ID: <e6e3331f-283d-03e8-b23e-41870b547e34@huawei.com> (raw)
Message-ID: <20200427115406.69lkWYqAxWNDxNdSp71QsZ-XEk2-w0UvVAsA44AxO4Y@z> (raw)
In-Reply-To: <42432F7C-D859-48B4-9547-A61BD22EFEEF@flygoat.com>

On 27/04/2020 12:03, Jiaxun Yang wrote:
> 
> 
> 于 2020年4月27日 GMT+08:00 下午6:43:09, John Garry <john.garry@huawei.com> 写到:
>> On 26/04/2020 12:47, Jiaxun Yang wrote:
>>> That would allow platforms reserve some lower address in PIO MMIO range
>>> to deal with legacy drivers with hardcoded I/O ports that can't be
>>> managed by logic_pio.
>>
>> Hi,
>>
>> Is there some reason why the logic_pio code cannot be improved to handle
>> these devices at these "fixed" addresses? Or do you have a plan to
>> improve it? We already support fixed bus address devices in the INDIRECT
>> IO region.
> 
> Hi,
> 
> The issue about "Fixed Address" is we can't control the ioport
> That driver used to operate devices.
> So any attempt to resolve it in logic_pio seems impossible.
> 
> Currently we have i8259, i8042, piix4_smbus, mc146818 rely on this assumption.

Right, and from glancing at a couple of drivers you mentioned, if we 
were to register a logic pio region for that legacy region, there does 
not seem to be an easy place to fixup to use logic pio addresses (for 
those devices). They use hardcoded values. However if all those drivers 
were mips specific, you could fixup those drivers to use logic_pio 
addresses today through some macro. But not sure on that.

So, going back to your change, I have a dilemma wondering whether you 
should still register a logic pio region for the legacy region instead 
of the carveout reservation, but ensure it is the first region 
registered, such that logic pio address base is 0 and no translation is 
required. At least then you have a region registered and it shows in 
/proc/ioports, but then this whole thing becomes a bit fragile.

Maybe Arnd or Bjorn have an opinion on this.

Thanks,
John


> 
> My plan is after getting this part merged, I'm going to work on a ISA Host bridge driver,
> then convert device drivers into logic_pio and Devicetree based driver step by step.
> 
> Finally when we nologner have any legacy driver, we can safely remove this reserved
> range.
> 
> Thanks.
> 
> 
>>
>> Carving out a region of IO space is less than ideal.
>>
>> Thanks,
>> John
>>
>>>
>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>>> ---
>>>    lib/logic_pio.c | 6 +++++-
>>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/logic_pio.c b/lib/logic_pio.c
>>> index f511a99bb389..57fff1cb7063 100644
>>> --- a/lib/logic_pio.c
>>> +++ b/lib/logic_pio.c
>>> @@ -20,6 +20,10 @@
>>>    static LIST_HEAD(io_range_list);
>>>    static DEFINE_MUTEX(io_range_mutex);
>>>    
>>> +#ifndef MMIO_LOWER_RESERVED
>>> +#define MMIO_LOWER_RESERVED	0
>>> +#endif
>>> +
>>>    /* Consider a kernel general helper for this */
>>>    #define in_range(b, first, len)        ((b) >= (first) && (b) < (first) + (len))
>>>    
>>> @@ -36,7 +40,7 @@ int logic_pio_register_range(struct logic_pio_hwaddr *new_range)
>>>    	struct logic_pio_hwaddr *range;
>>>    	resource_size_t start;
>>>    	resource_size_t end;
>>> -	resource_size_t mmio_end = 0;
>>> +	resource_size_t mmio_end = MMIO_LOWER_RESERVED;
>>>    	resource_size_t iio_sz = MMIO_UPPER_LIMIT;
>>>    	int ret = 0;
>>>    
>>>
>>
> 

  reply	other threads:[~2020-04-27 11:54 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-26 11:47 [PATCH 0/4] MIPS: Loongson64: Use logic_pio Jiaxun Yang
2020-04-26 11:47 ` [PATCH 1/4] MIPS: Massage address spaces headers Jiaxun Yang
2020-04-26 11:47 ` [PATCH 2/4] MIPS: Introduce PCI_IO_VMMAP Jiaxun Yang
2020-04-26 11:47 ` [PATCH 3/4] lib: logic_pio: Introduce MMIO_LOWER_RESERVED Jiaxun Yang
2020-04-27 10:43   ` John Garry
2020-04-27 11:03     ` Jiaxun Yang
2020-04-27 11:54       ` John Garry [this message]
2020-04-27 11:54         ` John Garry
2020-04-27 11:54         ` John Garry
2020-04-27 12:21         ` Jiaxun Yang
2020-04-27 12:21           ` Jiaxun Yang
2020-04-27 12:21           ` Jiaxun Yang
2020-04-26 11:47 ` [PATCH 4/4] MIPS: Loongson64: Enable PCI_IO_VMMAP Jiaxun Yang
2020-04-30  0:57 ` [PATCH v3 1/3] MIPS: Move VMALLOC_START into spaces.h Jiaxun Yang
2020-04-30  0:57   ` [PATCH v3 2/3] MIPS: Introduce PCI_IO_VMMAP Jiaxun Yang
2020-04-30  0:57   ` [PATCH v3 3/3] MIPS: Loongson64: Enable PCI_IO_VMMAP Jiaxun Yang
2020-05-08 11:44 ` [PATCH RESEND v3 1/3] MIPS: Move VMALLOC_START into spaces.h Jiaxun Yang
2020-05-08 11:44   ` [PATCH RESEND v3 2/3] MIPS: Introduce PCI_IO_VMMAP Jiaxun Yang
2020-05-08 16:11     ` Thomas Bogendoerfer
2020-05-08 16:22       ` Jiaxun Yang
2020-05-08 16:52         ` Thomas Bogendoerfer
2020-05-08 17:09           ` Jiaxun Yang
2020-05-14 14:21             ` Thomas Bogendoerfer
2020-05-14 14:56               ` Jiaxun Yang
2020-05-14 13:20     ` Jiaxun Yang
2020-05-08 11:44   ` [PATCH RESEND v3 3/3] MIPS: Loongson64: Enable PCI_IO_VMMAP Jiaxun Yang
2021-01-13 18:02     ` logical PIO code for mips question (was Re: [PATCH RESEND v3 3/3] MIPS: Loongson64: Enable PCI_IO_VMMAP) John Garry
2021-01-14  0:13       ` Jiaxun Yang
2021-01-14  9:18         ` John Garry
2021-01-14 11:10           ` Jiaxun Yang
2021-01-14 11:20             ` John Garry

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=e6e3331f-283d-03e8-b23e-41870b547e34@huawei.com \
    --to=john.garry@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=allison@lohutok.net \
    --cc=anshuman.khandual@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=chenhc@lemote.com \
    --cc=dansilsby@gmail.com \
    --cc=fancer.lancer@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mark.tomlinson@alliedtelesis.co.nz \
    --cc=ndesaulniers@google.com \
    --cc=paul@crapouillou.net \
    --cc=paulburton@kernel.org \
    --cc=robh@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=steve@sk2.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=xuwei5@hisilicon.com \
    --cc=yangtiezhu@loongson.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.