History log of /linux/drivers/of/platform.c (Results 1 – 25 of 147)
Revision Date Author Comments
# b49420d6 21-Aug-2024 Alex Deucher <alexander.deucher@amd.com>

video/aperture: optionally match the device in sysfb_disable()

In aperture_remove_conflicting_pci_devices(), we currently only
call sysfb_disable() on vga class devices. This leads to the
following

video/aperture: optionally match the device in sysfb_disable()

In aperture_remove_conflicting_pci_devices(), we currently only
call sysfb_disable() on vga class devices. This leads to the
following problem when the pimary device is not VGA compatible:

1. A PCI device with a non-VGA class is the boot display
2. That device is probed first and it is not a VGA device so
sysfb_disable() is not called, but the device resources
are freed by aperture_detach_platform_device()
3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()
4. NULL pointer dereference via sysfb_disable() since the resources
have already been freed by aperture_detach_platform_device() when
it was called by the other device.

Fix this by passing a device pointer to sysfb_disable() and checking
the device to determine if we should execute it or not.

v2: Fix build when CONFIG_SCREEN_INFO is not set
v3: Move device check into the mutex
Drop primary variable in aperture_remove_conflicting_pci_devices()
Drop __init on pci sysfb_pci_dev_is_enabled()

Fixes: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Helge Deller <deller@gmx.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240821191135.829765-1-alexander.deucher@amd.com

show more ...


# bd7b5868 26-Aug-2024 Jinjie Ruan <ruanjinjie@huawei.com>

of/platform: Simplify with scoped for each OF child

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Signed-off-by: Jinjie Ruan <ruanjinjie@hu

of/platform: Simplify with scoped for each OF child

Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.

Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20240826062408.2406734-3-ruanjinjie@huawei.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>

show more ...


# 814cff59 18-Jul-2024 Stephen Boyd <sboyd@kernel.org>

of/platform: Allow overlays to create platform devices from the root node

We'd like to apply overlays to the root node in KUnit so we can test
platform devices created as children of the root node.

of/platform: Allow overlays to create platform devices from the root node

We'd like to apply overlays to the root node in KUnit so we can test
platform devices created as children of the root node.

On some architectures (powerpc), the root node isn't marked with
OF_POPULATED_BUS. If an overlay tries to modify the root node on these
platforms it will fail, while on other platforms, such as ARM, it will
succeed. This is because the root node is marked with OF_POPULATED_BUS
by of_platform_default_populate_init() calling
of_platform_default_populate() with NULL as the first argument.

Loosen the requirement here so that platform devices can be created for
nodes created as children of the root node via DT overlays even if the
platform bus wasn't populated for the root node.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: Saravana Kannan <saravanak@google.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[sboyd@kernel.org: Folded in condition fix]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20240718210513.3801024-2-sboyd@kernel.org

show more ...


# 7b937cc2 17-Feb-2024 Frank Rowand <frowand.list@gmail.com>

of: Create of_root if no dtb provided by firmware

When enabling CONFIG_OF on a platform where 'of_root' is not populated
by firmware, we end up without a root node. In order to apply overlays
and cr

of: Create of_root if no dtb provided by firmware

When enabling CONFIG_OF on a platform where 'of_root' is not populated
by firmware, we end up without a root node. In order to apply overlays
and create subnodes of the root node, we need one. Create this root node
by unflattening an empty builtin dtb.

If firmware provides a flattened device tree (FDT) then the FDT is
unflattened via setup_arch(). Otherwise, the call to
unflatten(_and_copy)?_device_tree() will create an empty root node.

We make of_have_populated_dt() return true only if the DTB was loaded by
firmware so that existing callers don't change behavior after this
patch. The call in the of platform code is removed because it prevents
overlays from creating platform devices when the empty root node is
used.

[sboyd@kernel.org: Update of_have_populated_dt() to treat this empty dtb
as not populated. Drop setup_of() initcall]

Signed-off-by: Frank Rowand <frowand.list@gmail.com>
Link: https://lore.kernel.org/r/20230317053415.2254616-2-frowand.list@gmail.com
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20240217010557.2381548-3-sboyd@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 336157be 22-Feb-2024 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

of/platform: Inform about created platform devices using pr_debug()

For most nodes with a compatible property a platform device is created.
For some an amba device is created instead. For the latter

of/platform: Inform about created platform devices using pr_debug()

For most nodes with a compatible property a platform device is created.
For some an amba device is created instead. For the latter
of_amba_device_create() emits a message at debug level about the node
the device is created from. Add a similar message to
of_platform_device_create_pdata() to inform about the whole list of
created devices.

