<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v6.6.66</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.66</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.66'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-12-14T19:00:23+00:00</updated>
<entry>
<title>i3c: master: svc: fix possible assignment of the same address to two devices</title>
<updated>2024-12-14T19:00:23+00:00</updated>
<author>
<name>Frank Li</name>
<email>Frank.Li@nxp.com</email>
</author>
<published>2024-10-02T14:50:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=35163f642d916473a77e5976691adf575f7390d9'/>
<id>urn:sha1:35163f642d916473a77e5976691adf575f7390d9</id>
<content type='text'>
commit 3b2ac810d86eb96e882db80a3320a3848b133208 upstream.

svc_i3c_master_do_daa() {
    ...
    for (i = 0; i &lt; dev_nb; i++) {
        ret = i3c_master_add_i3c_dev_locked(m, addrs[i]);
        if (ret)
            goto rpm_out;
    }
}

If two devices (A and B) are detected in DAA and address 0xa is assigned to
device A and 0xb to device B, a failure in i3c_master_add_i3c_dev_locked()
for device A (addr: 0xa) could prevent device B (addr: 0xb) from being
registered on the bus. The I3C stack might still consider 0xb a free
address. If a subsequent Hotjoin occurs, 0xb might be assigned to Device A,
causing both devices A and B to use the same address 0xb, violating the I3C
specification.

The return value for i3c_master_add_i3c_dev_locked() should not be checked
because subsequent steps will scan the entire I3C bus, independent of
whether i3c_master_add_i3c_dev_locked() returns success.

If device A registration fails, there is still a chance to register device
B. i3c_master_add_i3c_dev_locked() can reset DAA if a failure occurs while
retrieving device information.

Cc: stable@kernel.org
Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry")
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Link: https://lore.kernel.org/r/20241002-svc-i3c-hj-v6-6-7e6e1d3569ae@nxp.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin</title>
<updated>2024-12-14T19:00:23+00:00</updated>
<author>
<name>Frank Li</name>
<email>Frank.Li@nxp.com</email>
</author>
<published>2024-10-01T16:22:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=43bbc5f8586eb1fb5ab62dd7c4dc4bae58f8ea95'/>
<id>urn:sha1:43bbc5f8586eb1fb5ab62dd7c4dc4bae58f8ea95</id>
<content type='text'>
commit 36faa04ce3d9c962b4b29d285ad07ca29e2988e4 upstream.

When a new device hotjoins, a new dynamic address is assigned.
i3c_master_add_i3c_dev_locked() identifies that the device was previously
attached to the bus and locates the olddev.

i3c_master_add_i3c_dev_locked()
{
    ...
    olddev = i3c_master_search_i3c_dev_duplicate(newdev);
    ...
    if (olddev) {
        ...
        i3c_dev_disable_ibi_locked(olddev);
        ^^^^^^
        The olddev should not receive any commands on the i3c bus as it
        does not exist and has been assigned a new address. This will
        result in NACK or timeout. So remove it.
    }

    i3c_dev_free_ibi_locked(olddev);
    ^^^^^^^^
    This function internally calls i3c_dev_disable_ibi_locked() function
    causing to send DISEC command with old Address.

    The olddev should not receive any commands on the i3c bus as it
    does not exist and has been assigned a new address. This will
    result in NACK or timeout. So, update the olddev-&gt;ibi-&gt;enabled
    flag to false to avoid DISEC with OldAddr.
}

Include part of Ravindra Yashvant Shinde's work:
https://lore.kernel.org/linux-i3c/20240820151917.3904956-1-ravindra.yashvant.shinde@nxp.com/T/#u

Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry")
Co-developed-by: Ravindra Yashvant Shinde &lt;ravindra.yashvant.shinde@nxp.com&gt;
Signed-off-by: Ravindra Yashvant Shinde &lt;ravindra.yashvant.shinde@nxp.com&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Link: https://lore.kernel.org/r/20241001162232.223724-1-Frank.Li@nxp.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: amba-pl011: fix build regression</title>
<updated>2024-12-14T19:00:23+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-11-15T10:59:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1baed369508b37ddae428f68817ee24df9985dcb'/>
<id>urn:sha1:1baed369508b37ddae428f68817ee24df9985dcb</id>
<content type='text'>
commit b5a23a60e8ab5711f4952912424347bf3864ce8d upstream.

When CONFIG_DMA_ENGINE is disabled, the driver now fails to build:

