<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/fsi, branch v5.15.208</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-09-19T10:22:46+00:00</updated>
<entry>
<title>fsi: aspeed: Reset master errors after CFAM reset</title>
<updated>2023-09-19T10:22:46+00:00</updated>
<author>
<name>Eddie James</name>
<email>eajames@linux.ibm.com</email>
</author>
<published>2023-06-12T19:56:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3274e32fc969e860cc9ea5a3cd5c1a1b8e53c943'/>
<id>urn:sha1:3274e32fc969e860cc9ea5a3cd5c1a1b8e53c943</id>
<content type='text'>
[ Upstream commit 52300909f4670ac552bfeb33c1355b896eac8c06 ]

It has been observed that sometimes the FSI master will return all 0xffs
after a CFAM has been taken out of reset, without presenting any error.
Resetting the FSI master errors resolves the issue.

Fixes: 4a851d714ead ("fsi: aspeed: Support CFAM reset GPIO")
Signed-off-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20230612195657.245125-8-eajames@linux.ibm.com
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsi: master-ast-cf: Add MODULE_FIRMWARE macro</title>
<updated>2023-09-06T20:28:39+00:00</updated>
<author>
<name>Juerg Haefliger</name>
<email>juerg.haefliger@canonical.com</email>
</author>
<published>2023-06-28T09:50:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=da0e7d435e31f273a398c54f9854ef812f9dff51'/>
<id>urn:sha1:da0e7d435e31f273a398c54f9854ef812f9dff51</id>
<content type='text'>
commit 3a1d7aff6e65ad6e285e28abe55abbfd484997ee upstream.

The module loads firmware so add a MODULE_FIRMWARE macro to provide that
information via modinfo.

Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire")
Cc: stable@vger.kernel.org # 4.19+
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@canonical.com&gt;
Link: https://lore.kernel.org/r/20230628095039.26218-1-juerg.haefliger@canonical.com
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>WRITE is "data source", not destination...</title>
<updated>2023-02-09T10:26:34+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2022-09-15T22:59:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a3649bf5bef2c6f8b0e28e9ef394b367d09f9ef'/>
<id>urn:sha1:7a3649bf5bef2c6f8b0e28e9ef394b367d09f9ef</id>
<content type='text'>
[ Upstream commit 974c36fb828aeae7b4f9063f94860ae6c5633efd ]

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsi: core: Check error number after calling ida_simple_get</title>
<updated>2022-10-26T10:35:17+00:00</updated>
<author>
<name>Jiasheng Jiang</name>
<email>jiasheng@iscas.ac.cn</email>
</author>
<published>2022-01-11T07:34:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f921d62c236ac823ce271a8b7ee80504b62c19c'/>
<id>urn:sha1:2f921d62c236ac823ce271a8b7ee80504b62c19c</id>
<content type='text'>
[ Upstream commit 35af9fb49bc5c6d61ef70b501c3a56fe161cce3e ]

If allocation fails, the ida_simple_get() will return error number.
So master-&gt;idx could be error number and be used in dev_set_name().
Therefore, it should be better to check it and return error if fails,
like the ida_simple_get() in __fsi_get_new_minor().

Fixes: 09aecfab93b8 ("drivers/fsi: Add fsi master definition")
Signed-off-by: Jiasheng Jiang &lt;jiasheng@iscas.ac.cn&gt;
Reviewed-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20220111073411.614138-1-jiasheng@iscas.ac.cn
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsi: occ: Force sequence numbering per OCC</title>
<updated>2022-07-07T15:53:32+00:00</updated>
<author>
<name>Eddie James</name>
<email>eajames@linux.ibm.com</email>
</author>
<published>2021-07-21T19:02:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=25daf14eacd1d6bd24afd879021d2447c5254c4e'/>
<id>urn:sha1:25daf14eacd1d6bd24afd879021d2447c5254c4e</id>
<content type='text'>
commit 62f79f3d0eb9f4c224bcc3c7f6fa758515a0a7fa upstream.

Set and increment the sequence number during the submit operation.
This prevents sequence number conflicts between different users of
the interface. A sequence number conflict may result in a user
getting an OCC response meant for a different command. Since the
sequence number is now modified, the checksum must be calculated and
set before submitting the command.

Signed-off-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Reviewed-by: Joel Stanley &lt;joel@jms.id.au&gt;
Link: https://lore.kernel.org/r/20210721190231.117185-2-eajames@linux.ibm.com
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fsi: Aspeed: Fix a potential double free</title>
<updated>2022-04-08T12:23:44+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2022-01-09T21:56:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=72c4f4200f9804adf10d598141bbd1eed5ebca59'/>
<id>urn:sha1:72c4f4200f9804adf10d598141bbd1eed5ebca59</id>
<content type='text'>
[ Upstream commit 83ba7e895debc529803a7a258653f2fe9bf3bf40 ]

