5.14.15-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 159/169 drm/kmb: Limit supported mode to 1080p
In reply to Greg Kroah-HartmanFrom: Anitha Chrisanthus <[email protected]>
[ Upstream commit a79f40cccd4644c32f6d5ae1ccf091a262e1dc57 ]
KMB only supports single resolution(1080p), this commit checks for 1920x1080x60 or 1920x1080x59 in crtc_mode_valid.
Also, modes with vfp < 4 are not supported in KMB display. This change prunes display modes with vfp < 4.
v2: added vfp check
--- drivers/gpu/drm/kmb/kmb_crtc.c | 34 ++++++++++++++++++++++++++++++++++ drivers/gpu/drm/kmb/kmb_drv.h | 9 ++++++++- 2 files changed, 42 insertions(+), 1 deletion(-)
drivers/gpu/drm/kmb/kmb_crtc.c +34 -0
@@ -186,11 +186,45 @@ static void kmb_crtc_atomic_flush(struct drm_crtc *crtc,spin_unlock_irq (&crtc->dev->event_lock); } +static enum drm_mode_status +kmb_crtc_mode_valid (struct drm_crtc *crtc, +const struct drm_display_mode *mode) +{ +int refresh; +struct drm_device *dev = crtc->dev; +int vfp = mode->vsync_start - mode->vdisplay; + +if (mode->vdisplay <KMB_CRTC_MAX_HEIGHT ) { +drm_dbg (dev,"height = %d less than %d" , + mode->vdisplay,KMB_CRTC_MAX_HEIGHT ); +return MODE_BAD_VVALUE ; + } +if (mode->hdisplay <KMB_CRTC_MAX_WIDTH ) { +drm_dbg (dev,"width = %d less than %d" , + mode->hdisplay,KMB_CRTC_MAX_WIDTH ); +return MODE_BAD_HVALUE ; + } + refresh =drm_mode_vrefresh (mode); +if (refresh <KMB_MIN_VREFRESH || refresh >KMB_MAX_VREFRESH ) { +drm_dbg (dev,"refresh = %d less than %d or greater than %d" , + refresh,KMB_MIN_VREFRESH ,KMB_MAX_VREFRESH ); +return MODE_BAD ; + } + +if (vfp <KMB_CRTC_MIN_VFP ) { +drm_dbg (dev,"vfp = %d less than %d" , vfp,KMB_CRTC_MIN_VFP ); +return MODE_BAD ; + } + +return MODE_OK ; +} +static const struct drm_crtc_helper_funcs kmb_crtc_helper_funcs = { .atomic_begin = kmb_crtc_atomic_begin, .atomic_enable = kmb_crtc_atomic_enable, .atomic_disable = kmb_crtc_atomic_disable, .atomic_flush = kmb_crtc_atomic_flush, + .mode_valid = kmb_crtc_mode_valid, };int kmb_setup_crtc (struct drm_device *drm)
drivers/gpu/drm/kmb/kmb_drv.h +8 -1
@@ -20,11 +20,18 @@#define DRIVER_MAJOR 1#define DRIVER_MINOR 1 +/* Platform definitions */ +#define KMB_CRTC_MIN_VFP 4 +#define KMB_CRTC_MAX_WIDTH 1920/* max width in pixels */ +#define KMB_CRTC_MAX_HEIGHT 1080/* max height in pixels */ +#define KMB_CRTC_MIN_WIDTH 1920 +#define KMB_CRTC_MIN_HEIGHT 1080#define KMB_FB_MAX_WIDTH 1920#define KMB_FB_MAX_HEIGHT 1080#define KMB_FB_MIN_WIDTH 1#define KMB_FB_MIN_HEIGHT 1 - +#define KMB_MIN_VREFRESH 59/*vertical refresh in Hz */ +#define KMB_MAX_VREFRESH 60/*vertical refresh in Hz */ #define KMB_LCD_DEFAULT_CLK 200000000#define KMB_SYS_CLK_MHZ 500
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 160/169 autofs: fix wait name hash calculation in autofs_wait()
In reply to Greg Kroah-HartmanFrom: Ian Kent <[email protected]>
commit 25f54d08f12feb593e62cc2193fedefaf7825301 upstream.
There's a mistake in commit 2be7828c9fefc ("get rid of autofs_getpath()") that affects kernels from v5.13.0, basically missed because of me not fully testing the change for Al.
The problem is that the hash calculation for the wait name qstr hasn't been updated to account for the change to use dentry_path_raw(). This prevents the correct matching an existing wait resulting in multiple notifications being sent to the daemon for the same mount which must not occur.
The problem wasn't discovered earlier because it only occurs when multiple processes trigger a request for the same mount concurrently so it only shows up in more aggressive testing.
--- fs/autofs/waitq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/autofs/waitq.c +1 -1
@@ -358,7 +358,7 @@ int autofs_wait(struct autofs_sb_info *s qstr.len =strlen (p); offset = p - name; } - qstr.hash =full_name_hash (dentry, name, qstr.len); + qstr.hash =full_name_hash (dentry, qstr.name, qstr.len);if (mutex_lock_interruptible (&sbi->wq_mutex)) {kfree (name);
Greg Kroah-Hartman
maintainerPATCH 161/169 scsi: core: Fix shost->cmd_per_lun calculation in scsi_add_host_with_dma()
In reply to Greg Kroah-HartmanFrom: Dexuan Cui <[email protected]>
commit 50b6cb3516365cb69753b006be2b61c966b70588 upstream.
After commit ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at can_queue"), a 416-CPU VM running on Hyper-V hangs during boot because the hv_storvsc driver sets scsi_driver.can_queue to an integer value that exceeds SHRT_MAX, and hence scsi_add_host_with_dma() sets shost->cmd_per_lun to a negative "short" value.
Use min_t(int, ...) to work around the issue.
--- drivers/scsi/hosts.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/scsi/hosts.c +2 -1
@@ -220,7 +220,8 @@ int scsi_add_host_with_dma(struct Scsi_H goto fail; } - shost->cmd_per_lun =min_t (short, shost->cmd_per_lun, +/* Use min_t(int, ...) in case shost->can_queue exceeds SHRT_MAX */ + shost->cmd_per_lun =min_t (int, shost->cmd_per_lun, shost->can_queue); error =scsi_init_sense_cache (shost);
Greg Kroah-Hartman
maintainerPATCH 162/169 s390/pci: cleanup resources only if necessary
In reply to Greg Kroah-HartmanFrom: Niklas Schnelle <[email protected]>
commit 02368b7cf6c7badefa13741aed7a8b91d9a11b19 upstream.
It's currently safe to call zpci_cleanup_bus_resources() even if the resources were never created but it makes no sense so check zdev->has_resources before we call zpci_cleanup_bus_resources() in zpci_release_device().
--- arch/s390/pci/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/s390/pci/pci.c +2 -1
@@ -829,7 +829,8 @@ void zpci_release_device(struct kref *krcase ZPCI_FN_STATE_STANDBY :if (zdev->has_hp_slot)zpci_exit_slot (zdev); -zpci_cleanup_bus_resources (zdev); +if (zdev->has_resources) +zpci_cleanup_bus_resources (zdev);zpci_bus_device_unregister (zdev);zpci_destroy_iommu (zdev); fallthrough;
Greg Kroah-Hartman
maintainerPATCH 163/169 s390/pci: fix zpci_zdev_put() on reserve
In reply to Greg Kroah-HartmanFrom: Niklas Schnelle <[email protected]>
commit a46044a92add6a400f4dada7b943b30221f7cc80 upstream.
Since commit 2a671f77ee49 ("s390/pci: fix use after free of zpci_dev") the reference count of a zpci_dev is incremented between pcibios_add_device() and pcibios_release_device() which was supposed to prevent the zpci_dev from being freed while the common PCI code has access to it. It was missed however that the handling of zPCI availability events assumed that once zpci_zdev_put() was called no later availability event would still see the device. With the previously mentioned commit however this assumption no longer holds and we must make sure that we only drop the initial long-lived reference the zPCI subsystem holds exactly once.
Do so by introducing a zpci_device_reserved() function that handles when a device is reserved. Here we make sure the zpci_dev will not be considered for further events by removing it from the zpci_list.
This also means that the device actually stays in the ZPCI_FN_STATE_RESERVED state between the time we know it has been reserved and the final reference going away. We thus need to consider it a real state instead of just a conceptual state after the removal. The final cleanup of PCI resources, removal from zbus, and destruction of the IOMMU stays in zpci_release_device() to make sure holders of the reference do see valid data until the release.
--- arch/s390/include/asm/pci.h | 2 + arch/s390/pci/pci.c | 45 ++++++++++++++++++++++++++++++++----- arch/s390/pci/pci_event.c | 4 +-- drivers/pci/hotplug/s390_pci_hpc.c | 9 ------- 4 files changed, 45 insertions(+), 15 deletions(-)
arch/s390/include/asm/pci.h +2 -0
@@ -207,6 +207,8 @@ int zpci_enable_device(struct zpci_dev *int zpci_disable_device (struct zpci_dev *);int zpci_scan_configured_device (struct zpci_dev *zdev,u32 fh);int zpci_deconfigure_device (struct zpci_dev *zdev); +void zpci_device_reserved (struct zpci_dev *zdev); +bool zpci_is_device_configured (struct zpci_dev *zdev);int zpci_register_ioat (struct zpci_dev *,u8 ,u64 ,u64 ,u64 );int zpci_unregister_ioat (struct zpci_dev *,u8 );
arch/s390/pci/pci.c +40 -5
75 lines not on this page · raw message
arch/s390/pci/pci_event.c +2 -2
@@ -137,7 +137,7 @@ static void __zpci_event_availability(st/* The 0x0304 event may immediately reserve the device */ if (!clp_get_state (zdev->fid, &state) && state ==ZPCI_FN_STATE_RESERVED ) { -zpci_zdev_put (zdev); +zpci_device_reserved (zdev); } }break ;
@@ -148,7 +148,7 @@ static void __zpci_event_availability(stcase 0x0308 :/* Standby -> Reserved */ if (!zdev)break ; -zpci_zdev_put (zdev); +zpci_device_reserved (zdev);break ;default :break ;
drivers/pci/hotplug/s390_pci_hpc.c +1 -8
@@ -62,14 +62,7 @@ static int get_power_status(struct hotpl struct zpci_dev *zdev = container_of(hotplug_slot, struct zpci_dev, hotplug_slot); -switch (zdev->state) { -case ZPCI_FN_STATE_STANDBY : - *value =0 ; -break ; -default : - *value =1 ; -break ; - } + *value =zpci_is_device_configured (zdev) ?1 :0 ;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 164/169 bpf, test, cgroup: Use sk_{alloc,free} for test cases
In reply to Greg Kroah-HartmanFrom: Daniel Borkmann <[email protected]>
commit 435b08ec0094ac1e128afe6cfd0d9311a8c617a7 upstream.
BPF test infra has some hacks in place which kzalloc() a socket and perform minimum init via sock_net_set() and sock_init_data(). As a result, the sk's skcd->cgroup is NULL since it didn't go through proper initialization as it would have been the case from sk_alloc(). Rather than re-adding a NULL test in sock_cgroup_ptr() just for this, use sk_{alloc,free}() pair for the test socket. The latter also allows to get rid of the bpf_sk_storage_free() special case.
--- net/bpf/test_run.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
net/bpf/test_run.c +9 -5
@@ -552,6 +552,12 @@ static void convert_skb_to___skb(struct __skb->gso_segs =skb_shinfo (skb)->gso_segs; } +static struct proto bpf_dummy_proto = { + .name ="bpf_dummy" , + .owner =THIS_MODULE , + .obj_size =sizeof (struct sock ), +}; +int bpf_prog_test_run_skb (struct bpf_prog *prog,const union bpf_attr *kattr,union bpf_attr __user *uattr) {
@@ -596,20 +602,19 @@ int bpf_prog_test_run_skb(struct bpf_probreak ; } - sk =kzalloc (sizeof (struct sock ),GFP_USER ); + sk =sk_alloc (net,AF_UNSPEC ,GFP_USER , &bpf_dummy_proto,1 );if (!sk) {kfree (data);kfree (ctx);return -ENOMEM ; } -sock_net_set (sk, net);sock_init_data (NULL , sk); skb =build_skb (data,0 );if (!skb) {kfree (data);kfree (ctx); -kfree (sk); +sk_free (sk);return -ENOMEM ; } skb->sk = sk;
@@ -682,8 +687,7 @@ out:if (dev && dev != net->loopback_dev)dev_put (dev);kfree_skb (skb); -bpf_sk_storage_free (sk); -kfree (sk); +sk_free (sk);kfree (ctx);return ret; }
Greg Kroah-Hartman
maintainerPATCH 165/169 usbnet: sanity check for maxpacket
In reply to Greg Kroah-HartmanFrom: Oliver Neukum <[email protected]>
commit 397430b50a363d8b7bdda00522123f82df6adc5e upstream.
maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up.
V2: fixed typo in log and stylistic issues
--- drivers/net/usb/usbnet.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/usb/usbnet.c +4 -0
@@ -1788,6 +1788,10 @@ usbnet_probe (struct usb_interface *udevif (!dev->rx_urb_size) dev->rx_urb_size = dev->hard_mtu; dev->maxpacket =usb_maxpacket (dev->udev, dev->out,1 ); +if (dev->maxpacket ==0 ) { +/* that is a broken device */ + goto out4; + }/* let userspace know we have a random address */ if (ether_addr_equal (net->dev_addr, node_id))
Re: [PATCH 5.14 165/169] usbnet: sanity check for maxpacket
Quoted 7 lines · Greg Kroah-Hartman
From: Oliver Neukum <[email protected]>
commit
397430b50a363d8b7bdda00522123f82df6adc5eupstream.maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up.
Quoted 8 lines
V2: fixed typo in log and stylistic issues
Signed-off-by Oliver Neukum <[email protected]>Reported-by [email protected]Reviewed-by Johan Hovold <[email protected]>Signed-off-by Jakub Kicinski <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Please drop this one from all stable queues until
https://lore.kernel.org/r/[email protected]
has landed.
Quoted 7 lines
--- drivers/net/usb/usbnet.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/usb/usbnet.c usbnet_probe (struct usb_interface *udev · line 1797
Quoted 10 lines
drivers/net/usb/usbnet.c +4
-0@@ -1788,6 +1788,10 @@ usbnet_probe (struct usb_interface *udevif (!dev->rx_urb_size) dev->rx_urb_size = dev->hard_mtu; dev->maxpacket =usb_maxpacket (dev->udev, dev->out,1 ); +if (dev->maxpacket ==0 ) { +/* that is a broken device */ + goto out4; + }/* let userspace know we have a random address */ if (ether_addr_equal (net->dev_addr, node_id))
Johan
Greg Kroah-Hartman
maintainerRe: [PATCH 5.14 165/169] usbnet: sanity check for maxpacket
Quoted 17 lines · Johan Hovold
Quoted 7 lines · Greg Kroah-Hartman
From: Oliver Neukum <[email protected]>
commit
397430b50a363d8b7bdda00522123f82df6adc5eupstream.maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up.
Quoted 8 lines
V2: fixed typo in log and stylistic issues
Signed-off-by Oliver Neukum <[email protected]>Reported-by [email protected]Reviewed-by Johan Hovold <[email protected]>Signed-off-by Jakub Kicinski <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Quoted 5 lines
Please drop this one from all stable queues until
https://lore.kernel.org/r/[email protected]has landed.
Will drop it now and wait for that one, thanks!
greg k-h
Greg Kroah-Hartman
maintainerPATCH 166/169 net: mdiobus: Fix memory leak in __mdiobus_register
In reply to Greg Kroah-HartmanFrom: Yanfei Xu <[email protected]>
commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.
Once device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it will cause memory leak.
BUG: memory leak
unreferenced object 0xffff888114032e00 (size 256):
comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff ................
08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff .........ve.....
backtrace:
[<ffffffff8265cfab>] kmalloc include/linux/slab.h:591 [inline]
[<ffffffff8265cfab>] kzalloc include/linux/slab.h:721 [inline]
[<ffffffff8265cfab>] device_private_init drivers/base/core.c:3203 [inline]
[<ffffffff8265cfab>] device_add+0x89b/0xdf0 drivers/base/core.c:3253
[<ffffffff828dd643>] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
[<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
[<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
[<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
[<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
[<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
[<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
[<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
[<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
[<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
[<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
[<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
[<ffffffff82660916>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[<ffffffff8265cd0b>] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
[<ffffffff82c343b9>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
[<ffffffff82c4473c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
BUG: memory leak
unreferenced object 0xffff888116f06900 (size 32):
comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
hex dump (first 32 bytes):
75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00 usb-001:003.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81484516>] kstrdup+0x36/0x70 mm/util.c:60
[<ffffffff814845a3>] kstrdup_const+0x53/0x80 mm/util.c:83
[<ffffffff82296ba2>] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
[<ffffffff82358d4b>] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
[<ffffffff826575f3>] dev_set_name+0x63/0x90 drivers/base/core.c:3147
[<ffffffff828dd63b>] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
[<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
[<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
[<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
[<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
[<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
[<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
[<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
[<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
[<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
[<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
[<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969--- drivers/net/phy/mdio_bus.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/phy/mdio_bus.c +1 -0
@@ -548,6 +548,7 @@ int __mdiobus_register(struct mii_bus *b err =device_register (&bus->dev);if (err) {pr_err ("mii_bus %s failed to register\n" , bus->id); +put_device (&bus->dev);return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 167/169 e1000e: Separate TGP board type from SPT
In reply to Greg Kroah-HartmanFrom: Sasha Neftin <[email protected]>
[ Upstream commit 280db5d420090a24e4e41f9ddcbf37920a598572 ]
We have the same LAN controller on different PCHs. Separate TGP board type from SPT which will allow for specific fixes to be applied for TGP platforms.
--- drivers/net/ethernet/intel/e1000e/e1000.h | 4 ++- drivers/net/ethernet/intel/e1000e/ich8lan.c | 20 ++++++++++++++ drivers/net/ethernet/intel/e1000e/netdev.c | 29 +++++++++++---------- 3 files changed, 38 insertions(+), 15 deletions(-)
drivers/net/ethernet/intel/e1000e/e1000.h +3 -1
@@ -113,7 +113,8 @@ enum e1000_boards { board_pch2lan, board_pch_lpt, board_pch_spt, - board_pch_cnp + board_pch_cnp, + board_pch_tgp }; struct e1000_ps_page {
@@ -499,6 +500,7 @@ extern const struct e1000_info e1000_pch2_info;extern const struct e1000_info e1000_pch_lpt_info;extern const struct e1000_info e1000_pch_spt_info;extern const struct e1000_info e1000_pch_cnp_info; +extern const struct e1000_info e1000_pch_tgp_info;extern const struct e1000_info e1000_es2_info;void e1000e_ptp_init (struct e1000_adapter *adapter);
drivers/net/ethernet/intel/e1000e/ich8lan.c +20 -0
@@ -5992,3 +5992,23 @@ const struct e1000_info e1000_pch_cnp_info = { .phy_ops = &ich8_phy_ops, .nvm_ops = &spt_nvm_ops, }; + +const struct e1000_info e1000_pch_tgp_info = { + .mac = e1000_pch_tgp, + .flags =FLAG_IS_ICH + |FLAG_HAS_WOL + |FLAG_HAS_HW_TIMESTAMP + |FLAG_HAS_CTRLEXT_ON_LOAD + |FLAG_HAS_AMT + |FLAG_HAS_FLASH + |FLAG_HAS_JUMBO_FRAMES + |FLAG_APME_IN_WUC , + .flags2 =FLAG2_HAS_PHY_STATS + |FLAG2_HAS_EEE , + .pba =26 , + .max_hw_frame_size =9022 , + .get_variants = e1000_get_variants_ich8lan, + .mac_ops = &ich8_mac_ops, + .phy_ops = &ich8_phy_ops, + .nvm_ops = &spt_nvm_ops, +};
drivers/net/ethernet/intel/e1000e/netdev.c +15 -14
@@ -51,6 +51,7 @@ static const struct e1000_info *e1000_info_tbl[] = { [board_pch_lpt] = &e1000_pch_lpt_info, [board_pch_spt] = &e1000_pch_spt_info, [board_pch_cnp] = &e1000_pch_cnp_info, + [board_pch_tgp] = &e1000_pch_tgp_info, };struct e1000_reg_info {
@@ -7844,20 +7845,20 @@ static const struct pci_device_id e1000_pci_tbl[] = { { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_CMP_I219_V11), board_pch_cnp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_CMP_I219_LM12), board_pch_spt }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_CMP_I219_V12), board_pch_spt }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_LM13), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_V13), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_LM14), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_V14), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_LM15), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_V15), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_LM16), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_V16), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_LM17), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_V17), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_LM18), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_V18), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_LM19), board_pch_cnp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_V19), board_pch_cnp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_LM13), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_V13), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_LM14), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_V14), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_LM15), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_TGP_I219_V15), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_LM16), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_V16), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_LM17), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_V17), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_LM18), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_V18), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_LM19), board_pch_tgp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_V19), board_pch_tgp }, { 0, 0, 0, 0, 0, 0, 0 } /* terminate list */ };
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 168/169 ARM: 9122/1: select HAVE_FUTEX_CMPXCHG
In reply to Greg Kroah-HartmanFrom: Nick Desaulniers <[email protected]>
commit 9d417cbe36eee7afdd85c2e871685f8dab7c2dba upstream.
tglx notes:
This function [futex_detect_cmpxchg] is only needed when an architecture has to runtime discover whether the CPU supports it or not. ARM has unconditional support for this, so the obvious thing to do is the below.
Fixes linkage failure from Clang randconfigs:
kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text' and boot failures for CONFIG_THUMB2_KERNEL.
Comments from Nick Desaulniers:
See-also: 03b8c7b623c8 ("futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test")
--- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+)
arch/arm/Kconfig +1 -0
@@ -93,6 +93,7 @@ config ARM select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG select HAVE_FUNCTION_TRACER if !XIP_KERNEL + select HAVE_FUTEX_CMPXCHG if FUTEX select HAVE_GCC_PLUGINS select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7) select HAVE_IRQ_TIME_ACCOUNTING
Greg Kroah-Hartman
maintainerPATCH 169/169 pinctrl: stm32: use valid pin identifier in stm32_pinctrl_resume()
In reply to Greg Kroah-HartmanFrom: Fabien Dessenne <[email protected]>
commit c370bb474016ab9edfdabd7c08a88dd13a71ddbd upstream.
When resuming from low power, the driver attempts to restore the configuration of some pins. This is done by a call to:
stm32_pinctrl_restore_gpio_regs(struct stm32_pinctrl *pctl, u32 pin)
where 'pin' must be a valid pin value (i.e. matching some 'groups->pin'). Fix the current implementation which uses some wrong 'pin' value.
--- drivers/pinctrl/stm32/pinctrl-stm32.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/pinctrl/stm32/pinctrl-stm32.c +2 -2
@@ -1644,8 +1644,8 @@ int __maybe_unused stm32_pinctrl_resume(struct stm32_pinctrl_group *g = pctl->groups;int i; -for (i = g->pin; i < g->pin + pctl->ngroups; i++) -stm32_pinctrl_restore_gpio_regs (pctl, i); +for (i =0 ; i < pctl->ngroups; i++, g++) +stm32_pinctrl_restore_gpio_regs (pctl, g->pin);return 0 ; }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +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.14.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +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.14.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
5.14.15-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +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.14.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.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.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +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.14.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.14.15-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.14.y
* git commit: 359943f37028eaedbff9d02dba3dab341682d227
* git describe: v5.14.14-170-g359943f37028
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.14.y/build/v5.14.14-170-g359943f37028
## No regressions (compared to v5.14.14)
## No fixes (compared to v5.14.14)
## Test result summary
total: 95431, pass: 80321, fail: 1255, skip: 13068, xfail: 787
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 289 total, 289 passed, 0 failed
* arm64: 39 total, 39 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 38 total, 38 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 37 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 36 total, 36 passed, 0 failed
* riscv: 24 total, 24 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 39 total, 39 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-te[
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* prep-inline
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +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.14.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.14:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 114 pass, 0 failLinux version: 5.14.15-rc1-g359943f37028
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +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.14.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Upgrading to Ubuntu 21.10 caused issues with the boot related to zstd compression which is the default initramfs.conf for 21.10
If others run into this:
Change the default to lz4. I ended up enabling CONFIG_DECOMPRESS_ZSTD=y for 5.4 since it has support for ZSTD
On another note CONFIG_ZSTD_DECOMPRESS and CONFIG_DECOMPRESS_ZSTD naming rather confusing.
thanks,
-- Shuah
Quoted 27 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.15-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.14.y and the diffstat can be found below.Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by Shuah Khan <[email protected]>Upgrading to Ubuntu 21.10 caused issues with the boot related to zstd compression which is the default initramfs.conf for 21.10
Quoted 8 lines
If others run into this:
Change the default to lz4. I ended up enabling
CONFIG_DECOMPRESS_ZSTD=yfor 5.4 since it has support for ZSTDOn another note
CONFIG_ZSTD_DECOMPRESSandCONFIG_DECOMPRESS_ZSTDnaming rather confusing.
Please ignore this comment about compression for 5.14
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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, 27 Oct 2021 19:08:09 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 480 pass: 480 fail: 0
Guenter
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.15 release. There are 169 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.
Hi Greg,
Looking good.
Run tested on:
- SolidRun Cubox-i Dual/Quad - NXP iMX6 (Cubox-i4Pro)
In addition: build tested on:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- Allwinner H6
- Intel x86_64
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
--
Rudi