5.4.228-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.4.228-rc1 review
This is the start of the stable review cycle for the 5.4.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +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.4.228-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.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.4.228-rc1
Yasushi SHOJI <[email protected]>
can: mcba_usb: Fix termination command argument
Heiko Schocher <[email protected]>
can: sja1000: fix size of OCR_MODE_MASK define
Ricardo Ribalda <[email protected]>
pinctrl: meditatek: Startup with the IRQs disabled
Mark Brown <[email protected]>
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
Jialiang Wang <[email protected]>
nfp: fix use-after-free in area_cache_get()
Ming Lei <[email protected]>
block: unhash blkdev part inode when the part is deleted
Baolin Wang <[email protected]>
mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page
Paul E. McKenney <[email protected]>
x86/smpboot: Move rcu_cpu_starting() earlier
Lorenzo Colitti <[email protected]>
net: bpf: Allow TC programs to call BPF_FUNC_skb_change_head
-------------
Diffstat:
Makefile | 4 +-- arch/x86/kernel/cpu/mtrr/mtrr.c | 2 -- arch/x86/kernel/smpboot.c | 1 + block/partition-generic.c | 7 +++++ drivers/net/can/usb/mcba_usb.c | 10 +++++--- .../ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 ++- drivers/pinctrl/mediatek/mtk-eint.c | 9 ++++--- include/linux/can/platform/sja1000.h | 2 +- include/linux/hugetlb.h | 6 ++--- mm/gup.c | 13 +++++++++- mm/hugetlb.c | 30 +++++++++++----------- net/core/filter.c | 2 ++ sound/soc/soc-ops.c | 6 +++++ 13 files changed, 64 insertions(+), 31 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/9 net: bpf: Allow TC programs to call BPF_FUNC_skb_change_head
From: Lorenzo Colitti <[email protected]>
commit 6f3f65d80dac8f2bafce2213005821fccdce194c upstream.
This allows TC eBPF programs to modify and forward (redirect) packets from interfaces without ethernet headers (for example cellular) to interfaces with (for example ethernet/wifi).
The lack of this appears to simply be an oversight.
Tested:
in active use in Android R on 4.14+ devices for ipv6 cellular to wifi tethering offload.
--- net/core/filter.c | 2 ++ 1 file changed, 2 insertions(+)
net/core/filter.c +2 -0
@@ -6196,6 +6196,8 @@ tc_cls_act_func_proto(enum bpf_func_id freturn &bpf_skb_adjust_room_proto;case BPF_FUNC_skb_change_tail:return &bpf_skb_change_tail_proto; +case BPF_FUNC_skb_change_head: +return &bpf_skb_change_head_proto;case BPF_FUNC_skb_get_tunnel_key:return &bpf_skb_get_tunnel_key_proto;case BPF_FUNC_skb_set_tunnel_key:
Greg Kroah-Hartman
maintainerPATCH 2/9 x86/smpboot: Move rcu_cpu_starting() earlier
In reply to Greg Kroah-HartmanFrom: Paul E. McKenney <[email protected]>
commit 29368e09392123800e5e2bf0f3eda91f16972e52 upstream.
The call to rcu_cpu_starting() in mtrr_ap_init() is not early enough in the CPU-hotplug onlining process, which results in lockdep splats as follows:
=============================
WARNING: suspicious RCU usage
5.9.0+ #268 Not tainted
-----------------------------kernel/kprobes.c:300 RCU-list traversed in non-reader section!!
other info that might help us debug this:
RCU used illegally from offline CPU!rcu_scheduler_active = 1, debug_locks = 1
no locks held by swapper/1/0.
stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.9.0+ #268 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: dump_stack+0x77/0x97 __is_insn_slot_addr+0x15d/0x170 kernel_text_address+0xba/0xe0 ? get_stack_info+0x22/0xa0 __kernel_text_address+0x9/0x30 show_trace_log_lvl+0x17d/0x380 ? dump_stack+0x77/0x97 dump_stack+0x77/0x97 __lock_acquire+0xdf7/0x1bf0 lock_acquire+0x258/0x3d0 ? vprintk_emit+0x6d/0x2c0 _raw_spin_lock+0x27/0x40 ? vprintk_emit+0x6d/0x2c0 vprintk_emit+0x6d/0x2c0 printk+0x4d/0x69 start_secondary+0x1c/0x100 secondary_startup_64_no_verify+0xb8/0xbb
This is avoided by moving the call to rcu_cpu_starting up near the beginning of the start_secondary() function. Note that the raw_smp_processor_id() is required in order to avoid calling into lockdep before RCU has declared the CPU to be watched for readers.
--- arch/x86/kernel/cpu/mtrr/mtrr.c | 2 -- arch/x86/kernel/smpboot.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-)
arch/x86/kernel/cpu/mtrr/mtrr.c +0 -2
@@ -794,8 +794,6 @@ void mtrr_ap_init(void)if (!use_intel () || mtrr_aps_delayed_init)return ; -rcu_cpu_starting (smp_processor_id ()); -/* * Ideally we should hold mtrr_mutex here to avoid mtrr entries * changed, but this routine will be called in cpu boot time,
arch/x86/kernel/smpboot.c +1 -0
@@ -224,6 +224,7 @@ static void notrace start_secondary(void#endif load_current_idt ();cpu_init (); +rcu_cpu_starting (raw_smp_processor_id ()); x86_cpuinit.early_percpu_clock_init ();preempt_disable ();smp_callin ();
Greg Kroah-Hartman
maintainerPATCH 3/9 mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page
In reply to Greg Kroah-HartmanFrom: Baolin Wang <[email protected]>
commit fac35ba763ed07ba93154c95ffc0c4a55023707f upstream.
On some architectures (like ARM64), it can support CONT-PTE/PMD size hugetlb, which means it can support not only PMD/PUD size hugetlb (2M and 1G), but also CONT-PTE/PMD size(64K and 32M) if a 4K page size specified.
So when looking up a CONT-PTE size hugetlb page by follow_page(), it will use pte_offset_map_lock() to get the pte entry lock for the CONT-PTE size hugetlb in follow_page_pte(). However this pte entry lock is incorrect for the CONT-PTE size hugetlb, since we should use huge_pte_lock() to get the correct lock, which is mm->page_table_lock.
That means the pte entry of the CONT-PTE size hugetlb under current pte lock is unstable in follow_page_pte(), we can continue to migrate or poison the pte entry of the CONT-PTE size hugetlb, which can cause some potential race issues, even though they are under the 'pte lock'.
For example, suppose thread A is trying to look up a CONT-PTE size hugetlb page by move_pages() syscall under the lock, however antoher thread B can migrate the CONT-PTE hugetlb page at the same time, which will cause thread A to get an incorrect page, if thread A also wants to do page migration, then data inconsistency error occurs.
Moreover we have the same issue for CONT-PMD size hugetlb in follow_huge_pmd().
To fix above issues, rename the follow_huge_pmd() as follow_huge_pmd_pte() to handle PMD and PTE level size hugetlb, which uses huge_pte_lock() to get the correct pte entry lock to make the pte entry stable.
Mike said:
Support for CONT_PMD/_PTE was added with bb9dd3df8ee9 ("arm64: hugetlb:
refactor find_num_contig()"). Patch series "Support for contiguous pte hugepages", v4. However, I do not believe these code paths were executed until migration support was added with 5480280d3f2d ("arm64/mm:
enable HugeTLB migration for contiguous bit HugeTLB pages") I would go with 5480280d3f2d for the Fixes: targe.
--- include/linux/hugetlb.h | 6 +++--- mm/gup.c | 13 ++++++++++++- mm/hugetlb.c | 30 +++++++++++++++--------------- 3 files changed, 30 insertions(+), 19 deletions(-)
include/linux/hugetlb.h +3 -3
@@ -127,8 +127,8 @@ struct page *follow_huge_addr(struct mm_struct page *follow_huge_pd (struct vm_area_struct *vma,unsigned long address,hugepd_t hpd,int flags,int pdshift); -struct page *follow_huge_pmd (struct mm_struct *mm,unsigned long address, -pmd_t *pmd,int flags); +struct page *follow_huge_pmd_pte (struct vm_area_struct *vma,unsigned long address, +int flags);struct page *follow_huge_pud (struct mm_struct *mm,unsigned long address,pud_t *pud,int flags); struct page *follow_huge_pgd(struct mm_struct *mm, unsigned long address,
@@ -175,7 +175,7 @@ static inline void hugetlb_show_meminfo( { }#define follow_huge_pd (vma, addr, hpd, flags, pdshift) NULL -#define follow_huge_pmd (mm, addr, pmd, flags) NULL +#define follow_huge_pmd_pte (vma, addr, flags) NULL#define follow_huge_pud (mm, addr, pud, flags) NULL#define follow_huge_pgd (mm, addr, pgd, flags) NULL#define prepare_hugepage_range (file, addr, len) (-EINVAL)
mm/gup.c +12 -1
@@ -188,6 +188,17 @@ static struct page *follow_page_pte(struspinlock_t *ptl;pte_t *ptep, pte; +/* +* Considering PTE level hugetlb, like continuous-PTE hugetlb on +* ARM64 architecture. +*/ +if (is_vm_hugetlb_page (vma)) { + page =follow_huge_pmd_pte (vma, address, flags); +if (page) +return page; +return no_page_table (vma, flags); + } + retry:if (unlikely (pmd_bad (*pmd)))return no_page_table (vma, flags);
@@ -333,7 +344,7 @@ static struct page *follow_pmd_mask(struif (pmd_none (pmdval))return no_page_table (vma, flags);if (pmd_huge (pmdval) && vma->vm_flags &VM_HUGETLB ) { - page =follow_huge_pmd (mm, address, pmd, flags); + page =follow_huge_pmd_pte (vma, address, flags);if (page)return page;return no_page_table (vma, flags);
mm/hugetlb.c +15 -15
@@ -5157,30 +5157,30 @@ follow_huge_pd(struct vm_area_struct *vm }struct page *__weak -follow_huge_pmd (struct mm_struct *mm,unsigned long address, -pmd_t *pmd,int flags) +follow_huge_pmd_pte (struct vm_area_struct *vma,unsigned long address,int flags) { +struct hstate *h =hstate_vma (vma); +struct mm_struct *mm = vma->vm_mm;struct page *page =NULL ;spinlock_t *ptl; -pte_t pte; +pte_t *ptep, pte; + retry: - ptl =pmd_lockptr (mm, pmd); -spin_lock (ptl); -/* -* make sure that the address range covered by this pmd is not -* unmapped from other threads. -*/ -if (!pmd_huge (*pmd)) - goto out; - pte =huge_ptep_get ((pte_t *)pmd); + ptep =huge_pte_offset (mm, address,huge_page_size (h)); +if (!ptep) +return NULL ; + + ptl =huge_pte_lock (h, mm, ptep); + pte =huge_ptep_get (ptep);if (pte_present (pte)) { - page =pmd_page (*pmd) + ((address & ~PMD_MASK ) >>PAGE_SHIFT ); + page =pte_page (pte) + + ((address & ~huge_page_mask (h)) >>PAGE_SHIFT );if (flags &FOLL_GET )get_page (page); }else {if (is_hugetlb_entry_migration (pte)) {spin_unlock (ptl); -__migration_entry_wait (mm, (pte_t *)pmd, ptl); +__migration_entry_wait (mm, ptep, ptl); goto retry; }/*
@@ -5188,7 +5188,7 @@ retry:* follow_page_mask(). */ } -out: +spin_unlock (ptl);return page; }
Greg Kroah-Hartman
maintainerPATCH 4/9 block: unhash blkdev part inode when the part is deleted
In reply to Greg Kroah-HartmanFrom: Ming Lei <[email protected]>
v5.11 changes the blkdev lookup mechanism completely since commit 22ae8ce8b892 ("block: simplify bdev/disk lookup in blkdev_get"), and small part of the change is to unhash part bdev inode when deleting partition. Turns out this kind of change does fix one nasty issue in case of BLOCK_EXT_MAJOR:
1) when one partition is deleted & closed, disk_put_part() is always called before bdput(bdev), see blkdev_put(); so the part's devt can be freed & re-used before the inode is dropped
2) then new partition with same devt can be created just before the inode in 1) is dropped, then the old inode/bdev structurein 1) is re-used for this new partition, this way causes use-after-free and kernel panic.
It isn't possible to backport the whole big patchset of "merge struct block_device and struct hd_struct v4" for addressing this issue.
https://lore.kernel.org/linux-block/[email protected]/
So fixes it by unhashing part bdev in delete_partition(), and this way is actually aligned with v5.11+'s behavior.
Backported from the following 5.10.y commit:
5f2f77560591 ("block: unhash blkdev part inode when the part is deleted")
--- block/partition-generic.c | 7 +++++++ 1 file changed, 7 insertions(+)
block/partition-generic.c +7 -0
@@ -272,6 +272,7 @@ void delete_partition(struct gendisk *distruct disk_part_tbl *ptbl =rcu_dereference_protected (disk->part_tbl,1 );struct hd_struct *part; +struct block_device *bdev;if (partno >= ptbl->len)return ;
@@ -292,6 +293,12 @@ void delete_partition(struct gendisk *di* "in-use" until we really free the gendisk. */ blk_invalidate_devt (part_devt (part)); + + bdev =bdget (part_devt (part)); +if (bdev) { +remove_inode_hash (bdev->bd_inode); +bdput (bdev); + }hd_struct_kill (part); }
Greg Kroah-Hartman
maintainerPATCH 5/9 nfp: fix use-after-free in area_cache_get()
In reply to Greg Kroah-HartmanFrom: Jialiang Wang <[email protected]>
commit 02e1a114fdb71e59ee6770294166c30d437bf86a upstream.
area_cache_get() is used to distribute cache->area and set cache->id,
and if cache->id is not 0 and cache->area->kref refcount is 0, it will release the cache->area by nfp_cpp_area_release(). area_cache_get() set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().
But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
is already set but the refcount is not increased as expected. At this time, calling the nfp_cpp_area_release() will cause use-after-free.
To avoid the use-after-free, set cache->id after area_init() and
nfp_cpp_area_acquire() complete successfully.
Note: This vulnerability is triggerable by providing emulated device
equipped with specified configuration.
BUG: KASAN: use-after-free in nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1 Call Trace: <TASK> nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884) Allocated by task 1: nfp_cpp_area_alloc_with_name (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303) nfp_cpp_area_cache_add (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802) nfp6000_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:1230) nfp_cpp_from_operations (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215) nfp_pci_probe (drivers/net/ethernet/netronome/nfp/nfp_main.c:744) Freed by task 1: kfree (mm/slub.c:4562) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873) nfp_cpp_read (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:924 drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973) nfp_cpp_readl (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpplib.c:48)
--- drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c +2 -1
@@ -874,7 +874,6 @@ area_cache_get(struct nfp_cpp *cpp, u32 }/* Adjust the start address to be cache size aligned */ - cache->id = id; cache->addr = addr & ~(u64)(cache->size -1 );/* Re-init to the new ID and address */
@@ -894,6 +893,8 @@ area_cache_get(struct nfp_cpp *cpp, u32return NULL ; } + cache->id = id; + exit:/* Adjust offset */ *offset = addr - cache->addr;
Greg Kroah-Hartman
maintainerPATCH 6/9 ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
[ Upstream commit 97eea946b93961fffd29448dcda7398d0d51c4b2 ]
The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks.
--- sound/soc/soc-ops.c | 6 ++++++ 1 file changed, 6 insertions(+)
sound/soc/soc-ops.c +6 -0
@@ -460,6 +460,12 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol,if (snd_soc_volsw_is_stereo (mc)) { val_mask = mask << rshift; val2 = (ucontrol->value.integer.value[1 ] + min) & mask; + +if (mc->platform_max && val2 > mc->platform_max) +return -EINVAL ; +if (val2 > max) +return -EINVAL ; + val2 = val2 << rshift; err = snd_soc_component_update_bits(component, reg2, val_mask,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 7/9 pinctrl: meditatek: Startup with the IRQs disabled
In reply to Greg Kroah-HartmanFrom: Ricardo Ribalda <[email protected]>
[ Upstream commit 11780e37565db4dd064d3243ca68f755c13f65b4 ]
If the system is restarted via kexec(), the peripherals do not start with a known state.
If the previous system had enabled an IRQs we will receive unexected IRQs that can lock the system.
[ 28.109251] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:0] [ 28.109263] Modules linked in: [ 28.109273] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.79-14458-g4b9edf7b1ac6 #1 9f2e76613148af94acccd64c609a552fb4b4354b [ 28.109284] Hardware name: Google Elm (DT) [ 28.109290] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.109298] pc : __do_softirq+0xa0/0x388 [ 28.109309] lr : __do_softirq+0x70/0x388 [ 28.109316] sp : ffffffc008003ee0 [ 28.109321] x29: ffffffc008003f00 x28: 000000000000000a x27: 0000000000000080 [ 28.109334] x26: 0000000000000001 x25: ffffffefa7b350c0 x24: ffffffefa7b47480 [ 28.109346] x23: ffffffefa7b3d000 x22: 0000000000000000 x21: ffffffefa7b0fa40 [ 28.109358] x20: ffffffefa7b005b0 x19: ffffffefa7b47480 x18: 0000000000065b6b [ 28.109370] x17: ffffffefa749c8b0 x16: 000000000000018c x15: 00000000000001b8 [ 28.109382] x14: 00000000000d3b6b x13: 0000000000000006 x12: 0000000000057e91 [ 28.109394] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffefa7b47480 [ 28.109406] x8 : 00000000000000e0 x7 : 000000000f424000 x6 : 0000000000000000 [ 28.109418] x5 : ffffffefa7dfaca0 x4 : ffffffefa7dfadf0 x3 : 000000000000000f [ 28.109429] x2 : 0000000000000000 x1 : 0000000000000100 x0 : 0000000001ac65c5 [ 28.109441] Call trace: [ 28.109447] __do_softirq+0xa0/0x388 [ 28.109454] irq_exit+0xc0/0xe0 [ 28.109464] handle_domain_irq+0x68/0x90 [ 28.109473] gic_handle_irq+0xac/0xf0 [ 28.109480] call_on_irq_stack+0x28/0x50 [ 28.109488] do_interrupt_handler+0x44/0x58 [ 28.109496] el1_interrupt+0x30/0x58 [ 28.109506] el1h_64_irq_handler+0x18/0x24 [ 28.109512] el1h_64_irq+0x7c/0x80 [ 28.109519] arch_local_irq_enable+0xc/0x18 [ 28.109529] default_idle_call+0x40/0x140 [ 28.109539] do_idle+0x108/0x290 [ 28.109547] cpu_startup_entry+0x2c/0x30 [ 28.109554] rest_init+0xe8/0xf8 [ 28.109562] arch_call_rest_init+0x18/0x24 [ 28.109571] start_kernel+0x338/0x42c [ 28.109578] __primary_switched+0xbc/0xc4 [ 28.109588] Kernel panic - not syncing: softlockup: hung tasks
--- drivers/pinctrl/mediatek/mtk-eint.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/pinctrl/mediatek/mtk-eint.c +6 -3
@@ -277,12 +277,15 @@ static struct irq_chip mtk_eint_irq_chip = {static unsigned int mtk_eint_hw_init (struct mtk_eint *eint) { -void __iomem *reg = eint->base + eint->regs->dom_en; +void __iomem *dom_en = eint->base + eint->regs->dom_en; +void __iomem *mask_set = eint->base + eint->regs->mask_set;unsigned int i;for (i =0 ; i < eint->hw->ap_num; i +=32 ) { -writel (0xffffffff , reg); - reg +=4 ; +writel (0xffffffff , dom_en); +writel (0xffffffff , mask_set); + dom_en +=4 ; + mask_set +=4 ; }return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 8/9 can: sja1000: fix size of OCR_MODE_MASK define
In reply to Greg Kroah-HartmanFrom: Heiko Schocher <[email protected]>
[ Upstream commit 26e8f6a75248247982458e8237b98c9fb2ffcf9d ]
bitfield mode in ocr register has only 2 bits not 3, so correct the OCR_MODE_MASK define.
--- include/linux/can/platform/sja1000.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/can/platform/sja1000.h +1 -1
@@ -14,7 +14,7 @@#define OCR_MODE_TEST 0x01#define OCR_MODE_NORMAL 0x02#define OCR_MODE_CLOCK 0x03 -#define OCR_MODE_MASK 0x07 +#define OCR_MODE_MASK 0x03#define OCR_TX0_INVERT 0x04#define OCR_TX0_PULLDOWN 0x08#define OCR_TX0_PULLUP 0x10
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 9/9 can: mcba_usb: Fix termination command argument
In reply to Greg Kroah-HartmanFrom: Yasushi SHOJI <[email protected]>
[ Upstream commit 1a8e3bd25f1e789c8154e11ea24dc3ec5a4c1da0 ]
Microchip USB Analyzer can activate the internal termination resistors by setting the "termination" option ON, or OFF to to deactivate them. As I've observed, both with my oscilloscope and captured USB packets below, you must send "0" to turn it ON, and "1" to turn it OFF.
Quoted 1 line
From the schematics in the user's guide, I can confirm that you must
drive the CAN_RES signal LOW "0" to activate the resistors.
Reverse the argument value of usb_msg.termination to fix this.
These are the two commands sequence, ON then OFF.
Quoted 7 lines
No. Time Source Destination Protocol Length Info 1 0.000000 host 1.3.1 USB 46 URB_BULK outFrame 1: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) USB URB
Leftover Capture Data:a80000000000000000000000000000000000a8
Quoted 6 lines
No. Time Source Destination Protocol Length Info 2 4.372547 host 1.3.1 USB 46 URB_BULK outFrame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) USB URB
Leftover Capture Data:a80100000000000000000000000000000000a9
--- drivers/net/can/usb/mcba_usb.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/can/usb/mcba_usb.c +7 -3
@@ -47,6 +47,10 @@#define MCBA_VER_REQ_USB 1#define MCBA_VER_REQ_CAN 2 +/* Drive the CAN_RES signal LOW "0" to activate R24 and R25 */ +#define MCBA_VER_TERMINATION_ON 0 +#define MCBA_VER_TERMINATION_OFF 1 +#define MCBA_SIDL_EXID_MASK 0x8#define MCBA_DLC_MASK 0xf#define MCBA_DLC_RTR_MASK 0x40
@@ -469,7 +473,7 @@ static void mcba_usb_process_ka_usb(struct mcba_priv *priv, priv->usb_ka_first_pass = false; } -if (msg->termination_state) +if (msg->termination_state ==MCBA_VER_TERMINATION_ON ) priv->can.termination =MCBA_TERMINATION_ENABLED ;else priv->can.termination =MCBA_TERMINATION_DISABLED ;
@@ -789,9 +793,9 @@ static int mcba_set_termination(struct net_device *netdev, u16 term) };if (term ==MCBA_TERMINATION_ENABLED ) - usb_msg.termination =1 ; + usb_msg.termination =MCBA_VER_TERMINATION_ON ;else - usb_msg.termination =0 ; + usb_msg.termination =MCBA_VER_TERMINATION_OFF ;mcba_usb_xmit_cmd (priv, (struct mcba_usb_msg *)&usb_msg);
Signature · 1 line
2.35.1
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +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.228-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.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +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.228-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.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.4.228-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: e538d4b64ed30c6b7248a14b4e8641db4db16736
* git describe: v5.4.227-10-ge538d4b64ed3
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.227-10-ge538d4b64ed3
## Test Regressions (compared to v5.4.226-68-g8c05f5e0777d)
## Metric Regressions (compared to v5.4.226-68-g8c05f5e0777d)
## Test Fixes (compared to v5.4.226-68-g8c05f5e0777d)
## Metric Fixes (compared to v5.4.226-68-g8c05f5e0777d)
## Test result summary
total: 114869, pass: 99876, fail: 1964, skip: 12795, xfail: 234
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 146 total, 145 passed, 1 failed
* arm64: 44 total, 40 passed, 4 failed
* i386: 26 total, 20 passed, 6 failed
* mips: 27 total, 27 passed, 0 failed
* parisc: 6 total, 6 passed, 0 failed
* powerpc: 30 total, 30 passed, 0 failed
* riscv: 12 total, 11 passed, 1 failed
* s390: 6 total, 6 passed, 0 failed
* sh: 12 total, 12 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 37 total, 35 passed, 2 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* 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-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* 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-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* ltp[
* network-basic-tests
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
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.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +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.228-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:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
59 tests: 59 pass, 0 failLinux version: 5.4.228-rc1-ge538d4b64ed3
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
Build test (gcc version 11.3.1 20221127):
mips: 65 configs -> no failure
arm: 106 configs -> no failure
arm64: 2 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
[1]. https://openqa.qa.codethink.co.uk/tests/2361
Signature · 2 lines
Regards Sudip
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +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.228-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
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 159 fail: 0 Qemu test results: total: 447 pass: 447 fail: 0
Guenter
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.228 release. There are 9 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 Sat, 17 Dec 2022 17:28:57 +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.4.228-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.
Quoted 5 lines
thanks,
greg k-h
-------------
Tested on arm64 and x86 for 5.4.228-rc1,
Kernel repo:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.4.y
Version: 5.4.228-rc1
Commit: e538d4b64ed30c6b7248a14b4e8641db4db16736
Compiler: gcc version 7.3.0 (GCC)
arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9017
passed: 9017
failed: 0
timeout: 0
--------------------------------------------------------------------
x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9017
passed: 9017
failed: 0
timeout: 0
--------------------------------------------------------------------