kernel/linux.git/drivers/of/property.c, branch v5.10.257

of: property: fix typo in io-channels

2024-02-23T07:42:29+00:00

commit 8f7e917907385e112a845d668ae2832f41e64bf5 upstream. The property is io-channels and not io-channel. This was effectively preventing the devlink creation. Fixes: 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sa Reviewed-by: Saravana Kannan Acked-by: Jonathan Cameron Link: https://lore.kernel.org/r/20240123-iio-backend-v7-1-1bff236b8693@analog.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

of: Add missing 'Return' section in kerneldoc comments

2023-12-13T17:26:58+00:00

[ Upstream commit 8c8239c2c1fb82f171cb22a707f3bb88a2f22109 ] Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand Cc: Mauro Carvalho Chehab Signed-off-by: Rob Herring Reviewed-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org Stable-dep-of: d79972789d17 ("of: dynamic: Fix of_reconfig_get_state_change() return value documentation") Signed-off-by: Sasha Levin

of: property: decrement node refcount in of_fwnode_get_reference_args()

2022-12-08T10:23:55+00:00

[ Upstream commit 60d865bd5a9b15a3961eb1c08bd4155682a3c81e ] In of_fwnode_get_reference_args(), the refcount of of_args.np has been incremented in the case of successful return from of_parse_phandle_with_args() or of_parse_phandle_with_fixed_args(). Decrement the refcount if of_args is not returned to the caller of of_fwnode_get_reference_args(). Fixes: 3e3119d3088f ("device property: Introduce fwnode_property_get_reference_args") Signed-off-by: Yang Yingliang Reviewed-by: Sakari Ailus Reviewed-by: Frank Rowand Link: https://lore.kernel.org/r/20221121023209.3909759-1-yangyingliang@huawei.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

of: property: fw_devlink: do not link ".*,nr-gpios"

2021-04-14T06:41:58+00:00

commit d473d32c2fbac2d1d7082c61899cfebd34eb267a upstream. [,]nr-gpios property is used by some GPIO drivers[0] to indicate the number of GPIOs present on a system, not define a GPIO. nr-gpios is not configured by #gpio-cells and can't be parsed along with other "*-gpios" properties. nr-gpios without the "," prefix is not allowed by the DT spec[1], so only add exception for the ",nr-gpios" suffix and let the error message continue being printed for non-compliant implementations. [0] nr-gpios is referenced in Documentation/devicetree/bindings/gpio: - gpio-adnp.txt - gpio-xgene-sb.txt - gpio-xlp.txt - snps,dw-apb-gpio.yaml [1] Link: https://github.com/devicetree-org/dt-schema/blob/cb53a16a1eb3e2169ce170c071e47940845ec26e/schemas/gpio/gpio-consumer.yaml#L20 Fixes errors such as: OF: /palmbus@300000/gpio@600: could not find phandle Fixes: 7f00be96f125 ("of: property: Add device link support for interrupt-parent, dmas and -gpio(s)") Signed-off-by: Ilya Lipnitskiy Cc: Saravana Kannan Cc: stable@vger.kernel.org # v5.5+ Link: https://lore.kernel.org/r/20210405222540.18145-1-ilya.lipnitskiy@gmail.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

Merge tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm

2020-08-06T02:50:06+00:00

