linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gabriele Paoloni <gabriele.paoloni@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"liviu.dudau@arm.com" <liviu.dudau@arm.com>,
	Linuxarm <linuxarm@huawei.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"xuwei (O)" <xuwei5@hisilicon.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	"T homas Petazzoni" <thomas.petazzo.ni@free-electrons.com>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"minyard@acm.org" <minyard@acm.org>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	John Garry <john.garry@huawei.com>,
	"olof@lixom.net" <olof@lixom.net>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"bhelgaas@go og le.com" <bhelgaas@google.com>,
	"kantyzc@163.com" <kantyzc@163.com>,
	"zhichang.yuan 02@gmail.com" <zhichang.yuan02@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Yuanzhichang <yuanzhichang@hisilicon.com>,
	"zourongrong@gmail.com" <zourongrong@gmail.com>
Subject: RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
Date: Fri, 25 Nov 2016 16:27:40 +0000	[thread overview]
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1F93B05D@lhreml507-mbx> (raw)
In-Reply-To: <107039805.6PaPa1fbx1@wuerfel>

Hi Arnd

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 25 November 2016 12:04
> To: Gabriele Paoloni
> Cc: linux-arm-kernel@lists.infradead.org; mark.rutland@arm.com;
> catalin.marinas@arm.com; linux-pci@vger.kernel.org;
> liviu.dudau@arm.com; Linuxarm; lorenzo.pieralisi@arm.com; xuwei (O);
> Jason Gunthorpe; T homas Petazzoni; linux-serial@vger.kernel.org;
> benh@kernel.crashing.org; devicetree@vger.kernel.org; minyard@acm.org;
> will.deacon@arm.com; John Garry; olof@lixom.net; robh+dt@kernel.org;
> bhelgaas@go og le.com; kantyzc@163.com; zhichang.yuan 02@gmail.com;
> linux-kernel@vger.kernel.org; Yuanzhichang; zourongrong@gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
> 
> On Friday, November 25, 2016 8:46:11 AM CET Gabriele Paoloni wrote:
> > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > >
> > > On Wednesday, November 23, 2016 6:07:11 PM CET Arnd Bergmann wrote:
> > > > On Wednesday, November 23, 2016 3:22:33 PM CET Gabriele Paoloni
> > > wrote:
> > > > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > > > > On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni
> > >  /*
> > > @@ -549,9 +548,14 @@ static int of_translate_one(struct device_node
> > > *parent, struct of_bus *bus,
> > >   * that translation is impossible (that is we are not dealing with
> a
> > > value
> > >   * that can be mapped to a cpu physical address). This is not
> really
> > > specified
> > >   * that way, but this is traditionally the way IBM at least do
> things
> > > + *
> > > + * Whenever the translation fails, the *host pointer will be set
> to
> > > the
> > > + * device that lacks a tranlation, and the return code is relative
> to
> > > + * that node.
> >
> > This seems to be wrong to me. We are abusing of the error conditions.
> > So effectively if there is a buggy DT for an IO resource we end up
> > assuming that we are using a special IO device with unmapped
> addresses.
> >
> > The patch at the bottom apply on top of this one and I think is a
> more
> > reasonable approach
> 
> It was meant as a logical extension to the existing interface,
> translating the address as far as we can, and reporting back
> how far we got.
> 
> Maybe we can return 'of_root' by instead of NULL to signify
> that we have converted all the way to the root of the DT?
> That would make it more consistent, but slightly more complicated
> for the common case.

Mmm not sure really...the point is that now the **host parameter is
used both as a flag and also in of_translate_ioport...the problem
that I see is where we set the "host" parameter...I have a proposal
below...

[...]

> pci_bus_alloc_resource(struct
> > > pci_bus *bus,
> > >  			void *alignf_data);
> 
> [Many lines of reply trimmed here, please make sure you don't quote too
> much context when you reply, it's really annoying to read through
> it otherwise]

Sorry! I'll take care of this in the future...

> 
> >  /*
> > + * of_isa_indirect_io - get the IO address from some isa reg
> property value.
> > + *	For some isa/lpc devices, no ranges property in ancestor node.
> > + *	The device addresses are described directly in their regs
> property.
> > + *	This fixup function will be called to get the IO address of
> isa/lpc
> > + *	devices when the normal of_translation failed.
> > + *
> > + * @parent:	points to the parent dts node;
> > + * @bus:		points to the of_bus which can be used to parse
> address;
> > + * @addr:	the address from reg property;
> > + * @na:		the address cell counter of @addr;
> > + * @presult:	store the address paresed from @addr;
> > + *
> > + * return 1 when successfully get the I/O address;
> > + * 0 will return for some failures.
> > + */
> > +static int of_get_isa_indirect_io(struct device_node *parent,
> > +				struct of_bus *bus, __be32 *addr,
> > +				int na, u64 *presult)
> > +{
> > +	unsigned int flags;
> > +	unsigned int rlen;
> > +
> > +	/* whether support indirectIO */
> > +	if (!indirect_io_enabled())
> > +		return 0;
> > +
> > +	if (!of_bus_isa_match(parent))
> > +		return 0;
> > +
> > +	flags = bus->get_flags(addr);
> > +	if (!(flags & IORESOURCE_IO))
> > +		return 0;
> > +
> > +	/* there is ranges property, apply the normal translation
> directly. */
> > +	if (of_get_property(parent, "ranges", &rlen))
> > +		return 0;
> > +
> > +	*presult = of_read_number(addr + 1, na - 1);
> > +	/* this fixup is only valid for specific I/O range. */
> > +	return addr_is_indirect_io(*presult);
> > +}
> 
> Right, this would work. The reason I didn't go down this route is
> that I wanted to keep it generic enough to allow doing the same
> for PCI host bridges with a nonlinear mapping of the I/O space.
> 
> There isn't really anything special about ISA here, other than the
> fact that the one driver that needs it happens to be for ISA rather
> than PCI.

