From: Xu Yang xu.yang_2@nxp.com
[ Upstream commit ec841b8d73cff37f8960e209017efe1eb2fb21f2 ]
Currently, the imx deivice controller has below limitations:
1. can't generate short packet interrupt if IOC not set in dTD. So if one request span more than one dTDs and only the last dTD set IOC, the usb request will pending there if no more data comes. 2. the controller can't accurately deliver data to differtent usb requests in some cases due to short packet. For example: one usb request span 3 dTDs, then if the controller received a short packet the next packet will go to 2nd dTD of current request rather than the first dTD of next request. 3. can't build a bus packet use multiple dTDs. For example: controller needs to send one packet of 512 bytes use dTD1 (200 bytes) + dTD2 (312 bytes), actually the host side will see 200 bytes short packet.
Based on these limits, add CI_HDRC_HAS_SHORT_PKT_LIMIT flag and use it on imx platforms.
Signed-off-by: Xu Yang xu.yang_2@nxp.com Acked-by: Peter Chen peter.chen@kernel.org Link: https://lore.kernel.org/r/20240923081203.2851768-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/usb/chipidea/ci.h | 1 + drivers/usb/chipidea/ci_hdrc_imx.c | 1 + drivers/usb/chipidea/core.c | 2 ++ include/linux/usb/chipidea.h | 1 + 4 files changed, 5 insertions(+)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h index 2a38e1eb65466..e4b003d060c26 100644 --- a/drivers/usb/chipidea/ci.h +++ b/drivers/usb/chipidea/ci.h @@ -260,6 +260,7 @@ struct ci_hdrc { bool b_sess_valid_event; bool imx28_write_fix; bool has_portsc_pec_bug; + bool has_short_pkt_limit; bool supports_runtime_pm; bool in_lpm; bool wakeup_int; diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index bdc04ce919f7a..b76e7c3fa2c6e 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -342,6 +342,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) struct ci_hdrc_platform_data pdata = { .name = dev_name(&pdev->dev), .capoffset = DEF_CAPOFFSET, + .flags = CI_HDRC_HAS_SHORT_PKT_LIMIT, .notify_event = ci_hdrc_imx_notify_event, }; int ret; diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 835bf2428dc6e..5aa16dbfc289c 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -1076,6 +1076,8 @@ static int ci_hdrc_probe(struct platform_device *pdev) CI_HDRC_SUPPORTS_RUNTIME_PM); ci->has_portsc_pec_bug = !!(ci->platdata->flags & CI_HDRC_HAS_PORTSC_PEC_MISSED); + ci->has_short_pkt_limit = !!(ci->platdata->flags & + CI_HDRC_HAS_SHORT_PKT_LIMIT); platform_set_drvdata(pdev, ci);
ret = hw_device_init(ci, base); diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h index 5a7f96684ea22..ebdfef124b2bc 100644 --- a/include/linux/usb/chipidea.h +++ b/include/linux/usb/chipidea.h @@ -65,6 +65,7 @@ struct ci_hdrc_platform_data { #define CI_HDRC_PHY_VBUS_CONTROL BIT(16) #define CI_HDRC_HAS_PORTSC_PEC_MISSED BIT(17) #define CI_HDRC_FORCE_VBUS_ACTIVE_ALWAYS BIT(18) +#define CI_HDRC_HAS_SHORT_PKT_LIMIT BIT(19) enum usb_dr_mode dr_mode; #define CI_HDRC_CONTROLLER_RESET_EVENT 0 #define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
From: Xu Yang xu.yang_2@nxp.com
[ Upstream commit ca8d18aa7b0f22d66a3ca9a90d8f73431b8eca89 ]
To let the device controller work properly on short packet limitations, one usb request should only correspond to one dTD. Then every dTD will set IOC. In theory, each dTD support up to 20KB data transfer if the offset is 0. Due to we cannot predetermine the offset, this will limit the usb request length to max 16KB. This should be fine since most of the user transfer data based on this size policy.
Signed-off-by: Xu Yang xu.yang_2@nxp.com Acked-by: Peter Chen peter.chen@kernel.org Link: https://lore.kernel.org/r/20240923081203.2851768-2-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/usb/chipidea/ci.h | 1 + drivers/usb/chipidea/udc.c | 6 ++++++ 2 files changed, 7 insertions(+)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h index e4b003d060c26..97437de52ef68 100644 --- a/drivers/usb/chipidea/ci.h +++ b/drivers/usb/chipidea/ci.h @@ -25,6 +25,7 @@ #define TD_PAGE_COUNT 5 #define CI_HDRC_PAGE_SIZE 4096ul /* page size for TD's */ #define ENDPT_MAX 32 +#define CI_MAX_REQ_SIZE (4 * CI_HDRC_PAGE_SIZE) #define CI_MAX_BUF_SIZE (TD_PAGE_COUNT * CI_HDRC_PAGE_SIZE)
/****************************************************************************** diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 69ef3cd8d4f83..d3556416dae4f 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -960,6 +960,12 @@ static int _ep_queue(struct usb_ep *ep, struct usb_request *req, return -EMSGSIZE; }
+ if (ci->has_short_pkt_limit && + hwreq->req.length > CI_MAX_REQ_SIZE) { + dev_err(hwep->ci->dev, "request length too big (max 16KB)\n"); + return -EMSGSIZE; + } + /* first nuke then test link, e.g. previous status has not sent */ if (!list_empty(&hwreq->queue)) { dev_err(hwep->ci->dev, "request already in queue\n");
From: Xu Yang xu.yang_2@nxp.com
[ Upstream commit edfcc455c85ccc5855f0c329ca5a2d85cc9fc6c6 ]
The chipidea controller doesn't fully support sglist, such as it can not transfer data spanned more dTDs to form a bus packet, so it can only work on very limited cases.
The limitations as below: 1. the end address of the first sg buffer must be 4KB aligned. 2. the start and end address of the middle sg buffer must be 4KB aligned. 3. the start address of the first sg buffer must be 4KB aligned.
However, not all the use cases violate these limitations. To make the controller compatible with most of the cases, this will try to bounce the problem sglist entries which can be found by sglist_get_invalid_entry(). Then a bounced line buffer (the size will roundup to page size) will be allocated to replace the remaining problem sg entries. The data will be copied between problem sg entries and bounce buffer according to the transfer direction. The bounce buffer will be freed when the request completed.
Acked-by: Peter Chen peter.chen@kernel.com Signed-off-by: Xu Yang xu.yang_2@nxp.com Link: https://lore.kernel.org/r/20240923081203.2851768-3-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/usb/chipidea/udc.c | 148 +++++++++++++++++++++++++++++++++++++ drivers/usb/chipidea/udc.h | 2 + 2 files changed, 150 insertions(+)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index d3556416dae4f..f0fcaf2b1f334 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -10,6 +10,7 @@ #include <linux/delay.h> #include <linux/device.h> #include <linux/dmapool.h> +#include <linux/dma-direct.h> #include <linux/err.h> #include <linux/irqreturn.h> #include <linux/kernel.h> @@ -540,6 +541,126 @@ static int prepare_td_for_sg(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq) return ret; }
+/* + * Verify if the scatterlist is valid by iterating each sg entry. + * Return invalid sg entry index which is less than num_sgs. + */ +static int sglist_get_invalid_entry(struct device *dma_dev, u8 dir, + struct usb_request *req) +{ + int i; + struct scatterlist *s = req->sg; + + if (req->num_sgs == 1) + return 1; + + dir = dir ? DMA_TO_DEVICE : DMA_FROM_DEVICE; + + for (i = 0; i < req->num_sgs; i++, s = sg_next(s)) { + /* Only small sg (generally last sg) may be bounced. If + * that happens. we can't ensure the addr is page-aligned + * after dma map. + */ + if (dma_kmalloc_needs_bounce(dma_dev, s->length, dir)) + break; + + /* Make sure each sg start address (except first sg) is + * page-aligned and end address (except last sg) is also + * page-aligned. + */ + if (i == 0) { + if (!IS_ALIGNED(s->offset + s->length, + CI_HDRC_PAGE_SIZE)) + break; + } else { + if (s->offset) + break; + if (!sg_is_last(s) && !IS_ALIGNED(s->length, + CI_HDRC_PAGE_SIZE)) + break; + } + } + + return i; +} + +static int sglist_do_bounce(struct ci_hw_req *hwreq, int index, + bool copy, unsigned int *bounced) +{ + void *buf; + int i, ret, nents, num_sgs; + unsigned int rest, rounded; + struct scatterlist *sg, *src, *dst; + + nents = index + 1; + ret = sg_alloc_table(&hwreq->sgt, nents, GFP_KERNEL); + if (ret) + return ret; + + sg = src = hwreq->req.sg; + num_sgs = hwreq->req.num_sgs; + rest = hwreq->req.length; + dst = hwreq->sgt.sgl; + + for (i = 0; i < index; i++) { + memcpy(dst, src, sizeof(*src)); + rest -= src->length; + src = sg_next(src); + dst = sg_next(dst); + } + + /* create one bounce buffer */ + rounded = round_up(rest, CI_HDRC_PAGE_SIZE); + buf = kmalloc(rounded, GFP_KERNEL); + if (!buf) { + sg_free_table(&hwreq->sgt); + return -ENOMEM; + } + + sg_set_buf(dst, buf, rounded); + + hwreq->req.sg = hwreq->sgt.sgl; + hwreq->req.num_sgs = nents; + hwreq->sgt.sgl = sg; + hwreq->sgt.nents = num_sgs; + + if (copy) + sg_copy_to_buffer(src, num_sgs - index, buf, rest); + + *bounced = rest; + + return 0; +} + +static void sglist_do_debounce(struct ci_hw_req *hwreq, bool copy) +{ + void *buf; + int i, nents, num_sgs; + struct scatterlist *sg, *src, *dst; + + sg = hwreq->req.sg; + num_sgs = hwreq->req.num_sgs; + src = sg_last(sg, num_sgs); + buf = sg_virt(src); + + if (copy) { + dst = hwreq->sgt.sgl; + for (i = 0; i < num_sgs - 1; i++) + dst = sg_next(dst); + + nents = hwreq->sgt.nents - num_sgs + 1; + sg_copy_from_buffer(dst, nents, buf, sg_dma_len(src)); + } + + hwreq->req.sg = hwreq->sgt.sgl; + hwreq->req.num_sgs = hwreq->sgt.nents; + hwreq->sgt.sgl = sg; + hwreq->sgt.nents = num_sgs; + + kfree(buf); + sg_free_table(&hwreq->sgt); +} + /** * _hardware_enqueue: configures a request at hardware level * @hwep: endpoint @@ -552,6 +673,8 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq) struct ci_hdrc *ci = hwep->ci; int ret = 0; struct td_node *firstnode, *lastnode; + unsigned int bounced_size; + struct scatterlist *sg;
/* don't queue twice */ if (hwreq->req.status == -EALREADY) @@ -559,11 +682,29 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq)
hwreq->req.status = -EALREADY;
+ if (hwreq->req.num_sgs && hwreq->req.length && + ci->has_short_pkt_limit) { + ret = sglist_get_invalid_entry(ci->dev->parent, hwep->dir, + &hwreq->req); + if (ret < hwreq->req.num_sgs) { + ret = sglist_do_bounce(hwreq, ret, hwep->dir == TX, + &bounced_size); + if (ret) + return ret; + } + } + ret = usb_gadget_map_request_by_dev(ci->dev->parent, &hwreq->req, hwep->dir); if (ret) return ret;
+ if (hwreq->sgt.sgl) { + /* We've mapped a bigger buffer, now recover the actual size */ + sg = sg_last(hwreq->req.sg, hwreq->req.num_sgs); + sg_dma_len(sg) = min(sg_dma_len(sg), bounced_size); + } + if (hwreq->req.num_mapped_sgs) ret = prepare_td_for_sg(hwep, hwreq); else @@ -733,6 +874,10 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq) usb_gadget_unmap_request_by_dev(hwep->ci->dev->parent, &hwreq->req, hwep->dir);
+ /* sglist bounced */ + if (hwreq->sgt.sgl) + sglist_do_debounce(hwreq, hwep->dir == RX); + hwreq->req.actual += actual;
if (hwreq->req.status) @@ -1580,6 +1725,9 @@ static int ep_dequeue(struct usb_ep *ep, struct usb_request *req)
usb_gadget_unmap_request(&hwep->ci->gadget, req, hwep->dir);
+ if (hwreq->sgt.sgl) + sglist_do_debounce(hwreq, false); + req->status = -ECONNRESET;
if (hwreq->req.complete != NULL) { diff --git a/drivers/usb/chipidea/udc.h b/drivers/usb/chipidea/udc.h index 5193df1e18c75..c8a47389a46bb 100644 --- a/drivers/usb/chipidea/udc.h +++ b/drivers/usb/chipidea/udc.h @@ -69,11 +69,13 @@ struct td_node { * @req: request structure for gadget drivers * @queue: link to QH list * @tds: link to TD list + * @sgt: hold original sglist when bounce sglist */ struct ci_hw_req { struct usb_request req; struct list_head queue; struct list_head tds; + struct sg_table sgt; };
#ifdef CONFIG_USB_CHIPIDEA_UDC
From: Xu Yang xu.yang_2@nxp.com
[ Upstream commit 548f48b66c0c5d4b9795a55f304b7298cde2a025 ]
As per USBSTS register description about UEI:
When completion of a USB transaction results in an error condition, this bit is set by the Host/Device Controller. This bit is set along with the USBINT bit, if the TD on which the error interrupt occurred also had its interrupt on complete (IOC) bit set.
UI is set only when IOC set. Add checking UEI to fix miss call isr_tr_complete_handler() when IOC have not set and transfer error happen.
Acked-by: Peter Chen peter.chen@kernel.com Signed-off-by: Xu Yang xu.yang_2@nxp.com Link: https://lore.kernel.org/r/20240926022906.473319-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/usb/chipidea/udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index f0fcaf2b1f334..fd6032874bf33 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -2217,7 +2217,7 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci) } }
- if (USBi_UI & intr) + if ((USBi_UI | USBi_UEI) & intr) isr_tr_complete_handler(ci);
if ((USBi_SLI & intr) && !(ci->suspended)) {
From: Saranya Gopal saranya.gopal@intel.com
[ Upstream commit fa48d7e81624efdf398b990a9049e9cd75a5aead ]
ACPI _DSM methods are needed only for UCSI write operations and for reading CCI during RESET_PPM operation. So, remove _DSM calls from other places. While there, remove the Zenbook quirk also since the default behavior now aligns with the Zenbook quirk. With this change, GET_CONNECTOR_STATUS returns at least 6 seconds faster than before in Arrowlake-S platforms.
Reviewed-by: Heikki Krogerus heikki.krogerus@linux.intel.com Signed-off-by: Saranya Gopal saranya.gopal@intel.com Reviewed-by: Christian A. Ehrhardt lk@c--e.de Link: https://lore.kernel.org/r/20240830084342.460109-1-saranya.gopal@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/usb/typec/ucsi/ucsi_acpi.c | 56 +++--------------------------- 1 file changed, 5 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c index 7a5dff8d9cc6c..accf15ff1306a 100644 --- a/drivers/usb/typec/ucsi/ucsi_acpi.c +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c @@ -61,9 +61,11 @@ static int ucsi_acpi_read_cci(struct ucsi *ucsi, u32 *cci) struct ucsi_acpi *ua = ucsi_get_drvdata(ucsi); int ret;
- ret = ucsi_acpi_dsm(ua, UCSI_DSM_FUNC_READ); - if (ret) - return ret; + if (UCSI_COMMAND(ua->cmd) == UCSI_PPM_RESET) { + ret = ucsi_acpi_dsm(ua, UCSI_DSM_FUNC_READ); + if (ret) + return ret; + }
memcpy(cci, ua->base + UCSI_CCI, sizeof(*cci));
@@ -73,11 +75,6 @@ static int ucsi_acpi_read_cci(struct ucsi *ucsi, u32 *cci) static int ucsi_acpi_read_message_in(struct ucsi *ucsi, void *val, size_t val_len) { struct ucsi_acpi *ua = ucsi_get_drvdata(ucsi); - int ret; - - ret = ucsi_acpi_dsm(ua, UCSI_DSM_FUNC_READ); - if (ret) - return ret;
memcpy(val, ua->base + UCSI_MESSAGE_IN, val_len);
@@ -102,42 +99,6 @@ static const struct ucsi_operations ucsi_acpi_ops = { .async_control = ucsi_acpi_async_control };
-static int -ucsi_zenbook_read_cci(struct ucsi *ucsi, u32 *cci) -{ - struct ucsi_acpi *ua = ucsi_get_drvdata(ucsi); - int ret; - - if (UCSI_COMMAND(ua->cmd) == UCSI_PPM_RESET) { - ret = ucsi_acpi_dsm(ua, UCSI_DSM_FUNC_READ); - if (ret) - return ret; - } - - memcpy(cci, ua->base + UCSI_CCI, sizeof(*cci)); - - return 0; -} - -static int -ucsi_zenbook_read_message_in(struct ucsi *ucsi, void *val, size_t val_len) -{ - struct ucsi_acpi *ua = ucsi_get_drvdata(ucsi); - - /* UCSI_MESSAGE_IN is never read for PPM_RESET, return stored data */ - memcpy(val, ua->base + UCSI_MESSAGE_IN, val_len); - - return 0; -} - -static const struct ucsi_operations ucsi_zenbook_ops = { - .read_version = ucsi_acpi_read_version, - .read_cci = ucsi_zenbook_read_cci, - .read_message_in = ucsi_zenbook_read_message_in, - .sync_control = ucsi_sync_control_common, - .async_control = ucsi_acpi_async_control -}; - static int ucsi_gram_read_message_in(struct ucsi *ucsi, void *val, size_t val_len) { u16 bogus_change = UCSI_CONSTAT_POWER_LEVEL_CHANGE | @@ -190,13 +151,6 @@ static const struct ucsi_operations ucsi_gram_ops = { };
static const struct dmi_system_id ucsi_acpi_quirks[] = { - { - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "ZenBook UX325UA_UM325UA"), - }, - .driver_data = (void *)&ucsi_zenbook_ops, - }, { .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
From: Nuno Sa nuno.sa@analog.com
[ Upstream commit b7f99fa1b64af2f696b13cec581cb4cd7d3982b8 ]
spi_get_device_match_data() can return a NULL pointer. Hence, let's check for it.
Signed-off-by: Nuno Sa nuno.sa@analog.com Link: https://patch.msgid.link/20241014-fix-error-check-v1-1-089e1003d12f@analog.c... Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/iio/adc/ad7192.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/iio/adc/ad7192.c b/drivers/iio/adc/ad7192.c index 334ab90991d4c..1d5958a05dee4 100644 --- a/drivers/iio/adc/ad7192.c +++ b/drivers/iio/adc/ad7192.c @@ -1255,6 +1255,9 @@ static int ad7192_probe(struct spi_device *spi) st->int_vref_mv = ret == -ENODEV ? avdd_mv : ret / MILLI;
st->chip_info = spi_get_device_match_data(spi); + if (!st->chip_info) + return -ENODEV; + indio_dev->name = st->chip_info->name; indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->info = st->chip_info->info;
From: Andy Shevchenko andriy.shevchenko@linux.intel.com
[ Upstream commit c26acb09ccbef47d1fddaf0783c1392d0462122c ]
It has been found that the (non-vendor issued) ACPI ID for Lite-On LTR303 is present in Microsoft catalog. Add it to the list of the supported devices.
Link: https://www.catalog.update.microsoft.com/Search.aspx?q=lter0303 Closes: https://lore.kernel.org/r/9cdda3e0-d56e-466f-911f-96ffd6f602c8@redhat.com Reported-by: Hans de Goede hdegoede@redhat.com Reviewed-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Link: https://patch.msgid.link/20241024191200.229894-24-andriy.shevchenko@linux.in... Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/iio/light/ltr501.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c index 8c516ede91161..640a5d3aa2c6e 100644 --- a/drivers/iio/light/ltr501.c +++ b/drivers/iio/light/ltr501.c @@ -1613,6 +1613,8 @@ static const struct acpi_device_id ltr_acpi_match[] = { { "LTER0501", ltr501 }, { "LTER0559", ltr559 }, { "LTER0301", ltr301 }, + /* https://www.catalog.update.microsoft.com/Search.aspx?q=lter0303 */ + { "LTER0303", ltr303 }, { }, }; MODULE_DEVICE_TABLE(acpi, ltr_acpi_match);
From: Saravana Kannan saravanak@google.com
[ Upstream commit fe2e59aa5d7077c5c564d55b7e2997e83710c314 ]
fwnode needs to be set for a device for fw_devlink to be able to track/enforce its dependencies correctly. Without this, you'll see error messages like this when the supplier has probed and tries to make sure all its fwnode consumers are linked to it using device links:
mediatek-drm-dp 1c500000.edp-tx: Failed to create device link (0x180) with backlight-lcd0
Reported-by: Nícolas F. R. A. Prado nfraprado@collabora.com Closes: https://lore.kernel.org/all/7b995947-4540-4b17-872e-e107adca4598@notapiano/ Tested-by: Nícolas F. R. A. Prado nfraprado@collabora.com Signed-off-by: Saravana Kannan saravanak@google.com Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Reviewed-by: Thierry Reding treding@nvidia.com Tested-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Link: https://lore.kernel.org/r/20241024061347.1771063-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/display/drm_dp_aux_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_aux_bus.c b/drivers/gpu/drm/display/drm_dp_aux_bus.c index d810529ebfb6e..ec7eac6b595f7 100644 --- a/drivers/gpu/drm/display/drm_dp_aux_bus.c +++ b/drivers/gpu/drm/display/drm_dp_aux_bus.c @@ -292,7 +292,7 @@ int of_dp_aux_populate_bus(struct drm_dp_aux *aux, aux_ep->dev.parent = aux->dev; aux_ep->dev.bus = &dp_aux_bus_type; aux_ep->dev.type = &dp_aux_device_type_type; - aux_ep->dev.of_node = of_node_get(np); + device_set_node(&aux_ep->dev, of_fwnode_handle(of_node_get(np))); dev_set_name(&aux_ep->dev, "aux-%s", dev_name(aux->dev));
ret = device_register(&aux_ep->dev);
On Wed, Dec 4, 2024 at 3:29 PM Sasha Levin sashal@kernel.org wrote:
From: Saravana Kannan saravanak@google.com
[ Upstream commit fe2e59aa5d7077c5c564d55b7e2997e83710c314 ]
fwnode needs to be set for a device for fw_devlink to be able to track/enforce its dependencies correctly. Without this, you'll see error messages like this when the supplier has probed and tries to make sure all its fwnode consumers are linked to it using device links:
mediatek-drm-dp 1c500000.edp-tx: Failed to create device link (0x180) with backlight-lcd0
Reported-by: Nícolas F. R. A. Prado nfraprado@collabora.com Closes: https://lore.kernel.org/all/7b995947-4540-4b17-872e-e107adca4598@notapiano/ Tested-by: Nícolas F. R. A. Prado nfraprado@collabora.com Signed-off-by: Saravana Kannan saravanak@google.com Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Reviewed-by: Thierry Reding treding@nvidia.com Tested-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Link: https://lore.kernel.org/r/20241024061347.1771063-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org
As mentioned in the original cover letter:
PSA: Do not pull any of these patches into stable kernels. fw_devlink had a lot of changes that landed in the last year. It's hard to ensure cherry-picks have picked up all the dependencies correctly. If any of these really need to get cherry-picked into stable kernels, cc me and wait for my explicit Ack.
Is there a pressing need for this in 4.19?
-Saravana
drivers/gpu/drm/display/drm_dp_aux_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_aux_bus.c b/drivers/gpu/drm/display/drm_dp_aux_bus.c index d810529ebfb6e..ec7eac6b595f7 100644 --- a/drivers/gpu/drm/display/drm_dp_aux_bus.c +++ b/drivers/gpu/drm/display/drm_dp_aux_bus.c @@ -292,7 +292,7 @@ int of_dp_aux_populate_bus(struct drm_dp_aux *aux, aux_ep->dev.parent = aux->dev; aux_ep->dev.bus = &dp_aux_bus_type; aux_ep->dev.type = &dp_aux_device_type_type;
aux_ep->dev.of_node = of_node_get(np);
device_set_node(&aux_ep->dev, of_fwnode_handle(of_node_get(np))); dev_set_name(&aux_ep->dev, "aux-%s", dev_name(aux->dev)); ret = device_register(&aux_ep->dev);-- 2.43.0
On Thu, Dec 5, 2024 at 4:06 PM Saravana Kannan saravanak@google.com wrote:
On Wed, Dec 4, 2024 at 3:29 PM Sasha Levin sashal@kernel.org wrote:
From: Saravana Kannan saravanak@google.com
[ Upstream commit fe2e59aa5d7077c5c564d55b7e2997e83710c314 ]
fwnode needs to be set for a device for fw_devlink to be able to track/enforce its dependencies correctly. Without this, you'll see error messages like this when the supplier has probed and tries to make sure all its fwnode consumers are linked to it using device links:
mediatek-drm-dp 1c500000.edp-tx: Failed to create device link (0x180) with backlight-lcd0
Reported-by: Nícolas F. R. A. Prado nfraprado@collabora.com Closes: https://lore.kernel.org/all/7b995947-4540-4b17-872e-e107adca4598@notapiano/ Tested-by: Nícolas F. R. A. Prado nfraprado@collabora.com Signed-off-by: Saravana Kannan saravanak@google.com Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Reviewed-by: Thierry Reding treding@nvidia.com Tested-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Link: https://lore.kernel.org/r/20241024061347.1771063-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org
As mentioned in the original cover letter:
PSA: Do not pull any of these patches into stable kernels. fw_devlink had a lot of changes that landed in the last year. It's hard to ensure cherry-picks have picked up all the dependencies correctly. If any of these really need to get cherry-picked into stable kernels, cc me and wait for my explicit Ack.
Is there a pressing need for this in 4.19?
I copy pasted this into several replies. In all those cases I meant the kernel version mentioned in the subject.
-Saravana
-Saravana
drivers/gpu/drm/display/drm_dp_aux_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_aux_bus.c b/drivers/gpu/drm/display/drm_dp_aux_bus.c index d810529ebfb6e..ec7eac6b595f7 100644 --- a/drivers/gpu/drm/display/drm_dp_aux_bus.c +++ b/drivers/gpu/drm/display/drm_dp_aux_bus.c @@ -292,7 +292,7 @@ int of_dp_aux_populate_bus(struct drm_dp_aux *aux, aux_ep->dev.parent = aux->dev; aux_ep->dev.bus = &dp_aux_bus_type; aux_ep->dev.type = &dp_aux_device_type_type;
aux_ep->dev.of_node = of_node_get(np);
device_set_node(&aux_ep->dev, of_fwnode_handle(of_node_get(np))); dev_set_name(&aux_ep->dev, "aux-%s", dev_name(aux->dev)); ret = device_register(&aux_ep->dev);-- 2.43.0
On Thu, Dec 05, 2024 at 04:07:45PM -0800, Saravana Kannan wrote:
On Thu, Dec 5, 2024 at 4:06 PM Saravana Kannan saravanak@google.com wrote:
On Wed, Dec 4, 2024 at 3:29 PM Sasha Levin sashal@kernel.org wrote:
From: Saravana Kannan saravanak@google.com
[ Upstream commit fe2e59aa5d7077c5c564d55b7e2997e83710c314 ]
fwnode needs to be set for a device for fw_devlink to be able to track/enforce its dependencies correctly. Without this, you'll see error messages like this when the supplier has probed and tries to make sure all its fwnode consumers are linked to it using device links:
mediatek-drm-dp 1c500000.edp-tx: Failed to create device link (0x180) with backlight-lcd0
Reported-by: Nícolas F. R. A. Prado nfraprado@collabora.com Closes: https://lore.kernel.org/all/7b995947-4540-4b17-872e-e107adca4598@notapiano/ Tested-by: Nícolas F. R. A. Prado nfraprado@collabora.com Signed-off-by: Saravana Kannan saravanak@google.com Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Reviewed-by: Thierry Reding treding@nvidia.com Tested-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Link: https://lore.kernel.org/r/20241024061347.1771063-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org
As mentioned in the original cover letter:
PSA: Do not pull any of these patches into stable kernels. fw_devlink had a lot of changes that landed in the last year. It's hard to ensure cherry-picks have picked up all the dependencies correctly. If any of these really need to get cherry-picked into stable kernels, cc me and wait for my explicit Ack.
Is there a pressing need for this in 4.19?
I copy pasted this into several replies. In all those cases I meant the kernel version mentioned in the subject.
I'll drop this and the other patch you've pointed out, thanks!
From: Saravana Kannan saravanak@google.com
[ Upstream commit 74ffe43bad3af3e2a786ca017c205555ba87ebad ]
fwnode needs to be set for a device for fw_devlink to be able to track/enforce its dependencies correctly. Without this, you'll see error messages like this when the supplier has probed and tries to make sure all its fwnode consumers are linked to it using device links:
tegra-xusb-padctl 3520000.padctl: Failed to create device link (0x180) with 1-0008
Reported-by: Jon Hunter jonathanh@nvidia.com Closes: https://lore.kernel.org/all/20240910130019.35081-1-jonathanh@nvidia.com/ Tested-by: Jon Hunter jonathanh@nvidia.com Suggested-by: Nícolas F. R. A. Prado nfraprado@collabora.com Signed-off-by: Saravana Kannan saravanak@google.com Acked-by: Thierry Reding treding@nvidia.com Link: https://lore.kernel.org/r/20241024061347.1771063-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/phy/tegra/xusb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c index cfdb54b6070a4..0a2096085971c 100644 --- a/drivers/phy/tegra/xusb.c +++ b/drivers/phy/tegra/xusb.c @@ -543,7 +543,7 @@ static int tegra_xusb_port_init(struct tegra_xusb_port *port,
device_initialize(&port->dev); port->dev.type = &tegra_xusb_port_type; - port->dev.of_node = of_node_get(np); + device_set_node(&port->dev, of_fwnode_handle(of_node_get(np))); port->dev.parent = padctl->dev;
err = dev_set_name(&port->dev, "%s-%u", name, index);
On Wed, Dec 4, 2024 at 3:29 PM Sasha Levin sashal@kernel.org wrote:
From: Saravana Kannan saravanak@google.com
[ Upstream commit 74ffe43bad3af3e2a786ca017c205555ba87ebad ]
fwnode needs to be set for a device for fw_devlink to be able to track/enforce its dependencies correctly. Without this, you'll see error messages like this when the supplier has probed and tries to make sure all its fwnode consumers are linked to it using device links:
tegra-xusb-padctl 3520000.padctl: Failed to create device link (0x180) with 1-0008
Reported-by: Jon Hunter jonathanh@nvidia.com Closes: https://lore.kernel.org/all/20240910130019.35081-1-jonathanh@nvidia.com/ Tested-by: Jon Hunter jonathanh@nvidia.com Suggested-by: Nícolas F. R. A. Prado nfraprado@collabora.com Signed-off-by: Saravana Kannan saravanak@google.com Acked-by: Thierry Reding treding@nvidia.com Link: https://lore.kernel.org/r/20241024061347.1771063-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org
As mentioned in the original cover letter:
PSA: Do not pull any of these patches into stable kernels. fw_devlink had a lot of changes that landed in the last year. It's hard to ensure cherry-picks have picked up all the dependencies correctly. If any of these really need to get cherry-picked into stable kernels, cc me and wait for my explicit Ack.
Is there a pressing need for this in 4.19?
-Saravana
drivers/phy/tegra/xusb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c index cfdb54b6070a4..0a2096085971c 100644 --- a/drivers/phy/tegra/xusb.c +++ b/drivers/phy/tegra/xusb.c @@ -543,7 +543,7 @@ static int tegra_xusb_port_init(struct tegra_xusb_port *port,
device_initialize(&port->dev); port->dev.type = &tegra_xusb_port_type;
port->dev.of_node = of_node_get(np);
device_set_node(&port->dev, of_fwnode_handle(of_node_get(np))); port->dev.parent = padctl->dev; err = dev_set_name(&port->dev, "%s-%u", name, index);-- 2.43.0
From: Dmitry Baryshkov dmitry.baryshkov@linaro.org
[ Upstream commit de9df030ccb5d3e31ee0c715d74cd77c619748f8 ]
Instead of checking if any of the USB-C ports have orientation GPIO and thus is orientation-aware, check for the GPIO for the port being registered. There are no boards that are affected by this change at this moment, so the patch is not marked as a fix, but it might affect other boards in future.
Reviewed-by: Abel Vesa abel.vesa@linaro.org Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Reviewed-by: Johan Hovold johan+linaro@kernel.org Tested-by: Johan Hovold johan+linaro@kernel.org Signed-off-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Link: https://lore.kernel.org/r/20241109-ucsi-glue-fixes-v2-2-8b21ff4f9fbe@linaro.... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/usb/typec/ucsi/ucsi_glink.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/typec/ucsi/ucsi_glink.c b/drivers/usb/typec/ucsi/ucsi_glink.c index 6aace19d595bc..ad0bc7804939b 100644 --- a/drivers/usb/typec/ucsi/ucsi_glink.c +++ b/drivers/usb/typec/ucsi/ucsi_glink.c @@ -172,12 +172,12 @@ static int pmic_glink_ucsi_async_control(struct ucsi *__ucsi, u64 command) static void pmic_glink_ucsi_update_connector(struct ucsi_connector *con) { struct pmic_glink_ucsi *ucsi = ucsi_get_drvdata(con->ucsi); - int i;
- for (i = 0; i < PMIC_GLINK_MAX_PORTS; i++) { - if (ucsi->port_orientation[i]) - con->typec_cap.orientation_aware = true; - } + if (con->num > PMIC_GLINK_MAX_PORTS || + !ucsi->port_orientation[con->num - 1]) + return; + + con->typec_cap.orientation_aware = true; }
static void pmic_glink_ucsi_connector_status(struct ucsi_connector *con)
From: Alex Far anf1980@gmail.com
[ Upstream commit 67a0463d339059eeeead9cd015afa594659cfdaf ]
This laptop model requires an additional detection quirk to enable the internal microphone
Signed-off-by: Alex Far anf1980@gmail.com Link: https://patch.msgid.link/ZzjrZY3sImcqTtGx@RedmiG Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index dc476bfb6da40..8b2ae20f828cf 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -402,6 +402,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "Xiaomi Book Pro 14 2022"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "TIMI"), + DMI_MATCH(DMI_PRODUCT_NAME, "Redmi G 2022"), + } + }, { .driver_data = &acp6x_card, .matches = {
From: Xiang Liu xiang.liu@amd.com
[ Upstream commit 928cd772e18ffbd7723cb2361db4a8ccf2222235 ]
It is not necessarily corrupted. When there is RAS fatal error, device memory access is blocked. Hence vcpu bo cannot be saved to system memory as in a regular suspend sequence before going for reset. In other full device reset cases, that gets saved and restored during resume.
v2: Remove redundant code like vcn_v4_0 did v2: Refine commit message v3: Drop the volatile v3: Refine commit message
Signed-off-by: Xiang Liu xiang.liu@amd.com Acked-by: Christian König christian.koenig@amd.com Reviewed-by: Stanley.Yang Stanley.Yang@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 30 ++++++++++++++++++------- 1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c index 9bae95538b628..77071967f965a 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c @@ -80,6 +80,20 @@ static int vcn_v4_0_3_early_init(void *handle) return amdgpu_vcn_early_init(adev); }
+static int vcn_v4_0_3_fw_shared_init(struct amdgpu_device *adev, int inst_idx) +{ + struct amdgpu_vcn4_fw_shared *fw_shared; + + fw_shared = adev->vcn.inst[inst_idx].fw_shared.cpu_addr; + fw_shared->present_flag_0 = cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE); + fw_shared->sq.is_enabled = 1; + + if (amdgpu_vcnfw_log) + amdgpu_vcn_fwlog_init(&adev->vcn.inst[inst_idx]); + + return 0; +} + /** * vcn_v4_0_3_sw_init - sw init for VCN block * @@ -110,8 +124,6 @@ static int vcn_v4_0_3_sw_init(void *handle) return r;
for (i = 0; i < adev->vcn.num_vcn_inst; i++) { - volatile struct amdgpu_vcn4_fw_shared *fw_shared; - vcn_inst = GET_INST(VCN, i);
ring = &adev->vcn.inst[i].ring_enc[0]; @@ -134,12 +146,7 @@ static int vcn_v4_0_3_sw_init(void *handle) if (r) return r;
- fw_shared = adev->vcn.inst[i].fw_shared.cpu_addr; - fw_shared->present_flag_0 = cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE); - fw_shared->sq.is_enabled = true; - - if (amdgpu_vcnfw_log) - amdgpu_vcn_fwlog_init(&adev->vcn.inst[i]); + vcn_v4_0_3_fw_shared_init(adev, i); }
if (amdgpu_sriov_vf(adev)) { @@ -224,6 +231,8 @@ static int vcn_v4_0_3_hw_init(void *handle) } } else { for (i = 0; i < adev->vcn.num_vcn_inst; ++i) { + struct amdgpu_vcn4_fw_shared *fw_shared; + vcn_inst = GET_INST(VCN, i); ring = &adev->vcn.inst[i].ring_enc[0];
@@ -247,6 +256,11 @@ static int vcn_v4_0_3_hw_init(void *handle) regVCN_RB1_DB_CTRL); }
+ /* Re-init fw_shared when RAS fatal error occurred */ + fw_shared = adev->vcn.inst[i].fw_shared.cpu_addr; + if (!fw_shared->sq.is_enabled) + vcn_v4_0_3_fw_shared_init(adev, i); + r = amdgpu_ring_test_helper(ring); if (r) return r;
From: Xi Ruoyao xry111@xry111.site
[ Upstream commit 4fbd66d8254cedfd1218393f39d83b6c07a01917 ]
Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0 Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).
Signed-off-by: Xi Ruoyao xry111@xry111.site Signed-off-by: Thomas Bogendoerfer tsbogend@alpha.franken.de Signed-off-by: Sasha Levin sashal@kernel.org --- arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 73 +++++++++++++++++++---- 1 file changed, 60 insertions(+), 13 deletions(-)
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi index cce9428afc41f..ee71045883e7e 100644 --- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi +++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi @@ -70,7 +70,6 @@ pci@1a000000 { device_type = "pci"; #address-cells = <3>; #size-cells = <2>; - #interrupt-cells = <2>; msi-parent = <&msi>;
reg = <0 0x1a000000 0 0x02000000>, @@ -234,7 +233,7 @@ phy1: ethernet-phy@1 { }; };
- pci_bridge@9,0 { + pcie@9,0 { compatible = "pci0014,7a19.1", "pci0014,7a19", "pciclass060400", @@ -244,12 +243,16 @@ pci_bridge@9,0 { interrupts = <32 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 32 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@a,0 { + pcie@a,0 { compatible = "pci0014,7a09.1", "pci0014,7a09", "pciclass060400", @@ -259,12 +262,16 @@ pci_bridge@a,0 { interrupts = <33 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 33 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@b,0 { + pcie@b,0 { compatible = "pci0014,7a09.1", "pci0014,7a09", "pciclass060400", @@ -274,12 +281,16 @@ pci_bridge@b,0 { interrupts = <34 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 34 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@c,0 { + pcie@c,0 { compatible = "pci0014,7a09.1", "pci0014,7a09", "pciclass060400", @@ -289,12 +300,16 @@ pci_bridge@c,0 { interrupts = <35 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 35 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@d,0 { + pcie@d,0 { compatible = "pci0014,7a19.1", "pci0014,7a19", "pciclass060400", @@ -304,12 +319,16 @@ pci_bridge@d,0 { interrupts = <36 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 36 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@e,0 { + pcie@e,0 { compatible = "pci0014,7a09.1", "pci0014,7a09", "pciclass060400", @@ -319,12 +338,16 @@ pci_bridge@e,0 { interrupts = <37 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 37 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@f,0 { + pcie@f,0 { compatible = "pci0014,7a29.1", "pci0014,7a29", "pciclass060400", @@ -334,12 +357,16 @@ pci_bridge@f,0 { interrupts = <40 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 40 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@10,0 { + pcie@10,0 { compatible = "pci0014,7a19.1", "pci0014,7a19", "pciclass060400", @@ -349,12 +376,16 @@ pci_bridge@10,0 { interrupts = <41 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 41 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@11,0 { + pcie@11,0 { compatible = "pci0014,7a29.1", "pci0014,7a29", "pciclass060400", @@ -364,12 +395,16 @@ pci_bridge@11,0 { interrupts = <42 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 42 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@12,0 { + pcie@12,0 { compatible = "pci0014,7a19.1", "pci0014,7a19", "pciclass060400", @@ -379,12 +414,16 @@ pci_bridge@12,0 { interrupts = <43 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 43 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@13,0 { + pcie@13,0 { compatible = "pci0014,7a29.1", "pci0014,7a29", "pciclass060400", @@ -394,12 +433,16 @@ pci_bridge@13,0 { interrupts = <38 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 38 IRQ_TYPE_LEVEL_HIGH>; + ranges; };
- pci_bridge@14,0 { + pcie@14,0 { compatible = "pci0014,7a19.1", "pci0014,7a19", "pciclass060400", @@ -409,9 +452,13 @@ pci_bridge@14,0 { interrupts = <39 IRQ_TYPE_LEVEL_HIGH>; interrupt-parent = <&pic>;
+ #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &pic 39 IRQ_TYPE_LEVEL_HIGH>; + ranges; }; };
On Wed, 2024-12-04 at 17:17 -0500, Sasha Levin wrote:
From: Xi Ruoyao xry111@xry111.site
[ Upstream commit 4fbd66d8254cedfd1218393f39d83b6c07a01917 ]
Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):
Is it better to drop this part from the the commit message? The referred commit isn't in 6.11 or earlier.
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0 Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).
Signed-off-by: Xi Ruoyao xry111@xry111.site Signed-off-by: Thomas Bogendoerfer tsbogend@alpha.franken.de Signed-off-by: Sasha Levin sashal@kernel.org
/* snip */
From: Uwe Kleine-König ukleinek@debian.org
[ Upstream commit cbc86dd0a4fe9f8c41075328c2e740b68419d639 ]
Add a quirk for Tova's Lenovo Thinkpad T14s with product name 21M1.
Suggested-by: Tova blueaddagio@laposte.net Link: https://bugs.debian.org/1087673 Signed-off-by: Uwe Kleine-König ukleinek@debian.org Link: https://patch.msgid.link/20241122075606.213132-2-ukleinek@debian.org Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 8b2ae20f828cf..d4bfc4a95e5fd 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -220,6 +220,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "21J6"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "21M1"), + } + }, { .driver_data = &acp6x_card, .matches = {
From: Michael Ellerman mpe@ellerman.id.au
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties, which is deprecated and now triggers a warning at boot since commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling").
For example:
Missing '#size-cells' in /pci@f2000000/mac-io@c/escc@13000 WARNING: CPU: 0 PID: 0 at drivers/of/base.c:133 of_bus_n_size_cells+0x98/0x108 Hardware name: PowerMac3,1 7400 0xc0209 PowerMac ... Call Trace: of_bus_n_size_cells+0x98/0x108 (unreliable) of_bus_default_count_cells+0x40/0x60 __of_get_address+0xc8/0x21c __of_address_to_resource+0x5c/0x228 pmz_init_port+0x5c/0x2ec pmz_probe.isra.0+0x144/0x1e4 pmz_console_init+0x10/0x48 console_init+0xcc/0x138 start_kernel+0x5c4/0x694
As powermacs boot via prom_init it's possible to add the missing properties to the device tree during boot, avoiding the warning. Note that `escc-legacy` nodes are also missing `#size-cells` properties, but they are skipped by the macio driver, so leave them alone.
Depends-on: 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling") Signed-off-by: Michael Ellerman mpe@ellerman.id.au Reviewed-by: Rob Herring robh@kernel.org Signed-off-by: Madhavan Srinivasan maddy@linux.ibm.com Link: https://patch.msgid.link/20241126025710.591683-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin sashal@kernel.org --- arch/powerpc/kernel/prom_init.c | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index fbb68fc28ed3a..935568d68196d 100644 --- a/arch/powerpc/kernel/prom_init.c +++ b/arch/powerpc/kernel/prom_init.c @@ -2932,7 +2932,7 @@ static void __init fixup_device_tree_chrp(void) #endif
#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC) -static void __init fixup_device_tree_pmac(void) +static void __init fixup_device_tree_pmac64(void) { phandle u3, i2c, mpic; u32 u3_rev; @@ -2972,7 +2972,31 @@ static void __init fixup_device_tree_pmac(void) &parent, sizeof(parent)); } #else -#define fixup_device_tree_pmac() +#define fixup_device_tree_pmac64() +#endif + +#ifdef CONFIG_PPC_PMAC +static void __init fixup_device_tree_pmac(void) +{ + __be32 val = 1; + char type[8]; + phandle node; + + // Some pmacs are missing #size-cells on escc nodes + for (node = 0; prom_next_node(&node); ) { + type[0] = '\0'; + prom_getprop(node, "device_type", type, sizeof(type)); + if (prom_strcmp(type, "escc")) + continue; + + if (prom_getproplen(node, "#size-cells") != PROM_ERROR) + continue; + + prom_setprop(node, NULL, "#size-cells", &val, sizeof(val)); + } +} +#else +static inline void fixup_device_tree_pmac(void) { } #endif
#ifdef CONFIG_PPC_EFIKA @@ -3197,6 +3221,7 @@ static void __init fixup_device_tree(void) fixup_device_tree_maple_memory_controller(); fixup_device_tree_chrp(); fixup_device_tree_pmac(); + fixup_device_tree_pmac64(); fixup_device_tree_efika(); fixup_device_tree_pasemi(); }
linux-stable-mirror@lists.linaro.org
-
Saravana Kannan -
Sasha Levin -
Xi Ruoyao