* Remove dead code in the DW driver
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcz9pLAAoJEGXtNgF+CLcAi3AP/3pjOrrJ0G+G3hry40Zr12NO
JvbUmRPr0YUmcg479iIxgwuJ4Pj5GNGmczGGvfc6ZIKJdDCZEeu8aLIh/KLDzXPX
nQ0SlcXBYCIk8gOwtZs/zxB+Oi8DVoiT4iz0Q3vvcqCho1K09IfFCDC1S8CZPUho
72+KapR1nYBhm5gPKpunFn/II7l9UNAzeF1uWLjREm6pCG2/2UNHgzPYGVdp2Pf/
i2lm6PXTMJyca6pqSDbMRWyDNeMva5SURoTkavvvBTwnTQTJaPukMi/jgWElHJ3C
ajMJdDtbLBXKWv7La+G2LtlwbbFCDa5wf/V5G7LH4RnszLNWud2BdUhbLEUJWBSr
/+VpAyYSUuz3vAGAHVaC+Fe7NtYXIxODKEGlSTqwl1Ns31P8fAwX6n+RuHdFNxpl
wwIVaJZHeU62e5Z7nujQ9buJMDea2msqi5EqmtWubjN59C3rLRWZhwiL7YG3bjLc
NbcaL5+Fz1IByKiOq7BGrI2w2uV8fK2/hE2mgw4yuNXvo7G0oKloHnSjB9zOxacJ
HNCSDx6TnoWWfWCzGfXBKzc1ycTXyYY5vmk45qVA78H4a9LY0KG8WGDfsTPXmp44
+PGQ+GKvvuPMzyYC+ENx1LN5OLkiZqU5c69++pFqkEXHiyPin+Ig4qm4XKbWy5FZ
mwd5URtCnn2s0vD5DrDH
=/U9S
-----END PGP SIGNATURE-----
Merge tag 'i3c/for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux
Pull i3c update from Boris Brezillon:
- Fix a shift wrap bug in the core
- Remove dead code in the DW driver
* tag 'i3c/for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux:
i3c: Fix a shift wrap bug in i3c_bus_set_addr_slot_status()
i3c: master: dw: remove dead code from dw_i3c_master_*_xfers()
The problem here is that addr can be I3C_BROADCAST_ADDR (126). That
means we're shifting by (126 * 2) % 64 which is 60. The
I3C_ADDR_SLOT_STATUS_MASK is an enum which is an unsigned int in GCC
so shifts greater than 31 are undefined.
Fixes: 3a379bbcea ("i3c: Add core I3C infrastructure")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
The validation of random PID should be done by checking the
boardinfo->pid instead of info.pid which is empty.
Doing the change the info struture declaration is no longer necessary.
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: <stable@vger.kernel.org>
Fixes: 3a379bbcea ("i3c: Add core I3C infrastructure")
Signed-off-by: Vitor Soares <vitor.soares@synopsys.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
If we failed to retrieve the i3c dev, we should detach the i3c dev
I.E i3c_master_detach_i3c_dev().
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
This should be >= ARRAY_SIZE() to avoid reading one element beyond the
end of the array.
Fixes: 3a379bbcea ("i3c: Add core I3C infrastructure")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
We should return "ret" as-is. The "newdev" variable is a valid pointer.
Fixes: 3a379bbcea ("i3c: Add core I3C infrastructure")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Add core infrastructure to support I3C in Linux and document it.
This infrastructure adds basic I3C support. Advanced features will be
added afterwards.
There are a few design choices that are worth mentioning because they
impact the way I3C device drivers can interact with their devices:
- all functions used to send I3C/I2C frames must be called in
non-atomic context. Mainly done this way to ease implementation, but
this is not set in stone, and if anyone needs async support, new
functions can be added later on.
- the bus element is a separate object, but it's tightly coupled with
the master object. We thus have a 1:1 relationship between i3c_bus
and i3c_master_controller objects, and if 2 master controllers are
connected to the same bus and both exposed to the same Linux instance
they will appear as two distinct busses, and devices on this bus will
be exposed twice.
- I2C backward compatibility has been designed to be transparent to I2C
drivers and the I2C subsystem. The I3C master just registers an I2C
adapter which creates a new I2C bus. I'd say that, from a
representation PoV it's not ideal because what should appear as a
single I3C bus exposing I3C and I2C devices here appears as 2
different buses connected to each other through the parenting (the
I3C master is the parent of the I2C and I3C busses).
On the other hand, I don't see a better solution if we want something
that is not invasive.
Missing features:
- I3C HDR modes are not supported
- no support for multi-master and the associated concepts (mastership
handover, support for secondary masters, ...)
- I2C devices can only be described using DT because this is the only
use case I have. However, the framework can easily be extended with
ACPI and board info support
- I3C slave framework. This has been completely omitted, but shouldn't
have a huge impact on the I3C framework because I3C slaves don't see
the whole bus, it's only about handling master requests and generating
IBIs. Some of the struct, constant and enum definitions could be
shared, but most of the I3C slave framework logic will be different
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