This also gives the right context for the following messages that
inform about created child devices.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240222153119.2026363-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 7f38b700 15-Dec-2023 Miquel Raynal <miquel.raynal@bootlin.com>

of: device: Export of_device_make_bus_id()

This helper is really handy to create unique device names based on their
device tree path, we may need it outside of the OF core (in the NVMEM
subsystem) s

of: device: Export of_device_make_bus_id()

This helper is really handy to create unique device names based on their
device tree path, we may need it outside of the OF core (in the NVMEM
subsystem) so let's export it. As this helper has nothing patform
specific, let's move it to of/device.c instead of of/platform.c so we
can add its prototype to of_device.h.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 3310288f 13-Nov-2023 Javier Martinez Canillas <javierm@redhat.com>

of/platform: Disable sysfb if a simple-framebuffer node is found

Some DT platforms use EFI to boot and in this case the EFI Boot Services
may register a EFI_GRAPHICS_OUTPUT_PROTOCOL handle, that wil

of/platform: Disable sysfb if a simple-framebuffer node is found

Some DT platforms use EFI to boot and in this case the EFI Boot Services
may register a EFI_GRAPHICS_OUTPUT_PROTOCOL handle, that will later be
queried by the Linux EFI stub to fill the global struct screen_info data.

The data is used by the Generic System Framebuffers (sysfb) framework to
add a platform device with platform data about the system framebuffer.

But if there is a "simple-framebuffer" node in the DT, the OF core will
also do the same and add another device for the system framebuffer.

This could lead for example, to two platform devices ("simple-framebuffer"
and "efi-framebuffer") to be added and matched with their corresponding
drivers. So both efifb and simpledrm will be probed, leading to following:

[ 0.055752] efifb: framebuffer at 0xbd58dc000, using 16000k, total 16000k
[ 0.055755] efifb: mode is 2560x1600x32, linelength=10240, pages=1
[ 0.055758] efifb: scrolling: redraw
[ 0.055759] efifb: Truecolor: size=2:10:10:10, shift=30:20:10:0
...
[ 3.295896] simple-framebuffer bd58dc000.framebuffer: [drm] *ERROR*
could not acquire memory range [??? 0xffff79f30a29ee40-0x2a5000001a7
flags 0x0]: -16
[ 3.298018] simple-framebuffer: probe of bd58dc000.framebuffer
failed with error -16

To prevent the issue, make the OF core to disable sysfb if there is a node
with a "simple-framebuffer" compatible. That way only this device will be
registered and sysfb would not attempt to register another one using the
screen_info data even if this has been filled.

This seems the correct thing to do in this case because:

a) On a DT platform, the DTB is the single source of truth since is what
describes the hardware topology. Even if EFI Boot Services are used to
boot the machine.

b) The of_platform_default_populate_init() function is called in the
arch_initcall_sync() initcall level while the sysfb_init() function
is called later in the subsys_initcall() initcall level.

Reported-by: Andrew Worsley <amworsley@gmail.com>
Closes: https://lore.kernel.org/all/20231111042926.52990-2-amworsley@gmail.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20231113085305.1823455-1-javierm@redhat.com
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 1080b5c0 17-Nov-2023 Johan Hovold <johan+linaro@kernel.org>

of: fix recursion typo in kernel doc

Fix a typo in the kernel doc for the of_platform_depopulate() functions,
which remove children "recursively".

Signed-off-by: Johan Hovold <johan+linaro@kernel.o

of: fix recursion typo in kernel doc

Fix a typo in the kernel doc for the of_platform_depopulate() functions,
which remove children "recursively".

Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20231117171628.20139-1-johan+linaro@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# ca5a75df 06-Oct-2023 Andy Shevchenko <andriy.shevchenko@linux.intel.com>

amba: bus: balance firmware node reference counting

Currently the ACPI code doesn't bump the reference count of
the firmware node, while OF counter part does. Not that it's
a problem right now, sinc

amba: bus: balance firmware node reference counting

Currently the ACPI code doesn't bump the reference count of
the firmware node, while OF counter part does. Not that it's
a problem right now, since ACPI doesn't really use the reference
counting for firmware nodes, it still makes sense to make code
robust against any changes done there. For this,
- switch ACPI case to use device_set_node() to be unified with OF
- move reference counting to amba_device_add()
- switch to use firmware nodes instead of OF ones

In the result we will have reference counting done in the same module
for all callers independently on the nature of firmware node behind.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231006145732.3419115-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# ef04d280 22-Aug-2023 Viresh Kumar <viresh.kumar@linaro.org>

