On Mon, Jun 18, 2018 at 1:57 PM, Daniel Walker <danie...@cisco.com> wrote: > Cisco has a couple platforms which depend on the domain values getting > set a certain way. We discovered our machines not detecting the pci > devices, and traced it back to this commit, > > 63a7228 powerpc/pci: Assign fixed PHB number based on device-tree > properties > > It seems that the code is expecting the return value of of_property_read_u64() > to be the opposite of what it actually is.. It returns zero on success, and a > negative return value on error. So if you only check when it's non-zero your > going to set Opal for all platforms but Opal, which I assume is not what was > expected.
Hi Daniel, thanks for exposing a potential issue and trying to fix. (And thanks Mauro to point this message, since my email changed). I disagree with your patch Daniel, I think it's wrong. Since the logic of my original patch is kind of convoluted, for improve (even my own) understanding, I tried to over-comment the logic here: https://pastebin.ubuntu.com/p/4DNvd9b2bY Please, take a look and see if you agree with the logic now. Regarding your issue, I'm interested - I think perhaps you have some FW flaw that might be exposing duplicated "reg" or "ibm,opal-phbid" properties. Or maybe you somehow rely on the old incremental PHB setting and your software stack is not working properly with the DT-based PHB values. Please, elaborate the issue a bit more in order we can try to figure out. And also, you could try reverting the below two patches and boot the kernel to be sure it works: 61e8a0d5a02 powerpc/pci: Fix endian bug in fixed PHB numbering 63a72284b15 powerpc/pci: Assign fixed PHB number based on device-tree properties *Notice* the first is a fix to my patch, and both should be tested together. Be sure your current kernel has _both or neither_ these patches! Cheers, Guilherme
