<[florian]> robher: pin?
9:54 AM <[florian]> *ping even
9:57 AM <headless> pinctrl!
9:58 AM <headless> now it's standardized
10:13 AM <robher> [florian]: No pins for me, thanks. ;)
10:21 AM <[florian]> robher: ah too bad, joke aside, do you have a few minutes to talk about pre-probe with respect to the MDIO/clock series I had sent out?
10:23 AM <robher> [florian]: sure
10:35 AM <[florian]> robher: cool, thanks. I can quite easily see how we could create a device reference for the bus such that before driver probe we could acquire various resources (clocks, regulators, resets)
10:35 AM <[florian]> robher: however for a number of buses we still need to read the device id to match the device with its driver
10:36 AM <[florian]> robher: so if we were to completely "delegate" the acquiring of resources to the driver it is not clear to me how to achieve that
10:37 AM <robher> [florian]: shouldn't we be able to fallback to DT based matching? We know there's a device on the bus because we have a DT node.
10:38 AM <[florian]> robher: right, maybe MDIO is special here but it only tells us where the device is, not necessarily what device is there since the compatible is optional
10:39 AM <robher> [florian]: I've said many times, compatible shouldn't be optional. MDIO is not special.
10:40 AM <robher> [florian]: Certainly for this case, it simply can't be optional nor generic.
10:41 AM <[florian]> robher: if we use the ethernet-phy<OUI> compatible form, then we don't even attempt to read anything from the device we probe its driver right away, so in some ways "problem solved"
10:42 AM <robher> [florian]: Great!
10:43 AM <[florian]> robher: if only the blob that is passed was that way ;)
10:43 AM <[florian]> robher: but let's consider PCIe, if you need to power on the regulator for the end-point to be succesfully enumerated
10:43 AM <[florian]> robher: we would need to have the bridge do that prior to registering itself
10:44 AM <[florian]> and we have sort of the same issue: DT told us there are devices at a specific location on the bus, but not necessarily the compatible string (arguably it should have, I suppose)
10:45 AM <robher> [florian]: PCI has a VID/PID compatible string, so we're good I think. Or if it is 'slot power
10:45 AM <robher> ... then the host bridge handles it.
10:46 AM <[florian]> this is more of a Wi-Fi soldered on board or a multi-chip module and a GPIO was used to power on/off the EP
10:51 AM <[florian]> humm it all seems to point to DT deficiences where the compatible string should have been provided but was not
10:51 AM <robher> I don't know offhand if that's actually handled for PCI. It's all per bus ATM, but as long as we have a way in DT to match driver, then we should be able to handle it in the drivers whether that's pre-probe or probe itself.
10:53 AM <robher> I can't help it if folks don't want to listen about having specific compatible strings...
10:53 AM <[florian]> I don't think PCI supports it, AFAICT only I2C/SPI/MDIO would do that compatible string based driver mataching
10:53 AM <[florian]> *matching
10:53 AM <[florian]> you are no stranger to embedded people ;) we do stupid stuff, all the time
10:55 AM <robher> I know, I'm one of them too. :)
10:55 AM <[florian]> the part that does not seem to scale well, despite having a boot loader that can patch FDT at runtime is to maintain a list of all possible PCI EP devices
10:56 AM <[florian]> which is why I would be inclined to punt on the bridge driver in that case, but make sure it's got pci_device populated for the slots
10:56 AM <[florian]> such that we could use the regulator/clocks/resets APIs with a proper device reference
10:56 AM <[florian]> maybe we could hide that being an opt-in flag such that it is not the default behavior
11:06 AM <robher> [florian]: That's only for PCI devices described in DT which is already the exception. Perhaps after the regular device creation happens, the bus core can check for DT nodes with no device and then create them. Wouldn't that be the same set of devices as an opt-in flag?
11:07 AM <[florian]> robher: we would not get to the point where we can crate those pci_device unless we have powered them on, right?
11:08 AM <[florian]> robher: my thinking was if the pci bus bridge sets a given flag, then we call this helper which creates the pci_device based on DT information and another helper to enable resources
11:11 AM <robher> [florian]: that's the part that has to be added. If the bridge can do it, then so could the core. The difference is just what triggers it. A flag or the fact that we have a DT node with no pci_device associated with it.
11:12 AM <[florian]> robher: right the "early" (with lack of a better name) device creation can be done by the core, but the resource enabling maybe not so much
11:15 AM <robher> [florian]: Do you mean clk/reg/reset resources or PCI resources?
11:19 AM <robher> [florian]: I'm not sure what all happens between creating pci_device and probe, but we'd either have to make that work with the device off for all of that sequence or add a hook to call into the driver earlier (i.e. the pre-probe hook).
11:19 AM <[florian]> clk/reg/resets yes
11:19 AM <[florian]> but for pre-probe to be directed at the right driver, you would have to know the PCI device's VID/PID
11:20 AM <[florian]> which you would not unless it's been turned on, that's the part that bothers me
11:20 AM <[florian]> we could have a pci_device that is created for which the VID/PID is not known yet
11:20 AM <robher> we'd populate that from the compatible rather than reading the config space.
11:21 AM <[florian]> sure, however, most systems I work with have no compatible, it was not practical and sometimes we just could not know what was connected
11:21 AM <[florian]> that's when we need the help of the bus
11:21 AM <robher> around in circles we go...
11:22 AM <[florian]> I know :)
11:23 AM <robher> Backing up...
11:25 AM <robher> Either you have a standardized way to power on or you have to know from DT what the device you have is.
11:27 AM <[florian]> for a MCM chip we would be able to, and if you have a full or half sized mini-PCIe slot, yes, the slot should provide power
11:27 AM <robher> But there is no standardized way. Starting with 'just turn on any clocks and regulators' is not it. That may work for simple cases, but then it a continuous addition of properties to handle timing and ordering constraints specific devices have.
11:27 AM <[florian]> correct, ultimately you just end up with a power sequence
11:28 AM <robher> If you have a slot, then that is standard and I have no issue with a bridge or 'slot driver' handling that.
11:34 AM <[florian]> ok, that makes sense
11:36 AM <[florian]> are you aware of any bridge driver that has slot power signals routed through GPIOs?
11:39 AM <[florian]> back to MDIO, using ethernet-phy-idcafe.babe would work, and should be preferred, I will do just that
11:43 AM <[florian]> looks like pcie-rockchip.c maybe one of those
11:50 AM <[florian]> robher: thanks, the path is clearer now
11:55 AM <robher> [florian]: If we add more slot handling such as regulators, I'd like to see a common implementation for that as well as the slot reset which we have lots of duplication for.
11:56 AM <[florian]> robher: there may still be some complication with the slot approach and the regulator api not having an of_* counterpart
11:57 AM <[florian]> robher: unless the regulator property is part of the bridge's node, in which case we already have a device reference to work with
11:57 AM <[florian]> or we do create a slot node as a child node of the bridge?
12:32 PM <robher> [florian]: PCI child nodes are pretty much defined to be PCI devices, so it's kind of too late to define slots.
12:38 PM <[florian]> robher: right, so the slot driver would need to somehow pre-populate those pci_device if the regulator/clocks/resets are defined as properties of PCI devices
12:42 PM <robher> [florian]: No, for a standard slot, I'd expect everything in the bridge node. Maybe I should say 'slot library' rather than driver. For anything else (soldered down with non-standard resources), there must be a compatible string and then way to let a driver handle the init.
12:46 PM <[florian]> ok then, even better
12:47 PM <[florian]> are there existing standardized property names for resets, regulators etc.
12:47 PM <[florian]> like pwr-en-supply ?