From: Peter Korsgaard peter@korsgaard.com
Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed.
Fixes: 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") Cc: stable@vger.kernel.org Signed-off-by: Peter Korsgaard peter@korsgaard.com Reviewed-by: Michal Simek michal.simek@amd.com Tested-by: Michal Simek michal.simek@amd.com Signed-off-by: Srinivas Kandagatla srini@kernel.org State: upstream (c708bbd57d158d9f20c2fcea5bcb6e0afac77bef) (cherry picked from commit 94c91acb3721403501bafcdd041bcd422c5b23c4) Signed-off-by: Ivan Vera ivan.vera@enclustra.com --- drivers/nvmem/zynqmp_nvmem.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/nvmem/zynqmp_nvmem.c b/drivers/nvmem/zynqmp_nvmem.c index 68c51cc3efa1..0f308e53d82f 100644 --- a/drivers/nvmem/zynqmp_nvmem.c +++ b/drivers/nvmem/zynqmp_nvmem.c @@ -213,6 +213,7 @@ static int zynqmp_nvmem_probe(struct platform_device *pdev) econfig.word_size = 1; econfig.size = ZYNQMP_NVMEM_SIZE; econfig.dev = dev; + econfig.priv = dev; econfig.add_legacy_fixed_of_cells = true; econfig.reg_read = zynqmp_nvmem_read; econfig.reg_write = zynqmp_nvmem_write;
On Wed, Nov 05, 2025 at 01:36:19PM +0100, Ivan Vera wrote:
From: Peter Korsgaard peter@korsgaard.com
Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed.
Fixes: 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") Cc: stable@vger.kernel.org Signed-off-by: Peter Korsgaard peter@korsgaard.com Reviewed-by: Michal Simek michal.simek@amd.com Tested-by: Michal Simek michal.simek@amd.com Signed-off-by: Srinivas Kandagatla srini@kernel.org State: upstream (c708bbd57d158d9f20c2fcea5bcb6e0afac77bef) (cherry picked from commit 94c91acb3721403501bafcdd041bcd422c5b23c4)
Neither of these git ids are valid, where did you get them from?
thanks,
greg k-h
"Greg" == Greg KH gregkh@linuxfoundation.org writes:
On Wed, Nov 05, 2025 at 01:36:19PM +0100, Ivan Vera wrote:
From: Peter Korsgaard peter@korsgaard.com
Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed.
Fixes: 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") Cc: stable@vger.kernel.org Signed-off-by: Peter Korsgaard peter@korsgaard.com Reviewed-by: Michal Simek michal.simek@amd.com Tested-by: Michal Simek michal.simek@amd.com Signed-off-by: Srinivas Kandagatla srini@kernel.org State: upstream (c708bbd57d158d9f20c2fcea5bcb6e0afac77bef) (cherry picked from commit 94c91acb3721403501bafcdd041bcd422c5b23c4)
Neither of these git ids are valid, where did you get them from?
git describe --contains c708bbd57d158d9f20c2fcea5bcb6e0afac77bef next-20250505~21^2~1^2
I guess it should have been fe8abdd175d7b547ae1a612757e7902bcd62e9cf instead, E.G. what ended up in master?
On Thu, Nov 06, 2025 at 08:38:28AM +0100, Peter Korsgaard wrote:
"Greg" == Greg KH gregkh@linuxfoundation.org writes:
On Wed, Nov 05, 2025 at 01:36:19PM +0100, Ivan Vera wrote:
From: Peter Korsgaard peter@korsgaard.com
Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed.
Fixes: 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") Cc: stable@vger.kernel.org Signed-off-by: Peter Korsgaard peter@korsgaard.com Reviewed-by: Michal Simek michal.simek@amd.com Tested-by: Michal Simek michal.simek@amd.com Signed-off-by: Srinivas Kandagatla srini@kernel.org State: upstream (c708bbd57d158d9f20c2fcea5bcb6e0afac77bef) (cherry picked from commit 94c91acb3721403501bafcdd041bcd422c5b23c4)
Neither of these git ids are valid, where did you get them from?
git describe --contains c708bbd57d158d9f20c2fcea5bcb6e0afac77bef next-20250505~21^2~1^2
I guess it should have been fe8abdd175d7b547ae1a612757e7902bcd62e9cf instead, E.G. what ended up in master?
We can't take stuff in stable unless it is in Linus's tree.
thanks,
greg k-h
"Greg" == Greg KH gregkh@linuxfoundation.org writes:
Hi,
Neither of these git ids are valid, where did you get them from?
git describe --contains c708bbd57d158d9f20c2fcea5bcb6e0afac77bef next-20250505~21^2~1^2
I guess it should have been fe8abdd175d7b547ae1a612757e7902bcd62e9cf instead, E.G. what ended up in master?
We can't take stuff in stable unless it is in Linus's tree.
Sure, it was apparently just the wrong commit hash used, E.G.:
git describe --contains fe8abdd175d7b547ae1a612757e7902bcd62e9cf v6.16-rc1~30^2~32
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Ivan Vera -
Peter Korsgaard