This patch adds Loongson-2K BMC IPMI support.
According to the existing design, we use software simulation to
implement the KCS interface registers: Stauts/Command/Data_Out/Data_In.
Also since both host side and BMC side read and write kcs status, fifo flag
is used to ensure data consistency.
The single KCS message block is as follows:
+-------------------------------------------------------------------------+
|FIFO flags| KCS register data | CMD data | KCS version | WR REQ | WR ACK |
+-------------------------------------------------------------------------+
Co-developed-by: Chong Qiao <qiaochong@loongson.cn>
Signed-off-by: Chong Qiao <qiaochong@loongson.cn>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Acked-by: Corey Minyard <corey@minyard.net>
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
Message-ID: <8f9ffb6f0405345af8f04193ce1510aacd075e72.1756987761.git.zhoubinbin@loongson.cn>
Signed-off-by: Corey Minyard <corey@minyard.net>
In nested arrays don't require that the intermediate attribute
type should be a valid attribute type, it might just be zero
or an incrementing index, it is often not even used.
See include/net/netlink.h about NLA_NESTED_ARRAY:
> The difference to NLA_NESTED is the structure:
> NLA_NESTED has the nested attributes directly inside
> while an array has the nested attributes at another
> level down and the attribute types directly in the
> nesting don't matter.
Example based on include/uapi/linux/wireguard.h:
> WGDEVICE_A_PEERS: NLA_NESTED
> 0: NLA_NESTED
> WGPEER_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
> [..]
> 0: NLA_NESTED
> ...
> ...
Previous the check required that the nested type was valid
in the parent attribute set, which in this case resolves to
WGDEVICE_A_UNSPEC, which is YNL_PT_REJECT, and it took the
early exit and returned YNL_PARSE_CB_ERROR.
This patch renames the old nl_attr_validate() to
__nl_attr_validate(), and creates a new inline function
nl_attr_validate() to mimic the old one.
The new __nl_attr_validate() takes the attribute type as an
argument, so we can use it to validate attributes of a
nested attribute, in the context of the parents attribute
type, which in the above case is generated as:
[WGDEVICE_A_PEERS] = {
.name = "peers",
.type = YNL_PT_NEST,
.nest = &wireguard_wgpeer_nest,
},
__nl_attr_validate() only checks if the attribute length
is plausible for a given attribute type, so the .nest in
the above example is not used.
As the new inline function needs to be defined after
ynl_attr_type(), then the definitions are moved down,
so we avoid a forward declaration of ynl_attr_type().
Some other examples are NL80211_BAND_ATTR_FREQS (nest) and
NL80211_ATTR_SUPPORTED_COMMANDS (u32) both in nl80211-user.c
$ make -C tools/net/ynl/generated nl80211-user.c
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20250915144301.725949-7-ast@fiberby.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Refactor the generation of local variables needed when building
requests, by moving the logic from put_req_nested() into a new
helper put_local_vars(), and use the helper before .attr_put() is
called, thus generating the local variables assumed by .attr_put().
Previously only put_req_nested() generated the variables assumed
by .attr_put(), print_req() only generated the count iterator `i`,
and print_dump() neither generated `i` nor `array`.
This patch fixes the build errors below:
$ make -C tools/net/ynl/generated/
[...]
-e GEN wireguard-user.c
-e GEN wireguard-user.h
-e CC wireguard-user.o
wireguard-user.c: In function ‘wireguard_get_device_dump’:
wireguard-user.c:480:9: error: ‘array’ undeclared (first use in func)
480 | array = ynl_attr_nest_start(nlh, WGDEVICE_A_PEERS);
| ^~~~~
wireguard-user.c:480:9: note: each undeclared identifier is reported
only once for each function it appears in
wireguard-user.c:481:14: error: ‘i’ undeclared (first use in func)
481 | for (i = 0; i < req->_count.peers; i++)
| ^
wireguard-user.c: In function ‘wireguard_set_device’:
wireguard-user.c:533:9: error: ‘array’ undeclared (first use in func)
533 | array = ynl_attr_nest_start(nlh, WGDEVICE_A_PEERS);
| ^~~~~
make: *** [Makefile:52: wireguard-user.o] Error 1
make: Leaving directory '/usr/src/linux/tools/net/ynl/generated'
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20250915144301.725949-5-ast@fiberby.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a check to verify that the sub-type is "nest", and throw an
exception if no policy could be generated, as a guard to prevent
against generating a bad policy.
This is a trivial patch with no behavioural changes intended.
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20250915144301.725949-4-ast@fiberby.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds support for NLA_POLICY_NESTED_ARRAY() policies.
Example spec (from future wireguard.yaml):
-
name: wgpeer
attributes:
-
name: allowedips
type: indexed-array
sub-type: nest
nested-attributes: wgallowedip
yields NLA_POLICY_NESTED_ARRAY(wireguard_wgallowedip_nl_policy).
This doesn't change any currently generated code, as it isn't
used in any specs currently used for generating code.
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20250915144301.725949-3-ast@fiberby.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Allow using custom name-prefix with constants,
just like it is for enum and flags declarations.
This is needed for generating WG_KEY_LEN in
include/uapi/linux/wireguard.h from a spec.
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20250915144301.725949-2-ast@fiberby.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
With indexed-array types such as "ops" from
Documentation/netlink/specs/nlctrl.yaml, the generator creates code
such as:
int nlctrl_getfamily_rsp_parse(const struct nlmsghdr *nlh,
struct ynl_parse_arg *yarg)
{
struct nlctrl_getfamily_rsp *dst;
const struct nlattr *attr_ops;
const struct nlattr *attr;
struct ynl_parse_arg parg;
unsigned int n_ops = 0;
int i;
...
ynl_attr_for_each(attr, nlh, yarg->ys->family->hdr_len) {
unsigned int type = ynl_attr_type(attr);
if (type == CTRL_ATTR_FAMILY_ID) {
...
} else if (type == CTRL_ATTR_OPS) {
const struct nlattr *attr2;
attr_ops = attr;
ynl_attr_for_each_nested(attr2, attr) {
if (ynl_attr_validate(yarg, attr2))
return YNL_PARSE_CB_ERROR;
n_ops++;
}
} else {
...
}
}
if (n_ops) {
dst->ops = calloc(n_ops, sizeof(*dst->ops));
dst->_count.ops = n_ops;
i = 0;
parg.rsp_policy = &nlctrl_op_attrs_nest;
ynl_attr_for_each_nested(attr, attr_ops) {
...
}
}
return YNL_PARSE_CB_OK;
}
It is clear that due to the sequential nature of code execution, when
n_ops (initially zero) is incremented, attr_ops is also assigned from
the value of "attr" (the current iterator).
But some compilers, like gcc version 12.2.0 (Debian 12.2.0-14+deb12u1)
as distributed by Debian Bookworm, seem to be not sophisticated enough
to see this, and fail to compile (warnings treated as errors):
In file included from ../lib/ynl.h:10,
from nlctrl-user.c:9:
In function ‘ynl_attr_data_end’,
inlined from ‘nlctrl_getfamily_rsp_parse’ at nlctrl-user.c:427:3:
../lib/ynl-priv.h:209:44: warning: ‘attr_ops’ may be used uninitialized [-Wmaybe-uninitialized]
209 | return (char *)ynl_attr_data(attr) + ynl_attr_data_len(attr);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
nlctrl-user.c: In function ‘nlctrl_getfamily_rsp_parse’:
nlctrl-user.c:341:30: note: ‘attr_ops’ was declared here
341 | const struct nlattr *attr_ops;
| ^~~~~~~~
It is a pity that we have to do this, but I see no other way than to
suppress the false positive by appeasing the compiler and initializing
the "*attr_{aspec.c_name}" variable with a bogus value (NULL). This will
never be used - at runtime it will always be overwritten when
"n_{struct[anest].c_name}" is non-zero.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20250915144414.1185788-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add shutdown handler to the Synopsys DesignWare I3C master driver,
ensuring the device is gracefully disabled during system shutdown.
The shutdown handler cancels any pending hot-join work and disables
interrupts.
Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com>
Link: https://lore.kernel.org/r/20250730151207.4113708-1-manikanta.guntupalli@amd.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Add device tree binding support for the I3C Bus Interface on Renesas
RZ/V2H(P) and RZ/V2N SoCs. The I3C IP on these SoCs is identical to
that found on the RZ/G3E SoC.
Add new compatible strings "renesas,r9a09g056-i3c" for RZ/V2N and
"renesas,r9a09g057-i3c" for RZ/V2H(P). Both variants use
"renesas,r9a09g047-i3c" as a fallback compatible to indicate hardware
compatibility with the RZ/G3E implementation.
Update the title to be more generic as it now covers multiple SoC
families beyond just RZ/G3S and RZ/G3E.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20250908093930.12591-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
In svc_i3c_master_handle_ibi(), an IBI slot is fetched from the pool
to store the IBI payload. However, when an error condition is encountered,
the function returns without recycling the IBI slot, resulting in an IBI
slot leak.
Fixes: c85e209b79 ("i3c: master: svc: fix ibi may not return mandatory data byte")
Signed-off-by: Stanley Chu <yschu@nuvoton.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250829012309.3562585-3-yschu@nuvoton.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Driver wants to nack the IBI request when the target is not in the
known address list. In below code, svc_i3c_master_nack_ibi() will
cause undefined behavior when using AUTOIBI with auto response rule,
because hw always auto ack the IBI request.
switch (ibitype) {
case SVC_I3C_MSTATUS_IBITYPE_IBI:
dev = svc_i3c_master_dev_from_addr(master, ibiaddr);
if (!dev || !is_events_enabled(master, SVC_I3C_EVENT_IBI))
svc_i3c_master_nack_ibi(master);
...
break;
AutoIBI has another issue that the controller doesn't quit AutoIBI state
after IBIWON polling timeout when there is a SDA glitch(high->low->high).
1. SDA high->low: raising an interrupt to execute IBI ISR
2. SDA low->high
3. Driver writes an AutoIBI request
4. AutoIBI process does not start because SDA is not low
5. IBIWON polling times out
6. Controller reamins in AutoIBI state and doesn't accept EmitStop request
Emitting broadcast address with IBIRESP_MANUAL avoids both issues.
Fixes: dd3c52846d ("i3c: master: svc: Add Silvaco I3C master driver")
Signed-off-by: Stanley Chu <yschu@nuvoton.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250829012309.3562585-2-yschu@nuvoton.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Add support for Analog Devices I3C Controller IP, an AXI-interfaced IP
core that supports I3C and I2C devices, multiple speed-grades and
I3C IBIs.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Jorge Marques <jorge.marques@analog.com>
Link: https://lore.kernel.org/r/20250827-adi-i3c-master-v9-2-04413925abe1@analog.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Add bindings doc for ADI I3C Controller IP core, a FPGA synthesizable IP
core that implements the MIPI I3C Basic controller specification.
The IP Core is versioned following Semantic Versioning 2.0.0 and
ADI's open-source HDL guidelines for devicetree bindings and drivers.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jorge Marques <jorge.marques@analog.com>
Link: https://lore.kernel.org/r/20250827-adi-i3c-master-v9-1-04413925abe1@analog.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Commit 3a379bbcea ("i3c: Add core I3C infrastructure") set the default
adapter timeout for I2C transfers as 1000 (ms). However that parameter
is defined in jiffies not in milliseconds.
With mipi-i3c-hci driver this wasn't visible until commit c0a90eb55a
("i3c: mipi-i3c-hci: use adapter timeout value for I2C transfers").
Fix this by setting the default timeout as HZ (CONFIG_HZ) not 1000.
Fixes: 1b84691e78 ("i3c: dw: use adapter timeout value for I2C transfers")
Fixes: be27ed6728 ("i3c: master: cdns: use adapter timeout value for I2C transfers")
Fixes: c0a90eb55a ("i3c: mipi-i3c-hci: use adapter timeout value for I2C transfers")
Fixes: a747e01ada ("i3c: master: svc: use adapter timeout value for I2C transfers")
Fixes: d028219a9f ("i3c: master: Add basic driver for the Renesas I3C controller")
Fixes: 3a379bbcea ("i3c: Add core I3C infrastructure")
Cc: stable@vger.kernel.org # 6.17
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20250905100320.954536-1-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Get rid of local DBG() macro and convert remaining debug prints to
dev_dbg() which can be controlled without code recompile when kernel is
built with dynamic debug support.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20250827103009.243771-6-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
These function enter DBG("") printouts are not very useful in error
report point of view because they require code recompile. In which case
they can be replaced with more informative debug prints if needed so
remove them for now.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20250827103009.243771-5-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Use the same "Ring" prefix in all prints that print out the ring number.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250827103009.243771-4-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Ring interrupt bit 7, INTR_WARN_INS_STOP_MODE was probably drafted at
some point but is marked as reserved in the MIPI I3C HCI specification
versions 1.1 and 1.2 that came out after the initial code and also in
the earlier specification versions so remove it.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250827103009.243771-3-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Change interrupt status prints from local DBG() macro to dev_dbg() in
order to make it easier to enable them without needing to recompile code
with DEBUG defined.
While doing so, spell out the status register names as they are in the
specification to make it easier to differentiate between different
interrupt status registers.
Since dynamic debug prints can include the line number remove the "(in)"
and "(out)" markers from the PIO interrupt status prints.
Prefix the ring interrupt status print using "Ring %d" instead of "rh%d"
to make it uniform across all other prints showing the ring number.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250827103009.243771-2-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Stop using I2C DMA-safe API for two reasons:
- Not needed if driver is using PIO mode.
- DMA transfers needs a DWORD align sized receive bounce buffer when the
device DMA is IOMMU mapped, which is causing needless double bounce
buffering in that case.
Cc: Billy Tsai <billy_tsai@aspeedtech.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250822105630.2820009-5-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
DMA transfer faults on Intel hardware when the IOMMU is enabled and
driver initialization will fail when attempting to do the first transfer:
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read NO_PASID] Request device [00:11.0] fault addr 0x676e3000 [fault reason 0x71] SM: Present bit in first-level paging entry is clear
i3c mipi-i3c-hci.0: ring 0: Transfer Aborted
mipi-i3c-hci mipi-i3c-hci.0: probe with driver mipi-i3c-hci failed with error -62
Reason for this is that the IOMMU setup is done for the physical devices
only and not for the virtual I3C Controller device object.
Therefore use the pointer to a physical device object with the DMA API.
Due to a data corruption observation when the device DMA is IOMMU
mapped, a properly sized receive bounce buffer is required if transfer
length is not a multiple of DWORDs.
Reported-by:
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250822105630.2820009-4-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
So far only I3C private and I2C transfers have required a bounce buffer
for DMA transfers when buffer is not DMA'able.
It was observed that when the device DMA is IOMMU mapped and the receive
length is not a multiple of DWORDs (32-bit), the last DWORD is padded
with stale data from the RX FIFO, corrupting 1-3 bytes beyond the
expected data.
A similar issue, though less severe, occurs when an I3C target returns
less data than requested. In this case, the padding does not exceed the
requested number of bytes, assuming the device DMA is not IOMMU mapped.
Therefore, all I3C private transfer, CCC command payload and I2C
transfer receive buffers must be properly sized for the DMA being IOMMU
mapped. Even if those buffers are already DMA safe, their size may not
be DWORD aligned.
To prepare for the device DMA being IOMMU mapped and to address the
above issue, use helpers from I3C core for DMA mapping and bounce
buffering for all DMA transfers.
For now, require bounce buffer only when the buffer is in the
vmalloc() area to avoid unnecessary copying with CCC commands and
DMA-safe I2C transfers.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250822105630.2820009-3-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Some I3C controllers such as MIPI I3C HCI may pad the last DWORD (32-bit)
with stale data from the RX FIFO in DMA transfers if the receive length
is not DWORD aligned and when the device DMA is IOMMU mapped.
In such a case, a properly sized bounce buffer is required in order to
avoid possible data corruption. In a review discussion, proposal was to
have a common helpers in I3C core for DMA mapping and bounce buffer
handling.
Drivers may use the helper i3c_master_dma_map_single() to map a buffer
for a DMA transfer. It internally allocates a bounce buffer if buffer is
not DMA'able or when the driver requires it for a transfer.
Helper i3c_master_dma_unmap_single() does the needed cleanups and
data copying from the bounce buffer.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250822105630.2820009-2-jarkko.nikula@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
On partial failure, some sysfs files created before the failure might
not be removed. Add common cleanup step to remove them all immediately,
as is should be harmless to attempt to remove non-existing files.
Fixes: 0e414bf7ad ("drm/xe: Expose PCIe link downgrade attributes")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Zongyao Bai <zongyao.bai@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250915214716.1327379-2-zongyao.bai@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
These laptops are the same as the already known 14-fe0xxx models, but
with a Purwa SoC, SKU number 14-fe1xxx. [1]
The supported features are the same as for the original Omnibook X14:
- Keyboard (no function keys though)
- Display
- PWM brightness control
- Touchpad
- Touchscreen
- PCIe ports (pcie4, pcie6a)
- USB type-c, type-a
- WCN6855 Wifi-6E
- WCN6855 Bluetooth
- ADSP and CDSP
- X1 GPU
- GPIO Keys (Lid switch)
- Audio definition (works via USB and with internal speakers)
[1]: https://www.hp.com/us-en/shop/pdp/hp-omnibook-x-laptop-next-gen-ai-pc-14-fe100-14-a4nd1av-1#techSpecs
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-3-fa457ca30ffe@oldschoolsolutions.biz
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Extract common elements into a shared .dtsi file for HP Omnibook X14 to
support both Hamoa (x1e*/x1p6*) and Purwa (x1p4*/x1*) variants.
Required because the device trees are not compatible.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-2-fa457ca30ffe@oldschoolsolutions.biz
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The HP Omnibook X14 AI PC is available in fe0 (Hamoa, x1e80100) and
fe1 (Purwa, x1p42100) SKUs. Since they are not completely dtb-compatible,
add another variant:
hp,omnibook-x14-fe1 compatible to cqom,x1p42100
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-1-fa457ca30ffe@oldschoolsolutions.biz
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
With ZONE_DEVICE now available for s390, struct pages can be allocated
for proper DAX support in dcssblk driver via devm_memremap_pages().
Adding struct pages for a range requires that the range is aligned to
SUBSECTION_SIZE, which is defined as 2 MB in common code. Therefore,
only enable DAX support and allocate struct pages for DCSS ranges that
are aligned to 2 MB.
Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Add node to support I2C bus inside of IPQ5018.
Signed-off-by: Vandhiadevan Karunamoorthy <vkarunam@codeaurora.org>
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Link: https://lore.kernel.org/r/20250915-ipq5018-i2c-v1-1-46bbf27396d6@outlook.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Enable IRIS to allow using the hardware-accelerated video codecs. The
firmware is not upstream in linux-firmware yet, so users need to copy it
from Windows to qcom/x1e80100/dell/xps13-9345/qcvss8380.mbn (just like
GPU/ADSP/CDSP firmware).
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-9-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Enable IRIS to allow using the hardware-accelerated video codecs. The
firmware is not upstream in linux-firmware yet, so users need to copy it
from Windows to qcom/x1e80100/dell/latitude-7455/qcvss8380.mbn (just like
GPU/ADSP/CDSP firmware).
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-8-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Enable IRIS to allow using the hardware-accelerated video codecs. The
firmware is not upstream in linux-firmware yet, so users need to copy it
from Windows to qcom/x1e80100/dell/inspiron-14-plus-7441/qcvss8380.mbn
(just like GPU/ADSP/CDSP firmware).
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-7-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
IRIS firmware for the Lenovo Yoga Slim 7x is already upstream in
linux-firmware at qcom/x1e80100/LENOVO/83ED/qcvss8380.mbn, so enable IRIS
for the Slim 7x with the corresponding firmware-name property.
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-6-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
IRIS firmware for the Lenovo ThinkPad T14s is already upstream in
linux-firmware at qcom/x1e80100/LENOVO/21N1/qcvss8380.mbn, so enable IRIS
for the T14s with the corresponding firmware-name property.
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-5-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
IRIS firmware for x1e80100-crd is already upstream in linux-firmware in the
default path, so enable IRIS for the CRD to accelerate video decoding.
It looks like the X1P CRD might need a different IRIS firmware (possibly
even changes in the Linux kernel driver), so keep it local to the X1E CRD
for now.
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-4-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The reset and IOMMU management for remoteprocs like IRIS is implemented in
the hypervisor for older targets such as X1E [1]. When booting Linux/KVM
directly in EL2, this functionality is missing and the PAS interface
normally used by IRIS to boot the video firmware is not working.
The Venus driver supports starting the video firmware without using the PAS
interface. The same code also works for X1E when using KVM. However, for
the new IRIS dt-bindings it was decided to avoid using the dummy
"video-firmware" node in the device tree to describe the IOMMU [2].
Discussion is still ongoing how to describe this properly [3].
To avoid regressions when running using KVM, add a TODO in x1-el2.dtso for
now and disable IRIS even when it was enabled by the board.
[1]: https://resources.linaro.org/en/resource/sF8jXifdb9V1mUefdbfafa
[2]: https://lore.kernel.org/r/20250823155349.22344-2-krzysztof.kozlowski@linaro.org/
[3]: https://lore.kernel.org/r/20250819165447.4149674-12-mukesh.ojha@oss.qualcomm.com/
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-3-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the IRIS video codec to accelerate video decoding/encoding. Copied
mostly from sm8550.dtsi, only the opp-table is slightly different for X1E.
For opp-240000000, we need to vote for a higher OPP on one of the power
domains, because the voltage requirements for the PLL and the derived
clocks differ (sm8550.dtsi has the same).
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Inspiron 14p
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED
Tested-by: Anthony Ruhier <aruhier@mailbox.org> # Lenovo Slim 7x
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-2-1f928de08fd4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the missing resets for the two SDCC controllers to allow fully
resetting previous hardware state from the bootloader.
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-3-a5c705df0c45@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
On most MSM8939 devices, the bootloader already initializes the display to
show the boot splash screen. In this situation, MDSS is already configured
and left running when starting Linux. To avoid side effects from the
bootloader configuration, the MDSS reset can be specified in the device
tree to start again with a clean hardware state.
The reset for MDSS is currently missing in msm8939.dtsi, which causes
errors when the MDSS driver tries to re-initialize the registers:
dsi_err_worker: status=6
dsi_err_worker: status=6
dsi_err_worker: status=6
...
It turns out that we have always indirectly worked around this by building
the MDSS driver as a module. Before v6.17, the power domain was temporarily
turned off until the module was loaded, long enough to clear the register
contents. In v6.17, power domains are not turned off during boot until
sync_state() happens, so this is no longer working. Even before v6.17 this
resulted in broken behavior, but notably only when the MDSS driver was
built-in instead of a module.
Cc: stable@vger.kernel.org
Fixes: 61550c6c15 ("arm64: dts: qcom: Add msm8939 SoC")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-2-a5c705df0c45@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
already initializes the display to show the boot splash screen. In this
situation, MDSS is already configured and left running when starting Linux.
To avoid side effects from the bootloader configuration, the MDSS reset can
be specified in the device tree to start again with a clean hardware state.
The reset for MDSS is currently missing in msm8916.dtsi, which causes
errors when the MDSS driver tries to re-initialize the registers:
dsi_err_worker: status=6
dsi_err_worker: status=6
dsi_err_worker: status=6
...
It turns out that we have always indirectly worked around this by building
the MDSS driver as a module. Before v6.17, the power domain was temporarily
turned off until the module was loaded, long enough to clear the register
contents. In v6.17, power domains are not turned off during boot until
sync_state() happens, so this is no longer working. Even before v6.17 this
resulted in broken behavior, but notably only when the MDSS driver was
built-in instead of a module.
Cc: stable@vger.kernel.org
Fixes: 305410ffd1 ("arm64: dts: msm8916: Add display support")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-1-a5c705df0c45@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The frame@17c27000 node uses the wrong base address 0x17c26000.
This does not match the node name.
Update the reg property to use the correct base address 0x17c27000,
which matches the node name and avoids the overlap.
Fixes: e13c6d144f ("arm64: dts: qcom: sm8150: Add base dts file")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250915200132.774377-1-alok.a.tiwari@oracle.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Particle Tachyon is a single board computer with 5G connectivity
with AI accelerator, based on the Qualcomm QCM6490 platform.
Introduce the board, with support for UFS, USB, USB Type-C PD and
altmode (DisplayPort), GPU, charger/battery status, PCIe shield,
SD-card, and remoteprocs.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250915-tachyon-v2-3-4f8b02a17512@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Particle Tachyon is a single board computer with 5G connectivity
with AI accelerator, based on the Qualcomm QCM6490 platform.
Document the top-level compatible for this board.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250915-tachyon-v2-2-4f8b02a17512@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
A number of existing schemas use 'leds' property to provide
phandle-array of LED(s) to the consumer. Additionally, with the
upcoming privacy-led support in device-tree, v4l2 subnode could be a
LED consumer, meaning that all camera sensors should support 'leds'
and 'led-names' property via common 'video-interface-devices.yaml'.
To avoid duplication, unify 'leds' property from existing schemas
to newly introduced 'led-consumer.yaml'.
Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://lore.kernel.org/r/20250910-leds-v5-2-bb90a0f897d5@vinarskis.com
Signed-off-by: Lee Jones <lee@kernel.org>
