misc: rp1: Fix an error handling path in rp1_probe()When DT is used to get the reference of 'rp1_node', it should be releasedwhen not needed anymore, otherwise it is leaking.In such a case, add
misc: rp1: Fix an error handling path in rp1_probe()When DT is used to get the reference of 'rp1_node', it should be releasedwhen not needed anymore, otherwise it is leaking.In such a case, add the missing of_node_put() call at the end of the probe,as already done in the error handling path.Fixes: 49d63971f963 ("misc: rp1: RaspberryPi RP1 misc driver")Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>Reviewed-by: Andrea della Porta <andrea.porta@suse.com>Link: https://patch.msgid.link/9bc1206de787fa86384f3e5ba0a8027947bc00ff.1762585959.git.christophe.jaillet@wanadoo.frSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
misc: rp1: RaspberryPi RP1 misc driverThe RaspberryPi RP1 is a PCI multi function device containingperipherals ranging from Ethernet to USB controller, I2C, SPIand others.Implement a bare minim
misc: rp1: RaspberryPi RP1 misc driverThe RaspberryPi RP1 is a PCI multi function device containingperipherals ranging from Ethernet to USB controller, I2C, SPIand others.Implement a bare minimum driver to operate the RP1, leveragingactual OF based driver implementations for the on-board peripheralsby loading a devicetree overlay during driver probe if the RP1node is not already present in the DT.The peripherals are accessed by mapping MMIO registers startingfrom PCI BAR1 region.With the overlay approach we can achieve more generic and agnosticapproach to managing this chipset, being that it is a PCI endpointand could possibly be reused in other hw implementations. Thepresented approach is also used by Bootlin's Microchip LAN966xpatchset (see link) as well, for a similar chipset.In this case, the inclusion tree for the DT overlay is as follow(the arrow points to the includer): rp1-pci.dtso <---- rp1-common.dtsiOn the other hand, to ensure compatibility with downstream, thisdriver can also work with a DT already comprising the RP1 node, sothe dynamically loaded overlay will not be used if the DT is alreadyfully defined.The reason why this driver is contained in drivers/misc hasbeen paved by Bootlin's LAN966X driver, which first used theoverlay approach to implement non discoverable peripherals behind aPCI bus. For RP1, the same arguments apply: it's not used as an SoCsince the driver code is not running on-chip and is not like an MFDsince it does not really need all the MFD infrastructure (shared regs,etc.). So, for this particular use, misc has been proposed and deemedas a good choice. For further details about that please check the links.This driver is heavily based on downstream code from RaspberryPiFoundation, and the original author is Phil Elwell.Link: https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdfLink: https://lore.kernel.org/all/20240612140208.GC1504919@google.com/Link: https://lore.kernel.org/all/83f7fa09-d0e6-4f36-a27d-cee08979be2a@app.fastmail.com/Link: https://lore.kernel.org/all/2024081356-mutable-everyday-6f9d@gregkh/Link: https://lore.kernel.org/all/20240808154658.247873-1-herve.codina@bootlin.com/Signed-off-by: Andrea della Porta <andrea.porta@suse.com>Acked-by: Bjorn Helgaas <bhelgaas@google.com> # quirks.c, pci_ids.hAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>Link: https://lore.kernel.org/r/20250529135052.28398-7-andrea.porta@suse.comSigned-off-by: Florian Fainelli <florian.fainelli@broadcom.com>