linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: "zhichang.yuan" <yuanzhichang@hisilicon.com>
Cc: catalin.marinas@arm.com, will.deacon@arm.com, robh+dt@kernel.org,
	bhelgaas@google.com, olof@lixom.net, arnd@arndb.de,
	linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com,
	linux-kernel@vger.kernel.org, linuxarm@huawei.com,
	devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-serial@vger.kernel.org, minyard@acm.org,
	benh@kernel.crashing.org, liviu.dudau@arm.com,
	zourongrong@gmail.com, john.garry@huawei.com,
	gabriele.paoloni@huawei.com, zhichang.yuan02@gmail.com,
	kantyzc@163.com, xuwei5@hisilicon.com, marc.zyngier@arm.com
Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
Date: Tue, 8 Nov 2016 11:49:53 +0000	[thread overview]
Message-ID: <20161108114953.GB15297@leverpostej> (raw)
In-Reply-To: <1478576829-112707-3-git-send-email-yuanzhichang@hisilicon.com>

On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote:
> +Hisilicon Hip06 low-pin-count device
> +  Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> +  locate on LPC bus can be accessed direclty. But some SoCs have independent
> +  LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> +  Hisilicon Hip06 implements this LPC device.

s/direclty/directly/

My understanding of ISA (which may be flawed) is that it's not part of
the PCI host bridge, but rather on x86 it happens to share the IO space
with PCI.

So, how about this becomes:

  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
  provides access to some legacy ISA devices.

I believe that we could theoretically have multiple independent LPC/ISA
busses, as is possible with PCI on !x86 systems. If the current ISA code
assumes a singleton bus, I think that's something that needs to be fixed
up more generically.

I don't see why we should need any architecture-specific code here. Why
can we not fix up the ISA bus code in drivers/of/address.c such that it
handles multiple ISA bus instances, and translates all sub-device
addresses relative to the specific bus instance?

> +Required properties:
> +- compatible: should be "hisilicon,low-pin-count"

This would be better as something like:

	"hisilicon,hip06-lpc-controller"

If it's reused in other SoCs, we can add more strings as we usually do.

> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the register set of this device is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b0000 {
> +	compatible = "hisilicom,low-pin-count";

s/hisilicom/hisilicon/

My comment above on the compatible string also applies.

> +	#address-cells = <2>;
> +	#size-cells = <1>;
> +	reg = <0x0 0xa01b0000 0x0 0x1000>;
> +
> +	ipmi0: bt@e4 {
> +		compatible = "ipmi-bt";
> +		device_type = "ipmi";
> +		reg = <0x01 0xe4 0x04>;
> +		status = "disabled";
> +	};
> +};

Please remove the status property; it's irrelevant to the example.

[...]

> +/**
> + * indirect_io_enabled - check whether indirectIO is enabled.
> + *	arm64_extio_ops will be set only when indirectIO mechanism had been
> + *	initialized.
> + *
> + * Returns true when indirectIO is enabled.
> + */
> +bool indirect_io_enabled(void)
> +{
> +	return arm64_extio_ops ? true : false;
> +}

	return !!arm64_extio_ops;

> +/**
> + * addr_is_indirect_io - check whether the input taddr is for indirectIO.
> + * @taddr: the io address to be checked.
> + *
> + * Returns 1 when taddr is in the range; otherwise return 0.
> + */
> +int addr_is_indirect_io(u64 taddr)
> +{
> +	if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
> +		return 0;
> +
> +	return 1;
> +}

Why not bool?

I don't think this is the right thing to do, regardless.

> + * 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);
> +}
> +
>  static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>  			    struct of_bus *pbus, __be32 *addr,
>  			    int na, int ns, int pna, const char *rprop)
> @@ -595,6 +639,15 @@ 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);
> +			break;
> +		}

I don't believe this is the right place for this to live. This should
live in the isa of_bus, matched in the usual way with of_match_bus(),
and used in pbus->translate() in of_translate_one().

If we need to extend the prototypes of those functions, we should do so.

If we need to be able to register instance-specific translations or
indirection, we should build the infrastructure for that rather than
forcing a singleton translation in here.

Thanks,
Mark.

  parent reply	other threads:[~2016-11-08 11:50 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 [this message]
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
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=20161108114953.GB15297@leverpostej \
    --to=mark.rutland@arm.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=gabriele.paoloni@huawei.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=marc.zyngier@arm.com \
    --cc=minyard@acm.org \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --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).