drivers/tty/serial/amba-pl011.c: In function 'pl011_unthrottle_rx':
drivers/tty/serial/amba-pl011.c:1822:16: error: 'struct uart_amba_port' has no member named 'using_rx_dma'
 1822 |         if (uap-&gt;using_rx_dma) {
      |                ^~
drivers/tty/serial/amba-pl011.c:1823:20: error: 'struct uart_amba_port' has no member named 'dmacr'
 1823 |                 uap-&gt;dmacr |= UART011_RXDMAE;
      |                    ^~
drivers/tty/serial/amba-pl011.c:1824:32: error: 'struct uart_amba_port' has no member named 'dmacr'
 1824 |                 pl011_write(uap-&gt;dmacr, uap, REG_DMACR);
      |                                ^~

Add the missing #ifdef check around these field accesses, matching
what other parts of this driver do.

Fixes: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used")
Cc: stable &lt;stable@kernel.org&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202411140617.nkjeHhsK-lkp@intel.com/
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://lore.kernel.org/r/20241115110021.744332-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: asus-wmi: Fix thermal profile initialization</title>
<updated>2024-12-14T19:00:23+00:00</updated>
<author>
<name>Armin Wolf</name>
<email>W_Armin@gmx.de</email>
</author>
<published>2024-10-25T19:15:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5eb15d2f4eb49ccd6078a18a1e776924259c3e85'/>
<id>urn:sha1:5eb15d2f4eb49ccd6078a18a1e776924259c3e85</id>
<content type='text'>
commit b012170fed282151f7ba8988a347670c299f5ab3 upstream.

When support for vivobook fan profiles was added, the initial
call to throttle_thermal_policy_set_default() was removed, which
however is necessary for full initialization.

Fix this by calling throttle_thermal_policy_set_default() again
when setting up the platform profile.

Fixes: bcbfcebda2cb ("platform/x86: asus-wmi: add support for vivobook fan profiles")
Reported-by: Michael Larabel &lt;Michael@phoronix.com&gt;
Closes: https://www.phoronix.com/review/lunar-lake-xe2/5
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Link: https://lore.kernel.org/r/20241025191514.15032-2-W_Armin@gmx.de
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: ep0: Don't reset resource alloc flag</title>
<updated>2024-12-14T19:00:22+00:00</updated>
<author>
<name>Thinh Nguyen</name>
<email>Thinh.Nguyen@synopsys.com</email>
</author>
<published>2024-04-16T01:23:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fe330624b85ffc182695a0ff02a55931a1af0de6'/>
<id>urn:sha1:fe330624b85ffc182695a0ff02a55931a1af0de6</id>
<content type='text'>
commit f2e0eee4703869dc5edb5302a919861566ca7797 upstream.

The DWC3_EP_RESOURCE_ALLOCATED flag ensures that the resource of an
endpoint is only assigned once. Unless the endpoint is reset, don't
clear this flag. Otherwise we may set endpoint resource again, which
prevents the driver from initiate transfer after handling a STALL or
endpoint halt to the control endpoint.

Cc: stable@vger.kernel.org
Fixes: b311048c174d ("usb: dwc3: gadget: Rewrite endpoint allocation flow")
Signed-off-by: Thinh Nguyen &lt;Thinh.Nguyen@synopsys.com&gt;
Link: https://lore.kernel.org/r/00122b7cc5be06abef461776e7cc9f5ebc8bc1cb.1713229786.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: rework resume handling for display (v2)</title>
<updated>2024-12-14T19:00:22+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2024-11-25T18:59:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2daba7d857e48035d71cdd95964350b6d0d51545'/>
<id>urn:sha1:2daba7d857e48035d71cdd95964350b6d0d51545</id>
<content type='text'>
commit 73dae652dcac776296890da215ee7dec357a1032 upstream.

Split resume into a 3rd step to handle displays when DCC is
enabled on DCN 4.0.1.  Move display after the buffer funcs
have been re-enabled so that the GPU will do the move and
properly set the DCC metadata for DCN.

v2: fix fence irq resume ordering

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org # 6.11.x
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iio: invensense: fix multiple odr switch when FIFO is off</title>
<updated>2024-12-14T19:00:21+00:00</updated>
<author>
<name>Jean-Baptiste Maneyrol</name>
<email>jean-baptiste.maneyrol@tdk.com</email>
</author>
<published>2024-10-21T08:38:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d11f14a7911ecdc668d0dab956b1ebe349b94aad'/>
<id>urn:sha1:d11f14a7911ecdc668d0dab956b1ebe349b94aad</id>
<content type='text'>
commit ef5f5e7b6f73f79538892a8be3a3bee2342acc9f upstream.

When multiple ODR switch happens during FIFO off, the change could
not be taken into account if you get back to previous FIFO on value.
For example, if you run sensor buffer at 50Hz, stop, change to
200Hz, then back to 50Hz and restart buffer, data will be timestamped
at 200Hz. This due to testing against mult and not new_mult.

To prevent this, let's just run apply_odr automatically when FIFO is
off. It will also simplify driver code.

Update inv_mpu6050 and inv_icm42600 to delete now useless apply_odr.

Fixes: 95444b9eeb8c ("iio: invensense: fix odr switching to same value")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Link: https://patch.msgid.link/20241021-invn-inv-sensors-timestamp-fix-switch-fifo-off-v2-1-39ffd43edcc4@tdk.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xhci: dbc: Fix STALL transfer event handling</title>
<updated>2024-12-14T19:00:21+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2024-09-05T14:32:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed968a1f1f66e9b9815cd9e79bed2abbf28e8b96'/>
<id>urn:sha1:ed968a1f1f66e9b9815cd9e79bed2abbf28e8b96</id>
<content type='text'>
commit 9044ad57b60b0556d42b6f8aa218a68865e810a4 upstream.

Don't flush all pending DbC data requests when an endpoint halts.

An endpoint may halt and xHC DbC triggers a STALL error event if there's
an issue with a bulk data transfer. The transfer should restart once xHC
DbC receives a ClearFeature(ENDPOINT_HALT) request from the host.

Once xHC DbC restarts it will start from the TRB pointed to by dequeue
field in the endpoint context, which might be the same TRB we got the
STALL event for. Turn the TRB to a no-op in this case to make sure xHC
DbC doesn't reuse and tries to retransmit this same TRB after we already
handled it, and gave its corresponding data request back.

Other STALL events might be completely bogus.
Lukasz Bartosik discovered that xHC DbC might issue spurious STALL events
if hosts sends a ClearFeature(ENDPOINT_HALT) request to non-halted
endpoints even without any active bulk transfers.

Assume STALL event is spurious if it reports 0 bytes transferred, and
the endpoint stopped on the STALLED TRB.
Don't give back the data request corresponding to the TRB in this case.

The halted status is per endpoint. Track it with a per endpoint flag
instead of the driver invented DbC wide DS_STALLED state.
DbC remains in DbC-Configured state even if endpoints halt. There is no
Stalled state in the DbC Port state Machine (xhci section 7.6.6)

Reported-by: Łukasz Bartosik &lt;ukaszb@chromium.org&gt;
Closes: https://lore.kernel.org/linux-usb/20240725074857.623299-1-ukaszb@chromium.org/
Tested-by: Łukasz Bartosik &lt;ukaszb@chromium.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240905143300.1959279-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vfio/mlx5: Align the page tracking max message size with the device capability</title>
<updated>2024-12-14T19:00:20+00:00</updated>
<author>
<name>Yishai Hadas</name>
<email>yishaih@nvidia.com</email>
</author>
<published>2024-12-05T12:26:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=032b4122a92ad1d9f6eed87a26b57a50fce85eee'/>
<id>urn:sha1:032b4122a92ad1d9f6eed87a26b57a50fce85eee</id>
<content type='text'>
[ Upstream commit 9c7c5430bca36e9636eabbba0b3b53251479c7ab ]

Align the page tracking maximum message size with the device's
capability instead of relying on PAGE_SIZE.

This adjustment resolves a mismatch on systems where PAGE_SIZE is 64K,
but the firmware only supports a maximum message size of 4K.

Now that we rely on the device's capability for max_message_size, we
must account for potential future increases in its value.

Key considerations include:
- Supporting message sizes that exceed a single system page (e.g., an 8K
  message on a 4K system).
- Ensuring the RQ size is adjusted to accommodate at least 4
  WQEs/messages, in line with the device specification.

The above has been addressed as part of the patch.

Fixes: 79c3cf279926 ("vfio/mlx5: Init QP based resources for dirty tracking")
Reviewed-by: Cédric Le Goater &lt;clg@redhat.com&gt;
Tested-by: Yingshun Cui &lt;yicui@redhat.com&gt;
Signed-off-by: Yishai Hadas &lt;yishaih@nvidia.com&gt;
Link: https://lore.kernel.org/r/20241205122654.235619-1-yishaih@nvidia.com
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: en7523: Initialize num before accessing hws in en7523_register_clocks()</title>
<updated>2024-12-14T19:00:20+00:00</updated>
<author>
<name>Haoyu Li</name>
<email>lihaoyu499@gmail.com</email>
</author>
<published>2024-12-03T14:29:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9d9bd3f7da8a4d4d108d8df8db1ab797c0f09b02'/>
<id>urn:sha1:9d9bd3f7da8a4d4d108d8df8db1ab797c0f09b02</id>
<content type='text'>
[ Upstream commit 52fd1709e41d3a85b48bcfe2404a024ebaf30c3b ]

With the new __counted_by annotation in clk_hw_onecell_data, the "num"
struct member must be set before accessing the "hws" array. Failing to
do so will trigger a runtime warning when enabling CONFIG_UBSAN_BOUNDS
and CONFIG_FORTIFY_SOURCE.

Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by")
Signed-off-by: Haoyu Li &lt;lihaoyu499@gmail.com&gt;
Link: https://lore.kernel.org/r/20241203142915.345523-1-lihaoyu499@gmail.com
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