A struct device can never be devm_alloc()'ed.
Here, it is embedded in "struct fsi_master", and "struct fsi_master" is
embedded in "struct fsi_master_aspeed".

Since "struct device" is embedded, the data structure embedding it must be
released with the release function, as is already done here.

So use kzalloc() instead of devm_kzalloc() when allocating "aspeed" and
update all error handling branches accordingly.

This prevent a potential double free().

This also fix another issue if opb_readl() fails. Instead of a direct
return, it now jumps in the error handling path.

Fixes: 606397d67f41 ("fsi: Add ast2600 master driver")
Suggested-by: Greg KH &lt;gregkh@linuxfoundation.org&gt;
Suggested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/2c123f8b0a40dc1a061fae982169fe030b4f47e6.1641765339.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsi: scom: Remove retries in indirect scoms</title>
<updated>2022-04-08T12:23:44+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2021-12-07T03:38:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=28a886a308ed5221557bcc8d812e0cf0228501a8'/>
<id>urn:sha1:28a886a308ed5221557bcc8d812e0cf0228501a8</id>
<content type='text'>
[ Upstream commit ab1b79159ad5a6dc4e4994b49737f7feb13b7155 ]

In commit f72ddbe1d7b7 ("fsi: scom: Remove retries") the retries were
removed from get and put scoms. That patch missed the retires in get and
put indirect scom.

For the same reason, remove them from the scom driver to allow the
caller to decide to retry.

This removes the following special case which would have caused the
retry code to return early:

 -       if ((ind_data &amp; XSCOM_DATA_IND_COMPLETE) || (err != SCOM_PIB_BLOCKED))
 -               return 0;

I believe this case is handled.

Fixes: f72ddbe1d7b7 ("fsi: scom: Remove retries")
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Reviewed-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20211207033811.518981-3-joel@jms.id.au
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsi: scom: Fix error handling</title>
<updated>2022-04-08T12:23:44+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2021-12-07T03:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9fdc543b0e2ac6058b03df5e300e6f2ed1834d07'/>
<id>urn:sha1:9fdc543b0e2ac6058b03df5e300e6f2ed1834d07</id>
<content type='text'>
[ Upstream commit d46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c ]

SCOM error handling is made complex by trying to pass around two bits of
information: the function return code, and a status parameter that
represents the CFAM error status register.

The commit f72ddbe1d7b7 ("fsi: scom: Remove retries") removed the
"hidden" retries in the SCOM driver, in preference of allowing the
calling code (userspace or driver) to decide how to handle a failed
SCOM. However it introduced a bug by attempting to be smart about the
return codes that were "errors" and which were ok to fall through to the
status register parsing.

We get the following errors:

 - EINVAL or ENXIO, for indirect scoms where the value is invalid
 - EINVAL, where the size or address is incorrect
 - EIO or ETIMEOUT, where FSI write failed (aspeed master)
 - EAGAIN, where the master detected a crc error (GPIO master only)
 - EBUSY, where the bus is disabled (GPIO master in external mode)

In all of these cases we should fail the SCOM read/write and return the
error.

Thanks to Dan Carpenter for the detailed bug report.

Fixes: f72ddbe1d7b7 ("fsi: scom: Remove retries")
Link: https://lists.ozlabs.org/pipermail/linux-fsi/2021-November/000235.html
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Reviewed-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20211207033811.518981-2-joel@jms.id.au
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsi/sbefifo: Fix reset timeout</title>
<updated>2021-06-04T06:36:57+00:00</updated>
<author>
<name>Joachim Fenkes</name>
<email>FENKES@de.ibm.com</email>
</author>
<published>2020-07-24T07:15:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ab1428dfe2c66b51e0b41337cd0164da0ab6080'/>
<id>urn:sha1:9ab1428dfe2c66b51e0b41337cd0164da0ab6080</id>
<content type='text'>
On BMCs with lower timer resolution than 1ms, msleep(1) will take
way longer than 1ms, so looping 10k times won't wait for 10s but
significantly longer.

Fix this by using jiffies like the rest of the code.

Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
Signed-off-by: Joachim Fenkes &lt;fenkes@de.ibm.com&gt;
Link: https://lore.kernel.org/r/20200724071518.430515-3-joel@jms.id.au
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>fsi/sbefifo: Clean up correct FIFO when receiving reset request from SBE</title>
<updated>2021-06-04T05:53:40+00:00</updated>
<author>
<name>Joachim Fenkes</name>
<email>FENKES@de.ibm.com</email>
</author>
<published>2020-07-24T07:15:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95152433e46fdb36652ebdbea442356a16ae1fa6'/>
<id>urn:sha1:95152433e46fdb36652ebdbea442356a16ae1fa6</id>
<content type='text'>
When the SBE requests a reset via the down FIFO, that is also the
FIFO we should go and reset ;)

Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
Signed-off-by: Joachim Fenkes &lt;FENKES@de.ibm.com&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Link: https://lore.kernel.org/r/20200724071518.430515-2-joel@jms.id.au
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
</feed>
