- 05 Apr, 2023 36 commits
-
-
Rafał Miłecki authored
U-Boot environment variables are stored in ASCII format so "ethaddr" requires parsing into binary to make it work with Ethernet interfaces. This includes support for indexes to support #nvmem-cell-cells = <1>. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-36-srinivas.kandagatla@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rafał Miłecki authored
Callback .read_post_process() is designed to modify raw cell content before providing it to the consumer. So far we were dealing with modifications that didn't affect cell size (length). In some cases however cell content needs to be reformatted and resized. It's required e.g. to provide properly formatted MAC address in case it's stored in a non-binary format (e.g. using ASCII). There were few discussions how to optimally handle that. Following possible solutions were considered: 1. Allow .read_post_process() to realloc (resize) content buffer 2. Allow .read_post_process() to adjust (decrease) just buffer length 3. Register NVMEM cells using post-read sizes The preferred solution was the last one. The problem is that simply adjusting "bytes" in NVMEM providers would result in core code NOT passing whole raw data to .read_post_process() callbacks. It means callback functions couldn't do their job without somehow manually reading original cell content on their own. This patch deals with that by registering NVMEM cells with both lengths: raw content one and post read one. It allows: 1. Core code to read whole raw cell content 2. Callbacks to return content they want Signed-off-by:
-
Rafał Miłecki authored
U-Boot's "ethaddr" environment variable is very often used to store *base* MAC address. It's used as a base for calculating addresses for multiple interfaces. It's done by adding proper values. Actual offsets are picked by manufacturers and vary across devices. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Yang Li authored
According to commit 890cc39a ("drivers: provide devm_platform_get_and_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Yang Li authored
According to commit 7945f929 ("drivers: provide devm_platform_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to use devm_platform_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yang Li authored
According to commit 7945f929 ("drivers: provide devm_platform_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to use devm_platform_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Konrad Dybcio authored
Docuemnt the QFPROM on SM6375. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Konrad Dybcio authored
Docuemnt the QFPROM on SM6350. Signed-off-by:
-
AngeloGioacchino Del Regno authored
On some MediaTek SoCs GPU speed binning data is available for read in the SoC's eFuse array but it has a format that is incompatible with what the OPP API expects, as we read a number from 0 to 7 but opp-supported-hw is expecting a bitmask to enable an OPP entry: being what we read limited to 0-7, it's straightforward to simply convert the value to BIT(value) as a post-processing action. So, introduce post-processing support and enable it by evaluating the newly introduced platform data's `uses_post_processing` member, currently enabled only for MT8186. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/nvmem/stm32-romem.c:271:34: error: ‘stm32_romem_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Rob Herring authored
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by:
-
Miquel Raynal authored
Following the introduction of the bindings for this NVMEM parser and the layout driver, add myself as maintainer. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Miquel Raynal authored
This layout applies on top of any non volatile storage device containing an ONIE table factory flashed. This table follows the tlv (type-length-value) organization described in the link below. We cannot afford using regular parsers because the content of these tables is manufacturer specific and must be dynamically discovered. Link: https://opencomputeproject.github.io/onie/design-spec/hw_requirements.htmlSigned-off-by:
-
Michael Walle authored
Add myself as a maintainer for the new sl28vpd nvmem layout driver. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Michael Walle authored
This layout applies to the VPD of the Kontron sl28 boards. The VPD only contains a base MAC address. Therefore, we have to add an individual offset to it. This is done by taking the second argument of the nvmem phandle into account. Also this let us checking the VPD version and the checksum. Signed-off-by:
-
Michael Walle authored
It doesn't make any more sense to have a opaque pointer set up by the nvmem device. Usually, the layout isn't associated with a particular nvmem device. Instead, let the caller who set the post process callback provide the priv pointer. Signed-off-by:
-
Michael Walle authored
There are no users anymore for the global cell_post_process callback anymore. New users should use proper nvmem layouts. Signed-off-by:
-
Michael Walle authored
In preparation of retiring the global post processing hook change this driver to use layouts. The layout will be supplied during registration and will be used to add the post processing hook to all added cells. Signed-off-by:
-
Michael Walle authored
Provide a way to modify a cell before it will get added. This is useful to attach a custom post processing hook via a layout. Signed-off-by:
-
Michael Walle authored
Instead of relying on the name the consumer is using for the cell, like it is done for the nvmem .cell_post_process configuration parameter, provide a per-cell post processing hook. This can then be populated by the NVMEM provider (or the NVMEM layout) when adding the cell. Signed-off-by:
-
Miquel Raynal authored
When a storage device like an eeprom or an mtd device probes, it registers an nvmem device if the nvmem subsystem has been enabled (bool symbol). During nvmem registration, if the device is using layouts to expose dynamic nvmem cells, the core will first try to get a reference over the layout driver callbacks. In practice there is not relationship that can be described between the storage driver and the nvmem layout. So there is no way we can enforce both drivers will be built-in or both will be modules. If the storage device driver is built-in but the layout is built as a module, instead of badly failing with an endless probe deferral loop, lets just make a modprobe call in case the driver was made available in an initramfs with of_device_node_request_module(), and offer a fully functional system to the user. Signed-off-by:
-
Miquel Raynal authored
Make nvmem_layout_get() return -EPROBE_DEFER while the expected layout is not available. This condition cannot be triggered today as nvmem layout drivers are initialed as part of an early init call, but soon these drivers will be converted into modules and be initialized with a standard priority, so the unavailability of the drivers might become a reality that must be taken care of. Let's anticipate this by telling the caller the layout might not yet be available. A probe deferral is requested in this case. Please note this does not affect any nvmem device not using layouts, because an early check against the "nvmem-layout" container presence will return NULL in this case. Signed-off-by:
-
Michael Walle authored
NVMEM layouts are used to generate NVMEM cells during runtime. Think of an EEPROM with a well-defined conent. For now, the content can be described by a device tree or a board file. But this only works if the offsets and lengths are static and don't change. One could also argue that putting the layout of the EEPROM in the device tree is the wrong place. Instead, the device tree should just have a specific compatible string. Right now there are two use cases: (1) The NVMEM cell needs special processing. E.g. if it only specifies a base MAC address offset and you need to add an offset, or it needs to parse a MAC from ASCII format or some proprietary format. (Post processing of cells is added in a later commit). (2) u-boot environment parsing. The cells don't have a particular offset but it needs parsing the content to determine the offsets and length. Co-developed-by: -
Miquel Raynal authored
A new helper has been introduced, of_request_module(). Users have been converted, this helper can now be deleted. Signed-off-by:
-
Miquel Raynal authored
There is a new helper supposed to replace of_device_request_module(), called of_request_module(). They are both strictly equivalent, besides the fact the latter receives a "struct device_node" directly. Use it. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Miquel Raynal authored
Depending on device.c for pure OF handling is considered backwards. Let's extract the content of of_device_request_module() to have the real logic under module.c. The next step will be to convert users of of_device_request_module() to use the new helper. Signed-off-by:
-
Miquel Raynal authored
Create a specific .c file for OF related module handling. Move of_modalias() inside as a first step. The helper is exposed through of.h even though it is only used by core files because the users from device.c will soon be split into an OF-only helper in module.c as well as a device-oriented inline helper in of_device.h. Putting this helper in of_private.h would require to include of_private.h from of_device.h, which is not acceptable. Suggested-by:
Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
Miquel Raynal authored
This helper does not produce a real modalias, but tries to get the "product" compatible part of the "vendor,product" compatibles only. It is far from creating a purely useful modalias string and does not seem to be used like that directly anyway, so let's try to give this helper a more meaningful name before moving there a real modalias helper (already existing under of/device.c). Also update the various documentations to refer to the strings as "aliases" rather than "modaliases" which has a real meaning in the Linux kernel. There is no functional change. Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sebastian Reichel <sre@kernel.org> Cc: Wolfram Sang <wsa@kernel.org> Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sebastian Reichel <sre@kernel.org> Link: https://lore.kernel.org/r/20230404172148.82422-9-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Miquel Raynal authored
This function only needs a "struct device_node" to work, but for convenience the author (and only user) of this helper did use a "struct device" and put it in device.c. Let's convert this helper to take a "struct device node" instead. This change asks for two additional changes: renaming it "of_modalias()" to fit the current naming, and moving it outside of device.c which will be done in a follow-up commit. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in platforn-name. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Neil Armstrong authored
Convert the Amlogic Meson GX eFuse bindings to dt-schema. Take in account the used variant with amlogic,meson-gx-efuse. Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Neil Armstrong authored
Convert the Amlogic Meson6 eFuse bindings to dt-schema. Reviewed-by:
-
Nick Alcock authored
This driver has a MODULE_LICENSE but is not tristate so cannot be built as a module, unlike all its peers: make it modular to match. Signed-off-by:
Nick Alcock <nick.alcock@oracle.com> Suggested-by:
Michal Simek <michal.simek@amd.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Michal Simek <michal.simek@xilinx.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Johan Hovold authored
The SPMI PMIC register region width is fixed and should not be encoded in the devicetree. Amend the example with a parent pmic node with the expected '#address-cells' and '#size-cells' and fix up the 'reg' property. Fixes: 9664a6b5 ("dt-bindings: nvmem: add binding for QTI SPMI SDAM") Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
-
Miquel Raynal authored
The helper generating an OF based modalias (of_device_get_modalias()) works fine, but due to the use of snprintf() internally it needs a buffer one byte longer than what should be needed just for the entire string (excluding the '\0'). Most users of this helper are sysfs hooks providing the modalias string to users. They all provide a PAGE_SIZE buffer which is way above the number of bytes required to fit the modalias string and hence do not suffer from this issue. There is another user though, of_device_request_module(), which is only called by drivers/usb/common/ulpi.c. This request module function is faulty, but maybe because in most cases there is an alternative, ULPI driver users have not noticed it. In this function, of_device_get_modalias() is called twice. The first time without buffer just to get the number of bytes required by the modalias string (excluding the null byte), and a second time, after buffer allocation, to fill the buffer. The allocation asks for an additional byte, in order to store the trailing '\0'. However, the buffer *length* provided to of_device_get_modalias() excludes this extra byte. The internal use of snprintf() with a length that is exactly the number of bytes to be written has the effect of using the last available byte to store a '\0', which then smashes the last character of the modalias string. Provide the actual size of the buffer to of_device_get_modalias() to fix this issue. Note: the "str[size - 1] = '\0';" line is not really needed as snprintf will anyway end the string with a null byte, but there is a possibility that this function might be called on a struct device_node without compatible, in this case snprintf() would not be executed. So we keep it just to avoid possible unbounded strings. Cc: Stephen Boyd <sboyd@kernel.org> Cc: Peter Chen <peter.chen@kernel.org> Fixes: 9c829c09 ("of: device: Support loading a module with OF based modalias") Signed-off-by:
-
Dae R. Jeong authored
During fuzzing, a general protection fault is observed in vmci_host_poll(). general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf] RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926 <- omitting registers -> Call Trace: <TASK> lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162 add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22 poll_wait include/linux/poll.h:49 [inline] vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174 vfs_poll include/linux/poll.h:88 [inline] do_pollfd fs/select.c:873 [inline] do_poll fs/select.c:921 [inline] do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015 __do_sys_ppoll fs/select.c:1121 [inline] __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Example thread interleaving that causes the general protection fault is as follows: CPU1 (vmci_host_poll) CPU2 (vmci_host_do_init_context) ----- ----- // Read uninitialized context context = vmci_host_dev->context; // Initialize context vmci_host_dev->context = vmci_ctx_create(); vmci_host_dev->ct_type = VMCIOBJ_CONTEXT; if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) { // Dereferencing the wrong pointer poll_wait(..., &context->host_context); } In this scenario, vmci_host_poll() reads vmci_host_dev->context first, and then reads vmci_host_dev->ct_type to check that vmci_host_dev->context is initialized. However, since these two reads are not atomically executed, there is a chance of a race condition as described above. To fix this race condition, read vmci_host_dev->context after checking the value of vmci_host_dev->ct_type so that vmci_host_poll() always reads an initialized context. Reported-by:Dae R. Jeong <threeearcat@gmail.com> Fixes: 8bf50399 ("VMCI: host side driver implementation.") Signed-off-by:
-
- 29 Mar, 2023 4 commits
-
-
Nipun Gupta authored
Create sysfs entry for CDX devices. Sysfs entries provided in each of the CDX device detected by the CDX controller - vendor id - device id - remove - reset of the device. - driver override Signed-off-by:
Puneet Gupta <puneet.gupta@amd.com> Signed-off-by:
Nipun Gupta <nipun.gupta@amd.com> Signed-off-by:
Tarak Reddy <tarak.reddy@amd.com> Reviewed-by:
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Tested-by:
Nikhil Agarwal <nikhil.agarwal@amd.com> Link: https://lore.kernel.org/r/20230313132636.31850-8-nipun.gupta@amd.comSigned-off-by:
-
Nipun Gupta authored
RPMsg is used as a transport communication channel. This change introduces RPMsg driver and integrates it with the CDX controller. Signed-off-by:
Abhijit Gangurde <abhijit.gangurde@amd.com> Signed-off-by:
-
Nipun Gupta authored
CDX controller uses MCDI interface as a protocol to communicate with the RPU firmware and registers the detected CDX devices on the CDX bus. It also uses RPMsg as the communication channel with the Firmware. Signed-off-by:
-
Nipun Gupta authored
The MCDI (Management CPU Driver Interface) is used as a protocol to communicate with the RPU firmware. It has pre-defined set of messages for different message exchanges between APU and RPU. Signed-off-by:
-
