Hi Thierry,
On 03/22/2014 01:50 PM, Thierry Bultel wrote:
When I communicated about the bug I had, and said that my temporary workaround was to disable the PCIe, my intention was not to make the suppression become a standard, and I believe it is a little bit frustrating for Marek.
I'm not sure I understand Marek's frustration. Marek's a capable guy, and certainly in a position to carry a 1-line patch around for his needs.
The AMOS820, based on the sabrelite/nitrogen has a PCIe slot on the main board, so there might be some interest of having the PCIe support enabled.
My first instinct is to say that if AMOS820 needs its' own setting, you can add a board for it and carry your own amos820.h.
AFAIK, this can be done without code updates in board/boundary (i.e. add include/configs/amos820.h and an entry into boards.cfg). We have users of our SOM that do precisely this to configure boards for their use cases.
It's our job primarily to support users of "actual" SABRE Lites and Nitrogen6X boards.
To my mind, the bug is in the kernel I am using, it should be robust to the fact that PCIe has been formerly probed.
Sure.
I pointed you at our tree, which likely has this fixed.
Wouldn't that be smarter to have the PCIe enabled or not, by an environment variable (defaulted to YES, and that the user could set to NO eventually for older kernels) ?
Regards,
Eric