From: Andre Przywara <[email protected]>
[ Upstream commit 0f607406525d25019dd9c498bcc0b42734fc59d5 ]
The USB PHY used in the Allwinner H616 SoC inherits some traits from its
various predecessors: it has four full PHYs like the H3, needs some
extra bits to be set like the H6, and puts SIDDQ on a different bit like
the A100. Plus it needs this weird PHY2 quirk.
Name all those properties in a new config struct and assign a new
compatible name to it.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Samuel Holland <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/phy/allwinner/phy-sun4i-usb.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index 651d5e2a25ce..230987e55ece 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -974,6 +974,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
.missing_phys = BIT(1) | BIT(2),
};
+static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
+ .num_phys = 4,
+ .type = sun50i_h6_phy,
+ .disc_thresh = 3,
+ .phyctl_offset = REG_PHYCTL_A33,
+ .dedicated_clocks = true,
+ .phy0_dual_route = true,
+ .hci_phy_ctl_clear = PHY_CTL_SIDDQ,
+ .needs_phy2_siddq = true,
+};
+
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-usb-phy", .data = &sun4i_a10_cfg },
{ .compatible = "allwinner,sun5i-a13-usb-phy", .data = &sun5i_a13_cfg },
@@ -988,6 +999,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun50i-a64-usb-phy",
.data = &sun50i_a64_cfg},
{ .compatible = "allwinner,sun50i-h6-usb-phy", .data = &sun50i_h6_cfg },
+ { .compatible = "allwinner,sun50i-h616-usb-phy", .data = &sun50i_h616_cfg },
{ },
};
MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
--
2.35.1
From: Nathan Lynch <[email protected]>
[ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]
It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0
[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0
[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4
[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68
[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50
[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0
[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0
[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0
[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420
[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200
Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.
Signed-off-by: Nathan Lynch <[email protected]>
Reviewed-by: Nicholas Piggin <[email protected]>
Reviewed-by: Andrew Donnellan <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/kernel/rtas.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index aa66317a9a49..014229c40435 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -732,10 +732,15 @@ void rtas_os_term(char *str)
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
+ /*
+ * Keep calling as long as RTAS returns a "try again" status,
+ * but don't use rtas_busy_delay(), which potentially
+ * schedules.
+ */
do {
status = rtas_call(ibm_os_term_token, 1, 1, NULL,
__pa(rtas_os_term_buf));
- } while (rtas_busy_delay(status));
+ } while (rtas_busy_delay_time(status));
if (status != 0)
printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
--
2.35.1
From: Terry Junge <[email protected]>
[ Upstream commit 3d57f36c89d8ba32b2c312f397a37fd1a2dc7cfc ]
I no longer work for Plantronics (aka Poly, aka HP) and do not have
access to the headsets in order to test. However, as noted by Maxim,
the other 32xx models that share the same base code set as the 3220
would need the same quirk. This patch adds the PIDs for the rest of
the Blackwire 32XX product family that require the quirk.
Plantronics Blackwire 3210 Series (047f:c055)
Plantronics Blackwire 3215 Series (047f:c057)
Plantronics Blackwire 3225 Series (047f:c058)
Quote from previous patch by Maxim Mikityanskiy
Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice
for each volume key press. This patch adds a quirk to hid-plantronics
for this product ID, which will ignore the second volume key press if
it happens within 5 ms from the last one that was handled.
The patch was tested on the mentioned model only, it shouldn't affect
other models, however, this quirk might be needed for them too.
Auto-repeat (when a key is held pressed) is not affected, because the
rate is about 3 times per second, which is far less frequent than once
in 5 ms.
End quote
Signed-off-by: Terry Junge <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-plantronics.c | 9 +++++++++
2 files changed, 12 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 70a693f8f034..18c4d8104ee9 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -948,7 +948,10 @@
#define USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S 0x8003
#define USB_VENDOR_ID_PLANTRONICS 0x047f
+#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3210_SERIES 0xc055
#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3220_SERIES 0xc056
+#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3215_SERIES 0xc057
+#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3225_SERIES 0xc058
#define USB_VENDOR_ID_PANASONIC 0x04da
#define USB_DEVICE_ID_PANABOARD_UBT780 0x1044
diff --git a/drivers/hid/hid-plantronics.c b/drivers/hid/hid-plantronics.c
index e81b7cec2d12..3d414ae194ac 100644
--- a/drivers/hid/hid-plantronics.c
+++ b/drivers/hid/hid-plantronics.c
@@ -198,9 +198,18 @@ static int plantronics_probe(struct hid_device *hdev,
}
static const struct hid_device_id plantronics_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS,
+ USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3210_SERIES),
+ .driver_data = PLT_QUIRK_DOUBLE_VOLUME_KEYS },
{ HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS,
USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3220_SERIES),
.driver_data = PLT_QUIRK_DOUBLE_VOLUME_KEYS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS,
+ USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3215_SERIES),
+ .driver_data = PLT_QUIRK_DOUBLE_VOLUME_KEYS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS,
+ USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3225_SERIES),
+ .driver_data = PLT_QUIRK_DOUBLE_VOLUME_KEYS },
{ HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS, HID_ANY_ID) },
{ }
};
--
2.35.1
From: José Expósito <[email protected]>
[ Upstream commit 4eab1c2fe06c98a4dff258dd64800b6986c101e9 ]
The HID descriptor of this device contains two mouse collections, one
for mouse emulation and the other for the trackpoint.
Both collections get merged and, because the first one defines X and Y,
the movemenent events reported by the trackpoint collection are
ignored.
Set the MT_CLS_WIN_8_FORCE_MULTI_INPUT class for this device to be able
to receive its reports.
This fix is similar to/based on commit 40d5bb87377a ("HID: multitouch:
enable multi-input as a quirk for some devices").
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/825
Reported-by: Akito <[email protected]>
Tested-by: Akito <[email protected]>
Signed-off-by: José Expósito <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hid/hid-multitouch.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index a78ce16d4782..ea8c52f0aa78 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1912,6 +1912,10 @@ static const struct hid_device_id mt_devices[] = {
HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
USB_VENDOR_ID_ELAN, 0x313a) },
+ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_ELAN, 0x3148) },
+
/* Elitegroup panel */
{ .driver_data = MT_CLS_SERIAL,
MT_USB_DEVICE(USB_VENDOR_ID_ELITEGROUP,
--
2.35.1
From: Marc Zyngier <[email protected]>
[ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]
Since 2f2940d16823 ("genirq/msi: Remove filter from
msi_free_descs_free_range()"), the core MSI code relies on the
msi_desc->irq field to have been cleared before the descriptor
can be freed, as it indicates that there is no association with
a device anymore.
The irq domain code provides this guarantee, and so does s390,
which is one of the two architectures not using irq domains for
MSIs.
Powerpc, however, is missing this particular requirements,
leading in a splat and leaked MSI descriptors.
Adding the now required irq reset to the handful of powerpc backends
that implement MSIs fixes that particular problem.
Reported-by: Guenter Roeck <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/platforms/4xx/hsta_msi.c | 1 +
arch/powerpc/platforms/cell/axon_msi.c | 1 +
arch/powerpc/platforms/pasemi/msi.c | 1 +
arch/powerpc/sysdev/fsl_msi.c | 1 +
arch/powerpc/sysdev/mpic_u3msi.c | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/powerpc/platforms/4xx/hsta_msi.c b/arch/powerpc/platforms/4xx/hsta_msi.c
index c950fed43b32..4f65bd0cf111 100644
--- a/arch/powerpc/platforms/4xx/hsta_msi.c
+++ b/arch/powerpc/platforms/4xx/hsta_msi.c
@@ -117,6 +117,7 @@ static void hsta_teardown_msi_irqs(struct pci_dev *dev)
msi_bitmap_free_hwirqs(&ppc4xx_hsta_msi.bmp, irq, 1);
pr_debug("%s: Teardown IRQ %u (index %u)\n", __func__,
entry->irq, irq);
+ entry->irq = 0;
}
}
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index ffbc7d2e9464..9f77dde61f31 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -295,6 +295,7 @@ static void axon_msi_teardown_msi_irqs(struct pci_dev *dev)
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+ entry->irq = 0;
}
}
diff --git a/arch/powerpc/platforms/pasemi/msi.c b/arch/powerpc/platforms/pasemi/msi.c
index d38944a1e258..76393c158ada 100644
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -69,6 +69,7 @@ static void pasemi_msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+ entry->irq = 0;
msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq, ALLOC_CHUNK);
}
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index d276c5e96445..5c3f3173638e 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -132,6 +132,7 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+ entry->irq = 0;
msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
}
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 3861023d378a..43686c82e483 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -111,6 +111,7 @@ static void u3msi_teardown_msi_irqs(struct pci_dev *pdev)
hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
irq_dispose_mapping(entry->irq);
+ entry->irq = 0;
msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq, 1);
}
--
2.35.1
From: Christophe Leroy <[email protected]>
[ Upstream commit efb11fdb3e1a9f694fa12b70b21e69e55ec59c36 ]
find_insn() will return NULL in case of failure. Check insn in order
to avoid a kernel Oops for NULL pointer dereference.
Tested-by: Naveen N. Rao <[email protected]>
Reviewed-by: Naveen N. Rao <[email protected]>
Acked-by: Josh Poimboeuf <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
tools/objtool/check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index ea80b29b9913..654ffb51e1dd 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -196,7 +196,7 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func,
return false;
insn = find_insn(file, func->sec, func->offset);
- if (!insn->func)
+ if (!insn || !insn->func)
return false;
func_for_each_insn(file, func, insn) {
--
2.35.1
From: Nathan Lynch <[email protected]>
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
while devtree_lock is held, rtas_os_term() as currently written could
hang.
Instead of discovering the relevant characteristics at panic time,
cache them in file-static variables at boot. Note the lookup for
"ibm,extended-os-term" is converted to of_property_read_bool() since it
is a boolean property, not an RTAS function token.
Signed-off-by: Nathan Lynch <[email protected]>
Reviewed-by: Nicholas Piggin <[email protected]>
Reviewed-by: Andrew Donnellan <[email protected]>
[mpe: Incorporate suggested change from Nick]
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/kernel/rtas.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index bf962051af0a..aa66317a9a49 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -715,6 +715,7 @@ void __noreturn rtas_halt(void)
/* Must be in the RMO region, so we place it here */
static char rtas_os_term_buf[2048];
+static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;
void rtas_os_term(char *str)
{
@@ -726,14 +727,13 @@ void rtas_os_term(char *str)
* this property may terminate the partition which we want to avoid
* since it interferes with panic_timeout.
*/
- if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
- RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
+ if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE)
return;
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
do {
- status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
+ status = rtas_call(ibm_os_term_token, 1, 1, NULL,
__pa(rtas_os_term_buf));
} while (rtas_busy_delay(status));
@@ -1267,6 +1267,13 @@ void __init rtas_initialize(void)
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", &entry);
rtas.entry = no_entry ? rtas.base : entry;
+ /*
+ * Discover these now to avoid device tree lookups in the
+ * panic path.
+ */
+ if (of_property_read_bool(rtas.dev, "ibm,extended-os-term"))
+ ibm_os_term_token = rtas_token("ibm,os-term");
+
/* If RTAS was found, allocate the RMO buffer for it and look for
* the stop-self token if any
*/
--
2.35.1
On Tue, 27 Dec 2022 15:58:16 -0600
Samuel Holland <[email protected]> wrote:
> Hi Sasha,
>
> On 12/27/22 14:35, Sasha Levin wrote:
> > From: Andre Przywara <[email protected]>
> >
> > [ Upstream commit 0f607406525d25019dd9c498bcc0b42734fc59d5 ]
> >
> > The USB PHY used in the Allwinner H616 SoC inherits some traits from its
> > various predecessors: it has four full PHYs like the H3, needs some
> > extra bits to be set like the H6, and puts SIDDQ on a different bit like
> > the A100. Plus it needs this weird PHY2 quirk.
> >
> > Name all those properties in a new config struct and assign a new
> > compatible name to it.
> >
> > Signed-off-by: Andre Przywara <[email protected]>
> > Reviewed-by: Samuel Holland <[email protected]>
> > Link: https://lore.kernel.org/r/[email protected]
> > Signed-off-by: Vinod Koul <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > ---
> > drivers/phy/allwinner/phy-sun4i-usb.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
> > index 651d5e2a25ce..230987e55ece 100644
> > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > @@ -974,6 +974,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
> > .missing_phys = BIT(1) | BIT(2),
> > };
> >
> > +static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
> > + .num_phys = 4,
> > + .type = sun50i_h6_phy,
> > + .disc_thresh = 3,
> > + .phyctl_offset = REG_PHYCTL_A33,
> > + .dedicated_clocks = true,
> > + .phy0_dual_route = true,
> > + .hci_phy_ctl_clear = PHY_CTL_SIDDQ,
> > + .needs_phy2_siddq = true,
>
> This will fail to compile without b45c6d80325b ("phy: sun4i-usb:
> Introduce port2 SIDDQ quirk"). However, like Andre mentioned in
> reference to the devicetree updates[1], we were not expecting any of
> these patches to be backported. Since you already dropped the DT
> portion, there is no need to bother with these two patches either.
Well, definitely not for 5.4 and 5.10, since the essential pinctrl and
clock patches for the H616 were only added in 5.12, so there is no
point in having USB support.
I don't know how useful it is for 6.0, but having both patches in 6.1
would make some sense, since it's an LTS kernel. The H616 SoC became
usable in 6.0, with the USB patches being delayed back then. And it's
only those two that are missing from enabling USB support, IIRC.
The DT part is not really relevant, since you can always use U-Boot's
DT (recommended) or the DT from any newer kernel.
So from an user's perspective, it would be very helpful to just have:
- [PATCH AUTOSEL 6.1 12/28]
- [PATCH AUTOSEL 6.1 13/28]
Personally I would support this, since it makes all H616 based devices
much more usable with next year's distribution kernels.
I don't know if this fulfils the stable kernel rules, though, since
strictly speaking they don't fix anything, but add (USB) support to a
new SoC. Then again they are little risk, since most of the code is
guarded by H616 filters, so wouldn't be used by other SoCs.
Cheers,
Andre
>
> Regards,
> Samuel
>
> [1]: https://lore.kernel.org/lkml/[email protected]/
>
> > +};
> > +
> > static const struct of_device_id sun4i_usb_phy_of_match[] = {
> > { .compatible = "allwinner,sun4i-a10-usb-phy", .data = &sun4i_a10_cfg },
> > { .compatible = "allwinner,sun5i-a13-usb-phy", .data = &sun5i_a13_cfg },
> > @@ -988,6 +999,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] = {
> > { .compatible = "allwinner,sun50i-a64-usb-phy",
> > .data = &sun50i_a64_cfg},
> > { .compatible = "allwinner,sun50i-h6-usb-phy", .data = &sun50i_h6_cfg },
> > + { .compatible = "allwinner,sun50i-h616-usb-phy", .data = &sun50i_h616_cfg },
> > { },
> > };
> > MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
>
Hi Sasha,
On 12/27/22 14:35, Sasha Levin wrote:
> From: Andre Przywara <[email protected]>
>
> [ Upstream commit 0f607406525d25019dd9c498bcc0b42734fc59d5 ]
>
> The USB PHY used in the Allwinner H616 SoC inherits some traits from its
> various predecessors: it has four full PHYs like the H3, needs some
> extra bits to be set like the H6, and puts SIDDQ on a different bit like
> the A100. Plus it needs this weird PHY2 quirk.
>
> Name all those properties in a new config struct and assign a new
> compatible name to it.
>
> Signed-off-by: Andre Przywara <[email protected]>
> Reviewed-by: Samuel Holland <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Vinod Koul <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> ---
> drivers/phy/allwinner/phy-sun4i-usb.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 651d5e2a25ce..230987e55ece 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -974,6 +974,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
> .missing_phys = BIT(1) | BIT(2),
> };
>
> +static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
> + .num_phys = 4,
> + .type = sun50i_h6_phy,
> + .disc_thresh = 3,
> + .phyctl_offset = REG_PHYCTL_A33,
> + .dedicated_clocks = true,
> + .phy0_dual_route = true,
> + .hci_phy_ctl_clear = PHY_CTL_SIDDQ,
> + .needs_phy2_siddq = true,
This will fail to compile without b45c6d80325b ("phy: sun4i-usb:
Introduce port2 SIDDQ quirk"). However, like Andre mentioned in
reference to the devicetree updates[1], we were not expecting any of
these patches to be backported. Since you already dropped the DT
portion, there is no need to bother with these two patches either.
Regards,
Samuel
[1]: https://lore.kernel.org/lkml/[email protected]/
> +};
> +
> static const struct of_device_id sun4i_usb_phy_of_match[] = {
> { .compatible = "allwinner,sun4i-a10-usb-phy", .data = &sun4i_a10_cfg },
> { .compatible = "allwinner,sun5i-a13-usb-phy", .data = &sun5i_a13_cfg },
> @@ -988,6 +999,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] = {
> { .compatible = "allwinner,sun50i-a64-usb-phy",
> .data = &sun50i_a64_cfg},
> { .compatible = "allwinner,sun50i-h6-usb-phy", .data = &sun50i_h6_cfg },
> + { .compatible = "allwinner,sun50i-h616-usb-phy", .data = &sun50i_h616_cfg },
> { },
> };
> MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
On Tue, Dec 27, 2022 at 10:23:30PM +0000, Andre Przywara wrote:
>On Tue, 27 Dec 2022 15:58:16 -0600
>Samuel Holland <[email protected]> wrote:
>
>> Hi Sasha,
>>
>> On 12/27/22 14:35, Sasha Levin wrote:
>> > From: Andre Przywara <[email protected]>
>> >
>> > [ Upstream commit 0f607406525d25019dd9c498bcc0b42734fc59d5 ]
>> >
>> > The USB PHY used in the Allwinner H616 SoC inherits some traits from its
>> > various predecessors: it has four full PHYs like the H3, needs some
>> > extra bits to be set like the H6, and puts SIDDQ on a different bit like
>> > the A100. Plus it needs this weird PHY2 quirk.
>> >
>> > Name all those properties in a new config struct and assign a new
>> > compatible name to it.
>> >
>> > Signed-off-by: Andre Przywara <[email protected]>
>> > Reviewed-by: Samuel Holland <[email protected]>
>> > Link: https://lore.kernel.org/r/[email protected]
>> > Signed-off-by: Vinod Koul <[email protected]>
>> > Signed-off-by: Sasha Levin <[email protected]>
>> > ---
>> > drivers/phy/allwinner/phy-sun4i-usb.c | 12 ++++++++++++
>> > 1 file changed, 12 insertions(+)
>> >
>> > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
>> > index 651d5e2a25ce..230987e55ece 100644
>> > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
>> > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
>> > @@ -974,6 +974,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
>> > .missing_phys = BIT(1) | BIT(2),
>> > };
>> >
>> > +static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
>> > + .num_phys = 4,
>> > + .type = sun50i_h6_phy,
>> > + .disc_thresh = 3,
>> > + .phyctl_offset = REG_PHYCTL_A33,
>> > + .dedicated_clocks = true,
>> > + .phy0_dual_route = true,
>> > + .hci_phy_ctl_clear = PHY_CTL_SIDDQ,
>> > + .needs_phy2_siddq = true,
>>
>> This will fail to compile without b45c6d80325b ("phy: sun4i-usb:
>> Introduce port2 SIDDQ quirk"). However, like Andre mentioned in
>> reference to the devicetree updates[1], we were not expecting any of
>> these patches to be backported. Since you already dropped the DT
>> portion, there is no need to bother with these two patches either.
>
>Well, definitely not for 5.4 and 5.10, since the essential pinctrl and
>clock patches for the H616 were only added in 5.12, so there is no
>point in having USB support.
>
>I don't know how useful it is for 6.0, but having both patches in 6.1
>would make some sense, since it's an LTS kernel. The H616 SoC became
>usable in 6.0, with the USB patches being delayed back then. And it's
>only those two that are missing from enabling USB support, IIRC.
>The DT part is not really relevant, since you can always use U-Boot's
>DT (recommended) or the DT from any newer kernel.
>
>So from an user's perspective, it would be very helpful to just have:
>- [PATCH AUTOSEL 6.1 12/28]
>- [PATCH AUTOSEL 6.1 13/28]
>Personally I would support this, since it makes all H616 based devices
>much more usable with next year's distribution kernels.
>
>I don't know if this fulfils the stable kernel rules, though, since
>strictly speaking they don't fix anything, but add (USB) support to a
>new SoC. Then again they are little risk, since most of the code is
>guarded by H616 filters, so wouldn't be used by other SoCs.
Quirks and new device ids are accepted in the stable trees. I'll leave
those two patches on 6.1. Thanks!
--
Thanks,
Sasha