of: Move of_skipped_node_table within #ifdef CONFIG_OF_ADDRESS

The `struct of_skipped_node_table` is used only when CONFIG_OF_ADDRESS
is defined, move it within the #ifdef/#endif to avoid warnings o

of: Move of_skipped_node_table within #ifdef CONFIG_OF_ADDRESS

The `struct of_skipped_node_table` is used only when CONFIG_OF_ADDRESS
is defined, move it within the #ifdef/#endif to avoid warnings on
configurations where CONFIG_OF_ADDRESS isn't defined.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308212037.YopffWSU-lkp@intel.com/
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/73dea4f4b389359a8beadbc77b00eb26853f9ab5.1692691032.git.viresh.kumar@linaro.org
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 7882541c 21-Aug-2023 Peng Fan <peng.fan@nxp.com>

of/platform: increase refcount of fwnode

commit 0f8e5651095b
("of/platform: Propagate firmware node by calling device_set_node()")
use of_fwnode_handle to replace of_node_get, which introduces a sid

of/platform: increase refcount of fwnode

commit 0f8e5651095b
("of/platform: Propagate firmware node by calling device_set_node()")
use of_fwnode_handle to replace of_node_get, which introduces a side
effect that the refcount is not increased. Then the out of tree
jailhouse hypervisor enable/disable test will trigger kernel dump in
of_overlay_remove, with the following sequence
"
of_changeset_revert(&overlay_changeset);
of_changeset_destroy(&overlay_changeset);
of_overlay_remove(&overlay_id);
"

So increase the refcount to avoid issues.

This patch also release the refcount when releasing amba device to avoid
refcount leakage.

Fixes: 0f8e5651095b ("of/platform: Propagate firmware node by calling device_set_node()")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230821023928.3324283-2-peng.fan@oss.nxp.com
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 66a4210b 17-Jul-2023 Rob Herring <robh@kernel.org>

of: Move of_device_{add,register,unregister} to platform.c

The declarations for of_device_{add,register,unregister} were moved into
of_platform.h, so the implementations should be moved to platform.

of: Move of_device_{add,register,unregister} to platform.c

The declarations for of_device_{add,register,unregister} were moved into
of_platform.h, so the implementations should be moved to platform.c as
well.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230717143718.1715773-2-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 73aca58b 17-Jul-2023 Rob Herring <robh@kernel.org>

of: Move of_platform_register_reconfig_notifier() into DT core

There's no reason the generic platform bus code needs to call
of_platform_register_reconfig_notifier(). The notifier can be setup
befor

of: Move of_platform_register_reconfig_notifier() into DT core

There's no reason the generic platform bus code needs to call
of_platform_register_reconfig_notifier(). The notifier can be setup
before the platform bus is. Let's move it into of_core_init() which is
called just before platform_bus_init() instead to keep more of the DT
bits in the DT code.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230717143718.1715773-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 0bb8f49c 10-Jul-2023 Rob Herring <robh@kernel.org>

of: Preserve "of-display" device name for compatibility

Since commit 241d2fb56a18 ("of: Make OF framebuffer device names unique"),
as spotted by Frédéric Bonnard, the historical "of-display" device

of: Preserve "of-display" device name for compatibility

Since commit 241d2fb56a18 ("of: Make OF framebuffer device names unique"),
as spotted by Frédéric Bonnard, the historical "of-display" device is
gone: the updated logic creates "of-display.0" instead, then as many
"of-display.N" as required.

This means that offb no longer finds the expected device, which prevents
the Debian Installer from setting up its interface, at least on ppc64el.

Fix this by keeping "of-display" for the first device and "of-display.N"
for subsequent devices.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217328
Link: https://bugs.debian.org/1033058
Fixes: 241d2fb56a18 ("of: Make OF framebuffer device names unique")
Cc: stable@vger.kernel.org
Cc: Cyril Brulebois <cyril@debamax.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Helge Deller <deller@gmx.de>
Acked-by: Helge Deller <deller@gmx.de>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Michal Suchánek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/20230710174007.2291013-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 0f8e5651 15-Jun-2023 Andy Shevchenko <andriy.shevchenko@linux.intel.com>

of/platform: Propagate firmware node by calling device_set_node()

Insulate of_device_alloc() and of_amba_device_create() from possible
changes to fwnode_handle implementation by using device_set_nod

of/platform: Propagate firmware node by calling device_set_node()

Insulate of_device_alloc() and of_amba_device_create() from possible
changes to fwnode_handle implementation by using device_set_node()
instead of open-coding dev->dev.fwnode assignments.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230615145243.37095-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 1a50d940 30-Mar-2023 Geert Uytterhoeven <geert+renesas@glider.be>

