Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

å 2016/1/4 19:13, Arnd Bergmann åé:
> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> > å 2015/12/31 23:00, Rongrong Zou åé:
> > > 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx <mailto:arnd@xxxxxxxx>>:
> > >   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> > >   > > å 2015/12/30 17:06, Arnd Bergmann åé:
> > >   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> > >   >
> > >   > The DT sample above looks good in principle. I believe what you are missing
> > >   > here is code in your driver to scan the child nodes to create the platform
> > >   > devices. of_bus_isa_translate() should work with your definition here
> > >   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> > >   > resources, so the absence of a ranges property is ok. Maybe all you
> > >   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> > >   >
> > >
> > > You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> > > will be sent later. By the way, it's my another email account use when i at home.
> >
> > I tried, and there need some additional changes.
> >
> > isa@a01b0000 {
> >
> > /*the node name should start with "isa", because of below definition
> > * static int of_bus_isa_match(struct device_node *np)
> > * {
> > *	return !strcmp(np->name, "isa");
> > * }
>
> Looks good. It would be nicer to match on device_type than on name,
> but this is ancient code and it's probably best not to touch it
> so we don't accidentally break some old SPARC or PPC system.
>
> > */
> > 	compatible = "low-pin-count";
> > 	device_type = "isa";
> > 	#address-cells = <2>;
> > 	#size-cells = <1>;
> > 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> > 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> > /*
> > *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> > *
> > */
> > 	ipmi_0:ipmi@000000e4{
> > 		device_type = "ipmi";
> > 		compatible = "ipmi-bt";
> > 		reg = <0x1 0x000000e4 0x4>;
> > };
>
> This looks wrong: the property above says that the I/O port range is
> translated to MMIO address 0x00000000 to 0x00010000, which is not
> true on your hardware. I think this needs to be changed in the code
> so the ranges property is not required for I/O ports.

Ranges property can set empty, but this means 1:1 translation. the I/O 
port range is translated to MMIO address 0x00000001 00000000 to 
0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy 
I/O port resource from dts.

For ipmi driver, I can get I/O port resource by DMI rather than dts.

> > drivers\of\address.c
> > static int __of_address_to_resource(struct device_node *dev,
> >                   const __be32 *addrp, u64 size, unsigned int flags,
> >                   const char *name, struct resource *r)
> > {
> >           u64 taddr;
> >
> >           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >                   return -EINVAL;
> >           taddr = of_translate_address(dev, addrp);
> >           if (taddr == OF_BAD_ADDR)
> >                   return -EINVAL;
> >           memset(r, 0, sizeof(struct resource));
> >           if (flags & IORESOURCE_IO) {
> >                   unsigned long port;
> >
> > /*****************************************************************/
> > /*legacy port(< 0x1000) is reserved, and need no translation here*/
> > /*****************************************************************/
> >                   if(taddr + size < PCIBIOS_MIN_IO){
> >                           r->start = taddr;
> >                           r->end = taddr + size - 1;
> >                   }
>
> I don't like having a special case based on the address here,
> the same kind of hack might be needed for PCI I/O spaces in
> hardware that uses an indirect method like your LPC bus
> does, and the code above will not work on any LPC implementation
> that correctly multiplexes its I/O ports with the first PCI domain.
>
> I think it would be better to avoid translating the port into
> a physical address to start with just to translate it back into
> a port number, what we need instead is the offset between the
> bus specific port number and the linux port number. I've added
> Liviu to Cc, he wrote this code originally and may have some idea
> of how we could do that.
>
> 	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/