Re: [PATCH v3 0/5] kexec_file: Add buffer hand-over for the next kernel

[Mimi Zohar]

On Thu, 2016-08-25 at 19:17 -0300, Thiago Jung Bauermann wrote:
> Am Donnerstag, 25 August 2016, 14:12:43 schrieb Andrew Morton:
> > I grabbed these two patch series.  I also merged the "IMA:
> > Demonstration code for kexec buffer passing." demonstration patch just
> > to get things a bit of testing.
> 
> Thank you very much!

Thank you, Andrew.

> > I assume that once the "ima: carry the
> > measurement list across kexec" series has stabilised, I should drop the
> > demo patch and also grab those?  If so, pelase start cc'ing me.
> 
> I'm not sure how Mimi is planning to upstream that series.

I'll re-post the patches shortly, cc'ing you.  It will contain support
for saving the binary measurement list on one architecture (eg. little
endian) and restoring it on another (eg. big endian).

Mimi

Re: [PATCH 3/5] of/platform: introduce a generic way to declare a platform bus

[Kevin Hao]

On Thu, Aug 25, 2016 at 08:44:56AM -0500, Rob Herring wrote:
> On Mon, Aug 22, 2016 at 9:06 PM, Kevin Hao  wrote:
> > The specific buses which need to be probed at boot time are different
> > between platforms. Instead of put all the buses into the default
> > of_default_bus_match_table[] match tables, this patch introduces a
> > general way to declare a platform bus.
> 
> I'd prefer to not do this with linker sections if possible. Doesn't
> PPC have machine descriptors that you could add the match table to? If
> that table exists then arch_want_default_of_probe could return a
> pointer to it.

Hmm, I thought about adding a match table in ppc_md. But it is very arch
specific. I thought maybe other archs also need to probe some arch or even
board specific bus, so I introduces these arch independent macros and wish
it may be useful for other archs. :-)

> 
> Are there any platforms that work with the default match table?

Yes, some boards can work with the default match table. But most won't.

> I'd be
> fine with adding some strings to the default if that helps.
> 
> { .type = "soc", },
> 
> device_type is deprecated for FDT, so this shouldn't be needed except
> for really old stuff.
> 
> { .compatible = "soc", },
> 
> Doesn't appear in kernel dts files. Could be out of tree or old ones?
> 
> { .compatible = "simple-bus" },
> 
> Already handled.
> 
> { .compatible = "gianfar" },
> 
> Seems like the children of this should be probed by the gianfar driver.
> 
> { .compatible = "gpio-leds", },
> 
> I don't think this is needed.
> 
> { .type = "qe", },
> 
> Again, deprecated.
> 
> { .compatible = "fsl,qe", },
> 
> No issue to add this. Though, you could also probe it from mpc85xx_qe_init().

Do you mean we put all the probe of the specific bus into the corresponding
drivers? Yes, if we do so, we probably can shrink the default match table to
be something like this:
{ .compatible = "soc", },
{ .compatible = "simple-bus" },

OK, now we have three options to fix this issue:
a) Create a separate link section to contain all the buses needed to be probed.
   Just as what this patch does.

b) Put the match table into the machine descriptor.

c) Sprinkle the probe of all the specific bus into the corresponding driver
   (such as gian, pcie controller) and the default probe function only handle
   the very common buses.

So what option do you guys think is best?

Thanks,
Kevin


signature.asc
Description: PGP signature