treewide: Fix probing of devices in DT overlays

When loading a DT overlay that creates a device, the device is not
probed, unless the DT overlay is unloaded and reloaded again.

After the recent ref

treewide: Fix probing of devices in DT overlays

When loading a DT overlay that creates a device, the device is not
probed, unless the DT overlay is unloaded and reloaded again.

After the recent refactoring to improve fw_devlink, it no longer depends
on the "compatible" property to identify which device tree nodes will
become struct devices. fw_devlink now picks up dangling consumers
(consumers pointing to descendent device tree nodes of a device that
aren't converted to child devices) when a device is successfully bound
to a driver. See __fw_devlink_pickup_dangling_consumers().

However, during DT overlay, a device's device tree node can have
sub-nodes added/removed without unbinding/rebinding the driver. This
difference in behavior between the normal device instantiation and
probing flow vs. the DT overlay flow has a bunch of implications that
are pointed out elsewhere[1]. One of them is that the fw_devlink logic
to pick up dangling consumers is never exercised.

This patch solves the fw_devlink issue by marking all DT nodes added by
DT overlays with FWNODE_FLAG_NOT_DEVICE (fwnode that won't become
device), and by clearing the flag when a struct device is actually
created for the DT node. This way, fw_devlink knows not to have
consumers waiting on these newly added DT nodes, and to propagate the
dependency to an ancestor DT node that has the corresponding struct
device.

Based on a patch by Saravana Kannan, which covered only platform and spi
devices.

[1] https://lore.kernel.org/r/CAGETcx_bkuFaLCiPrAWCPQz+w79ccDp6=9e881qmK=vx3hBMyg@mail.gmail.com

Fixes: 4a032827daa89350 ("of: property: Simplify of_link_to_phandle()")
Link: https://lore.kernel.org/r/CAGETcx_+rhHvaC_HJXGrr5_WAd2+k5f=rWYnkCZ6z5bGX-wj4w@mail.gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Saravana Kannan <saravanak@google.com>
Tested-by: Ivan Bornyakov <i.bornyakov@metrotek.ru>
Link: https://lore.kernel.org/r/e1fa546682ea4c8474ff997ab6244c5e11b6f8bc.1680182615.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 16b0c7ca 08-Feb-2023 Rob Herring <robh@kernel.org>

of: Use preferred of_property_read_* functions

Replace instances of of_get_property/of_find_property() with appropriate
typed of_property_read_*() functions.

Link: https://lore.kernel.org/all/20230

of: Use preferred of_property_read_* functions

Replace instances of of_get_property/of_find_property() with appropriate
typed of_property_read_*() functions.

Link: https://lore.kernel.org/all/20230215215502.690716-1-robh@kernel.org/
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 2f0cb475 09-Feb-2023 Rob Herring <robh@kernel.org>

of: Use of_property_present() helper

Use of_property_present() instead of of_get_property/of_find_property()
in places where we just need to test presence of a property.

Reviewed-by: Frank Rowand <

of: Use of_property_present() helper

Use of_property_present() instead of of_get_property/of_find_property()
in places where we just need to test presence of a property.

Reviewed-by: Frank Rowand <frowand.list@gmail.com>
Tested-by: Frank Rowand <frowand.list@gmail.com>
Link: https://lore.kernel.org/all/20230215215547.691573-2-robh@kernel.org/
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 241d2fb5 01-Feb-2023 Michal Suchanek <msuchanek@suse.de>

of: Make OF framebuffer device names unique

Since Linux 5.19 this error is observed:

sysfs: cannot create duplicate filename '/devices/platform/of-display'

This is because multiple devices with th

of: Make OF framebuffer device names unique

Since Linux 5.19 this error is observed:

sysfs: cannot create duplicate filename '/devices/platform/of-display'

This is because multiple devices with the same name 'of-display' are
created on the same bus. Update the code to create numbered device names
for the displays.

Also, fix a node refcounting issue when exiting the boot display loop.

cc: linuxppc-dev@lists.ozlabs.org
References: https://bugzilla.kernel.org/show_bug.cgi?id=216095
Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers")
Reported-by: Erhard F. <erhard_f@mailbox.org>
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/20230201162247.3575506-1-robh@kernel.org
[robh: Rework to avoid node refcount leaks]
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 32e8f9b3 08-Oct-2022 Yang Yingliang <yangyingliang@huawei.com>

of/platform: use of_address_count() helper

Use of_address_count() to instead of open-coding it.

Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/202210081156

of/platform: use of_address_count() helper

Use of_address_count() to instead of open-coding it.

Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221008115617.3583890-3-yangyingliang@huawei.com
Signed-off-by: Rob Herring <robh@kernel.org>

show more ...


# 7090d2f1 12-Apr-2022 Vincent Whitchurch <vincent.whitchurch@axis.com>

mtd: phram: Allow probing via reserved-memory

Allow phram to be probed from the devicetree. It expects to be in a
reserved-memory node as documented by the bindings. This allows things
like partit

mtd: phram: Allow probing via reserved-memory

Allow phram to be probed from the devicetree. It expects to be in a
reserved-memory node as documented by the bindings. This allows things
like partitioning to be specified via the devicetree.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220412135302.1682890-4-vincent.whitchurch@axis.com

show more ...


# 52b1b46c 19-Apr-2022 Thomas Zimmermann <tzimmermann@suse.de>

of: Create platform devices for OF framebuffers

Create a platform device for each OF-declared framebuffer and have
offb bind to these devices. Allows for real hot-unplugging and other
drivers beside

of: Create platform devices for OF framebuffers

Create a platform device for each OF-declared framebuffer and have
offb bind to these devices. Allows for real hot-unplugging and other
drivers besides offb.

Originally, offb created framebuffer devices while initializing its
module by parsing the OF device tree. No actual Linux device was set
up. This tied OF framebuffers to offb and makes writing other drivers
for the OF framebuffers complicated. The absence of a Linux device
further prevented real hot-unplugging. Adding a distinct platform
device for each OF framebuffer solves both problems. Specifically, a
DRM driver can now provide graphics output for modern userspace.

Some of the offb init code is now located in the OF initialization.
There's now also an implementation of of_platform_default_populate_init(),
which was missing before. The OF side creates different devices for
either OF display nodes or BootX displays as they require different
handling by the driver. The offb drivers picks up each type of device
and runs the appropriate fbdev initialization.

Tested with OF display nodes on qemu's ppc64le target.

v3:
* declare variable 'node' with function scope (Rob)
v2:
* run PPC code as part of existing initialization (Rob)
* add a few more error warnings (Javier)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220419100405.12600-2-tzimmermann@suse.de

show more ...


# a1a2b712 16-Mar-2022 Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

of/platform: Drop static setup of IRQ resource from DT core

Now that all the DT drivers have switched to platform_get_irq() we can now
safely drop the static setup of IRQ resource from DT core code.

of/platform: Drop static setup of IRQ resource from DT core

Now that all the DT drivers have switched to platform_get_irq() we can now
safely drop the static setup of IRQ resource from DT core code.

With the above change hierarchical setup of irq domains is no longer
bypassed and thus allowing hierarchical interrupt domains to describe
interrupts using "interrupts" DT property.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220316200633.28974-1-prabhakar.mahadev-lad.rj@bp.renesas.com

show more ...


# f396eded 26-Jan-2022 David Brazdil <dbrazdil@google.com>

misc: open-dice: Add driver to expose DICE data to userspace

Open Profile for DICE is an open protocol for measured boot compatible
with the Trusted Computing Group's Device Identifier Composition
E

misc: open-dice: Add driver to expose DICE data to userspace

Open Profile for DICE is an open protocol for measured boot compatible
with the Trusted Computing Group's Device Identifier Composition
Engine (DICE) specification. The generated Compound Device Identifier
(CDI) certificates represent the hardware/software combination measured
by DICE, and can be used for remote attestation and sealing.

Add a driver that exposes reserved memory regions populated by firmware
with DICE CDIs and exposes them to userspace via a character device.

Userspace obtains the memory region's size from read() and calls mmap()
to create a mapping of the memory region in its address space. The
mapping is not allowed to be write+shared, giving userspace a guarantee
that the data were not overwritten by another process.

Userspace can also call write(), which triggers a wipe of the DICE data
by the driver. Because both the kernel and userspace mappings use
write-combine semantics, all clients observe the memory as zeroed after
the syscall has returned.

Cc: Andrew Scull <ascull@google.com>
Cc: Will Deacon <will@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Brazdil <dbrazdil@google.com>
Link: https://lore.kernel.org/r/20220126231237.529308-3-dbrazdil@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 2f92ea21 12-Dec-2021 Hector Martin <marcan@marcan.st>

of: Move simple-framebuffer device handling from simplefb to of

This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in

of: Move simple-framebuffer device handling from simplefb to of

This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211212062407.138309-2-marcan@marcan.st

show more ...


123456