5.4.53-rc1 review
Greg Kroah-Hartman
maintainerPATCH 143/215 HID: logitech-hidpp: avoid repeated "multiplier = " log messages
In reply to Greg Kroah-HartmanFrom: Maciej S. Szmigiero <[email protected]>
commit e13762abf38ead29071407f32b9dcec38f21dc34 upstream.
These messages appear each time the mouse wakes from sleep, in my case (Logitech M705), every minute or so.
Let's downgrade them to the "debug" level so they don't fill the kernel log by default.
While we are at it, let's make clear that this is a wheel multiplier (and not, for example, XY movement multiplier).
--- drivers/hid/hid-logitech-hidpp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/hid-logitech-hidpp.c +1 -1
@@ -2964,7 +2964,7 @@ static int hi_res_scroll_enable(struct h multiplier =1 ; hidpp->vertical_wheel_counter.wheel_multiplier = multiplier; -hid_info (hidpp->hid_dev,"multiplier = %d\n" , multiplier); +hid_dbg (hidpp->hid_dev,"wheel multiplier = %d\n" , multiplier);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 144/215 HID: magicmouse: do not set up autorepeat
In reply to Greg Kroah-HartmanFrom: Dmitry Torokhov <[email protected]>
commit 6363d2065cd399cf9d6dc9d08c437f8658831100 upstream.
Neither the trackpad, nor the mouse want input core to generate autorepeat events for their buttons, so let's reset the bit (as hid-input sets it for these devices based on the usage vendor code).
--- drivers/hid/hid-magicmouse.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/hid/hid-magicmouse.c +6 -0
@@ -535,6 +535,12 @@ static int magicmouse_setup_input(struct__set_bit (MSC_RAW , input->mscbit); } +/* +* hid-input may mark device as using autorepeat, but neither +* the trackpad, nor the mouse actually want it. +*/ +__clear_bit (EV_REP , input->evbit); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 145/215 HID: quirks: Always poll Obins Anne Pro 2 keyboard
In reply to Greg Kroah-HartmanFrom: Sebastian Parschauer <[email protected]>
commit ca28aff0e1dc7dce9e12a7fd9276b7118ce5e73a upstream.
The Obins Anne Pro 2 keyboard (04d9:a293) disconnects after a few minutes of inactivity when using it wired and typing does not result in any input events any more. This is a common firmware flaw. So add the ALWAYS_POLL quirk for this device.
GitHub user Dietrich Moerman (dietrichm) tested the quirk and requested my help in my project
https://github.com/sriemer/fix-linux-mouse issue 22 to provide this patch.
--- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-quirks.c | 1 + 2 files changed, 2 insertions(+)
drivers/hid/hid-ids.h +1 -0
@@ -620,6 +620,7 @@#define USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A081 0xa081#define USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A0C2 0xa0c2#define USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A096 0xa096 +#define USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A293 0xa293#define USB_VENDOR_ID_IMATION 0x0718#define USB_DEVICE_ID_DISC_STAKKA 0xd000
drivers/hid/hid-quirks.c +1 -0
@@ -88,6 +88,7 @@ static const struct hid_device_id hid_qu { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A096), HID_QUIRK_NO_INIT_REPORTS }, + { HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A293), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
Greg Kroah-Hartman
maintainerPATCH 146/215 HID: quirks: Ignore Simply Automated UPB PIM
In reply to Greg Kroah-HartmanFrom: James Hilliard <[email protected]>
commit 1ee1369b46de1083238fced60ff718f59de4b8aa upstream.
As this is a cypress HID->COM RS232 style device that is handled by the cypress_M8 driver we also need to add it to the ignore list in hid-quirks.
--- drivers/hid/hid-ids.h | 2 ++ drivers/hid/hid-quirks.c | 1 + 2 files changed, 3 insertions(+)
drivers/hid/hid-ids.h +2 -0
@@ -996,6 +996,8 @@#define USB_DEVICE_ID_ROCCAT_RYOS_MK_PRO 0x3232#define USB_DEVICE_ID_ROCCAT_SAVU 0x2d5a +#define USB_VENDOR_ID_SAI 0x17dd +#define USB_VENDOR_ID_SAITEK 0x06a3#define USB_DEVICE_ID_SAITEK_RUMBLEPAD 0xff17#define USB_DEVICE_ID_SAITEK_PS1000 0x0621
drivers/hid/hid-quirks.c +1 -0
@@ -840,6 +840,7 @@ static const struct hid_device_id hid_ig { HID_USB_DEVICE(USB_VENDOR_ID_PETZL, USB_DEVICE_ID_PETZL_HEADLAMP) }, { HID_USB_DEVICE(USB_VENDOR_ID_PHILIPS, USB_DEVICE_ID_PHILIPS_IEEE802154_DONGLE) }, { HID_USB_DEVICE(USB_VENDOR_ID_POWERCOM, USB_DEVICE_ID_POWERCOM_UPS) }, + { HID_USB_DEVICE(USB_VENDOR_ID_SAI, USB_DEVICE_ID_CYPRESS_HIDCOM) }, #if IS_ENABLED(CONFIG_MOUSE_SYNAPTICS_USB) { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_TP) }, { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_INT_TP) },
Greg Kroah-Hartman
maintainerPATCH 147/215 ALSA: line6: Perform sanity check for each URB creation
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 6e8a914ad619042c5f25a4feb663357c4170fd8d upstream.
LINE6 drivers create stream URBs with a fixed pipe without checking its validity, and this may lead to a kernel WARNING at the submission when a malformed USB descriptor is passed.
For avoiding the kernel warning, perform the similar sanity checks for each pipe type at creating a URB.
--- sound/usb/line6/capture.c | 2 ++ sound/usb/line6/playback.c | 2 ++ 2 files changed, 4 insertions(+)
sound/usb/line6/capture.c +2 -0
@@ -287,6 +287,8 @@ int line6_create_audio_in_urbs(struct sn urb->interval =LINE6_ISO_INTERVAL ; urb->error_count =0 ; urb->complete = audio_in_callback; +if (usb_urb_ep_type_check (urb)) +return -EINVAL ; }return 0 ;
sound/usb/line6/playback.c +2 -0
@@ -432,6 +432,8 @@ int line6_create_audio_out_urbs(struct s urb->interval =LINE6_ISO_INTERVAL ; urb->error_count =0 ; urb->complete = audio_out_callback; +if (usb_urb_ep_type_check (urb)) +return -EINVAL ; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 148/215 ALSA: line6: Sync the pending work cancel at disconnection
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 68359a1ad8447c99732ebeab8c169bfed543667a upstream.
Recently syzkaller reported a UAF in LINE6 driver, and it's likely because we call cancel_delayed_work() at the disconnect callback instead of cancel_delayed_work_sync(). Let's use the correct one instead.
--- sound/usb/line6/driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/usb/line6/driver.c +1 -1
@@ -820,7 +820,7 @@ void line6_disconnect(struct usb_interfaif (WARN_ON (usbdev != line6->usbdev))return ; -cancel_delayed_work (&line6->startup_work); +cancel_delayed_work_sync (&line6->startup_work);if (line6->urb_listen !=NULL )line6_stop_listen (line6);
Greg Kroah-Hartman
maintainerPATCH 149/215 ALSA: usb-audio: Fix race against the error recovery URB submission
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 9b7e5208a941e2e491a83eb5fa83d889e888fa2f upstream.
USB MIDI driver has an error recovery mechanism to resubmit the URB in the delayed timer handler, and this may race with the standard start / stop operations. Although both start and stop operations themselves don't race with each other due to the umidi->mutex protection, but this isn't applied to the timer handler.
For fixing this potential race, the following changes are applied:
- Since the timer handler can't use the mutex, we apply the umidi->disc_lock protection at each input stream URB submission; this also needs to change the GFP flag to GFP_ATOMIC
- Add a check of the URB refcount and skip if already submitted
- Move the timer cancel call at disconnection to the beginning of the procedure; this assures the in-flight timer handler is gone properly before killing all pending URBs
--- sound/usb/midi.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
sound/usb/midi.c +12 -5
@@ -1499,6 +1499,8 @@ void snd_usbmidi_disconnect(struct list_spin_unlock_irq (&umidi->disc_lock);up_write (&umidi->disc_rwsem); +del_timer_sync (&umidi->error_timer); +for (i =0 ; i <MIDI_MAX_ENDPOINTS ; ++i) {struct snd_usb_midi_endpoint *ep = &umidi->endpoints[i];if (ep->out)
@@ -1525,7 +1527,6 @@ void snd_usbmidi_disconnect(struct list_ ep->in =NULL ; } } -del_timer_sync (&umidi->error_timer); }EXPORT_SYMBOL (snd_usbmidi_disconnect);
@@ -2282,16 +2283,22 @@ void snd_usbmidi_input_stop(struct list_ }EXPORT_SYMBOL (snd_usbmidi_input_stop); -static void snd_usbmidi_input_start_ep (struct snd_usb_midi_in_endpoint *ep) +static void snd_usbmidi_input_start_ep (struct snd_usb_midi *umidi, +struct snd_usb_midi_in_endpoint *ep) {unsigned int i; +unsigned long flags;if (!ep)return ;for (i =0 ; i <INPUT_URBS ; ++i) {struct urb *urb = ep->urbs[i]; - urb->dev = ep->umidi->dev; -snd_usbmidi_submit_urb (urb,GFP_KERNEL ); +spin_lock_irqsave (&umidi->disc_lock, flags); +if (!atomic_read (&urb->use_count)) { + urb->dev = ep->umidi->dev; +snd_usbmidi_submit_urb (urb,GFP_ATOMIC ); + } +spin_unlock_irqrestore (&umidi->disc_lock, flags); } }
@@ -2307,7 +2314,7 @@ void snd_usbmidi_input_start(struct listif (umidi->input_running || !umidi->opened[1 ])return ;for (i =0 ; i <MIDI_MAX_ENDPOINTS ; ++i) -snd_usbmidi_input_start_ep (umidi->endpoints[i].in); +snd_usbmidi_input_start_ep (umidi, umidi->endpoints[i].in); umidi->input_running =1 ; }EXPORT_SYMBOL (snd_usbmidi_input_start);
Greg Kroah-Hartman
maintainerPATCH 150/215 ALSA: hda/realtek - change to suitable link model for ASUS platform
In reply to Greg Kroah-HartmanFrom: Kailang Yang <[email protected]>
commit ef9ddb9dc4f8b1da3b975918cd1fd98ec055b918 upstream.
ASUS platform couldn't need to use Headset Mode model. It changes to the suitable model.
--- sound/pci/hda/patch_realtek.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/pci/hda/patch_realtek.c +2 -2
@@ -7082,7 +7082,7 @@ static const struct hda_fixup alc269_fix { } }, .chained = true, - .chain_id =ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC + .chain_id =ALC269_FIXUP_HEADSET_MIC }, [ALC294_FIXUP_ASUS_HEADSET_MIC] = { .type = HDA_FIXUP_PINS,
@@ -7091,7 +7091,7 @@ static const struct hda_fixup alc269_fix { } }, .chained = true, - .chain_id =ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC + .chain_id =ALC269_FIXUP_HEADSET_MIC }, [ALC294_FIXUP_ASUS_SPK] = { .type = HDA_FIXUP_VERBS,
Greg Kroah-Hartman
maintainerPATCH 151/215 ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G14(G401) series with ALC289
In reply to Greg Kroah-HartmanFrom: Armas Spann <[email protected]>
commit ff53664daff2a65f4bf2479ac56dfb3e908deff0 upstream.
This patch adds support for headset mic to the ASUS ROG Zephyrus G14(GA401) notebook series by adding the corresponding vendor/pci_device id, as well as adding a new fixup for the used realtek ALC289. The fixup stets the correct pin to get the headset mic correctly recognized on audio-jack.
--- sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+)
sound/pci/hda/patch_realtek.c +9 -0
@@ -6117,6 +6117,7 @@ enum {ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS ,ALC269VC_FIXUP_ACER_HEADSET_MIC ,ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE , + ALC289_FIXUP_ASUS_G401, }; static const struct hda_fixup alc269_fixups[] = {
@@ -7324,6 +7325,13 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id =ALC269_FIXUP_HEADSET_MIC }, + [ALC289_FIXUP_ASUS_G401] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl []) { + {0x19 ,0x03a11020 },/* headset mic with jack detect */ + { } + }, + }, };static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7504,6 +7512,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x1043 ,0x1bbd ,"ASUS Z550MA" ,ALC255_FIXUP_ASUS_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1043 ,0x1c23 ,"Asus X55U" ,ALC269_FIXUP_LIMIT_INT_MIC_BOOST ),SND_PCI_QUIRK (0x1043 ,0x1ccd ,"ASUS X555UB" ,ALC256_FIXUP_ASUS_MIC ), +SND_PCI_QUIRK (0x1043 ,0x1f11 ,"ASUS Zephyrus G14" ,ALC289_FIXUP_ASUS_G401 ),SND_PCI_QUIRK (0x1043 ,0x3030 ,"ASUS ZN270IE" ,ALC256_FIXUP_ASUS_AIO_GPIO2 ),SND_PCI_QUIRK (0x1043 ,0x831a ,"ASUS P901" ,ALC269_FIXUP_STEREO_DMIC ), SND_PCI_QUIRK(0x1043, 0x834a, "ASUS S101", ALC269_FIXUP_STEREO_DMIC),
Greg Kroah-Hartman
maintainerPATCH 152/215 ALSA: hda/realtek: Enable headset mic of Acer TravelMate B311R-31 with ALC256
In reply to Greg Kroah-HartmanFrom: Jian-Hong Pan <[email protected]>
commit f50a121d2f32bccc1d6b94df925a1ce44ea7eff7 upstream.
The Acer TravelMate B311R-31 laptop's audio (1025:1430) with ALC256 cannot detect the headset microphone until ALC256_FIXUP_ACER_MIC_NO_PRESENCE quirk maps the NID 0x19 as the headset mic pin.
--- sound/pci/hda/patch_realtek.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
sound/pci/hda/patch_realtek.c +11 -0
@@ -6118,6 +6118,7 @@ enum {ALC269VC_FIXUP_ACER_HEADSET_MIC ,ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE ,ALC289_FIXUP_ASUS_G401 , + ALC256_FIXUP_ACER_MIC_NO_PRESENCE, }; static const struct hda_fixup alc269_fixups[] = {
@@ -7332,6 +7333,15 @@ static const struct hda_fixup alc269_fix { } }, }, + [ALC256_FIXUP_ACER_MIC_NO_PRESENCE ] = { + .type =HDA_FIXUP_PINS , + .v.pins = (const struct hda_pintbl []) { + {0x19 ,0x02a11120 },/* use as headset mic, without its own jack detect */ + { } + }, + .chained = true, + .chain_id =ALC256_FIXUP_ASUS_HEADSET_MODE + }, };static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7360,6 +7370,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x1025 ,0x1308 ,"Acer Aspire Z24-890" ,ALC286_FIXUP_ACER_AIO_HEADSET_MIC ),SND_PCI_QUIRK (0x1025 ,0x132a ,"Acer TravelMate B114-21" ,ALC233_FIXUP_ACER_HEADSET_MIC ),SND_PCI_QUIRK (0x1025 ,0x1330 ,"Acer TravelMate X514-51T" ,ALC255_FIXUP_ACER_HEADSET_MIC ), +SND_PCI_QUIRK (0x1025 ,0x1430 ,"Acer TravelMate B311R-31" ,ALC256_FIXUP_ACER_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1028 ,0x0470 ,"Dell M101z" ,ALC269_FIXUP_DELL_M101Z ),SND_PCI_QUIRK (0x1028 ,0x054b ,"Dell XPS one 2710" ,ALC275_FIXUP_DELL_XPS ), SND_PCI_QUIRK(0x1028, 0x05bd, "Dell Latitude E6440", ALC292_FIXUP_DELL_E7X),
Greg Kroah-Hartman
maintainerPATCH 153/215 ALSA: hda/realtek - Enable Speaker for ASUS UX533 and UX534
In reply to Greg Kroah-HartmanFrom: Kailang Yang <[email protected]>
commit 473fbe13fd6f9082e413aea37e624ecbce5463cc upstream.
ASUS UX533 and UX534 speaker still can't output. End User feedback speaker didn't have output. Add this COEF value will enable it.
--- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+)
sound/pci/hda/patch_realtek.c +2 -0
@@ -7101,6 +7101,8 @@ static const struct hda_fixup alc269_fix/* Set EAPD high */ { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x8800 }, + { 0x20, AC_VERB_SET_COEF_INDEX, 0x0f }, + { 0x20, AC_VERB_SET_PROC_COEF, 0x7774 }, { } }, .chained = true,
Greg Kroah-Hartman
maintainerPATCH 154/215 ALSA: hda/realtek - Enable Speaker for ASUS UX563
In reply to Greg Kroah-HartmanFrom: Kailang Yang <[email protected]>
commit 158ae2f5e6fead30be1f0c203037f5556871513b upstream.
ASUS UX563 speaker can't output.
Add quirk to link suitable model will enable it. This model also could enable headset Mic.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -7516,6 +7516,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x1043 ,0x17d1 ,"ASUS UX431FL" ,ALC294_FIXUP_ASUS_DUAL_SPK ),SND_PCI_QUIRK (0x1043 ,0x18b1 ,"Asus MJ401TA" ,ALC256_FIXUP_ASUS_HEADSET_MIC ),SND_PCI_QUIRK (0x1043 ,0x18f1 ,"Asus FX505DT" ,ALC256_FIXUP_ASUS_HEADSET_MIC ), +SND_PCI_QUIRK (0x1043 ,0x194e ,"ASUS UX563FD" ,ALC294_FIXUP_ASUS_HPE ),SND_PCI_QUIRK (0x1043 ,0x19ce ,"ASUS B9450FA" ,ALC294_FIXUP_ASUS_HPE ),SND_PCI_QUIRK (0x1043 ,0x19e1 ,"ASUS UX581LV" ,ALC295_FIXUP_ASUS_MIC_NO_PRESENCE ), SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
Greg Kroah-Hartman
maintainerPATCH 155/215 USB: c67x00: fix use after free in c67x00_giveback_urb
In reply to Greg Kroah-HartmanFrom: Tom Rix <[email protected]>
commit 211f08347355cba1f769bbf3355816a12b3ddd55 upstream.
clang static analysis flags this error
c67x00-sched.c:489:55: warning: Use of memory after it is freed [unix.Malloc]
usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status);
^~~~~~~~~~~~Problem happens in this block of code
c67x00_release_urb(c67x00, urb); usb_hcd_unlink_urb_from_ep(c67x00_hcd_to_hcd(c67x00), urb); spin_unlock(&c67x00->lock); usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status);
In the call to c67x00_release_urb has this freeing of urbp
urbp = urb->hcpriv; urb->hcpriv = NULL; list_del(&urbp->hep_node); kfree(urbp);
And so urbp is freed before usb_hcd_giveback_urb uses it as its 3rd parameter.
Since all is required is the status, pass the status directly as is done in c64x00_urb_dequeue
--- drivers/usb/c67x00/c67x00-sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/c67x00/c67x00-sched.c +1 -1
@@ -486,7 +486,7 @@ c67x00_giveback_urb(struct c67x00_hcd *cc67x00_release_urb (c67x00, urb);usb_hcd_unlink_urb_from_ep (c67x00_hcd_to_hcd (c67x00), urb);spin_unlock (&c67x00->lock); -usb_hcd_giveback_urb (c67x00_hcd_to_hcd (c67x00), urb, urbp->status); +usb_hcd_giveback_urb (c67x00_hcd_to_hcd (c67x00), urb, status);spin_lock (&c67x00->lock); }
Greg Kroah-Hartman
maintainerPATCH 156/215 usb: dwc2: Fix shutdown callback in platform
In reply to Greg Kroah-HartmanFrom: Minas Harutyunyan <[email protected]>
commit 4fdf228cdf6925af45a2066d403821e0977bfddb upstream.
To avoid lot of interrupts from dwc2 core, which can be asserted in specific conditions need to disable interrupts on HW level instead of disable IRQs on Kernel level, because of IRQ can be shared between drivers.
--- drivers/usb/dwc2/platform.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/dwc2/platform.c +2 -1
@@ -337,7 +337,8 @@ static void dwc2_driver_shutdown(struct {struct dwc2_hsotg *hsotg =platform_get_drvdata (dev); -disable_irq (hsotg->irq); +dwc2_disable_global_interrupts (hsotg); +synchronize_irq (hsotg->irq); }/**
Greg Kroah-Hartman
maintainerPATCH 157/215 usb: chipidea: core: add wakeup support for extcon
In reply to Greg Kroah-HartmanFrom: Peter Chen <[email protected]>
commit 876d4e1e8298ad1f94d9e9392fc90486755437b4 upstream.
If wakeup event occurred by extcon event, it needs to call ci_irq again since the first ci_irq calling at extcon notifier only wakes up controller, but do noop for event handling, it causes the extcon use case can't work well from low power mode.
--- drivers/usb/chipidea/core.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/usb/chipidea/core.c +24 -0
@@ -1261,6 +1261,29 @@ static void ci_controller_suspend(structenable_irq (ci->irq); } +/* +* Handle the wakeup interrupt triggered by extcon connector +* We need to call ci_irq again for extcon since the first +* interrupt (wakeup int) only let the controller be out of +* low power mode, but not handle any interrupts. +*/ +static void ci_extcon_wakeup_int (struct ci_hdrc *ci) +{ +struct ci_hdrc_cable *cable_id, *cable_vbus; +u32 otgsc =hw_read_otgsc (ci, ~0 ); + + cable_id = &ci->platdata->id_extcon; + cable_vbus = &ci->platdata->vbus_extcon; + +if (!IS_ERR (cable_id->edev) && ci->is_otg && + (otgsc &OTGSC_IDIE ) && (otgsc &OTGSC_IDIS )) +ci_irq (ci->irq, ci); + +if (!IS_ERR (cable_vbus->edev) && ci->is_otg && + (otgsc &OTGSC_BSVIE ) && (otgsc &OTGSC_BSVIS )) +ci_irq (ci->irq, ci); +} +static int ci_controller_resume (struct device *dev) {struct ci_hdrc *ci =dev_get_drvdata (dev);
@@ -1293,6 +1316,7 @@ static int ci_controller_resume(struct denable_irq (ci->irq);if (ci_otg_is_fsm_mode (ci))ci_otg_fsm_wakeup_by_srp (ci); +ci_extcon_wakeup_int (ci); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 158/215 usb: gadget: function: fix missing spinlock in f_uac1_legacy
In reply to Greg Kroah-HartmanFrom: Zhang Qiang <[email protected]>
commit 8778eb0927ddcd3f431805c37b78fa56481aeed9 upstream.
Add a missing spinlock protection for play_queue, because the play_queue may be destroyed when the "playback_work" work func and "f_audio_out_ep_complete" callback func operate this paly_queue at the same time.
--- drivers/usb/gadget/function/f_uac1_legacy.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/gadget/function/f_uac1_legacy.c +2 -0
@@ -336,7 +336,9 @@ static int f_audio_out_ep_complete(struc/* Copy buffer is full, add it to the play_queue */ if (audio_buf_size - copy_buf->actual < req->actual) { +spin_lock_irq (&audio->lock);list_add_tail (©_buf->list, &audio->play_queue); +spin_unlock_irq (&audio->lock);schedule_work (&audio->playback_work); copy_buf =f_audio_buffer_alloc (audio_buf_size);if (IS_ERR (copy_buf))
Greg Kroah-Hartman
maintainerPATCH 159/215 USB: serial: iuu_phoenix: fix memory corruption
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit e7b931bee739e8a77ae216e613d3b99342b6dec0 upstream.
The driver would happily overwrite its write buffer with user data in 256 byte increments due to a removed buffer-space sanity check.
--- drivers/usb/serial/iuu_phoenix.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/usb/serial/iuu_phoenix.c +5 -3
@@ -697,14 +697,16 @@ static int iuu_uart_write(struct tty_strstruct iuu_private *priv =usb_get_serial_port_data (port);unsigned long flags; -if (count >256 ) -return -ENOMEM ; -spin_lock_irqsave (&priv->lock, flags); + count =min (count,256 - priv->writelen); +if (count ==0 ) + goto out; +/* fill the buffer */ memcpy (priv->writebuf + priv->writelen, buf, count); priv->writelen += count; +out:spin_unlock_irqrestore (&priv->lock, flags);return count;
Greg Kroah-Hartman
maintainerPATCH 160/215 USB: serial: cypress_m8: enable Simply Automated UPB PIM
In reply to Greg Kroah-HartmanFrom: James Hilliard <[email protected]>
commit 5c45d04c5081c1830d674f4d22d4400ea2083afe upstream.
This is a UPB (Universal Powerline Bus) PIM (Powerline Interface Module) which allows for controlling multiple UPB compatible devices from Linux using the standard serial interface.
Based on vendor application source code there are two different models of USB based PIM devices in addition to a number of RS232 based PIM's.
The vendor UPB application source contains the following USB ID's:
#define USB_PCS_VENDOR_ID 0x04b4 #define USB_PCS_PIM_PRODUCT_ID 0x5500 #define USB_SAI_VENDOR_ID 0x17dd #define USB_SAI_PIM_PRODUCT_ID 0x5500
The first set of ID's correspond to the PIM variant sold by Powerline Control Systems while the second corresponds to the Simply Automated Incorporated PIM. As the product ID for both of these match the default cypress HID->COM RS232 product ID it assumed that they both use an internal variant of this HID->COM RS232 converter hardware. However as the vendor ID for the Simply Automated variant is different we need to also add it to the cypress_M8 driver so that it is properly detected.
--- drivers/usb/serial/cypress_m8.c | 2 ++ drivers/usb/serial/cypress_m8.h | 3 +++ 2 files changed, 5 insertions(+)
drivers/usb/serial/cypress_m8.c +2 -0
@@ -59,6 +59,7 @@ static const struct usb_device_id id_tabstatic const struct usb_device_id id_table_cyphidcomrs232[] = { {USB_DEVICE (VENDOR_ID_CYPRESS ,PRODUCT_ID_CYPHIDCOM ) }, + {USB_DEVICE (VENDOR_ID_SAI ,PRODUCT_ID_CYPHIDCOM ) }, {USB_DEVICE (VENDOR_ID_POWERCOM ,PRODUCT_ID_UPS ) }, {USB_DEVICE (VENDOR_ID_FRWD ,PRODUCT_ID_CYPHIDCOM_FRWD ) }, { }/* Terminating entry */
@@ -73,6 +74,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB) }, { USB_DEVICE(VENDOR_ID_DELORME, PRODUCT_ID_EARTHMATEUSB_LT20) }, { USB_DEVICE(VENDOR_ID_CYPRESS, PRODUCT_ID_CYPHIDCOM) }, + { USB_DEVICE(VENDOR_ID_SAI, PRODUCT_ID_CYPHIDCOM) }, { USB_DEVICE(VENDOR_ID_POWERCOM, PRODUCT_ID_UPS) }, { USB_DEVICE(VENDOR_ID_FRWD, PRODUCT_ID_CYPHIDCOM_FRWD) }, { USB_DEVICE(VENDOR_ID_DAZZLE, PRODUCT_ID_CA42) },
drivers/usb/serial/cypress_m8.h +3 -0
@@ -25,6 +25,9 @@#define VENDOR_ID_CYPRESS 0x04b4#define PRODUCT_ID_CYPHIDCOM 0x5500 +/* Simply Automated HID->COM UPB PIM (using Cypress PID 0x5500) */ +#define VENDOR_ID_SAI 0x17dd +/* FRWD Dongle - a GPS sports watch */ #define VENDOR_ID_FRWD 0x6737#define PRODUCT_ID_CYPHIDCOM_FRWD 0x0001
Greg Kroah-Hartman
maintainerPATCH 161/215 USB: serial: ch341: add new Product ID for CH340
In reply to Greg Kroah-HartmanFrom: Igor Moura <[email protected]>
commit 5d0136f8e79f8287e6a36780601f0ce797cf11c2 upstream.
Add PID for CH340 that's found on some ESP8266 dev boards made by LilyGO. The specific device that contains such serial converter can be seen here: https://github.com/LilyGO/LILYGO-T-OI.
Apparently, it's a regular CH340, but I've confirmed with others that also bought this board that the PID found on this device (0x7522) differs from other devices with the "same" converter (0x7523). Simply adding its PID to the driver and rebuilding it made it work as expected.
--- drivers/usb/serial/ch341.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/ch341.c +1 -0
@@ -81,6 +81,7 @@static const struct usb_device_id id_table[] = { {USB_DEVICE (0x4348 ,0x5523 ) }, + {USB_DEVICE (0x1a86 ,0x7522 ) }, {USB_DEVICE (0x1a86 ,0x7523 ) }, {USB_DEVICE (0x1a86 ,0x5523 ) }, { },
Greg Kroah-Hartman
maintainerPATCH 162/215 USB: serial: option: add GosunCn GM500 series
In reply to Greg Kroah-HartmanFrom: Jörgen Storvist <[email protected]>
commit 08d4ef5cc9203a113702f24725f6cf4db476c958 upstream.
Add USB IDs for GosunCn GM500 series cellular modules.
RNDIS config:
usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=305a ProdID=1404 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber= C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
MBIM config:
usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=305a ProdID=1405 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber= C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
ECM config:
usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 13 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=305a ProdID=1406 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber= C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
--- drivers/usb/serial/option.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/serial/option.c +3 -0
@@ -2028,6 +2028,9 @@ static const struct usb_device_id option .driver_info = RSVD(4) | RSVD(5) }, { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0105, 0xff), /* Fibocom NL678 series */ .driver_info = RSVD(6) }, + { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1404, 0xff) }, /* GosunCn GM500 RNDIS */ + { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1405, 0xff) }, /* GosunCn GM500 MBIM */ + { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1406, 0xff) }, /* GosunCn GM500 ECM/NCM */ { } /* Terminating entry */ };MODULE_DEVICE_TABLE (usb, option_ids);
Greg Kroah-Hartman
maintainerPATCH 163/215 USB: serial: option: add Quectel EG95 LTE modem
In reply to Greg Kroah-HartmanFrom: AceLan Kao <[email protected]>
commit da6902e5b6dbca9081e3d377f9802d4fd0c5ea59 upstream.
Add support for Quectel Wireless Solutions Co., Ltd. EG95 LTE modem
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0195 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
--- drivers/usb/serial/option.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/serial/option.c +3 -0
@@ -245,6 +245,7 @@ static void option_instat_callback(struc/* These Quectel products use Quectel's vendor ID */ #define QUECTEL_PRODUCT_EC21 0x0121#define QUECTEL_PRODUCT_EC25 0x0125 +#define QUECTEL_PRODUCT_EG95 0x0195#define QUECTEL_PRODUCT_BG96 0x0296#define QUECTEL_PRODUCT_EP06 0x0306#define QUECTEL_PRODUCT_EM12 0x0512
@@ -1097,6 +1098,8 @@ static const struct usb_device_id option .driver_info = RSVD(4) }, { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25), .driver_info = RSVD(4) }, + { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG95), + .driver_info = RSVD(4) }, { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96), .driver_info = RSVD(4) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06, 0xff, 0xff, 0xff),
Greg Kroah-Hartman
maintainerPATCH 164/215 virt: vbox: Fix VBGL_IOCTL_VMMDEV_REQUEST_BIG and _LOG req numbers to match upstream
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit f794db6841e5480208f0c3a3ac1df445a96b079e upstream.
Until this commit the mainline kernel version (this version) of the vboxguest module contained a bug where it defined VBGL_IOCTL_VMMDEV_REQUEST_BIG and VBGL_IOCTL_LOG using _IOC(_IOC_READ | _IOC_WRITE, 'V', ...) instead of_IO(V, ...) as the out of tree VirtualBox upstream version does.
Since the VirtualBox userspace bits are always built against VirtualBox upstream's headers, this means that so far the mainline kernel version of the vboxguest module has been failing these 2 ioctls with -ENOTTY. I guess that VBGL_IOCTL_VMMDEV_REQUEST_BIG is never used causing us to not hit that one and sofar the vboxguest driver has failed to actually log any log messages passed it through VBGL_IOCTL_LOG.
This commit changes the VBGL_IOCTL_VMMDEV_REQUEST_BIG and VBGL_IOCTL_LOG defines to match the out of tree VirtualBox upstream vboxguest version, while keeping compatibility with the old wrong request defines so as to not break the kernel ABI in case someone has been using the old request defines.
--- drivers/virt/vboxguest/vboxguest_core.c | 4 +++- drivers/virt/vboxguest/vboxguest_core.h | 15 +++++++++++++++ drivers/virt/vboxguest/vboxguest_linux.c | 3 ++- include/uapi/linux/vboxguest.h | 4 ++-- 4 files changed, 22 insertions(+), 4 deletions(-)
drivers/virt/vboxguest/vboxguest_core.c +3 -1
@@ -1519,7 +1519,8 @@ int vbg_core_ioctl(struct vbg_session *s/* For VMMDEV_REQUEST hdr->type != VBG_IOCTL_HDR_TYPE_DEFAULT */ if (req_no_size ==VBG_IOCTL_VMMDEV_REQUEST (0 ) || - req ==VBG_IOCTL_VMMDEV_REQUEST_BIG ) + req ==VBG_IOCTL_VMMDEV_REQUEST_BIG || + req ==VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT )return vbg_ioctl_vmmrequest (gdev, session, data);if (hdr->type !=VBG_IOCTL_HDR_TYPE_DEFAULT )
@@ -1557,6 +1558,7 @@ int vbg_core_ioctl(struct vbg_session *scase VBG_IOCTL_HGCM_CALL (0 ):return vbg_ioctl_hgcm_call (gdev, session, f32bit, data);case VBG_IOCTL_LOG (0 ): +case VBG_IOCTL_LOG_ALT (0 ):return vbg_ioctl_log (data); }
drivers/virt/vboxguest/vboxguest_core.h +15 -0
@@ -15,6 +15,21 @@#include <linux/vboxguest.h> #include "vmmdev.h" +/* +* The mainline kernel version (this version) of the vboxguest module +* contained a bug where it defined VBGL_IOCTL_VMMDEV_REQUEST_BIG and +* VBGL_IOCTL_LOG using _IOC(_IOC_READ | _IOC_WRITE, 'V', ...) instead +* of _IO(V, ...) as the out of tree VirtualBox upstream version does. +* +* These _ALT definitions keep compatibility with the wrong defines the +* mainline kernel version used for a while. +* Note the VirtualBox userspace bits have always been built against +* VirtualBox upstream's headers, so this is likely not necessary. But +* we must never break our ABI so we keep these around to be 100% sure. +*/ +#define VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT _IOC(_IOC_READ | _IOC_WRITE, 'V', 3, 0) +#define VBG_IOCTL_LOG_ALT (s) _IOC(_IOC_READ | _IOC_WRITE, 'V', 9, s) +struct vbg_session ;/** VBox guest memory balloon. */
drivers/virt/vboxguest/vboxguest_linux.c +2 -1
@@ -131,7 +131,8 @@ static long vbg_misc_device_ioctl(struct* the need for a bounce-buffer and another copy later on. */ is_vmmdev_req = (req & ~IOCSIZE_MASK ) ==VBG_IOCTL_VMMDEV_REQUEST (0 ) || - req ==VBG_IOCTL_VMMDEV_REQUEST_BIG ; + req ==VBG_IOCTL_VMMDEV_REQUEST_BIG || + req ==VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT ;if (is_vmmdev_req) buf = vbg_req_alloc(size, VBG_IOCTL_HDR_TYPE_DEFAULT,
include/uapi/linux/vboxguest.h +2 -2
@@ -103,7 +103,7 @@ VMMDEV_ASSERT_SIZE(vbg_ioctl_driver_vers/* IOCTL to perform a VMM Device request larger then 1KB. */ -#define VBG_IOCTL_VMMDEV_REQUEST_BIG _IOC(_IOC_READ | _IOC_WRITE, 'V', 3, 0) +#define VBG_IOCTL_VMMDEV_REQUEST_BIG _IO('V', 3)/** VBG_IOCTL_HGCM_CONNECT data structure. */
@@ -198,7 +198,7 @@ struct vbg_ioctl_log { } u; }; -#define VBG_IOCTL_LOG (s) _IOC(_IOC_READ | _IOC_WRITE, 'V', 9, s) +#define VBG_IOCTL_LOG (s) _IO('V', 9)/** VBG_IOCTL_WAIT_FOR_EVENTS data structure. */
Greg Kroah-Hartman
maintainerPATCH 165/215 virt: vbox: Fix guest capabilities mask check
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit 59d1d2e8e1e7c50d2657d5e4812b53f71f507968 upstream.
Check the passed in capabilities against VMMDEV_GUEST_CAPABILITIES_MASK instead of against VMMDEV_EVENT_VALID_EVENT_MASK.
This tightens the allowed mask from 0x7ff to 0x7.
--- drivers/virt/vboxguest/vboxguest_core.c | 2 +- drivers/virt/vboxguest/vmmdev.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-)
drivers/virt/vboxguest/vboxguest_core.c +1 -1
@@ -1443,7 +1443,7 @@ static int vbg_ioctl_change_guest_capabi or_mask = caps->u.in.or_mask; not_mask = caps->u.in.not_mask; -if ((or_mask | not_mask) & ~VMMDEV_EVENT_VALID_EVENT_MASK ) +if ((or_mask | not_mask) & ~VMMDEV_GUEST_CAPABILITIES_MASK )return -EINVAL ; ret = vbg_set_session_capabilities(gdev, session, or_mask, not_mask,
drivers/virt/vboxguest/vmmdev.h +2 -0
@@ -206,6 +206,8 @@ VMMDEV_ASSERT_SIZE(vmmdev_mask, 24 + 8);* not. */ #define VMMDEV_GUEST_SUPPORTS_GRAPHICS BIT(2) +/* The mask of valid capabilities, for sanity checking. */ +#define VMMDEV_GUEST_CAPABILITIES_MASK 0x00000007U/** struct vmmdev_hypervisorinfo - Hypervisor info structure. */ struct vmmdev_hypervisorinfo {
Greg Kroah-Hartman
maintainerPATCH 166/215 Revert "tty: xilinx_uartps: Fix missing id assignment to the console"
In reply to Greg Kroah-HartmanFrom: Jan Kiszka <[email protected]>
commit 76ed2e105796710cf5b8a4ba43c81eceed948b70 upstream.
This reverts commit 2ae11c46d5fdc46cb396e35911c713d271056d35.
It turned out to break the ultra96-rev1, e.g., which uses uart1 as serial0 (and stdout-path = "serial0:115200n8").
--- drivers/tty/serial/xilinx_uartps.c | 1 - 1 file changed, 1 deletion(-)
drivers/tty/serial/xilinx_uartps.c +0 -1
@@ -1445,7 +1445,6 @@ static int cdns_uart_probe(struct platfo cdns_uart_uart_driver.nr =CDNS_UART_NR_PORTS ;#ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE cdns_uart_uart_driver.cons = &cdns_uart_console; - cdns_uart_console.index = id;#endif rc =uart_register_driver (&cdns_uart_uart_driver);
Greg Kroah-Hartman
maintainerPATCH 167/215 virtio: virtio_console: add missing MODULE_DEVICE_TABLE() for rproc serial
In reply to Greg Kroah-HartmanFrom: Alexander Lobakin <[email protected]>
commit 897c44f0bae574c5fb318c759b060bebf9dd6013 upstream.
rproc_serial_id_table lacks an exposure to module devicetable, so when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent is generated and no module autoloading occurs.
Add missing MODULE_DEVICE_TABLE() annotation and move the existing one for VIRTIO_ID_CONSOLE right to the table itself.
--- drivers/char/virtio_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/char/virtio_console.c +2 -1
@@ -2118,6 +2118,7 @@ static struct virtio_device_id id_table[ { VIRTIO_ID_CONSOLE, VIRTIO_DEV_ANY_ID }, { 0 }, }; +MODULE_DEVICE_TABLE (virtio, id_table);static unsigned int features[] = { VIRTIO_CONSOLE_F_SIZE,
@@ -2130,6 +2131,7 @@ static struct virtio_device_id rproc_ser#endif { 0 }, }; +MODULE_DEVICE_TABLE (virtio, rproc_serial_id_table);static unsigned int rproc_serial_features[] = { };
@@ -2282,6 +2284,5 @@ static void __exit fini(void)module_init (init);module_exit (fini); -MODULE_DEVICE_TABLE (virtio, id_table);MODULE_DESCRIPTION ("Virtio console driver" );MODULE_LICENSE ("GPL" );
Greg Kroah-Hartman
maintainerPATCH 168/215 serial: mxs-auart: add missed iounmap() in probe failure and remove
In reply to Greg Kroah-HartmanFrom: Chuhong Yuan <[email protected]>
commit d8edf8eb5f6e921fe6389f96d2cd05862730a6ff upstream.
This driver calls ioremap() in probe, but it misses calling iounmap() in probe's error handler and remove.
Add the missed calls to fix it.
--- drivers/tty/serial/mxs-auart.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/tty/serial/mxs-auart.c +8 -4
@@ -1701,21 +1701,21 @@ static int mxs_auart_probe(struct platfo irq =platform_get_irq (pdev,0 );if (irq <0 ) { ret = irq; - goto out_disable_clks; + goto out_iounmap; } s->port.irq = irq; ret =devm_request_irq (&pdev->dev, irq, mxs_auart_irq_handle,0 ,dev_name (&pdev->dev), s);if (ret) - goto out_disable_clks; + goto out_iounmap;platform_set_drvdata (pdev, s); ret =mxs_auart_init_gpios (s, &pdev->dev);if (ret) {dev_err (&pdev->dev,"Failed to initialize GPIOs.\n" ); - goto out_disable_clks; + goto out_iounmap; }/*
@@ -1723,7 +1723,7 @@ static int mxs_auart_probe(struct platfo*/ ret =mxs_auart_request_gpio_irq (s);if (ret) - goto out_disable_clks; + goto out_iounmap; auart_port[s->port.line] = s;
@@ -1749,6 +1749,9 @@ out_free_qpio_irq:mxs_auart_free_gpio_irq (s); auart_port[pdev->id] =NULL ; +out_iounmap: +iounmap (s->port.membase); + out_disable_clks:if (is_asm9260_auart (s)) {clk_disable_unprepare (s->clk);
@@ -1764,6 +1767,7 @@ static int mxs_auart_remove(struct platfuart_remove_one_port (&auart_driver, &s->port); auart_port[pdev->id] =NULL ;mxs_auart_free_gpio_irq (s); +iounmap (s->port.membase);if (is_asm9260_auart (s)) {clk_disable_unprepare (s->clk);clk_disable_unprepare (s->clk_ahb);
Greg Kroah-Hartman
maintainerPATCH 169/215 ovl: fix regression with re-formatted lower squashfs
In reply to Greg Kroah-HartmanFrom: Amir Goldstein <[email protected]>
commit a888db310195400f050b89c47673f0f8babfbb41 upstream.
Commit 9df085f3c9a2 ("ovl: relax requirement for non null uuid of lower fs") relaxed the requirement for non null uuid with single lower layer to allow enabling index and nfs_export features with single lower squashfs.
Fabian reported a regression in a setup when overlay re-uses an existing upper layer and re-formats the lower squashfs image. Because squashfs has no uuid, the origin xattr in upper layer are decoded from the new lower layer where they may resolve to a wrong origin file and user may get an ESTALE or EIO error on lookup.
To avoid the reported regression while still allowing the new features with single lower squashfs, do not allow decoding origin with lower null uuid unless user opted-in to one of the new features that require following the lower inode of non-dir upper (index, xino, metacopy).
--- fs/overlayfs/super.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
fs/overlayfs/super.c +12 -0
@@ -1258,6 +1258,18 @@ static bool ovl_lower_uuid_ok(struct ovlif (!ofs->config.nfs_export && !ofs->upper_mnt)return true; +/* +* We allow using single lower with null uuid for index and nfs_export +* for example to support those features with single lower squashfs. +* To avoid regressions in setups of overlay with re-formatted lower +* squashfs, do not allow decoding origin with lower null uuid unless +* user opted-in to one of the new features that require following the +* lower inode of non-dir upper. +*/ +if (!ofs->config.index && !ofs->config.metacopy && !ofs->config.xino && +uuid_is_null (uuid)) +return false; +for (i =0 ; i < ofs->numlowerfs; i++) {/* * We use uuid to associate an overlay lower file handle with a
Greg Kroah-Hartman
maintainerPATCH 170/215 ovl: inode reference leak in ovl_is_inuse true case.
In reply to Greg Kroah-HartmanFrom: youngjun <[email protected]>
commit 24f14009b8f1754ec2ae4c168940c01259b0f88a upstream.
When "ovl_is_inuse" true case, trap inode reference not put. plus adding the comment explaining sequence of ovl_is_inuse after ovl_setup_trap.
--- fs/overlayfs/super.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
fs/overlayfs/super.c +10 -1
@@ -1356,14 +1356,23 @@ static int ovl_get_lower_layers(struct sif (err <0 ) goto out; +/* +* Check if lower root conflicts with this overlay layers before +* checking if it is in-use as upperdir/workdir of "another" +* mount, because we do not bother to check in ovl_is_inuse() if +* the upperdir/workdir is in fact in-use by our +* upperdir/workdir. +*/ err =ovl_setup_trap (sb, stack[i].dentry, &trap,"lowerdir" );if (err) goto out;if (ovl_is_inuse (stack[i].dentry)) { err =ovl_report_in_use (ofs,"lowerdir" ); -if (err) +if (err) { +iput (trap); goto out; + } } mnt =clone_private_mount (&stack[i]);
Greg Kroah-Hartman
maintainerPATCH 171/215 ovl: relax WARN_ON() when decoding lower directory file handle
In reply to Greg Kroah-HartmanFrom: Amir Goldstein <[email protected]>
commit 124c2de2c0aee96271e4ddab190083d8aa7aa71a upstream.
Decoding a lower directory file handle to overlay path with cold inode/dentry cache may go as follows:
1. Decode real lower file handle to lower dir path
2. Check if lower dir is indexed (was copied up)
3. If indexed, get the upper dir path from index
4. Lookup upper dir path in overlay
5. If overlay path found, verify that overlay lower is the lower dir from step 1
On failure to verify step 5 above, user will get an ESTALE error and a WARN_ON will be printed.
A mismatch in step 5 could be a result of lower directory that was renamed while overlay was offline, after that lower directory has been copied up and indexed.
This is a scripted reproducer based on xfstest overlay/052:
# Create lower subdir
create_dirs
create_test_files $lower/lowertestdir/subdir
mount_dirs
# Copy up lower dir and encode lower subdir file handle touch $SCRATCH_MNT/lowertestdir
test_file_handles $SCRATCH_MNT/lowertestdir/subdir -p -o $tmp.fhandle # Rename lower dir offline
unmount_dirs
mv $lower/lowertestdir $lower/lowertestdir.new/
mount_dirs
# Attempt to decode lower subdir file handle test_file_handles $SCRATCH_MNT -p -i $tmp.fhandle
Since this WARN_ON() can be triggered by user we need to relax it.
--- fs/overlayfs/export.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/overlayfs/export.c +1 -1
@@ -482,7 +482,7 @@ static struct dentry *ovl_lookup_real_inif (IS_ERR_OR_NULL (this))return this; -if (WARN_ON (ovl_dentry_real_at (this, layer->idx) != real)) { +if (ovl_dentry_real_at (this, layer->idx) != real) {dput (this); this =ERR_PTR (-EIO ); }
Greg Kroah-Hartman
maintainerPATCH 172/215 ovl: fix unneeded call to ovl_change_flags()
In reply to Greg Kroah-HartmanFrom: Amir Goldstein <[email protected]>
commit 81a33c1ee941c3bb9ffc6bac8f676be13351344e upstream.
The check if user has changed the overlay file was wrong, causing unneeded call to ovl_change_flags() including taking f_lock on every file access.
--- fs/overlayfs/file.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
fs/overlayfs/file.c +6 -4
@@ -21,13 +21,16 @@ static char ovl_whatisit(struct inode *ireturn 'm' ; } +/* No atime modificaton nor notify on underlying */ +#define OVL_OPEN_FLAGS (O_NOATIME | FMODE_NONOTIFY) +static struct file *ovl_open_realfile (const struct file *file,struct inode *realinode) {struct inode *inode =file_inode (file);struct file *realfile;const struct cred *old_cred; -int flags = file->f_flags |O_NOATIME |FMODE_NONOTIFY ; +int flags = file->f_flags |OVL_OPEN_FLAGS ; old_cred =ovl_override_creds (inode->i_sb); realfile = open_with_fake_path(&file->f_path, flags, realinode,
@@ -48,8 +51,7 @@ static int ovl_change_flags(struct filestruct inode *inode =file_inode (file);int err; -/* No atime modificaton on underlying */ - flags |=O_NOATIME |FMODE_NONOTIFY ; + flags |=OVL_OPEN_FLAGS ;/* If some flag changed that cannot be changed then something's amiss */ if (WARN_ON ((file->f_flags ^ flags) & ~OVL_SETFL_MASK ))
@@ -102,7 +104,7 @@ static int ovl_real_fdget_meta(const str }/* Did the flags change since open? */ -if (unlikely ((file->f_flags ^ real->file->f_flags) & ~O_NOATIME )) +if (unlikely ((file->f_flags ^ real->file->f_flags) & ~OVL_OPEN_FLAGS ))return ovl_change_flags (real->file, file->f_flags);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 173/215 fuse: ignore data argument of mount(..., MS_REMOUNT)
In reply to Greg Kroah-HartmanFrom: Miklos Szeredi <[email protected]>
commit e8b20a474cf2c42698d1942f939ff2128819f151 upstream.
The command
mount -o remount -o unknownoption /mnt/fuse
succeeds on kernel versions prior to v5.4 and fails on kernel version at or after. This is because fuse_parse_param() rejects any unrecognised options in case of FS_CONTEXT_FOR_RECONFIGURE, just as for FS_CONTEXT_FOR_MOUNT.
This causes a regression in case the fuse filesystem is in fstab, since remount sends all options found there to the kernel; even ones that are meant for the initial mount and are consumed by the userspace fuse server.
Fix this by ignoring mount options, just as fuse_remount_fs() did prior to the conversion to the new API.
--- fs/fuse/inode.c | 7 +++++++ 1 file changed, 7 insertions(+)
fs/fuse/inode.c +7 -0
@@ -473,6 +473,13 @@ static int fuse_parse_param(struct fs_costruct fuse_fs_context *ctx = fc->fs_private;int opt; +/* +* Ignore options coming from mount(MS_REMOUNT) for backward +* compatibility. +*/ +if (fc->purpose ==FS_CONTEXT_FOR_RECONFIGURE ) +return 0 ; + opt =fs_parse (fc, &fuse_fs_parameters, param, &result);if (opt <0 )return opt;
Greg Kroah-Hartman
maintainerPATCH 174/215 fuse: use ->reconfigure() instead of ->remount_fs()
In reply to Greg Kroah-HartmanFrom: Miklos Szeredi <[email protected]>
commit 0189a2d367f49729622fdafaef5da73161591859 upstream.
s_op->remount_fs() is only called from legacy_reconfigure(), which is not used after being converted to the new API.
Convert to using ->reconfigure(). This restores the previous behavior of syncing the filesystem and rejecting MS_MANDLOCK on remount.
--- fs/fuse/inode.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
fs/fuse/inode.c +5 -3
@@ -121,10 +121,12 @@ static void fuse_evict_inode(struct inod } } -static int fuse_remount_fs (struct super_block *sb,int *flags,char *data) +static int fuse_reconfigure (struct fs_context *fc) { +struct super_block *sb = fc->root->d_sb; +sync_filesystem (sb); -if (*flags &SB_MANDLOCK ) +if (fc->sb_flags &SB_MANDLOCK )return -EINVAL ;return 0 ;
@@ -822,7 +824,6 @@ static const struct super_operations fus .evict_inode = fuse_evict_inode, .write_inode = fuse_write_inode, .drop_inode = generic_delete_inode, - .remount_fs = fuse_remount_fs, .put_super = fuse_put_super, .umount_begin = fuse_umount_begin, .statfs = fuse_statfs,
@@ -1296,6 +1297,7 @@ static int fuse_get_tree(struct fs_contestatic const struct fs_context_operations fuse_context_ops = { .free = fuse_free_fc, .parse_param = fuse_parse_param, + .reconfigure = fuse_reconfigure, .get_tree = fuse_get_tree, };
Greg Kroah-Hartman
maintainerPATCH 175/215 fuse: Fix parameter for FS_IOC_{GET,SET}FLAGS
In reply to Greg Kroah-HartmanFrom: Chirantan Ekbote <[email protected]>
commit 31070f6ccec09f3bd4f1e28cd1e592fa4f3ba0b6 upstream.
The ioctl encoding for this parameter is a long but the documentation says it should be an int and the kernel drivers expect it to be an int. If the fuse driver treats this as a long it might end up scribbling over the stack of a userspace process that only allocated enough space for an int.
This was previously discussed in [1] and a patch for fuse was proposed in [2]. From what I can tell the patch in [2] was nacked in favor of adding new, "fixed" ioctls and using those from userspace. However there is still no "fixed" version of these ioctls and the fact is that it's sometimes infeasible to change all userspace to use the new one.
Handling the ioctls specially in the fuse driver seems like the most pragmatic way for fuse servers to support them without causing crashes in userspace applications that call them.
[1]: https://lore.kernel.org/linux-fsdevel/[email protected]/T/
[2]: https://sourceforge.net/p/fuse/mailman/message/31771759/
--- fs/fuse/file.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
fs/fuse/file.c +11 -1
@@ -18,6 +18,7 @@#include <linux/swap.h> #include <linux/falloc.h> #include <linux/uio.h> +#include <linux/fs.h> static struct page **fuse_pages_alloc (unsigned int npages,gfp_t flags,struct fuse_page_desc **desc)
@@ -2758,7 +2759,16 @@ long fuse_do_ioctl(struct file *file, unstruct iovec *iov = iov_page; iov->iov_base = (void __user *)arg; - iov->iov_len =_IOC_SIZE (cmd); + +switch (cmd) { +case FS_IOC_GETFLAGS : +case FS_IOC_SETFLAGS : + iov->iov_len =sizeof (int ); +break ; +default : + iov->iov_len =_IOC_SIZE (cmd); +break ; + }if (_IOC_DIR (cmd) & _IOC_WRITE) { in_iov = iov;
Greg Kroah-Hartman
maintainerPATCH 176/215 Revert "zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()"
In reply to Greg Kroah-HartmanFrom: Wade Mealing <[email protected]>
commit 853eab68afc80f59f36bbdeb715e5c88c501e680 upstream.
Turns out that the permissions for 0400 really are what we want here, otherwise any user can read from this file.
[fixed formatting, added changelog, and made attribute static - gregkh]
--- drivers/block/zram/zram_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/block/zram/zram_drv.c +2 -1
@@ -2023,7 +2023,8 @@ static ssize_t hot_add_show(struct classreturn ret;return scnprintf (buf,PAGE_SIZE ,"%d\n" , ret); } -static CLASS_ATTR_RO (hot_add); +static struct class_attribute class_attr_hot_add = +__ATTR (hot_add,0400 , hot_add_show,NULL ); static ssize_t hot_remove_store(struct class *class, struct class_attribute *attr,
Greg Kroah-Hartman
maintainerPATCH 177/215 mei: bus: dont clean driver pointer
In reply to Greg Kroah-HartmanFrom: Alexander Usyskin <[email protected]>
commit e852c2c251ed9c23ae6e3efebc5ec49adb504207 upstream.
It's not needed to set driver to NULL in mei_cl_device_remove() which is bus_type remove() handler as this is done anyway in __device_release_driver().
Actually this is causing an endless loop in driver_detach() on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module. The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty. as the check is always true in __device_release_driver()
if (dev->driver != drv) return;
The non upstream patch is causing this behavior, titled:
'vfio -- release device lock before userspace requests'
Nevertheless the fix is correct also for the upstream.
--- drivers/misc/mei/bus.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/misc/mei/bus.c +1 -2
@@ -745,9 +745,8 @@ static int mei_cl_device_remove(struct dmei_cl_bus_module_put (cldev);module_put (THIS_MODULE ); - dev->driver =NULL ; -return ret; +return ret; } static ssize_t name_show(struct device *dev, struct device_attribute *a,
Greg Kroah-Hartman
maintainerPATCH 178/215 Input: i8042 - add Lenovo XiaoXin Air 12 to i8042 nomux list
In reply to Greg Kroah-HartmanFrom: David Pedersen <[email protected]>
commit 17d51429da722cd8fc77a365a112f008abf4f8b3 upstream.
This fixes two finger trackpad scroll on the Lenovo XiaoXin Air 12. Without nomux, the trackpad behaves as if only one finger is present and moves the cursor when trying to scroll.
--- drivers/input/serio/i8042-x86ia64io.h | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/input/serio/i8042-x86ia64io.h +7 -0
@@ -426,6 +426,13 @@ static const struct dmi_system_id __init }, }, { +/* Lenovo XiaoXin Air 12 */ + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_NAME, "80UN"), + }, + }, + { .matches = {DMI_MATCH (DMI_SYS_VENDOR ,"Acer" ), DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 1360"),
Greg Kroah-Hartman
maintainerPATCH 179/215 Input: elan_i2c - add more hardware ID for Lenovo laptops
In reply to Greg Kroah-HartmanFrom: Dave Wang <[email protected]>
commit a50ca29523b18baea548bdf5df9b4b923c2bb4f6 upstream.
This adds more hardware IDs for Elan touchpads found in various Lenovo laptops.
--- include/linux/input/elan-i2c-ids.h | 7 +++++++ 1 file changed, 7 insertions(+)
include/linux/input/elan-i2c-ids.h +7 -0
@@ -67,8 +67,15 @@ static const struct acpi_device_id elan_ { "ELAN062B", 0 }, { "ELAN062C", 0 }, { "ELAN062D", 0 }, + { "ELAN062E", 0 }, /* Lenovo V340 Whiskey Lake U */ + { "ELAN062F", 0 }, /* Lenovo V340 Comet Lake U */ { "ELAN0631", 0 }, { "ELAN0632", 0 }, + { "ELAN0633", 0 }, /* Lenovo S145 */ + { "ELAN0634", 0 }, /* Lenovo V340 Ice lake */ + { "ELAN0635", 0 }, /* Lenovo V1415-IIL */ + { "ELAN0636", 0 }, /* Lenovo V1415-Dali */ + { "ELAN0637", 0 }, /* Lenovo V1415-IGLR */ { "ELAN1000", 0 }, { } };
Greg Kroah-Hartman
maintainerPATCH 180/215 uio_pdrv_genirq: Remove warning when irq is not specified
In reply to Greg Kroah-HartmanFrom: Esben Haabendal <[email protected]>
commit 324ac45f25e634eca6346953ae531e8da3e0c73d upstream.
Since e3a3c3a20555 ("UIO: fix uio_pdrv_genirq with device tree but no interrupt"), the uio_pdrv_genirq has supported use without interrupt, so the change in 7723f4c5ecdb ("driver core: platform: Add an error message to") added false warnings for those cases.
--- drivers/uio/uio_pdrv_genirq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/uio/uio_pdrv_genirq.c +1 -1
@@ -152,7 +152,7 @@ static int uio_pdrv_genirq_probe(struct priv->pdev = pdev;if (!uioinfo->irq) { - ret =platform_get_irq (pdev,0 ); + ret =platform_get_irq_optional (pdev,0 ); uioinfo->irq = ret;if (ret == -ENXIO && pdev->dev.of_node) uioinfo->irq =UIO_IRQ_NONE ;
Greg Kroah-Hartman
maintainerPATCH 181/215 uio_pdrv_genirq: fix use without device tree and no interrupt
In reply to Greg Kroah-HartmanFrom: Esben Haabendal <[email protected]>
commit bf12fdf0ab728ca8e5933aac46dd972c0dd0421e upstream.
While e3a3c3a20555 ("UIO: fix uio_pdrv_genirq with device tree but no interrupt") added support for using uio_pdrv_genirq for devices without interrupt for device tree platforms, the removal of uio_pdrv in 26dac3c49d56 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") broke the support for non device tree platforms.
This change fixes this, so that uio_pdrv_genirq can be used without interrupt on all platforms.
This still leaves the support that uio_pdrv had for custom interrupt handler lacking, as uio_pdrv_genirq does not handle it (yet).
--- drivers/uio/uio_pdrv_genirq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/uio/uio_pdrv_genirq.c +1 -1
@@ -154,7 +154,7 @@ static int uio_pdrv_genirq_probe(structif (!uioinfo->irq) { ret =platform_get_irq_optional (pdev,0 ); uioinfo->irq = ret; -if (ret == -ENXIO && pdev->dev.of_node) +if (ret == -ENXIO ) uioinfo->irq =UIO_IRQ_NONE ;else if (ret <0 ) {dev_err (&pdev->dev,"failed to get IRQ\n" );
Greg Kroah-Hartman
maintainerPATCH 182/215 scsi: megaraid_sas: Remove undefined ENABLE_IRQ_POLL macro
In reply to Greg Kroah-HartmanFrom: Chandrakanth Patil <[email protected]>
commit 07d3f04550023395bbf34b99ec7e00fc50d9859f upstream.
As the ENABLE_IRQ_POLL macro is undefined, the check for ENABLE_IRQ_POLL macro in ISR will always be false. This leads to irq polling being non-functional.
Remove ENABLE_IRQ_POLL check from ISR.
--- drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 -- 1 file changed, 2 deletions(-)
drivers/scsi/megaraid/megaraid_sas_fusion.c +0 -2
@@ -3787,10 +3787,8 @@ static irqreturn_t megasas_isr_fusion(inif (instance->mask_interrupts)return IRQ_NONE ; -#if defined(ENABLE_IRQ_POLL )if (irq_context->irq_poll_scheduled)return IRQ_HANDLED ; -#endif if (!instance->msix_vectors) { mfiStatus = instance->instancet->clear_intr (instance);
Greg Kroah-Hartman
maintainerPATCH 183/215 timer: Prevent base->clk from moving backward
In reply to Greg Kroah-HartmanFrom: Frederic Weisbecker <[email protected]>
commit 30c66fc30ee7a98c4f3adf5fb7e213b61884474f upstream.
When a timer is enqueued with a negative delta (ie: expiry is below base->clk), it gets added to the wheel as expiring now (base->clk).
Yet the value that gets stored in base->next_expiry, while calling trigger_dyntick_cpu(), is the initial timer->expires value. The resulting state becomes:
base->next_expiry < base->clk
On the next timer enqueue, forward_timer_base() may accidentally rewind base->clk. As a possible outcome, timers may expire way too early, the worst case being that the highest wheel levels get spuriously processed again.
To prevent from that, make sure that base->next_expiry doesn't get below base->clk.
--- kernel/time/timer.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
kernel/time/timer.c +14 -3
@@ -585,7 +585,15 @@ trigger_dyntick_cpu(struct timer_base *b* Set the next expiry time and kick the CPU so it can reevaluate the * wheel: */ - base->next_expiry = timer->expires; +if (time_before (timer->expires, base->clk)) { +/* +* Prevent from forward_timer_base() moving the base->clk +* backward +*/ + base->next_expiry = base->clk; + }else { + base->next_expiry = timer->expires; + }wake_up_nohz_cpu (base->cpu); }
@@ -897,10 +905,13 @@ static inline void forward_timer_base(st* If the next expiry value is > jiffies, then we fast forward to * jiffies otherwise we forward to the next expiry value. */ -if (time_after (base->next_expiry, jnow)) +if (time_after (base->next_expiry, jnow)) { base->clk = jnow; -else + }else { +if (WARN_ON_ONCE (time_before (base->next_expiry, base->clk))) +return ; base->clk = base->next_expiry; + }#endif }
Greg Kroah-Hartman
maintainerPATCH 184/215 timer: Fix wheel index calculation on last level
In reply to Greg Kroah-HartmanFrom: Frederic Weisbecker <[email protected]>
commit e2a71bdea81690b6ef11f4368261ec6f5b6891aa upstream.
When an expiration delta falls into the last level of the wheel, that delta has be compared against the maximum possible delay and reduced to fit in if necessary.
However instead of comparing the delta against the maximum, the code compares the actual expiry against the maximum. Then instead of fixing the delta to fit in, it sets the maximum delta as the expiry value.
This can result in various undesired outcomes, the worst possible one being a timer expiring 15 days ahead to fire immediately.
--- kernel/time/timer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/time/timer.c +2 -2
@@ -522,8 +522,8 @@ static int calc_wheel_index(unsigned lon* Force expire obscene large timeouts to expire at the * capacity limit of the wheel. */ -if (expires >=WHEEL_TIMEOUT_CUTOFF ) - expires =WHEEL_TIMEOUT_MAX ; +if (delta >=WHEEL_TIMEOUT_CUTOFF ) + expires = clk +WHEEL_TIMEOUT_MAX ; idx =calc_index (expires,LVL_DEPTH -1 ); }
Greg Kroah-Hartman
maintainerPATCH 185/215 riscv: use 16KB kernel stack on 64-bit
In reply to Greg Kroah-HartmanFrom: Andreas Schwab <[email protected]>
commit 0cac21b02ba5f3095fd2dcc77c26a25a0b2432ed upstream.
With the current 8KB stack size there are frequent overflows in a 64-bit configuration. We may split IRQ stacks off in the future, but this fixes a number of issues right now.
--- arch/riscv/include/asm/thread_info.h | 4 ++++ 1 file changed, 4 insertions(+)
arch/riscv/include/asm/thread_info.h +4 -0
@@ -12,7 +12,11 @@#include <linux/const.h> /* thread information allocation */ +#ifdef CONFIG_64BIT +#define THREAD_SIZE_ORDER (2) +#else #define THREAD_SIZE_ORDER (1) +#endif #define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)#ifndef __ASSEMBLY__
Greg Kroah-Hartman
maintainerPATCH 186/215 hwmon: (emc2103) fix unable to change fan pwm1_enable attribute
In reply to Greg Kroah-HartmanFrom: Vishwas M <[email protected]>
commit 14b0e83dc4f1e52b94acaeb85a18fd7fdd46d2dc upstream.
This patch fixes a bug which does not let FAN mode to be changed from sysfs(pwm1_enable). i.e pwm1_enable can not be set to 3, it will always remain at 0.
This is caused because the device driver handles the result of "read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg)" incorrectly. The driver thinks an error has occurred if the (result != 0). This has been fixed by changing the condition to (result < 0).
--- drivers/hwmon/emc2103.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/emc2103.c +1 -1
@@ -443,7 +443,7 @@ static ssize_t pwm1_enable_store(struct } result =read_u8_from_i2c (client,REG_FAN_CONF1 , &conf_reg); -if (result) { +if (result <0 ) { count = result; goto err; }
Greg Kroah-Hartman
maintainerPATCH 187/215 powerpc/book3s64/pkeys: Fix pkey_access_permitted() for execute disable pkey
In reply to Greg Kroah-HartmanFrom: Aneesh Kumar K.V <[email protected]>
commit 192b6a780598976feb7321ff007754f8511a4129 upstream.
Even if the IAMR value denies execute access, the current code returns true from pkey_access_permitted() for an execute permission check, if the AMR read pkey bit is cleared.
This results in repeated page fault loop with a test like below:
#define _GNU_SOURCE #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> #include <inttypes.h> #include <assert.h> #include <malloc.h> #include <unistd.h> #include <pthread.h> #include <sys/mman.h> #ifdef SYS_pkey_mprotect #undef SYS_pkey_mprotect #endif #ifdef SYS_pkey_alloc #undef SYS_pkey_alloc #endif #ifdef SYS_pkey_free #undef SYS_pkey_free #endif #undef PKEY_DISABLE_EXECUTE #define PKEY_DISABLE_EXECUTE 0x4 #define SYS_pkey_mprotect 386 #define SYS_pkey_alloc 384 #define SYS_pkey_free 385 #define PPC_INST_NOP 0x60000000 #define PPC_INST_BLR 0x4e800020 #define PROT_RWX (PROT_READ | PROT_WRITE | PROT_EXEC)
static int sys_pkey_mprotect(void *addr, size_t len, int prot, int pkey) {
return syscall(SYS_pkey_mprotect, addr, len, prot, pkey);
}
static int sys_pkey_alloc(unsigned long flags, unsigned long access_rights)
{
return syscall(SYS_pkey_alloc, flags, access_rights);
}
static int sys_pkey_free(int pkey)
{
return syscall(SYS_pkey_free, pkey);
}
static void do_execute(void *region)
{
/* jump to region */
asm volatile(
"mtctr %0;"
"bctrl"
: : "r"(region) : "ctr", "lr");
}
static void do_protect(void *region)
{
size_t pgsize;
int i, pkey;
pgsize = getpagesize();
pkey = sys_pkey_alloc(0, PKEY_DISABLE_EXECUTE);
assert (pkey > 0);
/* perform mprotect */
assert(!sys_pkey_mprotect(region, pgsize, PROT_RWX, pkey));
do_execute(region);
/* free pkey */
assert(!sys_pkey_free(pkey));
}
int main(int argc, char **argv)
{
size_t pgsize, numinsns;
unsigned int *region;
int i;
/* allocate memory region to protect */
pgsize = getpagesize();
region = memalign(pgsize, pgsize);
assert(region != NULL);
assert(!mprotect(region, pgsize, PROT_RWX));
/* fill page with NOPs with a BLR at the end */
numinsns = pgsize / sizeof(region[0]);
for (i = 0; i < numinsns - 1; i++)
region[i] = PPC_INST_NOP;
region[i] = PPC_INST_BLR;
do_protect(region);
return EXIT_SUCCESS;
}The fix is to only check the IAMR for an execute check, the AMR value is not relevant.
--- arch/powerpc/mm/book3s64/pkeys.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
arch/powerpc/mm/book3s64/pkeys.c +7 -5
@@ -367,12 +367,14 @@ static bool pkey_access_permitted(int pkreturn true; pkey_shift =pkeyshift (pkey); -if (execute && !(read_iamr () & (IAMR_EX_BIT << pkey_shift))) -return true; +if (execute) +return !(read_iamr () & (IAMR_EX_BIT << pkey_shift)); + + amr =read_amr (); +if (write) +return !(amr & (AMR_WR_BIT << pkey_shift)); - amr =read_amr ();/* Delay reading amr until absolutely needed */ -return ((!write && !(amr & (AMR_RD_BIT << pkey_shift))) || - (write && !(amr & (AMR_WR_BIT << pkey_shift)))); +return !(amr & (AMR_RD_BIT << pkey_shift)); }bool arch_pte_access_permitted (u64 pte,bool write,bool execute)
Greg Kroah-Hartman
maintainerPATCH 188/215 powerpc/pseries/svm: Fix incorrect check for shared_lppaca_size
In reply to Greg Kroah-HartmanFrom: Satheesh Rajendran <[email protected]>
commit b710d27bf72068b15b2f0305d825988183e2ff28 upstream.
Early secure guest boot hits the below crash while booting with vcpus numbers aligned with page boundary for PAGE size of 64k and LPPACA size of 1k i.e 64, 128 etc.
Partition configured for 64 cpus.
CPU maps initialized for 1 thread per core
------------[ cut here ]------------ kernel BUG at arch/powerpc/kernel/paca.c:89! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
This is due to the BUG_ON() for shared_lppaca_total_size equal to shared_lppaca_size. Instead the code should only BUG_ON() if we have exceeded the total_size, which indicates we've overflowed the array.
--- arch/powerpc/kernel/paca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/paca.c +1 -1
@@ -86,7 +86,7 @@ static void *__init alloc_shared_lppaca(* This is very early in boot, so no harm done if the kernel crashes at * this point. */ -BUG_ON (shared_lppaca_size >= shared_lppaca_total_size); +BUG_ON (shared_lppaca_size > shared_lppaca_total_size);return ptr; }
Greg Kroah-Hartman
maintainerPATCH 189/215 intel_th: pci: Add Jasper Lake CPU support
In reply to Greg Kroah-HartmanFrom: Alexander Shishkin <[email protected]>
commit 203c1f615052921901b7a8fbe2005d8ea6add076 upstream.
This adds support for the Trace Hub in Jasper Lake CPU.
--- drivers/hwtracing/intel_th/pci.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/hwtracing/intel_th/pci.c +5 -0
@@ -235,6 +235,11 @@ static const struct pci_device_id intel_ .driver_data = (kernel_ulong_t)&intel_th_2x, }, { +/* Jasper Lake CPU */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4e29), + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + {/* Elkhart Lake CPU */ PCI_DEVICE (PCI_VENDOR_ID_INTEL ,0x4529 ), .driver_data = (kernel_ulong_t)&intel_th_2x,
Greg Kroah-Hartman
maintainerPATCH 190/215 intel_th: pci: Add Tiger Lake PCH-H support
In reply to Greg Kroah-HartmanFrom: Alexander Shishkin <[email protected]>
commit 6227585dc7b6a5405fc08dc322f98cb95e2f0eb4 upstream.
This adds support for the Trace Hub in Tiger Lake PCH-H.
--- drivers/hwtracing/intel_th/pci.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/hwtracing/intel_th/pci.c +5 -0
@@ -230,6 +230,11 @@ static const struct pci_device_id intel_ .driver_data = (kernel_ulong_t)&intel_th_2x, }, { +/* Tiger Lake PCH-H */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x43a6), + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + {/* Jasper Lake PCH */ PCI_DEVICE (PCI_VENDOR_ID_INTEL ,0x4da6 ), .driver_data = (kernel_ulong_t)&intel_th_2x,
Greg Kroah-Hartman
maintainerPATCH 191/215 intel_th: pci: Add Emmitsburg PCH support
In reply to Greg Kroah-HartmanFrom: Alexander Shishkin <[email protected]>
commit fd73d74a32bfaaf259441322cc5a1c83caaa94f2 upstream.
This adds support for the Trace Hub in Emmitsburg PCH.
--- drivers/hwtracing/intel_th/pci.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/hwtracing/intel_th/pci.c +5 -0
@@ -254,6 +254,11 @@ static const struct pci_device_id intel_ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4b26), .driver_data = (kernel_ulong_t)&intel_th_2x, }, + { +/* Emmitsburg PCH */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x1bcc), + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, { 0 }, };
Greg Kroah-Hartman
maintainerPATCH 192/215 intel_th: Fix a NULL dereference when hub driver is not loaded
In reply to Greg Kroah-HartmanFrom: Alexander Shishkin <[email protected]>
commit e78e1fdb282726beaf88aa75943682217e6ded0e upstream.
Connecting master to an output port when GTH driver module is not loaded triggers a NULL dereference:
Quoted 5 lines
RIP: 0010:intel_th_set_output+0x35/0x70 [intel_th] Call Trace: ? sth_stm_link+0x12/0x20 [intel_th_sth] stm_source_link_store+0x164/0x270 [stm_core] dev_attr_store+0x17/0x30
Quoted 8 lines
sysfs_kf_write+0x3e/0x50 kernfs_fop_write+0xda/0x1b0 __vfs_write+0x1b/0x40 vfs_write+0xb9/0x1a0 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x57/0x1d0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Make sure the module in question is loaded and return an error if not.
--- drivers/hwtracing/intel_th/core.c | 21 ++++++++++++++++++--- drivers/hwtracing/intel_th/sth.c | 4 +--- 2 files changed, 19 insertions(+), 6 deletions(-)
drivers/hwtracing/intel_th/core.c +18 -3
@@ -1021,15 +1021,30 @@ int intel_th_set_output(struct intel_th_ {struct intel_th_device *hub =to_intel_th_hub (thdev);struct intel_th_driver *hubdrv =to_intel_th_driver (hub->dev.driver); +int ret;/* In host mode, this is up to the external debugger, do nothing. */ if (hub->host_mode)return 0 ; -if (!hubdrv->set_output) -return -ENOTSUPP ; +/* +* hub is instantiated together with the source device that +* calls here, so guaranteed to be present. +*/ + hubdrv =to_intel_th_driver (hub->dev.driver); +if (!hubdrv || !try_module_get (hubdrv->driver.owner)) +return -EINVAL ; -return hubdrv->set_output (hub, master); +if (!hubdrv->set_output) { + ret = -ENOTSUPP ; + goto out; + } + + ret = hubdrv->set_output (hub, master); + +out: +module_put (hubdrv->driver.owner); +return ret; }EXPORT_SYMBOL_GPL (intel_th_set_output);
drivers/hwtracing/intel_th/sth.c +1 -3
@@ -161,9 +161,7 @@ static int sth_stm_link(struct stm_data { struct sth_device *sth = container_of(stm_data, struct sth_device, stm); -intel_th_set_output (to_intel_th_device (sth->dev), master); - -return 0 ; +return intel_th_set_output (to_intel_th_device (sth->dev), master); }static int intel_th_sw_init (struct sth_device *sth)
Greg Kroah-Hartman
maintainerPATCH 193/215 dmaengine: fsl-edma: Fix NULL pointer exception in fsl_edma_tx_handler
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
commit f5e5677c420346b4e9788051c2e4d750996c428c upstream.
NULL pointer exception happens occasionally on serial output initiated by login timeout. This was reproduced only if kernel was built with significant debugging options and EDMA driver is used with serial console.
col-vf50 login: root
Password:
Login timed out after 60 seconds.
Unable to handle kernel NULL pointer dereference at virtual address 00000044
Internal error: Oops: 5 [#1] ARM
CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-20200610-dirty #4
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
(fsl_edma_tx_handler) from [<8016eb10>] (__handle_irq_event_percpu+0x64/0x304)
(__handle_irq_event_percpu) from [<8016eddc>] (handle_irq_event_percpu+0x2c/0x7c)
(handle_irq_event_percpu) from [<8016ee64>] (handle_irq_event+0x38/0x5c)
(handle_irq_event) from [<801729e4>] (handle_fasteoi_irq+0xa4/0x160)
(handle_fasteoi_irq) from [<8016ddcc>] (generic_handle_irq+0x34/0x44)
(generic_handle_irq) from [<8016e40c>] (__handle_domain_irq+0x54/0xa8)
(__handle_domain_irq) from [<80508bc8>] (gic_handle_irq+0x4c/0x80)
(gic_handle_irq) from [<80100af0>] (__irq_svc+0x70/0x98)
Exception stack(0x8459fe80 to 0x8459fec8)
fe80: 72286b00 e3359f64 00000001 0000412d a0070013 85c98840 85c98840 a0070013
fea0: 8054e0d4 00000000 00000002 00000000 00000002 8459fed0 8081fbe8 8081fbec
fec0: 60070013 ffffffff
(__irq_svc) from [<8081fbec>] (_raw_spin_unlock_irqrestore+0x30/0x58)
(_raw_spin_unlock_irqrestore) from [<8056cb48>] (uart_flush_buffer+0x88/0xf8)
(uart_flush_buffer) from [<80554e60>] (tty_ldisc_hangup+0x38/0x1ac)
(tty_ldisc_hangup) from [<8054c7f4>] (__tty_hangup+0x158/0x2bc)
(__tty_hangup) from [<80557b90>] (disassociate_ctty.part.1+0x30/0x23c)
(disassociate_ctty.part.1) from [<8011fc18>] (do_exit+0x580/0xba0)
(do_exit) from [<801214f8>] (do_group_exit+0x3c/0xb4)
(do_group_exit) from [<80121580>] (__wake_up_parent+0x0/0x14)Issue looks like race condition between interrupt handler fsl_edma_tx_handler() (called as result of fsl_edma_xfer_desc()) and terminating the transfer with fsl_edma_terminate_all().
The fsl_edma_tx_handler() handles interrupt for a transfer with already freed edesc and idle==true.
--- drivers/dma/fsl-edma.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/dma/fsl-edma.c +7 -0
@@ -45,6 +45,13 @@ static irqreturn_t fsl_edma_tx_handler(i fsl_chan = &fsl_edma->chans[ch];spin_lock (&fsl_chan->vchan.lock); + +if (!fsl_chan->edesc) { +/* terminate_all called before */ +spin_unlock (&fsl_chan->vchan.lock); +continue ; + } +if (!fsl_chan->edesc->iscyclic) {list_del (&fsl_chan->edesc->vdesc.node);vchan_cookie_complete (&fsl_chan->edesc->vdesc);
Greg Kroah-Hartman
maintainerPATCH 194/215 dmaengine: mcf-edma: Fix NULL pointer exception in mcf_edma_tx_handler
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
commit 8995aa3d164ddd9200e6abcf25c449cf5298c858 upstream.
On Toradex Colibri VF50 (Vybrid VF5xx) with fsl-edma driver NULL pointer exception happens occasionally on serial output initiated by login timeout.
This was reproduced only if kernel was built with significant debugging options and EDMA driver is used with serial console.
Issue looks like a race condition between interrupt handler fsl_edma_tx_handler() (called as a result of fsl_edma_xfer_desc()) and terminating the transfer with fsl_edma_terminate_all().
The fsl_edma_tx_handler() handles interrupt for a transfer with already freed edesc and idle==true.
The mcf-edma driver shares design and lot of code with fsl-edma. It looks like being affected by same problem. Fix this pattern the same way as fix for fsl-edma driver.
--- drivers/dma/mcf-edma.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/dma/mcf-edma.c +7 -0
@@ -35,6 +35,13 @@ static irqreturn_t mcf_edma_tx_handler(i mcf_chan = &mcf_edma->chans[ch];spin_lock (&mcf_chan->vchan.lock); + +if (!mcf_chan->edesc) { +/* terminate_all called before */ +spin_unlock (&mcf_chan->vchan.lock); +continue ; + } +if (!mcf_chan->edesc->iscyclic) {list_del (&mcf_chan->edesc->vdesc.node);vchan_cookie_complete (&mcf_chan->edesc->vdesc);
Greg Kroah-Hartman
maintainerPATCH 195/215 dmaengine: fsl-edma-common: correct DSIZE_32BYTE
In reply to Greg Kroah-HartmanFrom: Robin Gong <[email protected]>
commit e142087b15960a4e1e5932942e5abae1f49d2318 upstream.
Correct EDMA_TCD_ATTR_DSIZE_32BYTE define since it's broken by the below:
'0x0005 --> BIT(3) | BIT(0))'
--- drivers/dma/fsl-edma-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma/fsl-edma-common.h +1 -1
@@ -33,7 +33,7 @@#define EDMA_TCD_ATTR_DSIZE_16BIT BIT(0)#define EDMA_TCD_ATTR_DSIZE_32BIT BIT(1)#define EDMA_TCD_ATTR_DSIZE_64BIT (BIT(0) | BIT(1)) -#define EDMA_TCD_ATTR_DSIZE_32BYTE (BIT(3) | BIT(0)) +#define EDMA_TCD_ATTR_DSIZE_32BYTE (BIT(2) | BIT(0))#define EDMA_TCD_ATTR_SSIZE_8BIT 0#define EDMA_TCD_ATTR_SSIZE_16BIT (EDMA_TCD_ATTR_DSIZE_16BIT << 8)#define EDMA_TCD_ATTR_SSIZE_32BIT (EDMA_TCD_ATTR_DSIZE_32BIT << 8)
Greg Kroah-Hartman
maintainerPATCH 196/215 misc: atmel-ssc: lock with mutex instead of spinlock
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit b037d60a3b1d1227609fd858fa34321f41829911 upstream.
Uninterruptible context is not needed in the driver and causes lockdep warning because of mutex taken in of_alias_get_id(). Convert the lock to mutex to avoid the issue.
--- drivers/misc/atmel-ssc.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/misc/atmel-ssc.c +12 -12
@@ -10,7 +10,7 @@#include <linux/clk.h> #include <linux/err.h> #include <linux/io.h> -#include <linux/spinlock.h> +#include <linux/mutex.h> #include <linux/atmel-ssc.h> #include <linux/slab.h> #include <linux/module.h>
@@ -20,7 +20,7 @@#include "../../sound/soc/atmel/atmel_ssc_dai.h" /* Serialize access to ssc_list and user count */ -static DEFINE_SPINLOCK (user_lock); +static DEFINE_MUTEX (user_lock);static LIST_HEAD (ssc_list);struct ssc_device *ssc_request (unsigned int ssc_num)
@@ -28,7 +28,7 @@ struct ssc_device *ssc_request(unsignedint ssc_valid =0 ;struct ssc_device *ssc; -spin_lock (&user_lock); +mutex_lock (&user_lock);list_for_each_entry (ssc, &ssc_list, list) {if (ssc->pdev->dev.of_node) { if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc")
@@ -44,18 +44,18 @@ struct ssc_device *ssc_request(unsigned }if (!ssc_valid) { -spin_unlock (&user_lock); +mutex_unlock (&user_lock);pr_err ("ssc: ssc%d platform device is missing\n" , ssc_num);return ERR_PTR (-ENODEV ); }if (ssc->user) { -spin_unlock (&user_lock); +mutex_unlock (&user_lock);dev_dbg (&ssc->pdev->dev,"module busy\n" );return ERR_PTR (-EBUSY ); } ssc->user++; -spin_unlock (&user_lock); +mutex_unlock (&user_lock);clk_prepare (ssc->clk);
@@ -67,14 +67,14 @@ void ssc_free(struct ssc_device *ssc) {bool disable_clk = true; -spin_lock (&user_lock); +mutex_lock (&user_lock);if (ssc->user) ssc->user--;else { disable_clk = false;dev_dbg (&ssc->pdev->dev,"device already free\n" ); } -spin_unlock (&user_lock); +mutex_unlock (&user_lock);if (disable_clk)clk_unprepare (ssc->clk);
@@ -237,9 +237,9 @@ static int ssc_probe(struct platform_devreturn -ENXIO ; } -spin_lock (&user_lock); +mutex_lock (&user_lock);list_add_tail (&ssc->list, &ssc_list); -spin_unlock (&user_lock); +mutex_unlock (&user_lock);platform_set_drvdata (pdev, ssc);
@@ -258,9 +258,9 @@ static int ssc_remove(struct platform_dessc_sound_dai_remove (ssc); -spin_lock (&user_lock); +mutex_lock (&user_lock);list_del (&ssc->list); -spin_unlock (&user_lock); +mutex_unlock (&user_lock);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 197/215 thermal: int3403_thermal: Downgrade error message
In reply to Greg Kroah-HartmanFrom: Alex Hung <[email protected]>
commit f3d7fb38976b1b0a8462ba1c7cbd404ddfaad086 upstream.
Downgrade "Unsupported event" message from dev_err to dev_dbg to avoid flooding with this message on some platforms.
--- drivers/thermal/intel/int340x_thermal/int3403_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/thermal/intel/int340x_thermal/int3403_thermal.c +1 -1
@@ -74,7 +74,7 @@ static void int3403_notify(acpi_handle h THERMAL_TRIP_CHANGED);break ;default : -dev_err (&priv->pdev->dev,"Unsupported event [0x%x]\n" , event); +dev_dbg (&priv->pdev->dev,"Unsupported event [0x%x]\n" , event);break ; } }
Greg Kroah-Hartman
maintainerPATCH 198/215 thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
In reply to Greg Kroah-HartmanFrom: Finley Xiao <[email protected]>
commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream.
The function cpu_power_to_freq is used to find a frequency and set the cooling device to consume at most the power to be converted. For example, if the power to be converted is 80mW, and the em table is as follow.
struct em_cap_state table[] = {
/* KHz mW */
{ 1008000, 36, 0 },
{ 1200000, 49, 0 },
{ 1296000, 59, 0 },
{ 1416000, 72, 0 },
{ 1512000, 86, 0 },
};The target frequency should be 1416000KHz, not 1512000KHz.
--- drivers/thermal/cpu_cooling.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/thermal/cpu_cooling.c +3 -3
@@ -210,11 +210,11 @@ static u32 cpu_power_to_freq(struct cpufint i;struct freq_table *freq_table = cpufreq_cdev->freq_table; -for (i =1 ; i <= cpufreq_cdev->max_level; i++) -if (power > freq_table[i].power) +for (i =0 ; i < cpufreq_cdev->max_level; i++) +if (power >= freq_table[i].power)break ; -return freq_table[i -1 ].frequency; +return freq_table[i].frequency; }/**
Greg Kroah-Hartman
maintainerPATCH 199/215 arm64: ptrace: Override SPSR.SS when single-stepping is enabled
In reply to Greg Kroah-HartmanFrom: Will Deacon <[email protected]>
commit 3a5a4366cecc25daa300b9a9174f7fdd352b9068 upstream.
Luis reports that, when reverse debugging with GDB, single-step does not function as expected on arm64:
| I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP | request by GDB won't execute the underlying instruction. As a consequence, | the PC doesn't move, but we return a SIGTRAP just like we would for a | regular successful PTRACE_SINGLESTEP request.
The underlying problem is that when the CPU register state is restored as part of a reverse step, the SPSR.SS bit is cleared and so the hardware single-step state can transition to the "active-pending" state, causing an unexpected step exception to be taken immediately if a step operation is attempted.
In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate accessible by the GPR regset, but it's a bit late for that now. Instead, simply prevent userspace from configuring the bit to a value which is inconsistent with the TIF_SINGLESTEP state for the task being traced.
--- arch/arm64/include/asm/debug-monitors.h | 2 ++ arch/arm64/kernel/debug-monitors.c | 20 ++++++++++++++++---- arch/arm64/kernel/ptrace.c | 4 ++-- 3 files changed, 20 insertions(+), 6 deletions(-)
arch/arm64/include/asm/debug-monitors.h +2 -0
@@ -109,6 +109,8 @@ void disable_debug_monitors(enum dbg_actvoid user_rewind_single_step (struct task_struct *task);void user_fastforward_single_step (struct task_struct *task); +void user_regs_reset_single_step (struct user_pt_regs *regs, +struct task_struct *task);void kernel_enable_single_step (struct pt_regs *regs);void kernel_disable_single_step (void );
arch/arm64/kernel/debug-monitors.c +16 -4
@@ -141,17 +141,20 @@ postcore_initcall(debug_monitors_init);/* * Single step API and exception handling. */ -static void set_regs_spsr_ss (struct pt_regs *regs) +static void set_user_regs_spsr_ss (struct user_pt_regs *regs) { regs->pstate |=DBG_SPSR_SS ; } -NOKPROBE_SYMBOL (set_regs_spsr_ss); +NOKPROBE_SYMBOL (set_user_regs_spsr_ss); -static void clear_regs_spsr_ss (struct pt_regs *regs) +static void clear_user_regs_spsr_ss (struct user_pt_regs *regs) { regs->pstate &= ~DBG_SPSR_SS ; } -NOKPROBE_SYMBOL (clear_regs_spsr_ss); +NOKPROBE_SYMBOL (clear_user_regs_spsr_ss); + +#define set_regs_spsr_ss (r) set_user_regs_spsr_ss(&(r)->user_regs) +#define clear_regs_spsr_ss (r) clear_user_regs_spsr_ss(&(r)->user_regs)static DEFINE_SPINLOCK (debug_hook_lock);static LIST_HEAD (user_step_hook);
@@ -404,6 +407,15 @@ void user_fastforward_single_step(structclear_regs_spsr_ss (task_pt_regs (task)); } +void user_regs_reset_single_step (struct user_pt_regs *regs, +struct task_struct *task) +{ +if (test_tsk_thread_flag (task,TIF_SINGLESTEP )) +set_user_regs_spsr_ss (regs); +else +clear_user_regs_spsr_ss (regs); +} +/* Kernel API */ void kernel_enable_single_step (struct pt_regs *regs) {
arch/arm64/kernel/ptrace.c +2 -2
@@ -1935,8 +1935,8 @@ static int valid_native_regs(struct user*/ int valid_user_regs (struct user_pt_regs *regs,struct task_struct *task) { -if (!test_tsk_thread_flag (task,TIF_SINGLESTEP )) - regs->pstate &= ~DBG_SPSR_SS ; +/* https://lore.kernel.org/lkml/20191118131525.GA4180@willie-the-truck */ +user_regs_reset_single_step (regs, task);if (is_compat_thread (task_thread_info (task)))return valid_compat_regs (regs);
Greg Kroah-Hartman
maintainerPATCH 200/215 arm64: ptrace: Consistently use pseudo-singlestep exceptions
In reply to Greg Kroah-HartmanFrom: Will Deacon <[email protected]>
commit ac2081cdc4d99c57f219c1a6171526e0fa0a6fff upstream.
Although the arm64 single-step state machine can be fast-forwarded in cases where we wish to generate a SIGTRAP without actually executing an instruction, this has two major limitations outside of simply skipping an instruction due to emulation.
1. Stepping out of a ptrace signal stop into a signal handler where SIGTRAP is blocked. Fast-forwarding the stepping state machine in this case will result in a forced SIGTRAP, with the handler reset to SIG_DFL.
2. The hardware implicitly fast-forwards the state machine when executing an SVC instruction for issuing a system call. This can interact badly with subsequent ptrace stops signalled during the execution of the system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt the stepping state by updating the PSTATE for the tracee.
Resolve both of these issues by injecting a pseudo-singlestep exception on entry to a signal handler and also on return to userspace following a system call.
--- arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/kernel/ptrace.c | 27 ++++++++++++++++++++------- arch/arm64/kernel/signal.c | 11 ++--------- arch/arm64/kernel/syscall.c | 2 +- 4 files changed, 24 insertions(+), 17 deletions(-)
arch/arm64/include/asm/thread_info.h +1 -0
@@ -91,6 +91,7 @@ void arch_release_task_struct(struct tas#define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)#define _TIF_UPROBE (1 << TIF_UPROBE)#define _TIF_FSCHECK (1 << TIF_FSCHECK) +#define _TIF_SINGLESTEP (1 << TIF_SINGLESTEP)#define _TIF_32BIT (1 << TIF_32BIT)#define _TIF_SVE (1 << TIF_SVE)
arch/arm64/kernel/ptrace.c +20 -7
@@ -1819,12 +1819,23 @@ static void tracehook_report_syscall(str saved_reg = regs->regs[regno]; regs->regs[regno] = dir; -if (dir ==PTRACE_SYSCALL_EXIT ) +if (dir ==PTRACE_SYSCALL_ENTER ) { +if (tracehook_report_syscall_entry (regs)) +forget_syscall (regs); + regs->regs[regno] = saved_reg; + }else if (!test_thread_flag (TIF_SINGLESTEP )) {tracehook_report_syscall_exit (regs,0 ); -else if (tracehook_report_syscall_entry (regs)) -forget_syscall (regs); - - regs->regs[regno] = saved_reg; + regs->regs[regno] = saved_reg; + }else { + regs->regs[regno] = saved_reg; + +/* +* Signal a pseudo-step exception since we are stepping but +* tracer modifications to the registers may have rewound the +* state machine. +*/ +tracehook_report_syscall_exit (regs,1 ); + } }int syscall_trace_enter (struct pt_regs *regs)
@@ -1852,12 +1863,14 @@ int syscall_trace_enter(struct pt_regs *void syscall_trace_exit (struct pt_regs *regs) { +unsigned long flags =READ_ONCE (current_thread_info ()->flags); +audit_syscall_exit (regs); -if (test_thread_flag (TIF_SYSCALL_TRACEPOINT )) +if (flags & _TIF_SYSCALL_TRACEPOINT)trace_sys_exit (regs,regs_return_value (regs)); -if (test_thread_flag (TIF_SYSCALL_TRACE )) +if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP))tracehook_report_syscall (regs,PTRACE_SYSCALL_EXIT );rseq_syscall (regs);
arch/arm64/kernel/signal.c +2 -9
@@ -782,7 +782,6 @@ static void setup_restart_syscall(struct*/ static void handle_signal (struct ksignal *ksig,struct pt_regs *regs) { -struct task_struct *tsk = current;sigset_t *oldset =sigmask_to_save ();int usig = ksig->sig;int ret;
@@ -806,14 +805,8 @@ static void handle_signal(struct ksignal*/ ret |= !valid_user_regs (®s->user_regs, current); -/* -* Fast forward the stepping logic so we step into the signal -* handler. -*/ -if (!ret) -user_fastforward_single_step (tsk); - -signal_setup_done (ret, ksig,0 ); +/* Step into the signal handler if we are stepping */ +signal_setup_done (ret, ksig,test_thread_flag (TIF_SINGLESTEP )); }/*
arch/arm64/kernel/syscall.c +1 -1
@@ -121,7 +121,7 @@ static void el0_svc_common(struct pt_regif (!has_syscall_work (flags) && !IS_ENABLED (CONFIG_DEBUG_RSEQ )) {local_daif_mask (); flags =current_thread_info ()->flags; -if (!has_syscall_work (flags)) { +if (!has_syscall_work (flags) && !(flags & _TIF_SINGLESTEP)) {/* * We're off to userspace, where interrupts are * always enabled after we restore the flags from
Greg Kroah-Hartman
maintainerPATCH 201/215 arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return
In reply to Greg Kroah-HartmanFrom: Will Deacon <[email protected]>
commit 15956689a0e60aa0c795174f3c310b60d8794235 upstream.
Although we zero the upper bits of x0 on entry to the kernel from an AArch32 task, we do not clear them on the exception return path and can therefore expose 64-bit sign extended syscall return values to userspace via interfaces such as the 'perf_regs' ABI, which deal exclusively with 64-bit registers.
Explicitly clear the upper 32 bits of x0 on return from a compat system call.
--- arch/arm64/include/asm/syscall.h | 12 +++++++++++- arch/arm64/kernel/syscall.c | 3 +++ 2 files changed, 14 insertions(+), 1 deletion(-)
arch/arm64/include/asm/syscall.h +11 -1
@@ -34,6 +34,10 @@ static inline long syscall_get_error(str struct pt_regs *regs) {unsigned long error = regs->regs[0 ]; + +if (is_compat_thread (task_thread_info (task))) + error =sign_extend64 (error,31 ); +return IS_ERR_VALUE (error) ? error :0 ; }
@@ -47,7 +51,13 @@ static inline void syscall_set_return_vastruct pt_regs *regs, int error, long val) { - regs->regs[0] = (long) error ? error : val; + if (error) + val = error; + +if (is_compat_thread (task_thread_info (task))) + val =lower_32_bits (val); + + regs->regs[0 ] = val; }#define SYSCALL_MAX_ARGS 6
arch/arm64/kernel/syscall.c +3 -0
@@ -50,6 +50,9 @@ static void invoke_syscall(struct pt_reg ret =do_ni_syscall (regs, scno); } +if (is_compat_task ()) + ret =lower_32_bits (ret); + regs->regs[0 ] = ret; }
Greg Kroah-Hartman
maintainerPATCH 202/215 sched: Fix unreliable rseq cpu_id for new tasks
In reply to Greg Kroah-HartmanFrom: Mathieu Desnoyers <[email protected]>
commit ce3614daabea8a2d01c1dd17ae41d1ec5e5ae7db upstream.
While integrating rseq into glibc and replacing glibc's sched_getcpu implementation with rseq, glibc's tests discovered an issue with incorrect __rseq_abi.cpu_id field value right after the first time a newly created process issues sched_setaffinity.
For the records, it triggers after building glibc and running tests, and then issuing:
for x in {1..2000} ; do posix/tst-affinity-static & done
and shows up as:
error: Unexpected CPU 2, expected 0
error: Unexpected CPU 2, expected 0
error: Unexpected CPU 2, expected 0
error: Unexpected CPU 2, expected 0
error: Unexpected CPU 138, expected 0
error: Unexpected CPU 138, expected 0
error: Unexpected CPU 138, expected 0
error: Unexpected CPU 138, expected 0
This is caused by the scheduler invoking __set_task_cpu() directly from sched_fork() and wake_up_new_task(), thus bypassing rseq_migrate() which is done by set_task_cpu().
Add the missing rseq_migrate() to both functions. The only other direct use of __set_task_cpu() is done by init_idle(), which does not involve a user-space task.
Based on my testing with the glibc test-case, just adding rseq_migrate() to wake_up_new_task() is sufficient to fix the observed issue. Also add it to sched_fork() to keep things consistent.
The reason why this never triggered so far with the rseq/basic_test selftest is unclear.
The current use of sched_getcpu(3) does not typically require it to be always accurate. However, use of the __rseq_abi.cpu_id field within rseq critical sections requires it to be accurate. If it is not accurate, it can cause corruption in the per-cpu data targeted by rseq critical sections in user-space.
--- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/sched/core.c +2 -0
@@ -2889,6 +2889,7 @@ int sched_fork(unsigned long clone_flags* Silence PROVE_RCU. */ raw_spin_lock_irqsave (&p->pi_lock, flags); +rseq_migrate (p);/* * We're setting the CPU for the first time, we don't migrate, * so use __set_task_cpu().
@@ -2953,6 +2954,7 @@ void wake_up_new_task(struct task_struct* as we're not fully set-up yet. */ p->recent_used_cpu =task_cpu (p); +rseq_migrate (p);__set_task_cpu (p,select_task_rq (p,task_cpu (p),SD_BALANCE_FORK ,0 ));#endif rq =__task_rq_lock (p, &rf);
Greg Kroah-Hartman
maintainerPATCH 203/215 sched/fair: handle case of task_h_load() returning 0
In reply to Greg Kroah-HartmanFrom: Vincent Guittot <[email protected]>
commit 01cfcde9c26d8555f0e6e9aea9d6049f87683998 upstream.
task_h_load() can return 0 in some situations like running stress-ng mmapfork, which forks thousands of threads, in a sched group on a 224 cores system. The load balance doesn't handle this correctly because env->imbalance never decreases and it will stop pulling tasks only after reaching loop_max, which can be equal to the number of running tasks of the cfs. Make sure that imbalance will be decreased by at least 1.
misfit task is the other feature that doesn't handle correctly such situation although it's probably more difficult to face the problem because of the smaller number of CPUs and running tasks on heterogenous system.
We can't simply ensure that task_h_load() returns at least one because it would imply to handle underflow in other places.
--- kernel/sched/fair.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
kernel/sched/fair.c +14 -2
@@ -3824,7 +3824,11 @@ static inline void update_misfit_status( return; } - rq->misfit_task_load =task_h_load (p); +/* +* Make sure that misfit_task_load will not be null even if +* task_h_load() returns 0. +*/ + rq->misfit_task_load = max_t(unsigned long, task_h_load(p), 1); }#else /* CONFIG_SMP */
@@ -7407,7 +7411,15 @@ static int detach_tasks(struct lb_env *eif (!can_migrate_task (p, env)) goto next; - load =task_h_load (p); +/* +* Depending of the number of CPUs and tasks and the +* cgroup hierarchy, task_h_load() can return a null +* value. Make sure that env->imbalance decreases +* otherwise detach_tasks() will stop only after +* detaching up to loop_max tasks. +*/ + load = max_t(unsigned long, task_h_load(p), 1); +if (sched_feat (LB_MIN ) && load <16 && !env->sd->nr_balance_failed) goto next;
Greg Kroah-Hartman
maintainerPATCH 204/215 genirq/affinity: Handle affinity setting on inactive interrupts correctly
In reply to Greg Kroah-HartmanFrom: Thomas Gleixner <[email protected]>
commit baedb87d1b53532f81b4bd0387f83b05d4f7eb9a upstream.
Setting interrupt affinity on inactive interrupts is inconsistent when hierarchical irq domains are enabled. The core code should just store the affinity and not call into the irq chip driver for inactive interrupts because the chip drivers may not be in a state to handle such requests.
X86 has a hacky workaround for that but all other irq chips have not which causes problems e.g. on GIC V3 ITS.
Instead of adding more ugly hacks all over the place, solve the problem in the core code. If the affinity is set on an inactive interrupt then:
- Store it in the irq descriptors affinity mask
- Update the effective affinity to reflect that so user space has a consistent view
- Don't call into the irq chip driver
This is the core equivalent of the X86 workaround and works correctly because the affinity setting is established in the irq chip when the interrupt is activated later on.
Note, that this is only effective when hierarchical irq domains are enabled by the architecture. Doing it unconditionally would break legacy irq chip implementations.
For hierarchial irq domains this works correctly as none of the drivers can have a dependency on affinity setting in inactive state by design.
Remove the X86 workaround as it is not longer required.
--- arch/x86/kernel/apic/vector.c | 22 +++++----------------- kernel/irq/manage.c | 37 +++++++++++++++++++++++++++++++++++-- 2 files changed, 40 insertions(+), 19 deletions(-)
arch/x86/kernel/apic/vector.c +5 -17
@@ -446,12 +446,10 @@ static int x86_vector_activate(struct irtrace_vector_activate (irqd->irq, apicd->is_managed, apicd->can_reserve, reserve); -/* Nothing to do for fixed assigned vectors */ -if (!apicd->can_reserve && !apicd->is_managed) -return 0 ; -raw_spin_lock_irqsave (&vector_lock, flags); -if (reserve ||irqd_is_managed_and_shutdown (irqd)) +if (!apicd->can_reserve && !apicd->is_managed) +assign_irq_vector_any_locked (irqd); +else if (reserve ||irqd_is_managed_and_shutdown (irqd))vector_assign_managed_shutdown (irqd);else if (apicd->is_managed) ret =activate_managed (irqd);
@@ -769,20 +767,10 @@ void lapic_offline(void)static int apic_set_affinity (struct irq_data *irqd,const struct cpumask *dest,bool force) { -struct apic_chip_data *apicd =apic_chip_data (irqd);int err; -/* -* Core code can call here for inactive interrupts. For inactive -* interrupts which use managed or reservation mode there is no -* point in going through the vector assignment right now as the -* activation will assign a vector which fits the destination -* cpumask. Let the core code store the destination mask and be -* done with it. -*/ -if (!irqd_is_activated (irqd) && - (apicd->is_managed || apicd->can_reserve)) -return IRQ_SET_MASK_OK ; +if (WARN_ON_ONCE (!irqd_is_activated (irqd))) +return -EIO ;raw_spin_lock (&vector_lock);cpumask_and (vector_searchmask, dest, cpu_online_mask);
kernel/irq/manage.c +35 -2
@@ -194,9 +194,9 @@ void irq_set_thread_affinity(struct irq_set_bit (IRQTF_AFFINITY , &action->thread_flags); } +#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK static void irq_validate_effective_affinity (struct irq_data *data) { -#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK const struct cpumask *m =irq_data_get_effective_affinity_mask (data);struct irq_chip *chip =irq_data_get_irq_chip (data);
@@ -204,9 +204,19 @@ static void irq_validate_effective_affinreturn ;pr_warn_once ("irq_chip %s did not update eff. affinity mask of irq %u\n" , chip->name, data->irq); -#endif } +static inline void irq_init_effective_affinity (struct irq_data *data, +const struct cpumask *mask) +{ +cpumask_copy (irq_data_get_effective_affinity_mask (data), mask); +} +#else +static inline void irq_validate_effective_affinity (struct irq_data *data) { } +static inline void irq_init_effective_affinity (struct irq_data *data, +const struct cpumask *mask) { } +#endif +int irq_do_set_affinity (struct irq_data *data,const struct cpumask *mask,bool force) {
@@ -265,6 +275,26 @@ static int irq_try_set_affinity(struct ireturn ret; } +static bool irq_set_affinity_deactivated (struct irq_data *data, +const struct cpumask *mask,bool force) +{ +struct irq_desc *desc =irq_data_to_desc (data); + +/* +* If the interrupt is not yet activated, just store the affinity +* mask and do not call the chip driver at all. On activation the +* driver has to make sure anyway that the interrupt is in a +* useable state so startup works. +*/ +if (!IS_ENABLED (CONFIG_IRQ_DOMAIN_HIERARCHY ) ||irqd_is_activated (data)) +return false; + +cpumask_copy (desc->irq_common_data.affinity, mask); +irq_init_effective_affinity (data, mask); +irqd_set (data,IRQD_AFFINITY_SET ); +return true; +} +int irq_set_affinity_locked (struct irq_data *data,const struct cpumask *mask,bool force) {
@@ -275,6 +305,9 @@ int irq_set_affinity_locked(struct irq_dif (!chip || !chip->irq_set_affinity)return -EINVAL ; +if (irq_set_affinity_deactivated (data, mask, force)) +return 0 ; +if (irq_can_move_pcntxt (data) && !irqd_is_setaffinity_pending (data)) { ret =irq_try_set_affinity (data, mask, force); }else {
Greg Kroah-Hartman
maintainerPATCH 205/215 drm/amdgpu/sdma5: fix wptr overwritten in ->get_wptr()
In reply to Greg Kroah-HartmanFrom: Xiaojie Yuan <[email protected]>
commit 05051496b2622e4d12e2036b35165969aa502f89 upstream.
"u64 *wptr" points to the the wptr value in write back buffer and "*wptr = (*wptr) >> 2;" results in the value being overwritten each time when ->get_wptr() is called.
umr uses /sys/kernel/debug/dri/0/amdgpu_ring_sdma0 to get rptr/wptr and decode ring content and it is affected by this issue.
fix and simplify the logic similar as sdma_v4_0_ring_get_wptr().
v2: fix for sdma5.2 as well
v3: drop sdma 5.2 changes for 5.8 and stable
--- drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-)
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c +8 -18
@@ -286,30 +286,20 @@ static uint64_t sdma_v5_0_ring_get_rptr(static uint64_t sdma_v5_0_ring_get_wptr (struct amdgpu_ring *ring) {struct amdgpu_device *adev = ring->adev; -u64 *wptr =NULL ; -uint64_t local_wptr =0 ; +u64 wptr;if (ring->use_doorbell) {/* XXX check if swapping is necessary on BE */ - wptr = ((u64 *)&adev->wb.wb[ring->wptr_offs]); -DRM_DEBUG ("wptr/doorbell before shift == 0x%016llx\n" , *wptr); - *wptr = (*wptr) >>2 ; -DRM_DEBUG ("wptr/doorbell after shift == 0x%016llx\n" , *wptr); + wptr =READ_ONCE (*((u64 *)&adev->wb.wb[ring->wptr_offs])); +DRM_DEBUG ("wptr/doorbell before shift == 0x%016llx\n" , wptr); }else { -u32 lowbit, highbit; - - wptr = &local_wptr; - lowbit =RREG32 (sdma_v5_0_get_reg_offset (adev, ring->me, mmSDMA0_GFX_RB_WPTR)) >>2 ; - highbit =RREG32 (sdma_v5_0_get_reg_offset (adev, ring->me, mmSDMA0_GFX_RB_WPTR_HI)) >>2 ; - -DRM_DEBUG ("wptr [%i]high== 0x%08x low==0x%08x\n" , - ring->me, highbit, lowbit); - *wptr = highbit; - *wptr = (*wptr) <<32 ; - *wptr |= lowbit; + wptr =RREG32 (sdma_v5_0_get_reg_offset (adev, ring->me, mmSDMA0_GFX_RB_WPTR_HI)); + wptr = wptr <<32 ; + wptr |=RREG32 (sdma_v5_0_get_reg_offset (adev, ring->me, mmSDMA0_GFX_RB_WPTR)); +DRM_DEBUG ("wptr before shift [%i] wptr == 0x%016llx\n" , ring->me, wptr); } -return *wptr; +return wptr >>2 ; }/**
Greg Kroah-Hartman
maintainerPATCH 206/215 drm/i915/gt: Ignore irq enabling on the virtual engines
In reply to Greg Kroah-HartmanFrom: Chris Wilson <[email protected]>
commit 858f1299fd6f7518ddef19ddd304c8398ac79fa5 upstream.
We do not use the virtual engines for interrupts (they have physical components), but we do use them to decouple the fence signaling during submission. Currently, when we submit a completed request, we try to enable the interrupt handler for the virtual engine, but we never disarm it. A quick fix is then to mark the irq as enabled, and it will then remain enabled -- and this prevents us from waking the device and never letting it sleep again.
--- drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/i915/gt/intel_lrc.c +1 -0
@@ -3751,6 +3751,7 @@ intel_execlists_create_virtual(struct i9intel_engine_init_active (&ve->base,ENGINE_VIRTUAL );intel_engine_init_execlists (&ve->base); + ve->base.breadcrumbs.irq_armed = true;/* fake HW, used for irq_work */ ve->base.cops = &virtual_context_ops; ve->base.request_alloc = execlists_request_alloc;
Greg Kroah-Hartman
maintainerPATCH 207/215 block: fix splitting segments on boundary masks
In reply to Greg Kroah-HartmanFrom: Ming Lei <[email protected]>
commit 429120f3df2dba2bf3a4a19f4212a53ecefc7102 upstream.
We ran into a problem with a mpt3sas based controller, where we would see random (and hard to reproduce) file corruption). The issue seemed specific to this controller, but wasn't specific to the file system. After a lot of debugging, we find out that it's caused by segments spanning a 4G memory boundary. This shouldn't happen, as the default setting for segment boundary masks is 4G.
Turns out there are two issues in get_max_segment_size():
1) The default segment boundary mask is bypassed
2) The segment start address isn't taken into account when checking segment boundary limit
Fix these two issues by removing the bypass of the segment boundary check even if the mask is set to the default value, and taking into account the actual start address of the request when checking if a segment needs splitting.
Dropped const on the page pointer, ppc page_to_phys() doesn't mark the page as const...
--- block/blk-merge.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
block/blk-merge.c +9 -9
@@ -157,16 +157,14 @@ static inline unsigned get_max_io_size(sreturn sectors & (lbs -1 ); } -static unsigned get_max_segment_size (const struct request_queue *q, -unsigned offset) +static inline unsigned get_max_segment_size (const struct request_queue *q, +struct page *start_page, +unsigned long offset) {unsigned long mask =queue_segment_boundary (q); -/* default segment boundary mask means no boundary limit */ -if (mask ==BLK_SEG_BOUNDARY_MASK ) -return queue_max_segment_size (q); - - return min_t(unsigned long, mask - (mask & offset) + 1, + offset = mask & (page_to_phys (start_page) + offset); + return min_t(unsigned long, mask - offset + 1,queue_max_segment_size (q)); }
@@ -201,7 +199,8 @@ static bool bvec_split_segs(const structunsigned seg_size =0 ;while (len && *nsegs < max_segs) { - seg_size =get_max_segment_size (q, bv->bv_offset + total_len); + seg_size =get_max_segment_size (q, bv->bv_page, + bv->bv_offset + total_len); seg_size =min (seg_size, len); (*nsegs)++;
@@ -404,7 +403,8 @@ static unsigned blk_bvec_map_sg(struct rwhile (nbytes >0 ) {unsigned offset = bvec->bv_offset + total; -unsigned len =min (get_max_segment_size (q, offset), nbytes); +unsigned len =min (get_max_segment_size (q, bvec->bv_page, + offset), nbytes);struct page *page = bvec->bv_page;/*
Greg Kroah-Hartman
maintainerPATCH 208/215 block: fix get_max_segment_size() overflow on 32bit arch
In reply to Greg Kroah-HartmanFrom: Ming Lei <[email protected]>
commit 4a2f704eb2d831a2d73d7f4cdd54f45c49c3c353 upstream.
Commit 429120f3df2d starts to take account of segment's start dma address when computing max segment size, and data type of 'unsigned long' is used to do that. However, the segment mask may be 0xffffffff, so the figured out segment size may be overflowed in case of zero physical address on 32bit arch.
Fix the issue by returning queue_max_segment_size() directly when that happens.
--- block/blk-merge.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
block/blk-merge.c +7 -2
@@ -164,8 +164,13 @@ static inline unsigned get_max_segment_sunsigned long mask =queue_segment_boundary (q); offset = mask & (page_to_phys (start_page) + offset); - return min_t(unsigned long, mask - offset + 1, -queue_max_segment_size (q)); + +/* +* overflow may be triggered in case of zero page physical address +* on 32bit arch, use queue's max segment size when that happens. +*/ +return min_not_zero (mask - offset +1 , + (unsigned long )queue_max_segment_size (q)); }/**
Greg Kroah-Hartman
maintainerPATCH 209/215 libceph: dont omit recovery_deletes in target_copy()
In reply to Greg Kroah-HartmanFrom: Ilya Dryomov <[email protected]>
commit 2f3fead62144002557f322c2a7c15e1255df0653 upstream.
Currently target_copy() is used only for sending linger pings, so this doesn't come up, but generally omitting recovery_deletes can result in unneeded resends (force_resend in calc_target()).
--- net/ceph/osd_client.c | 1 + 1 file changed, 1 insertion(+)
net/ceph/osd_client.c +1 -0
@@ -445,6 +445,7 @@ static void target_copy(struct ceph_osd_ dest->size = src->size; dest->min_size = src->min_size; dest->sort_bitwise = src->sort_bitwise; + dest->recovery_deletes = src->recovery_deletes; dest->flags = src->flags; dest->paused = src->paused;
Greg Kroah-Hartman
maintainerPATCH 210/215 rxrpc: Fix trace string
In reply to Greg Kroah-HartmanFrom: David Howells <[email protected]>
commit aadf9dcef9d4cd68c73a4ab934f93319c4becc47 upstream.
The trace symbol printer (__print_symbolic()) ignores symbols that map to an empty string and prints the hex value instead.
Fix the symbol for rxrpc_cong_no_change to " -" instead of "" to avoid this.
--- include/trace/events/rxrpc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/trace/events/rxrpc.h +1 -1
@@ -400,7 +400,7 @@ enum rxrpc_tx_point { EM(rxrpc_cong_begin_retransmission, " Retrans") \ EM(rxrpc_cong_cleared_nacks, " Cleared") \ EM(rxrpc_cong_new_low_nack, " NewLowN") \ - EM(rxrpc_cong_no_change, "") \ + EM(rxrpc_cong_no_change, " -") \ EM(rxrpc_cong_progress, " Progres") \ EM(rxrpc_cong_retransmit_again, " ReTxAgn") \EM (rxrpc_cong_rtt_window_end," RttWinE" ) \
Greg Kroah-Hartman
maintainerPATCH 211/215 spi: sprd: switch the sequence of setting WDG_LOAD_LOW and _HIGH
In reply to Greg Kroah-HartmanFrom: Lingling Xu <[email protected]>
commit 8bdd79dae1ff5397351b95e249abcae126572617 upstream.
The watchdog counter consists of WDG_LOAD_LOW and WDG_LOAD_HIGH, which would be loaded to watchdog counter once writing WDG_LOAD_LOW.
--- drivers/spi/spi-sprd-adi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-sprd-adi.c +1 -1
@@ -384,9 +384,9 @@ static int sprd_adi_restart_handler(strusprd_adi_write (sadi, sadi->slave_pbase +REG_WDG_LOCK ,WDG_UNLOCK_KEY );/* Load the watchdog timeout value, 50ms is always enough. */ +sprd_adi_write (sadi, sadi->slave_pbase +REG_WDG_LOAD_HIGH ,0 );sprd_adi_write (sadi, sadi->slave_pbase +REG_WDG_LOAD_LOW ,WDG_LOAD_VAL &WDG_LOAD_MASK ); -sprd_adi_write (sadi, sadi->slave_pbase +REG_WDG_LOAD_HIGH ,0 );/* Start the watchdog to reset system */ sprd_adi_read (sadi, sadi->slave_pbase +REG_WDG_CTRL , &val);
Greg Kroah-Hartman
maintainerPATCH 212/215 ionic: export features for vlans to use
In reply to Greg Kroah-HartmanFrom: Shannon Nelson <[email protected]>
commit ef7232da6bcd4294cbb2d424bc35885721570f01 upstream.
Set up vlan_features for use by any vlans above us.
--- drivers/net/ethernet/pensando/ionic/ionic_lif.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/pensando/ionic/ionic_lif.c +1 -0
@@ -1187,6 +1187,7 @@ static int ionic_init_nic_features(struc netdev->hw_features |= netdev->hw_enc_features; netdev->features |= netdev->hw_features; + netdev->vlan_features |= netdev->features & ~NETIF_F_VLAN_FEATURES ; netdev->priv_flags |=IFF_UNICAST_FLT ;
Greg Kroah-Hartman
maintainerPATCH 213/215 iommu/vt-d: Make Intel SVM code 64-bit only
In reply to Greg Kroah-HartmanFrom: Lu Baolu <[email protected]>
commit 9486727f5981a5ec5c0b699fb1777451bd6786e4 upstream.
Current Intel SVM is designed by setting the pgd_t of the processor page table to FLPTR field of the PASID entry. The first level translation only supports 4 and 5 level paging structures, hence it's infeasible for the IOMMU to share a processor's page table when it's running in 32-bit mode. Let's disable 32bit support for now and claim support only when all the missing pieces are ready in the future.
--- drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/Kconfig +1 -1
@@ -205,7 +205,7 @@ config INTEL_IOMMU_DEBUGFS config INTEL_IOMMU_SVM bool "Support for Shared Virtual Memory with Intel IOMMU" - depends on INTEL_IOMMU && X86 + depends on INTEL_IOMMU && X86_64 select PCI_PASID select MMU_NOTIFIER help
Greg Kroah-Hartman
maintainerPATCH 214/215 drm/i915/gvt: Fix two CFL MMIO handling caused by regression.
In reply to Greg Kroah-HartmanFrom: Colin Xu <[email protected]>
commit fccd0f7cf4d532674d727c7f204f038456675dee upstream.
D_CFL was incorrectly removed for:GAMT_CHKN_BIT_REGGEN9_CTX_PREEMPT_REG
V2: Update commit message.
V3: Rebase and split Fixes and mis-handled MMIO.
--- drivers/gpu/drm/i915/gvt/handlers.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/gvt/handlers.c +2 -2
@@ -3103,8 +3103,8 @@ static int init_skl_mmio_info(struct intMMIO_DFH (GEN9_WM_CHICKEN3 ,D_SKL_PLUS ,F_MODE_MASK |F_CMD_ACCESS ,NULL ,NULL ); -MMIO_D (GAMT_CHKN_BIT_REG ,D_KBL ); -MMIO_D (GEN9_CTX_PREEMPT_REG ,D_KBL |D_SKL ); +MMIO_D (GAMT_CHKN_BIT_REG ,D_KBL |D_CFL ); +MMIO_D (GEN9_CTX_PREEMPT_REG ,D_SKL_PLUS );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 215/215 gpio: pca953x: disable regmap locking for automatic address incrementing
In reply to Greg Kroah-HartmanFrom: Andy Shevchenko <[email protected]>
commit ec3decd21380081e3b5de4ba8d85d90a95f201a0 upstream.
It's a repetition of the commit aa58a21ae378
("gpio: pca953x: disable regmap locking")
which states the following:
This driver uses its own locking but regmap silently uses a mutex for all operations too. Add the option to disable locking to the regmap config struct.
--- drivers/gpio/gpio-pca953x.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpio/gpio-pca953x.c +1 -0
@@ -398,6 +398,7 @@ static const struct regmap_config pca953 .writeable_reg = pca953x_writeable_register, .volatile_reg = pca953x_volatile_register, + .disable_locking = true, .cache_type = REGCACHE_RBTREE, .max_register = 0x7f, };
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.53 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Jul 2020 15:27:31 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.53-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.53 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Jul 2020 15:27:31 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.53-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on arm and arm64 (Juno-r2)
perf test cases failed
perf:
* perf_record_test
* perf_report_test
* Track-with-sched_switch (ignore intermittent failure)
Bad case:
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf-lava-test.data ]
when it was pass it prints number of samples like below,
Good case:
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.004 MB perf-lava-test.data (46 samples) ]
steps to reproduce:
# perf record -e cycles -o perf-lava-test.data ls -a 2>&1 | tee perf-record.log
Link to full test:
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.52-216-g95f1079149bd/testrun/2969631/suite/perf/test/perf_record_test/log
test case:
https://github.com/Linaro/test-definitions/blob/master/automated/linux/perf/perf.sh
Summary
------------------------------------------------------------------------
kernel: 5.4.53-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 95f1079149bd5596df492ff3dd12dacdd264e0ea
git describe: v5.4.52-216-g95f1079149bd
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.52-216-g95f1079149bd
Regressions (compared to build v5.4.52)
------------------------------------------------------------------------
perf:
* perf_record_test
* perf_report_test
* Track-with-sched_switch (ignore intermittent failure)
No fixes (compared to build v5.4.52)
Ran 36089 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* perf
* v4l2-compliance
* kvm-unit-tests
* ltp-commands-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* network-basic-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.53 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Jul 2020 15:27:31 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.53-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
11 builds: 11 pass, 0 fail
26 boots: 26 pass, 0 fail
56 tests: 56 pass, 0 failLinux version: 5.4.53-rc1-g95f1079149bd
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Cheers,
Thierry
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.53 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 22 Jul 2020 15:27:31 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 157 fail: 0 Qemu test results: total: 430 pass: 430 fail: 0
Guenter