Pull drm updates from Dave Airlie: "New xilinx displayport driver, AMD support for two new GPUs (more header files), i915 initial support for RocketLake and some work on their DG1 (discrete chip). The core also grew some lockdep annotations to try and constrain what drivers do with dma-fences, and added some documentation on why the idea of indefinite fences doesn't work. The long list is below. I do have some fixes trees outstanding, but I'll follow up with those later. core: - add user def flag to cmd line modes - dma_fence_wait added might_sleep - dma-fence lockdep annotations - indefinite fences are bad documentation - gem CMA functions used in more drivers - struct mutex removal - more drm_ debug macro usage - set/drop master api fixes - fix for drm/mm hole size comparison - drm/mm remove invalid entry optimization - optimise drm/mm hole handling - VRR debugfs added - uncompressed AFBC modifier support - multiple display id blocks in EDID - multiple driver sg handling fixes - __drm_atomic_helper_crtc_reset in all drivers - managed vram helpers ttm: - ttm_mem_reg handling cleanup - remove bo offset field - drop CMA memtype flag - drop mappable flag xilinx: - New Xilinx ZynqMP DisplayPort Subsystem driver nouveau: - add CRC support - start using NVIDIA published class header files - convert all push buffer emission to new macros - Proper push buffer space management for EVO/NVD channels. - firmware loading fixes - 2MiB system memory pages support on Pascal and newer vkms: - larger cursor support i915: - Rocketlake platform enablement - Early DG1 enablement - Numerous GEM refactorings - DP MST fixes - FBC, PSR, Cursor, Color, Gamma fixes - TGL, RKL, EHL workaround updates - TGL 8K display support fixes - SDVO/HDMI/DVI fixes amdgpu: - Initial support for Sienna Cichlid GPU - Initial support for Navy Flounder GPU - SI UVD/VCE support - expose rotation property - Add support for unique id on Arcturus - Enable runtime PM on vega10 boards that support BACO - Skip BAR resizing if the bios already did id - Major swSMU code cleanup - Fixes for DCN bandwidth calculations amdkfd: - Track SDMA usage per process - SMI events interface radeon: - Default to on chip GART for AGP boards on all arches - Runtime PM reference count fixes msm: - headers regenerated causing churn - a650/a640 display and GPU enablement - dpu dither support for 6bpc panels - dpu cursor fix - dsi/mdp5 enablement for sdm630/sdm636/sdm66 tegra: - video capture prep support - reflection support mediatek: - convert mtk_dsi to bridge API meson: - FBC support sun4i: - iommu support rockchip: - register locking fix - per-pixel alpha support PX30 VOP mgag200: - ported to simple and shmem helpers - device init cleanups - use managed pci functions - dropped hw cursor support ast: - use managed pci functions - use managed VRAM helpers - rework cursor support malidp: - dev_groups support hibmc: - refactor hibmc_drv_vdac: vc4: - create TXP CRTC imx: - error path fixes and cleanups etnaviv: - clock handling and error handling cleanups - use pin_user_pages" * tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm: (1747 commits) drm/msm: use kthread_create_worker instead of kthread_run drm/msm/mdp5: Add MDP5 configuration for SDM636/660 drm/msm/dsi: Add DSI configuration for SDM660 drm/msm/mdp5: Add MDP5 configuration for SDM630 drm/msm/dsi: Add phy configuration for SDM630/636/660 drm/msm/a6xx: add A640/A650 hwcg drm/msm/a6xx: hwcg tables in gpulist drm/msm/dpu: add SM8250 to hw catalog drm/msm/dpu: add SM8150 to hw catalog drm/msm/dpu: intf timing path for displayport drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3 drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845 drm/msm/dpu: move some sspp caps to dpu_caps drm/msm/dpu: update UBWC config for sm8150 and sm8250 drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250 drm/msm/a6xx: set ubwc config for A640 and A650 drm/msm/adreno: un-open-code some packets drm/msm: sync generated headers drm/msm/a6xx: add build_bw_table for A640/A650 drm/msm/a6xx: fix crashstate capture for A650 ...

of: property: Add device link support for pinctrl-0 through pinctrl-8

2020-07-27T21:07:31+00:00

Add support for pinctrl-0 through pinctrl-8 explicitly instead of trying to add support for pinctrl-%d properties. Of all the pinctrl-* properties in dts files (20322), only 47% (9531) are pinctrl-%d properties. Of all the pinctrl-%d properties, 99.5% (9486) are made up of pinctrl-[0-2]. 'pinctrl-8' is the current maximum found in dts files. Trying to parse all pinctrl-* properties and checking for pinctrl-%d is unnecessarily complicated. So, just add support for pinctrl-[0-8] for now. In the unlikely event we ever exceed pinctrl-8, we can come back and improve this. Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20200724234415.1651639-2-saravanak@google.com Signed-off-by: Rob Herring

of: property: Add device link support for multiple DT bindings

2020-07-27T21:06:33+00:00

Add support for creating device links out of the following DT bindings: - interrupts-extended - nvmem-cells - phys - wakeup-parent Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20200724234415.1651639-1-saravanak@google.com Signed-off-by: Rob Herring

of_graph: add of_graph_is_present()

2020-07-01T08:49:02+00:00

In some cases it's very useful to silently check whether port node exists at all in a device-tree before proceeding with parsing the graph. The DRM bridges code is one example of such case where absence of a graph in a device-tree is a legit condition. This patch adds of_graph_is_present() which returns true if given device-tree node contains OF graph port. Reviewed-by: Rob Herring Signed-off-by: Dmitry Osipenko Reviewed-by: Laurent Pinchart Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200701074232.13632-2-digetx@gmail.com

of: property: Improve cycle detection when one of the devices is never added

2020-06-17T22:11:18+00:00

Consider this example where -> means LHS device is a consumer of RHS device and indentation represents "child of" of the previous device. Device A -> Device C Device B -> Device A Device C Without this commit: 1. Device A is added. 2. Device A is added to waiting for supplier list (Device C) 3. Device B is added 4. Device B is linked as a consumer to Device A 5. Device A doesn't probe because it's waiting for Device C to be added. 6. Device B doesn't probe because Device A hasn't probed. 7. Device C will never be added because it's parent hasn't probed. So, Device A, B and C will be in a probe/add deadlock. This commit detects this scenario and stops trying to create a device link between Device A and Device C since doing so would create the following cycle: Device A -> Devic C -(parent)-> Device B -> Device A. With this commit: 1. Device A is added. 3. Device B is added 4. Device B is linked as a consumer to Device A 5. Device A probes. 6. Device B probes because Device A has probed. 7. Device C is added and probed. Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20200610011934.49795-3-saravanak@google.com Signed-off-by: Rob Herring

of: property: Do not link to disabled devices

2020-04-28T17:47:47+00:00

When creating a consumer/supplier relationship between two devices, make sure the supplier node is actually active. Otherwise this will create a link relationship that will never be fulfilled. This, in the worst case scenario, will hang the system during boot. Note that, in practice, the fact that a device-tree represented consumer/supplier relationship isn't fulfilled will not prevent devices from successfully probing. Fixes: a3e1d1a7f5fc ("of: property: Add functional dependency link from DT bindings") Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Saravana Kannan Signed-off-by: Rob Herring