Yes I see your point please consider the patch at the bottom...

> 
> > +/*
> >   * Translate an address from the device-tree into a CPU physical
> address,
> >   * this walks up the tree and applies the various bus mappings on
> the
> >   * way.
> > @@ -600,14 +643,23 @@ static u64 __of_translate_address(struct
> device_node *dev,
> >  			result = of_read_number(addr, na);
> >  			break;
> >  		}
> > +		/*
> > +		 * For indirectIO device which has no ranges property, get
> > +		 * the address from reg directly.
> > +		 */
> > +		if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
> > +			pr_debug("isa indirectIO matched(%s)..addr =
> 0x%llx\n",
> > +				of_node_full_name(dev), result);
> > +			*host = of_node_get(parent);
> > +			break;
> > +		}
> >
> 
> If we do the special case for ISA as you suggest above, I would still
> want
> to keep it in of_translate_ioport(), I think that's a useful change by
> itself in my patch.

This comes without saying...the patch I proposed here already applied on
top of your changes and, in fact, you can see that I set 
"*host = of_node_get(parent);" above in my patch to be used by 
of_translate_ioport()
 
> 
> 	Arnde
> 
> 
> 

Below I have reworked my patch (that still applies on top of your one) to
make it not ISA specific.
Notice that of_translate_ioport() still stands and that in addr_is_indirect_io()
we make sure the bus address to be in the bus address range that the special
host operates on...

---
 drivers/of/address.c       | 56 ++++++++++++++++++++++++++++++++++++++++++++--
 include/linux/of_address.h | 17 ++++++++++++++
 2 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5decaba..2b34931 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -540,6 +540,48 @@ static u64 of_translate_one(struct device_node *parent, struct of_bus *bus,
 }
 
 /*
+ * of_get_indirect_io - get the IO address from some reg property value.
+ *	For some special host devices, we have no ranges property node and
+ *	we directly use the bus addresses of the children regs property.
+ *	This fixup function will be called to get the IO address of isa/lpc
+ *	devices when the normal of_translation failed.
+ *
+ * @parent:	points to the parent dts node;
+ * @bus:		points to the of_bus which can be used to parse address;
+ * @addr:	the address from reg property;
+ * @na:		the address cell counter of @addr;
+ * @presult:	store the address parsed from @addr;
+ *
+ * return 1 when successfully get the I/O address;
+ * 0 will return for some failures.
+ */
+static int of_get_indirect_io(struct device_node *parent,
+				struct of_bus *bus, __be32 *addr,
+				int na, u64 *presult)
+{
+	unsigned int flags;
+	unsigned int rlen;
+
+	/* whether support indirectIO */
+	if (!indirect_io_enabled())
+		return 0;
+
+	flags = bus->get_flags(addr);
+	if (!(flags & IORESOURCE_IO))
+		return 0;
+
+	/* there is ranges property, apply the normal translation directly. */
+	if (of_get_property(parent, "ranges", &rlen))
+		return 0;
+
+	*presult = of_read_number(addr + 1, na - 1);
+
+	/* check if the bus address falls into the range of
+	 * the special host device*/
+	return addr_is_indirect_io(*presult);
+}
+
+/*
  * Translate an address from the device-tree into a CPU physical address,
  * this walks up the tree and applies the various bus mappings on the
  * way.
@@ -601,13 +643,23 @@ static u64 __of_translate_address(struct device_node *dev,
 			break;
 		}
 
+		/*
+		 * For indirectIO device which has no ranges property, get
+		 * the address from reg directly.
+		 */
+		if (of_get_indirect_io(dev, bus, addr, na, &result)) {
+			pr_debug("isa indirectIO matched(%s)..addr = 0x%llx\n",
+				of_node_full_name(dev), result);
+			*host = of_node_get(parent);
+			break;
+		}
+
 		/* Get new parent bus and counts */
 		pbus = of_match_bus(parent);
 		pbus->count_cells(dev, &pna, &pns);
 		if (!OF_CHECK_COUNTS(pna, pns)) {
-			pr_debug("Bad cell count for %s\n",
+			pr_err("Bad cell count for %s\n",
 				 of_node_full_name(dev));
-			*host = of_node_get(parent);
 			break;
 		}
 
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 3786473..14848d8 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -24,6 +24,23 @@ struct of_pci_range {
 #define for_each_of_pci_range(parser, range) \
 	for (; of_pci_range_parser_one(parser, range);)
 
+#ifndef indirect_io_enabled
+#define indirect_io_enabled indirect_io_enabled
+static inline bool indirect_io_enabled(void)
+{
+	return false;
+}
+#endif
+
+#ifndef addr_is_indirect_io
+#define addr_is_indirect_io addr_is_indirect_io
+static inline int addr_is_indirect_io(u64 taddr)
+{
+	return 0;
+}
+#endif
+
+
 /* Translate a DMA address from device space to CPU space */
 extern u64 of_translate_dma_address(struct device_node *dev,
 				    const __be32 *in_addr);
-- 
2.7.4

  reply	other threads:[~2016-11-25 16:29 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-08  3:47 [PATCH V5 0/3] ARM64 LPC: legacy ISA I/O support zhichang.yuan
2016-11-08  3:47 ` [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced zhichang.yuan
2016-11-08 12:03   ` Mark Rutland
2016-11-08 16:09     ` Arnd Bergmann
2016-11-08 16:15       ` Arnd Bergmann
2016-11-08 23:16     ` Benjamin Herrenschmidt
2016-11-10  8:33       ` zhichang.yuan
2016-11-10 11:22       ` Mark Rutland
2016-11-10 19:32         ` Benjamin Herrenschmidt
2016-11-11 10:07           ` zhichang.yuan
2016-11-18  9:20             ` Arnd Bergmann
2016-11-18 11:12               ` zhichang.yuan
2016-11-18 11:38                 ` Arnd Bergmann
2016-11-21 12:58       ` John Garry
2016-11-08 16:12   ` Will Deacon
2016-11-08 16:33     ` John Garry
2016-11-08 16:49       ` Will Deacon
2016-11-08 17:05         ` John Garry
2016-11-08 22:35         ` Arnd Bergmann
2016-11-09 11:29           ` John Garry
2016-11-09 21:33             ` Arnd Bergmann
2016-12-22  8:15   ` Ming Lei
2016-12-23  1:43     ` zhichang.yuan
2016-12-23  7:24       ` Ming Lei
2017-01-06 11:43     ` Arnd Bergmann
2016-11-08  3:47 ` [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA zhichang.yuan
2016-11-08  5:17   ` kbuild test robot
2016-11-08  5:27   ` kbuild test robot
2016-11-08 11:49   ` Mark Rutland
2016-11-08 16:19     ` Arnd Bergmann
2016-11-08 17:10       ` Mark Rutland
2016-11-09 13:54       ` One Thousand Gnomes
2016-11-09 14:51         ` Gabriele Paoloni
2016-11-09 21:38         ` Arnd Bergmann
2016-11-14 11:11           ` One Thousand Gnomes
2016-11-18  9:22             ` Arnd Bergmann
2016-11-08 23:12     ` Benjamin Herrenschmidt
2016-11-09 11:20       ` Mark Rutland
2016-11-10  7:08         ` Benjamin Herrenschmidt
2016-11-09 11:39   ` liviu.dudau
2016-11-09 16:16     ` Gabriele Paoloni
2016-11-09 16:50       ` liviu.dudau
2016-11-10  6:24         ` zhichang.yuan
2016-11-10 16:06         ` Gabriele Paoloni
2016-11-11 10:37           ` liviu.dudau
2016-11-08  3:47 ` [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 zhichang.yuan
2016-11-08  6:11   ` kbuild test robot
2016-11-08 16:24   ` Arnd Bergmann
2016-11-09 12:10     ` Gabriele Paoloni
2016-11-09 21:34       ` Arnd Bergmann
2016-11-10  6:40         ` zhichang.yuan
2016-11-10  9:12           ` Arnd Bergmann
2016-11-10 12:36             ` zhichang.yuan
2016-11-18 11:46               ` Arnd Bergmann
2016-11-10 15:36             ` Gabriele Paoloni
2016-11-10 16:07               ` Arnd Bergmann
2016-11-11 10:09                 ` zhichang.yuan
2016-11-11 10:48                 ` liviu.dudau
2016-11-11 13:39                 ` Gabriele Paoloni
2016-11-11 14:45                   ` liviu.dudau
2016-11-11 15:53                     ` Gabriele Paoloni
2016-11-11 18:16                       ` liviu.dudau
2016-11-14  8:26                         ` Gabriele Paoloni
2016-11-14 11:26                           ` liviu.dudau
2016-11-18 10:17                             ` Arnd Bergmann
2016-11-18 12:07                               ` Gabriele Paoloni
2016-11-18 12:24                                 ` Arnd Bergmann
2016-11-18 12:53                                   ` Gabriele Paoloni
2016-11-18 13:42                                     ` Arnd Bergmann
2016-11-18 16:18                                       ` Gabriele Paoloni
2016-11-18 16:34                                         ` Arnd Bergmann
2016-11-18 17:03                                           ` Gabriele Paoloni
2016-11-23 14:16                                             ` Arnd Bergmann
2016-11-23 15:22                                               ` Gabriele Paoloni
2016-11-23 17:07                                                 ` Arnd Bergmann
2016-11-23 23:23                                                   ` Arnd Bergmann
2016-11-24  9:12                                                     ` zhichang.yuan
2016-11-24 10:24                                                       ` Arnd Bergmann
2016-11-25  8:46                                                     ` Gabriele Paoloni
2016-11-25 12:03                                                       ` Arnd Bergmann
2016-11-25 16:27                                                         ` Gabriele Paoloni [this message]
2016-11-11 16:54                     ` zhichang.yuan
2016-11-14 11:06         ` One Thousand Gnomes

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=EE11001F9E5DDD47B7634E2F8A612F2E1F93B05D@lhreml507-mbx \
    --to=gabriele.paoloni@huawei.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=john.garry@huawei.com \
    --cc=kantyzc@163.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liviu.dudau@arm.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=minyard@acm.org \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=thomas.petazzo.ni@free-electrons.com \
    --cc=will.deacon@arm.com \
    --cc=xuwei5@hisilicon.com \
    --cc=yuanzhichang@hisilicon.com \
    --cc=zhichang.yuan02@gmail.com \
    --cc=zourongrong@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;
as well as URLs for NNTP newsgroup(s).