* Re: [PATCH] checkpatch: Add kmap and kmap_atomic to the deprecated list
From: Chaitanya Kulkarni @ 2022-08-14 5:25 UTC (permalink / raw)
To: ira.weiny@intel.com, Andy Whitcroft, Joe Perches
Cc: nvdimm@lists.linux.dev, kvm@vger.kernel.org,
linux-sh@vger.kernel.org, kgdb-bugreport@lists.sourceforge.net,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
linux-ide@vger.kernel.org, dm-devel@redhat.com,
keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux1394-devel@lists.sourceforge.net, linux-scsi@vger.kernel.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
linux-csky@vger.kernel.org, iommu@lists.linux.dev,
linux-snps-arc@lists.infradead.org, Fabio M . De Francesco,
linux-media@vger.kernel.org, linux-xtensa@linux-xtensa.org,
linux-um@lists.infradead.org, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, loongarch@lists.linux.dev,
Thomas Gleixner, virtualization@lists.linux-foundation.org,
bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org, linux-raid@vger.kernel.org,
netdev@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20220813220034.806698-1-ira.weiny@intel.com>
On 8/13/22 15:00, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> kmap() and kmap_atomic() are being deprecated in favor of
> kmap_local_page().
>
> There are two main problems with kmap(): (1) It comes with an overhead
> as mapping space is restricted and protected by a global lock for
> synchronization and (2) it also requires global TLB invalidation when
> the kmap’s pool wraps and it might block when the mapping space is fully
> utilized until a slot becomes available.
>
> kmap_local_page() is safe from any context and is therefore redundant
> with kmap_atomic() with the exception of any pagefault or preemption
> disable requirements. However, using kmap_atomic() for these side
> effects makes the code less clear. So any requirement for pagefault or
> preemption disable should be made explicitly.
>
> With kmap_local_page() the mappings are per thread, CPU local, can take
> page faults, and can be called from any context (including interrupts).
> It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
> the tasks can be preempted and, when they are scheduled to run again,
> the kernel virtual addresses are restored.
>
> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> Suggested-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> ---
> Suggested by credits.
> Thomas: Idea to keep from growing more kmap/kmap_atomic calls.
> Fabio: Stole some of his boiler plate commit message.
>
> Notes on tree-wide conversions:
>
> I've cc'ed mailing lists for subsystems which currently contains either kmap()
> or kmap_atomic() calls. As some of you already know Fabio and I have been
> working through converting kmap() calls to kmap_local_page(). But there is a
> lot more work to be done. Help from the community is always welcome,
> especially with kmap_atomic() conversions. To keep from stepping on each
> others toes I've created a spreadsheet of the current calls[1]. Please let me
> or Fabio know if you plan on tacking one of the conversions so we can mark it
> off the list.
>
> [1] https://docs.google.com/spreadsheets/d/1i_ckZ10p90bH_CkxD2bYNi05S2Qz84E2OFPv8zq__0w/edit#gid=1679714357
>
Looks good.
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
^ permalink raw reply
* Re: [GIT PULL] virtio: fatures, fixes
From: Andres Freund @ 2022-08-14 4:39 UTC (permalink / raw)
To: Xuan Zhuo
Cc: Linus Torvalds, kvm, virtualization, netdev, linux-kernel,
alvaro.karsz, colin.i.king, colin.king, dan.carpenter, david,
elic, eperezma, gautam.dawar, gshan, hdegoede, hulkci, jasowang,
jiaming, kangjie.xu, lingshan.zhu, liubo03, michael.christie,
pankaj.gupta, peng.fan, quic_mingxue, robin.murphy, sgarzare,
suwan.kim027, syoshida, xieyongji, xuqiang36, Michael S. Tsirkin
In-Reply-To: <20220814035239.m7rtepyum5xvtu2c@awork3.anarazel.de>
Hi,
On 2022-08-13 20:52:39 -0700, Andres Freund wrote:
> Is there specific information you'd like from the VM? I just recreated the
> problem and can extract.
Actually, after reproducing I seem to now hit a likely different issue. I
guess I should have checked exactly the revision I had a problem with earlier,
rather than doing a git pull (up to aea23e7c464b)
[ 0.727199] scsi host0: Virtio SCSI HBA
[ 0.732257] scsi 0:0:1:0: Direct-Access Google PersistentDisk 1 PQ: 0 ANSI: 6
[ 0.736259] Freeing initrd memory: 7236K
[ 0.741743] sd 0:0:1:0: Attached scsi generic sg0 type 0
[ 0.742569] sd 0:0:1:0: [sda] 52428800 512-byte logical blocks: (26.8 GB/25.0 GiB)
[ 0.742628] tun: Universal TUN/TAP device driver, 1.6
[ 0.743730] sd 0:0:1:0: [sda] 4096-byte physical blocks
[ 0.748026] sd 0:0:1:0: [sda] Write Protect is off
[ 0.750684] sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 0.795519] BUG: unable to handle page fault for address: ffffa3107bd80008
[ 0.795753] sky2: driver version 1.30
[ 0.796500] #PF: supervisor read access in kernel mode
[ 0.797252] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.796500] #PF: error_code(0x0000) - not-present page
[ 0.796500] PGD 100001067 P4D 100001067 PUD 0
[ 0.796500] Oops: 0000 [#1] PREEMPT SMP PTI
[ 0.796500] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.19.0-origin-14013-gaea23e7c464b #2
[ 0.798728] ehci-pci: EHCI PCI platform driver
[ 0.796500] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/29/2022
[ 0.800112] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.796500] RIP: 0010:kmem_cache_free+0x155/0x3e0
[ 0.801875] ohci-pci: OHCI PCI platform driver
[ 0.796500] Code: 02 00 00 65 48 ff 08 e8 e9 cd e6 ff 66 90 8b 45 28 48 c7 04 03 00 00 00 00 48 85 db 74 38 48 8b 45 00 65 48 03 05 fb 13 34 6d <48> 8b 50 08 4c 39 60 10 0f 85 da 01 00 00 8b 4d 28 48 8b 00 48 89
[ 0.803798] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.796500] RSP: 0000:ffffa29cc0134e80 EFLAGS: 00010286
[ 0.805319] RAX: ffffa3107bd80000 RBX: ffff998840b253c0 RCX: ffff029c00000000
[ 0.805319] RDX: 0000000000000000 RSI: ffffc8f280000000 RDI: ffff998840ab2300
[ 0.805319] RBP: ffff998840ab2300 R08: fffffffffff0bddf R09: 0000000000000008
[ 0.805319] R10: ffffffff93e060c0 R11: ffffa29cc0134ff8 R12: ffffc8f28402c940
[ 0.805319] R13: ffffffff92f17edd R14: 0000000000001000 R15: 0000000000001000
[ 0.805319] FS: 0000000000000000(0000) GS:ffff99887bd80000(0000) knlGS:0000000000000000
[ 0.805319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.805319] CR2: ffffa3107bd80008 CR3: 000000002720c001 CR4: 00000000003706e0
[ 0.805319] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.805319] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.805319] Call Trace:
[ 0.805319] <IRQ>
[ 0.805319] blk_update_request+0xfd/0x3d0
[ 0.805319] ? detach_buf_split+0x6a/0x150
[ 0.805319] scsi_end_request+0x22/0x1b0
[ 0.805319] scsi_io_completion+0x3c/0x750
[ 0.805319] blk_complete_reqs+0x38/0x50
[ 0.805319] __do_softirq+0xe1/0x2ed
[ 0.805319] ? handle_edge_irq+0x9a/0x230
[ 0.805319] __irq_exit_rcu+0xa6/0x100
[ 0.805319] common_interrupt+0xa5/0xc0
[ 0.805319] </IRQ>
[ 0.805319] <TASK>
[ 0.805319] asm_common_interrupt+0x22/0x40
[ 0.805319] RIP: 0010:acpi_idle_do_entry+0x46/0x60
[ 0.805319] Code: 75 08 48 8b 15 2f 1a 19 01 ed c3 cc cc cc cc 65 48 8b 04 25 00 ad 01 00 48 8b 00 a8 08 75 eb 66 90 0f 00 2d 9c 0d 5b 00 fb f4 <fa> c3 cc cc cc cc e9 2f fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00
[ 0.805319] RSP: 0000:ffffa29cc00a7e68 EFLAGS: 00000246
[ 0.805319] RAX: 0000000000004000 RBX: 0000000000000001 RCX: 000000000000098d
[ 0.805319] RDX: ffff99887bd80000 RSI: ffff998840b2c000 RDI: ffff998840b2c064
[ 0.805319] RBP: ffff998841a2a400 R08: fffffffffff0be0e R09: 0000000157c1aaba
[ 0.805319] R10: 0000000000000018 R11: 0000000000000c27 R12: ffffffff93fc46a0
[ 0.805319] R13: ffff998840b2c064 R14: 0000000000000001 R15: 0000000000000000
[ 0.805319] acpi_idle_enter+0x9f/0x100
[ 0.805319] cpuidle_enter_state+0x84/0x400
[ 0.805319] cpuidle_enter+0x24/0x40
[ 0.805319] do_idle+0x1df/0x260
[ 0.805319] cpu_startup_entry+0x14/0x20
[ 0.805319] start_secondary+0xe8/0xf0
[ 0.805319] secondary_startup_64_no_verify+0xe0/0xeb
[ 0.805319] </TASK>
[ 0.805319] Modules linked in:
[ 0.805319] CR2: ffffa3107bd80008
[ 0.805319] ---[ end trace 0000000000000000 ]---
Regards,
Andres
^ permalink raw reply
* Re: [PATCH net-next v1 07/10] net: dsa: microchip: warn about not supported synclko properties on KSZ9893 chips
From: Oleksij Rempel @ 2022-08-14 4:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, Florian Fainelli, David S. Miller, netdev,
linux-kernel, UNGLinuxDriver, Eric Dumazet, Vladimir Oltean,
kernel, Jakub Kicinski, Paolo Abeni, Vivien Didelot, Rob Herring,
devicetree
In-Reply-To: <YvgMnfSkEeD8jwIG@lunn.ch>
Ccing Rob Herring.
On Sat, Aug 13, 2022 at 10:42:05PM +0200, Andrew Lunn wrote:
> On Sat, Aug 13, 2022 at 06:18:50PM +0200, Oleksij Rempel wrote:
> > On Sat, Aug 13, 2022 at 05:11:45PM +0200, Andrew Lunn wrote:
> > > On Sat, Aug 13, 2022 at 04:32:15PM +0200, Oleksij Rempel wrote:
> > > > On Fri, Aug 05, 2022 at 04:42:34PM +0300, Vladimir Oltean wrote:
> > > > > On Fri, Aug 05, 2022 at 01:56:01PM +0200, Oleksij Rempel wrote:
> > > > > > Hm, if we will have any random not support OF property in the switch
> > > > > > node. We won't be able to warn about it anyway. So, if it is present
> > > > > > but not supported, we will just ignore it.
> > > > > >
> > > > > > I'll drop this patch.
> > > > >
> > > > > To continue, I think the right way to go about this is to edit the
> > > > > dt-schema to say that these properties are only applicable to certain
> > > > > compatible strings, rather than for all. Then due to the
> > > > > "unevaluatedProperties: false", you'd get the warnings you want, at
> > > > > validation time.
> > > >
> > > > Hm, with "unevaluatedProperties: false" i have no warnings. Even if I
> > > > create examples with random strings as properties. Are there some new
> > > > json libraries i should use?
> > >
> > > Try
> > >
> > > additionalProperties: False
> >
> > Yes, it works. But in this case I'll do more changes. Just wont to make
> > sure I do not fix not broken things.
>
> I've been working on converting some old SoCs bindings from .txt to
> .yaml. My observations is that the yaml is sometimes more restrictive
> than what the drivers actually imposes. So you might need to change
> perfectly working .dts files to get it warning free. Or you just
> accept the warnings and move on. At lot will depend on the number of
> warnings and how easy it is to see real problems mixed in with
> warnings you never intend to fix.
Heh :) Currently with "unevaluatedProperties: false" restrictions do not
work at all. At least for me. For example with this change I have no
warnings:
diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
index 1e26d876d1463..da38ad98a152f 100644
--- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
@@ -120,6 +120,7 @@ examples:
ethernet-switch@1 {
reg = <0x1>;
compatible = "nxp,sja1105t";
+ something-random-here;
ethernet-ports {
#address-cells = <1>;
make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
So the main question is, is it broken for all or just for me? If it is
just me, what i'm doing wrong?
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
* Re: [GIT PULL] virtio: fatures, fixes
From: Andres Freund @ 2022-08-14 3:52 UTC (permalink / raw)
To: Xuan Zhuo
Cc: Linus Torvalds, kvm, virtualization, netdev, linux-kernel,
alvaro.karsz, colin.i.king, colin.king, dan.carpenter, david,
elic, eperezma, gautam.dawar, gshan, hdegoede, hulkci, jasowang,
jiaming, kangjie.xu, lingshan.zhu, liubo03, michael.christie,
pankaj.gupta, peng.fan, quic_mingxue, robin.murphy, sgarzare,
suwan.kim027, syoshida, xieyongji, xuqiang36, Michael S. Tsirkin
In-Reply-To: <1660441835.6907768-1-xuanzhuo@linux.alibaba.com>
Hi,
On 2022-08-14 09:50:35 +0800, Xuan Zhuo wrote:
> Sorry, I didn't get any valuable information from the logs, can you tell me how
> to get such an image? Or how your [1] script is executed.
Is there specific information you'd like from the VM? I just recreated the
problem and can extract.
The last image that succeeded getting built is publically available, so you
could create a gcp VM for that, go to /usr/src/linux, git pull, make & install
the new kernel and reproduce the problem that way. The git pull will take a
bit because it's a shallow clone...
gcloud compute instances create myvm --preemptible --project your-gcp-project --image-project pg-ci-images --image pg-ci-sid-newkernel-2022-08-12t06-52 --zone us-west1-a --custom-cpu=4 --custom-memory=4 --metadata=serial-port-enable=true
If you want to log in via serial console, you'd have set a password before
rebooting.
gcloud compute connect-to-serial-port --zone us-west1-a --project=pg-ci-images-dev myvm
Executing the script requires a gcp key with the right to create instances and
images. Here's how to invoke it:
PACKER_LOG=1 GOOGLE_APPLICATION_CREDENTIALS=~/image-builder@pg-ci-images-dev.iam.gserviceaccount.com.json \
packer build \
-var gcp_project=pg-ci-images-dev \
-var "image_date=$(date --utc +'%Y-%m-%dt%H-%M')" \
-var "task_name=sid-newkernel" \
-only 'linux.googlecompute.sid-newkernel' \
-on-error=ask \
packer/linux_debian.pkr.hcl
Of course you'd need to change the gcp_project= variable to point to a the
project you have access to and GOOGLE_APPLICATION_CREDENTIALS to point to your
gcp key.
Initially (package upgrades, kernel builds) the VM would be SSH
accessible. After building the kernel it's only accessible via serial console.
I can probably also get you the image in some other form that you prefer,
although I don't know if the problem will reproduce outside gcp. If helpful I
could upload a "broken" gcp image that you could use to
> > [1] https://github.com/anarazel/pg-vm-images/blob/main/packer/linux_debian.pkr.hcl#L225
Greetings,
Andres Freund
^ permalink raw reply
* Re: [PATCH bpf-next 13/15] mm, memcg: Add new helper get_obj_cgroup_from_cgroup
From: Yafang Shao @ 2022-08-14 2:35 UTC (permalink / raw)
To: Roman Gushchin
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau,
Song Liu, Yonghong Song, john fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, jolsa, Johannes Weiner, Michal Hocko,
Shakeel Butt, Muchun Song, Andrew Morton, netdev, bpf, Linux MM
In-Reply-To: <YvftrF7GmqMjvAa+@P9FQF9L96D.corp.robot.car>
On Sun, Aug 14, 2022 at 2:30 AM Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
> On Sat, Aug 13, 2022 at 07:56:54AM +0800, Yafang Shao wrote:
> > On Sat, Aug 13, 2022 at 1:40 AM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> > >
> > > On Fri, Aug 12, 2022 at 08:35:19AM +0800, Yafang Shao wrote:
> > > > On Fri, Aug 12, 2022 at 12:16 AM Roman Gushchin
> > > > <roman.gushchin@linux.dev> wrote:
> > > > >
> > > > > On Wed, Aug 10, 2022 at 03:18:38PM +0000, Yafang Shao wrote:
> > > > > > Introduce new helper get_obj_cgroup_from_cgroup() to get obj_cgroup from
> > > > > > a specific cgroup.
> > > > > >
> > > > > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > > > > > ---
> > > > > > include/linux/memcontrol.h | 1 +
> > > > > > mm/memcontrol.c | 41 +++++++++++++++++++++++++++++++++++++++++
> > > > > > 2 files changed, 42 insertions(+)
> > > > > >
> > > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > > > > > index 2f0a611..901a921 100644
> > > > > > --- a/include/linux/memcontrol.h
> > > > > > +++ b/include/linux/memcontrol.h
> > > > > > @@ -1713,6 +1713,7 @@ static inline void set_shrinker_bit(struct mem_cgroup *memcg,
> > > > > > int __memcg_kmem_charge_page(struct page *page, gfp_t gfp, int order);
> > > > > > void __memcg_kmem_uncharge_page(struct page *page, int order);
> > > > > >
> > > > > > +struct obj_cgroup *get_obj_cgroup_from_cgroup(struct cgroup *cgrp);
> > > > > > struct obj_cgroup *get_obj_cgroup_from_current(void);
> > > > > > struct obj_cgroup *get_obj_cgroup_from_page(struct page *page);
> > > > > >
> > > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > > > index 618c366..762cffa 100644
> > > > > > --- a/mm/memcontrol.c
> > > > > > +++ b/mm/memcontrol.c
> > > > > > @@ -2908,6 +2908,47 @@ static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg)
> > > > > > return objcg;
> > > > > > }
> > > > > >
> > > > > > +static struct obj_cgroup *get_obj_cgroup_from_memcg(struct mem_cgroup *memcg)
> > > > > > +{
> > > > > > + struct obj_cgroup *objcg;
> > > > > > +
> > > > > > + if (memcg_kmem_bypass())
> > > > > > + return NULL;
> > > > > > +
> > > > > > + rcu_read_lock();
> > > > > > + objcg = __get_obj_cgroup_from_memcg(memcg);
> > > > > > + rcu_read_unlock();
> > > > > > + return objcg;
> > > > >
> > > > > This code doesn't make sense to me. What does rcu read lock protect here?
> > > >
> > > > To protect rcu_dereference(memcg->objcg);.
> > > > Doesn't it need the read rcu lock ?
> > >
> > > No, it's not how rcu works. Please, take a look at the docs here:
> > > https://docs.kernel.org/RCU/whatisRCU.html#whatisrcu .
> > > In particular, it describes this specific case very well.
> > >
> > > In 2 words, you don't protect the rcu_dereference() call, you protect the pointer
> >
> > I just copied and pasted rcu_dereference(memcg->objcg) there to make it clear.
> > Actually it protects memcg->objcg, doesn't it ?
> >
> > > you get, cause it's valid only inside the rcu read section. After rcu_read_unlock()
> > > it might point at a random data, because the protected object can be already freed.
> > >
> >
> > Are you sure?
> > Can't the obj_cgroup_tryget(objcg) prevent it from being freed ?
>
> Ok, now I see where it comes from. You copy-pasted it from get_obj_cgroup_from_current()?
> There rcu read lock section protects memcg, not objcg.
Could you pls explain in detail why we should protect memcg instead of objcg ?
Why does the memcg need the read rcu lock ?
> In your case you don't need it, because memcg is passed as a parameter to the function,
> so it's the duty of the caller to ensure the lifetime of memcg.
>
I'm still a bit confused. See below,
objcg = rcu_dereference(memcg->objcg);
percpu_ref_tryget(&objcg->refcnt); <<<< what if the objcg is freed
before this operation ??
--
Regards
Yafang
^ permalink raw reply
* Re: [GIT PULL] virtio: fatures, fixes
From: Xuan Zhuo @ 2022-08-14 1:50 UTC (permalink / raw)
To: Andres Freund
Cc: Linus Torvalds, kvm, virtualization, netdev, linux-kernel,
alvaro.karsz, colin.i.king, colin.king, dan.carpenter, david,
elic, eperezma, gautam.dawar, gshan, hdegoede, hulkci, jasowang,
jiaming, kangjie.xu, lingshan.zhu, liubo03, michael.christie,
pankaj.gupta, peng.fan, quic_mingxue, robin.murphy, sgarzare,
suwan.kim027, syoshida, xieyongji, xuqiang36, Michael S. Tsirkin
In-Reply-To: <20220814004522.33ecrwkmol3uz7aq@awork3.anarazel.de>
On Sat, 13 Aug 2022 17:45:22 -0700, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> On 2022-08-12 11:42:50 -0400, Michael S. Tsirkin wrote:
> > The following changes since commit 3d7cb6b04c3f3115719235cc6866b10326de34cd:
> >
> > Linux 5.19 (2022-07-31 14:03:01 -0700)
> >
> > are available in the Git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
> >
> > for you to fetch changes up to 93e530d2a1c4c0fcce45e01ae6c5c6287a08d3e3:
> >
> > vdpa/mlx5: Fix possible uninitialized return value (2022-08-11 10:00:36 -0400)
> > ----------------------------------------------------------------
> > virtio: fatures, fixes
> >
> > A huge patchset supporting vq resize using the
> > new vq reset capability.
> > Features, fixes, cleanups all over the place.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ----------------------------------------------------------------
>
> I have a script [1] that daily builds google cloud VM images with a fresh vanilla
> kernel for postgres CI testing. The last successful image creation was
> 7ebfc85e2cd7b08f518b526173e9a33b56b3913b
> and the first failing was
> 69dac8e431af26173ca0a1ebc87054e01c585bcc
>
> Since then creating a new kernel boots but network does not come up.
>
> Looking at the merges between those commit makes me suspect this merge:
>
> 69dac8e431af Merge tag 'riscv-for-linus-5.20-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
> 6c833c0581f1 Merge tag 'devicetree-fixes-for-6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> 3d076fec5a0c Merge tag 'rtc-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
> 4a9350597aff Merge tag 'sound-fix-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
> 7a53e17accce Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
> 999324f58c41 Merge tag 'loongarch-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
> f7cdaeeab8ca Merge tag 'for-v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
> d16b418fac3d Merge tag 'vfio-v6.0-rc1pt2' of https://github.com/awilliam/linux-vfio
> 9801002f76c6 perf: riscv_pmu{,_sbi}: Miscallenous improvement & fixes
> c3adefb5baf3 Merge tag 'for-6.0/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> 7ce2aa6d7fe1 Merge tag 'drm-next-2022-08-12-1' of git://anongit.freedesktop.org/drm/drm
> 7ab52f75a9cf RISC-V: Add Sstc extension support
> 36fa1cb56ac5 Merge tag 'drm-misc-next-fixes-2022-08-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
> da06cc5bb600 RISC-V: fixups to work with crash tool
> 6de9eb21cd36 Merge 'irq/loongarch', 'pci/ctrl/loongson' and 'pci/header-cleanup-immutable'
> 3aefb2ee5bdd riscv: implement Zicbom-based CMO instructions + the t-head variant
> 8f2f74b4b6e6 RISC-V: Canaan devicetree fixes
> f94ba7039fb4 Merge tag 'at91-reset-sama7g5-signed' into psy-next
>
> all the drivers/net changes in that commit range were part of this pull
> request.
>
>
> excerpt from serial log for debian sid kernel (sorry for the interspersed logs):
>
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 cloud-ifupdown-helper: Generated configuration for ens4
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kern[ OK ] Finished Raise network interfaces.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Found device Virtio network device.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Commit a transient machine-id on disk was skipped because of a failed condition check (ConditionPathIsMountPoint[ OK ] Reached target Network.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Started ifup for ens4.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.354044] x86: [ OK ] Reached target Network is Online.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Internet Systems Consortium DHCP Client 4.4.3
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Internet Systems Consortium DHCP Client 4.4.3
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Copyright 2004-2022 Internet Systems Consortium.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: For info, please visit https://www.isc.org/software/dhcp/
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Copyright 2004-2022 Internet Systems Consortium.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: For info, please visit https://www.isc.org/software/dhcp/
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Starting Raise network interfaces...
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 ifup[356]: ifup: waiting for lock on /run/network/ifstate.ens4
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Listening on LPF/ens4/42:01:0a:a8:00:07
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Listening on LPF/ens4/42:01:0a:a8:00:07
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Sending on LPF/ens4/42:01:0a:a8:00:07
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Sending on LPF/ens4/42:01:0a:a8:00:07
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 7
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.400657] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 7
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.408289] audit: initializing netlink subsys (disabled)
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPOFFER of 10.168.0.7 from 169.254.169.254
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPOFFER of 10.168.0.7 from 169.254.169.254
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPREQUEST for 10.168.0.7 on ens4 to 255.255.255.255 port 67
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPREQUEST for 10.168.0.7 on ens4 to 255.255.255.255 port 67
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPACK of 10.168.0.7 from 169.254.169.254
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPACK of 10.168.0.7 from 169.254.169.254
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.549954] NetLabel: Initializing
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.550736] NetLabel: domain hash size = 128
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.551480] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.552303] NetLabel: unlabeled traffic allowed by default
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.570445] NET: Registered PF_INET protocol family
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.586842] NET: Registered PF_UNIX/PF_LOCAL protocol family
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.587916] NET: Registered PF_XDP protocol family
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.865585] NET: Registered PF_INET6 protocol family
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.872235] NET: Registered PF_PACKET protocol family
> rnel: [ 1.153962] virtio_net virtio1 ens4: renamed from eth0
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[474]: ens4=ens4
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Finished Raise network interfaces.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Reached target Network.
> Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Reached target Network is Online.
>
> rebooting into the new kernel:
>
> [ 0.475837] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> [ 0.476558] audit: initializing netlink subsys (disabled)
> [ 0.630598] NetLabel: Initializing
> [ 0.631503] NetLabel: domain hash size = 128
> [ 0.632409] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
> [ 0.632515] NetLabel: unlabeled traffic allowed by default
> [ 0.654654] NET: Registered PF_INET protocol family
> [ 0.672514] NET: Registered PF_UNIX/PF_LOCAL protocol family
> [ 0.871362] Initializing XFRM netlink socket
> [ 0.872171] NET: Registered PF_INET6 protocol family
> [ 0.875791] NET: Registered PF_PACKET protocol family
> [ 0.876932] 9pnet: Installing 9P2000 support
> [ 0.887570] printk: console [netcon0] enabled
> [ 0.888339] netconsole: network logging started
> [ 0.943112] virtio_net virtio1 enp0s4: renamed from eth0
> Starting Raise network interfaces...
> [ OK ] Found device Virtio network device.
> [ 1.876517] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s4: link becomes ready
> Aug 13 22:51:16 debian systemd[1]: Starting Raise network interfaces...
> Aug 13 22:51:16 debian dhclient[349]: Internet Systems Consortium DHCP Client 4.4.3
> Aug 13 22:51:16 debian ifup[349]: Internet Systems Consortium DHCP Client 4.4.3
> Aug 13 22:51:16 debian ifup[349]: Copyright 2004-2022 Internet Systems Consortium.
> Aug 13 22:51:16 debian ifup[349]: For info, please visit https://www.isc.org/software/dhcp/
> Aug 13 22:51:16 debian dhclient[349]: Copyright 2004-2022 Internet Systems Consortium.
> Aug 13 22:51:16 debian dhclient[349]: For info, please visit https://www.isc.org/software/dhcp/
> Aug 13 22:51:16 debian kernel: [ 0.475837] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> Aug 13 22:51:16 debian kernel: [ 0.476558] audit: initializing netlink subsys (disabled)
> Aug 13 22:51:16 debian systemd[1]: Found device Virtio network device.
> Aug 13 22:51:16 debian ifup[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 6
> Aug 13 22:51:16 debian dhclient[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 6
> Aug 13 22:51:16 debian sh[356]: ifup: waiting for lock on /run/network/ifstate.enp0s4
> Aug 13 22:51:16 debian kernel: [ 0.630598] NetLabel: Initializing
> Aug 13 22:51:16 debian kernel: [ 0.631503] NetLabel: domain hash size = 128
> Aug 13 22:51:16 debian kernel: [ 0.632409] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
> Aug 13 22:51:16 debian kernel: [ 0.632515] NetLabel: unlabeled traffic allowed by default
> Aug 13 22:51:16 debian kernel: [ 0.654654] NET: Registered PF_INET protocol family
> Aug 13 22:51:16 debian kernel: [ 0.672514] NET: Registered PF_UNIX/PF_LOCAL protocol family
> Aug 13 22:51:16 debian kernel: [ 0.871362] Initializing XFRM netlink socket
> Aug 13 22:51:16 debian kernel: [ 0.872171] NET: Registered PF_INET6 protocol family
> Aug 13 22:51:16 debian kernel: [ 0.875791] NET: Registered PF_PACKET protocol family
> Aug 13 22:51:16 debian kernel: [ 0.876932] 9pnet: Installing 9P2000 support
> Aug 13 22:51:16 debian kernel: [ 0.887570] printk: console [netcon0] enabled
> Aug 13 22:51:16 debian kernel: [ 0.888339] netconsole: network logging started
> Aug 13 22:51:16 debian kernel: [ 0.943112] virtio_net virtio1 enp0s4: renamed from eth0
> Aug 13 22:51:16 debian kernel: [ 1.876517] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s4: link becomes ready
> [ *** ] A start job is running for Raise network interfaces (6s / 5min)
> Aug 13 22:51:22 debian dhclient[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 13
> [*** ] A start job is running for Raise network interfaces (19s / 5min)
> Aug 13 22:51:35 debian dhclient[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 14
> [*** ] A start job is running for Raise network interfaces (33s / 5min)
> ...
>
Hi,
Sorry, I didn't get any valuable information from the logs, can you tell me how
to get such an image? Or how your [1] script is executed.
Thanks.
>
> Greetings,
>
> Andres Freund
>
>
> [1] https://github.com/anarazel/pg-vm-images/blob/main/packer/linux_debian.pkr.hcl#L225
^ permalink raw reply
* Re: [GIT PULL] virtio: fatures, fixes
From: Andres Freund @ 2022-08-14 0:45 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Linus Torvalds, kvm, virtualization, netdev, linux-kernel,
alvaro.karsz, colin.i.king, colin.king, dan.carpenter, david,
elic, eperezma, gautam.dawar, gshan, hdegoede, hulkci, jasowang,
jiaming, kangjie.xu, lingshan.zhu, liubo03, michael.christie,
pankaj.gupta, peng.fan, quic_mingxue, robin.murphy, sgarzare,
suwan.kim027, syoshida, xieyongji, xuanzhuo, xuqiang36
In-Reply-To: <20220812114250-mutt-send-email-mst@kernel.org>
Hi,
On 2022-08-12 11:42:50 -0400, Michael S. Tsirkin wrote:
> The following changes since commit 3d7cb6b04c3f3115719235cc6866b10326de34cd:
>
> Linux 5.19 (2022-07-31 14:03:01 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
>
> for you to fetch changes up to 93e530d2a1c4c0fcce45e01ae6c5c6287a08d3e3:
>
> vdpa/mlx5: Fix possible uninitialized return value (2022-08-11 10:00:36 -0400)
> ----------------------------------------------------------------
> virtio: fatures, fixes
>
> A huge patchset supporting vq resize using the
> new vq reset capability.
> Features, fixes, cleanups all over the place.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ----------------------------------------------------------------
I have a script [1] that daily builds google cloud VM images with a fresh vanilla
kernel for postgres CI testing. The last successful image creation was
7ebfc85e2cd7b08f518b526173e9a33b56b3913b
and the first failing was
69dac8e431af26173ca0a1ebc87054e01c585bcc
Since then creating a new kernel boots but network does not come up.
Looking at the merges between those commit makes me suspect this merge:
69dac8e431af Merge tag 'riscv-for-linus-5.20-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
6c833c0581f1 Merge tag 'devicetree-fixes-for-6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
3d076fec5a0c Merge tag 'rtc-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
4a9350597aff Merge tag 'sound-fix-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
7a53e17accce Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
999324f58c41 Merge tag 'loongarch-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
f7cdaeeab8ca Merge tag 'for-v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
d16b418fac3d Merge tag 'vfio-v6.0-rc1pt2' of https://github.com/awilliam/linux-vfio
9801002f76c6 perf: riscv_pmu{,_sbi}: Miscallenous improvement & fixes
c3adefb5baf3 Merge tag 'for-6.0/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
7ce2aa6d7fe1 Merge tag 'drm-next-2022-08-12-1' of git://anongit.freedesktop.org/drm/drm
7ab52f75a9cf RISC-V: Add Sstc extension support
36fa1cb56ac5 Merge tag 'drm-misc-next-fixes-2022-08-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
da06cc5bb600 RISC-V: fixups to work with crash tool
6de9eb21cd36 Merge 'irq/loongarch', 'pci/ctrl/loongson' and 'pci/header-cleanup-immutable'
3aefb2ee5bdd riscv: implement Zicbom-based CMO instructions + the t-head variant
8f2f74b4b6e6 RISC-V: Canaan devicetree fixes
f94ba7039fb4 Merge tag 'at91-reset-sama7g5-signed' into psy-next
all the drivers/net changes in that commit range were part of this pull
request.
excerpt from serial log for debian sid kernel (sorry for the interspersed logs):
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 cloud-ifupdown-helper: Generated configuration for ens4
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kern[ OK ] Finished Raise network interfaces.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Found device Virtio network device.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Commit a transient machine-id on disk was skipped because of a failed condition check (ConditionPathIsMountPoint[ OK ] Reached target Network.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Started ifup for ens4.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.354044] x86: [ OK ] Reached target Network is Online.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Internet Systems Consortium DHCP Client 4.4.3
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Internet Systems Consortium DHCP Client 4.4.3
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Copyright 2004-2022 Internet Systems Consortium.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: For info, please visit https://www.isc.org/software/dhcp/
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Copyright 2004-2022 Internet Systems Consortium.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: For info, please visit https://www.isc.org/software/dhcp/
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Starting Raise network interfaces...
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 ifup[356]: ifup: waiting for lock on /run/network/ifstate.ens4
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Listening on LPF/ens4/42:01:0a:a8:00:07
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Listening on LPF/ens4/42:01:0a:a8:00:07
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: Sending on LPF/ens4/42:01:0a:a8:00:07
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: Sending on LPF/ens4/42:01:0a:a8:00:07
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 7
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.400657] NET: Registered PF_NETLINK/PF_ROUTE protocol family
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 7
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.408289] audit: initializing netlink subsys (disabled)
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPOFFER of 10.168.0.7 from 169.254.169.254
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPOFFER of 10.168.0.7 from 169.254.169.254
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPREQUEST for 10.168.0.7 on ens4 to 255.255.255.255 port 67
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPREQUEST for 10.168.0.7 on ens4 to 255.255.255.255 port 67
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 dhclient[354]: DHCPACK of 10.168.0.7 from 169.254.169.254
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[354]: DHCPACK of 10.168.0.7 from 169.254.169.254
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.549954] NetLabel: Initializing
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.550736] NetLabel: domain hash size = 128
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.551480] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.552303] NetLabel: unlabeled traffic allowed by default
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.570445] NET: Registered PF_INET protocol family
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.586842] NET: Registered PF_UNIX/PF_LOCAL protocol family
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.587916] NET: Registered PF_XDP protocol family
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.865585] NET: Registered PF_INET6 protocol family
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 kernel: [ 0.872235] NET: Registered PF_PACKET protocol family
rnel: [ 1.153962] virtio_net virtio1 ens4: renamed from eth0
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 sh[474]: ens4=ens4
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Finished Raise network interfaces.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Reached target Network.
Aug 13 22:44:15 build-sid-newkernel-2022-08-13t22-41 systemd[1]: Reached target Network is Online.
rebooting into the new kernel:
[ 0.475837] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.476558] audit: initializing netlink subsys (disabled)
[ 0.630598] NetLabel: Initializing
[ 0.631503] NetLabel: domain hash size = 128
[ 0.632409] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 0.632515] NetLabel: unlabeled traffic allowed by default
[ 0.654654] NET: Registered PF_INET protocol family
[ 0.672514] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.871362] Initializing XFRM netlink socket
[ 0.872171] NET: Registered PF_INET6 protocol family
[ 0.875791] NET: Registered PF_PACKET protocol family
[ 0.876932] 9pnet: Installing 9P2000 support
[ 0.887570] printk: console [netcon0] enabled
[ 0.888339] netconsole: network logging started
[ 0.943112] virtio_net virtio1 enp0s4: renamed from eth0
Starting Raise network interfaces...
[ OK ] Found device Virtio network device.
[ 1.876517] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s4: link becomes ready
Aug 13 22:51:16 debian systemd[1]: Starting Raise network interfaces...
Aug 13 22:51:16 debian dhclient[349]: Internet Systems Consortium DHCP Client 4.4.3
Aug 13 22:51:16 debian ifup[349]: Internet Systems Consortium DHCP Client 4.4.3
Aug 13 22:51:16 debian ifup[349]: Copyright 2004-2022 Internet Systems Consortium.
Aug 13 22:51:16 debian ifup[349]: For info, please visit https://www.isc.org/software/dhcp/
Aug 13 22:51:16 debian dhclient[349]: Copyright 2004-2022 Internet Systems Consortium.
Aug 13 22:51:16 debian dhclient[349]: For info, please visit https://www.isc.org/software/dhcp/
Aug 13 22:51:16 debian kernel: [ 0.475837] NET: Registered PF_NETLINK/PF_ROUTE protocol family
Aug 13 22:51:16 debian kernel: [ 0.476558] audit: initializing netlink subsys (disabled)
Aug 13 22:51:16 debian systemd[1]: Found device Virtio network device.
Aug 13 22:51:16 debian ifup[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 6
Aug 13 22:51:16 debian dhclient[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 6
Aug 13 22:51:16 debian sh[356]: ifup: waiting for lock on /run/network/ifstate.enp0s4
Aug 13 22:51:16 debian kernel: [ 0.630598] NetLabel: Initializing
Aug 13 22:51:16 debian kernel: [ 0.631503] NetLabel: domain hash size = 128
Aug 13 22:51:16 debian kernel: [ 0.632409] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
Aug 13 22:51:16 debian kernel: [ 0.632515] NetLabel: unlabeled traffic allowed by default
Aug 13 22:51:16 debian kernel: [ 0.654654] NET: Registered PF_INET protocol family
Aug 13 22:51:16 debian kernel: [ 0.672514] NET: Registered PF_UNIX/PF_LOCAL protocol family
Aug 13 22:51:16 debian kernel: [ 0.871362] Initializing XFRM netlink socket
Aug 13 22:51:16 debian kernel: [ 0.872171] NET: Registered PF_INET6 protocol family
Aug 13 22:51:16 debian kernel: [ 0.875791] NET: Registered PF_PACKET protocol family
Aug 13 22:51:16 debian kernel: [ 0.876932] 9pnet: Installing 9P2000 support
Aug 13 22:51:16 debian kernel: [ 0.887570] printk: console [netcon0] enabled
Aug 13 22:51:16 debian kernel: [ 0.888339] netconsole: network logging started
Aug 13 22:51:16 debian kernel: [ 0.943112] virtio_net virtio1 enp0s4: renamed from eth0
Aug 13 22:51:16 debian kernel: [ 1.876517] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s4: link becomes ready
[ *** ] A start job is running for Raise network interfaces (6s / 5min)
Aug 13 22:51:22 debian dhclient[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 13
[*** ] A start job is running for Raise network interfaces (19s / 5min)
Aug 13 22:51:35 debian dhclient[349]: DHCPDISCOVER on enp0s4 to 255.255.255.255 port 67 interval 14
[*** ] A start job is running for Raise network interfaces (33s / 5min)
...
Greetings,
Andres Freund
[1] https://github.com/anarazel/pg-vm-images/blob/main/packer/linux_debian.pkr.hcl#L225
^ permalink raw reply
* [PATCH] checkpatch: Add kmap and kmap_atomic to the deprecated list
From: ira.weiny @ 2022-08-13 22:00 UTC (permalink / raw)
To: Andy Whitcroft, Joe Perches
Cc: Ira Weiny, Thomas Gleixner, Fabio M . De Francesco, Andrew Morton,
linux-kernel, linux-snps-arc, linux-arm-kernel, linux-csky,
loongarch, linux-mips, linuxppc-dev, linux-riscv, linux-sh,
sparclinux, linux-um, x86, linux-xtensa, keyrings, linux-ide,
linux-block, linux-crypto, linux-media, linux-edac,
linux1394-devel, dri-devel, dm-devel, linux-raid, linux-mmc,
linux-rdma, linux-mtd, netdev, nvdimm, linux-nvme, linux-scsi,
virtualization, linux-fsdevel, kgdb-bugreport, iommu, bpf, kvm
From: Ira Weiny <ira.weiny@intel.com>
kmap() and kmap_atomic() are being deprecated in favor of
kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead
as mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when
the kmap’s pool wraps and it might block when the mapping space is fully
utilized until a slot becomes available.
kmap_local_page() is safe from any context and is therefore redundant
with kmap_atomic() with the exception of any pagefault or preemption
disable requirements. However, using kmap_atomic() for these side
effects makes the code less clear. So any requirement for pagefault or
preemption disable should be made explicitly.
With kmap_local_page() the mappings are per thread, CPU local, can take
page faults, and can be called from any context (including interrupts).
It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
the tasks can be preempted and, when they are scheduled to run again,
the kernel virtual addresses are restored.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Suggested-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Suggested by credits.
Thomas: Idea to keep from growing more kmap/kmap_atomic calls.
Fabio: Stole some of his boiler plate commit message.
Notes on tree-wide conversions:
I've cc'ed mailing lists for subsystems which currently contains either kmap()
or kmap_atomic() calls. As some of you already know Fabio and I have been
working through converting kmap() calls to kmap_local_page(). But there is a
lot more work to be done. Help from the community is always welcome,
especially with kmap_atomic() conversions. To keep from stepping on each
others toes I've created a spreadsheet of the current calls[1]. Please let me
or Fabio know if you plan on tacking one of the conversions so we can mark it
off the list.
[1] https://docs.google.com/spreadsheets/d/1i_ckZ10p90bH_CkxD2bYNi05S2Qz84E2OFPv8zq__0w/edit#gid=1679714357
---
scripts/checkpatch.pl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 79e759aac543..9ff219e0a9d5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -807,6 +807,8 @@ our %deprecated_apis = (
"rcu_barrier_sched" => "rcu_barrier",
"get_state_synchronize_sched" => "get_state_synchronize_rcu",
"cond_synchronize_sched" => "cond_synchronize_rcu",
+ "kmap" => "kmap_local_page",
+ "kmap_atomic" => "kmap_local_page",
);
#Create a search pattern for all these strings to speed up a loop below
base-commit: 4a9350597aff50bbd0f4b80ccf49d2e02d1111f5
--
2.35.3
^ permalink raw reply related
* [PATCH] net: sfp: use simplified HWMON_CHANNEL_INFO macro
From: Beniamin Sandu @ 2022-08-13 20:46 UTC (permalink / raw)
To: linux, andrew, hkallweit1, davem, edumazet, kuba, pabeni
Cc: netdev, linux-kernel, Beniamin Sandu
This makes the code look cleaner and easier to read.
Signed-off-by: Beniamin Sandu <beniaminsandu@gmail.com>
---
drivers/net/phy/sfp.c | 121 +++++++++++++-----------------------------
1 file changed, 38 insertions(+), 83 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 63f90fe9a4d2..a12f7b599da2 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1195,90 +1195,45 @@ static const struct hwmon_ops sfp_hwmon_ops = {
.read_string = sfp_hwmon_read_string,
};
-static u32 sfp_hwmon_chip_config[] = {
- HWMON_C_REGISTER_TZ,
- 0,
-};
-
-static const struct hwmon_channel_info sfp_hwmon_chip = {
- .type = hwmon_chip,
- .config = sfp_hwmon_chip_config,
-};
-
-static u32 sfp_hwmon_temp_config[] = {
- HWMON_T_INPUT |
- HWMON_T_MAX | HWMON_T_MIN |
- HWMON_T_MAX_ALARM | HWMON_T_MIN_ALARM |
- HWMON_T_CRIT | HWMON_T_LCRIT |
- HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM |
- HWMON_T_LABEL,
- 0,
-};
-
-static const struct hwmon_channel_info sfp_hwmon_temp_channel_info = {
- .type = hwmon_temp,
- .config = sfp_hwmon_temp_config,
-};
-
-static u32 sfp_hwmon_vcc_config[] = {
- HWMON_I_INPUT |
- HWMON_I_MAX | HWMON_I_MIN |
- HWMON_I_MAX_ALARM | HWMON_I_MIN_ALARM |
- HWMON_I_CRIT | HWMON_I_LCRIT |
- HWMON_I_CRIT_ALARM | HWMON_I_LCRIT_ALARM |
- HWMON_I_LABEL,
- 0,
-};
-
-static const struct hwmon_channel_info sfp_hwmon_vcc_channel_info = {
- .type = hwmon_in,
- .config = sfp_hwmon_vcc_config,
-};
-
-static u32 sfp_hwmon_bias_config[] = {
- HWMON_C_INPUT |
- HWMON_C_MAX | HWMON_C_MIN |
- HWMON_C_MAX_ALARM | HWMON_C_MIN_ALARM |
- HWMON_C_CRIT | HWMON_C_LCRIT |
- HWMON_C_CRIT_ALARM | HWMON_C_LCRIT_ALARM |
- HWMON_C_LABEL,
- 0,
-};
-
-static const struct hwmon_channel_info sfp_hwmon_bias_channel_info = {
- .type = hwmon_curr,
- .config = sfp_hwmon_bias_config,
-};
-
-static u32 sfp_hwmon_power_config[] = {
- /* Transmit power */
- HWMON_P_INPUT |
- HWMON_P_MAX | HWMON_P_MIN |
- HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
- HWMON_P_CRIT | HWMON_P_LCRIT |
- HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
- HWMON_P_LABEL,
- /* Receive power */
- HWMON_P_INPUT |
- HWMON_P_MAX | HWMON_P_MIN |
- HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
- HWMON_P_CRIT | HWMON_P_LCRIT |
- HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
- HWMON_P_LABEL,
- 0,
-};
-
-static const struct hwmon_channel_info sfp_hwmon_power_channel_info = {
- .type = hwmon_power,
- .config = sfp_hwmon_power_config,
-};
-
static const struct hwmon_channel_info *sfp_hwmon_info[] = {
- &sfp_hwmon_chip,
- &sfp_hwmon_vcc_channel_info,
- &sfp_hwmon_temp_channel_info,
- &sfp_hwmon_bias_channel_info,
- &sfp_hwmon_power_channel_info,
+ HWMON_CHANNEL_INFO(chip,
+ HWMON_C_REGISTER_TZ),
+ HWMON_CHANNEL_INFO(in,
+ HWMON_I_INPUT |
+ HWMON_I_MAX | HWMON_I_MIN |
+ HWMON_I_MAX_ALARM | HWMON_I_MIN_ALARM |
+ HWMON_I_CRIT | HWMON_I_LCRIT |
+ HWMON_I_CRIT_ALARM | HWMON_I_LCRIT_ALARM |
+ HWMON_I_LABEL),
+ HWMON_CHANNEL_INFO(temp,
+ HWMON_T_INPUT |
+ HWMON_T_MAX | HWMON_T_MIN |
+ HWMON_T_MAX_ALARM | HWMON_T_MIN_ALARM |
+ HWMON_T_CRIT | HWMON_T_LCRIT |
+ HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM |
+ HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(curr,
+ HWMON_C_INPUT |
+ HWMON_C_MAX | HWMON_C_MIN |
+ HWMON_C_MAX_ALARM | HWMON_C_MIN_ALARM |
+ HWMON_C_CRIT | HWMON_C_LCRIT |
+ HWMON_C_CRIT_ALARM | HWMON_C_LCRIT_ALARM |
+ HWMON_C_LABEL),
+ HWMON_CHANNEL_INFO(power,
+ /* Transmit power */
+ HWMON_P_INPUT |
+ HWMON_P_MAX | HWMON_P_MIN |
+ HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
+ HWMON_P_CRIT | HWMON_P_LCRIT |
+ HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
+ HWMON_P_LABEL,
+ /* Receive power */
+ HWMON_P_INPUT |
+ HWMON_P_MAX | HWMON_P_MIN |
+ HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
+ HWMON_P_CRIT | HWMON_P_LCRIT |
+ HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
+ HWMON_P_LABEL),
NULL,
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v1 07/10] net: dsa: microchip: warn about not supported synclko properties on KSZ9893 chips
From: Andrew Lunn @ 2022-08-13 20:42 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Woojung Huh, Florian Fainelli, netdev, linux-kernel,
Vivien Didelot, UNGLinuxDriver, Eric Dumazet, Paolo Abeni, kernel,
Jakub Kicinski, Vladimir Oltean, David S. Miller
In-Reply-To: <20220813161850.GB12534@pengutronix.de>
On Sat, Aug 13, 2022 at 06:18:50PM +0200, Oleksij Rempel wrote:
> On Sat, Aug 13, 2022 at 05:11:45PM +0200, Andrew Lunn wrote:
> > On Sat, Aug 13, 2022 at 04:32:15PM +0200, Oleksij Rempel wrote:
> > > On Fri, Aug 05, 2022 at 04:42:34PM +0300, Vladimir Oltean wrote:
> > > > On Fri, Aug 05, 2022 at 01:56:01PM +0200, Oleksij Rempel wrote:
> > > > > Hm, if we will have any random not support OF property in the switch
> > > > > node. We won't be able to warn about it anyway. So, if it is present
> > > > > but not supported, we will just ignore it.
> > > > >
> > > > > I'll drop this patch.
> > > >
> > > > To continue, I think the right way to go about this is to edit the
> > > > dt-schema to say that these properties are only applicable to certain
> > > > compatible strings, rather than for all. Then due to the
> > > > "unevaluatedProperties: false", you'd get the warnings you want, at
> > > > validation time.
> > >
> > > Hm, with "unevaluatedProperties: false" i have no warnings. Even if I
> > > create examples with random strings as properties. Are there some new
> > > json libraries i should use?
> >
> > Try
> >
> > additionalProperties: False
>
> Yes, it works. But in this case I'll do more changes. Just wont to make
> sure I do not fix not broken things.
I've been working on converting some old SoCs bindings from .txt to
.yaml. My observations is that the yaml is sometimes more restrictive
than what the drivers actually imposes. So you might need to change
perfectly working .dts files to get it warning free. Or you just
accept the warnings and move on. At lot will depend on the number of
warnings and how easy it is to see real problems mixed in with
warnings you never intend to fix.
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next 13/15] mm, memcg: Add new helper get_obj_cgroup_from_cgroup
From: Roman Gushchin @ 2022-08-13 18:30 UTC (permalink / raw)
To: Yafang Shao
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau,
Song Liu, Yonghong Song, john fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, jolsa, Johannes Weiner, Michal Hocko,
Shakeel Butt, Muchun Song, Andrew Morton, netdev, bpf, Linux MM
In-Reply-To: <CALOAHbBh4=yxX5c2_TK8-uf14KKg=Vp1NoHAEZGxS2wAxCnZWA@mail.gmail.com>
On Sat, Aug 13, 2022 at 07:56:54AM +0800, Yafang Shao wrote:
> On Sat, Aug 13, 2022 at 1:40 AM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> > On Fri, Aug 12, 2022 at 08:35:19AM +0800, Yafang Shao wrote:
> > > On Fri, Aug 12, 2022 at 12:16 AM Roman Gushchin
> > > <roman.gushchin@linux.dev> wrote:
> > > >
> > > > On Wed, Aug 10, 2022 at 03:18:38PM +0000, Yafang Shao wrote:
> > > > > Introduce new helper get_obj_cgroup_from_cgroup() to get obj_cgroup from
> > > > > a specific cgroup.
> > > > >
> > > > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > > > > ---
> > > > > include/linux/memcontrol.h | 1 +
> > > > > mm/memcontrol.c | 41 +++++++++++++++++++++++++++++++++++++++++
> > > > > 2 files changed, 42 insertions(+)
> > > > >
> > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > > > > index 2f0a611..901a921 100644
> > > > > --- a/include/linux/memcontrol.h
> > > > > +++ b/include/linux/memcontrol.h
> > > > > @@ -1713,6 +1713,7 @@ static inline void set_shrinker_bit(struct mem_cgroup *memcg,
> > > > > int __memcg_kmem_charge_page(struct page *page, gfp_t gfp, int order);
> > > > > void __memcg_kmem_uncharge_page(struct page *page, int order);
> > > > >
> > > > > +struct obj_cgroup *get_obj_cgroup_from_cgroup(struct cgroup *cgrp);
> > > > > struct obj_cgroup *get_obj_cgroup_from_current(void);
> > > > > struct obj_cgroup *get_obj_cgroup_from_page(struct page *page);
> > > > >
> > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > > index 618c366..762cffa 100644
> > > > > --- a/mm/memcontrol.c
> > > > > +++ b/mm/memcontrol.c
> > > > > @@ -2908,6 +2908,47 @@ static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg)
> > > > > return objcg;
> > > > > }
> > > > >
> > > > > +static struct obj_cgroup *get_obj_cgroup_from_memcg(struct mem_cgroup *memcg)
> > > > > +{
> > > > > + struct obj_cgroup *objcg;
> > > > > +
> > > > > + if (memcg_kmem_bypass())
> > > > > + return NULL;
> > > > > +
> > > > > + rcu_read_lock();
> > > > > + objcg = __get_obj_cgroup_from_memcg(memcg);
> > > > > + rcu_read_unlock();
> > > > > + return objcg;
> > > >
> > > > This code doesn't make sense to me. What does rcu read lock protect here?
> > >
> > > To protect rcu_dereference(memcg->objcg);.
> > > Doesn't it need the read rcu lock ?
> >
> > No, it's not how rcu works. Please, take a look at the docs here:
> > https://docs.kernel.org/RCU/whatisRCU.html#whatisrcu .
> > In particular, it describes this specific case very well.
> >
> > In 2 words, you don't protect the rcu_dereference() call, you protect the pointer
>
> I just copied and pasted rcu_dereference(memcg->objcg) there to make it clear.
> Actually it protects memcg->objcg, doesn't it ?
>
> > you get, cause it's valid only inside the rcu read section. After rcu_read_unlock()
> > it might point at a random data, because the protected object can be already freed.
> >
>
> Are you sure?
> Can't the obj_cgroup_tryget(objcg) prevent it from being freed ?
Ok, now I see where it comes from. You copy-pasted it from get_obj_cgroup_from_current()?
There rcu read lock section protects memcg, not objcg.
In your case you don't need it, because memcg is passed as a parameter to the function,
so it's the duty of the caller to ensure the lifetime of memcg.
Thanks!
^ permalink raw reply
* Re: [WIP v2] igc: fix deadlock caused by taking RTNL in RPM resume path
From: James Hogan @ 2022-08-13 17:18 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: Paul Menzel, Tony Nguyen, Jesse Brandeburg, netdev,
intel-wired-lan, Sasha Neftin, Aleksandr Loktionov
In-Reply-To: <87o7wpxb1m.fsf@intel.com>
On Saturday, 13 August 2022 01:05:41 BST Vinicius Costa Gomes wrote:
> James Hogan <jhogan@kernel.org> writes:
> > On Thursday, 11 August 2022 21:25:24 BST Vinicius Costa Gomes wrote:
> >> It was reported a RTNL deadlock in the igc driver that was causing
> >> problems during suspend/resume.
> >>
> >> The solution is similar to commit ac8c58f5b535 ("igb: fix deadlock
> >> caused by taking RTNL in RPM resume path").
> >>
> >> Reported-by: James Hogan <jhogan@kernel.org>
> >> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> >> ---
> >> Sorry for the noise earlier, my kernel config didn't have runtime PM
> >> enabled.
> >
> > Thanks for looking into this.
> >
> > This is identical to the patch I've been running for the last week. The
> > deadlock is avoided, however I now occasionally see an assertion from
> > netif_set_real_num_tx_queues due to the lock not being taken in some cases
> > via the runtime_resume path, and a suspicious rcu_dereference_protected()
> > warning (presumably due to the same issue of the lock not being taken).
> > See here for details:
> > https://lore.kernel.org/netdev/4765029.31r3eYUQgx@saruman/
>
> Oh, sorry. I missed the part that the rtnl assert splat was already
> using similar/identical code to what I got/copied from igb.
>
> So what this seems to be telling us is that the "fix" from igb is only
> hiding the issue,
I suppose the patch just changes the assumption from "lock will never be held
on runtime resume path" (incorrect, deadlock) to "lock will always be held on
runtime resume path" (also incorrect, probably racy).
> and we would need to remove the need for taking the
> RTNL for the suspend/resume paths in igc and igb? (as someone else said
> in that igb thread, iirc)
(I'll defer to others on this. I'm pretty unfamiliar with networking code and
this particular lock.)
Cheers
James
^ permalink raw reply
* Re: [PATCH v2] wifi: cfg80211: Fix UAF in ieee80211_scan_rx()
From: Siddh Raman Pant @ 2022-08-13 16:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: greg kh, johannes berg, david s. miller, eric dumazet,
paolo abeni, netdev, syzbot+6cb476b7c69916a0caca, linux-wireless,
linux-kernel, syzbot+f9acff9bf08a845f225d,
syzbot+9250865a55539d384347, linux-kernel-mentees
In-Reply-To: <20220812122509.281f0536@kernel.org>
On Sat, 13 Aug 2022 00:55:09 +0530 Jakub Kicinski wrote:
> Similarly to Greg, I'm not very familiar with the code base but one
> sure way to move things forward would be to point out a commit which
> broke things and put it in a Fixes tag. Much easier to validate a fix
> by looking at where things went wrong.
Thanks, I now looked at some history.
The following commit on 28 Sep 2020 put the kfree call before NULLing:
c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning")
The following commit on 19 Nov 2014 introduces RCU:
6ea0a69ca21b ("mac80211: rcu-ify scan and scheduled scan request pointers")
The kfree call wasn't "rcu-ified" in this commit, and neither were
RCU heads added.
The following commit on 18 Dec 2014 added RCU head for sched_scan_req:
31a60ed1e95a ("nl80211: Convert sched_scan_req pointer to RCU pointer")
It seems a similar thing might not have been done for scan_req, but I
could have also missed commits.
So what should go into the fixes tag, if any? Probably 6ea0a69ca21b?
Also, I probably should use RCU_INIT_POINTER in this patch. Or should
I make a patch somewhat like 31a60ed1e95a?
Thanks,
Siddh
^ permalink raw reply
* Re: [PATCH net-next v1 07/10] net: dsa: microchip: warn about not supported synclko properties on KSZ9893 chips
From: Oleksij Rempel @ 2022-08-13 16:18 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, Florian Fainelli, netdev, linux-kernel,
Vivien Didelot, UNGLinuxDriver, Eric Dumazet, Paolo Abeni, kernel,
Jakub Kicinski, Vladimir Oltean, David S. Miller
In-Reply-To: <Yve/MSMc/4klJPFL@lunn.ch>
On Sat, Aug 13, 2022 at 05:11:45PM +0200, Andrew Lunn wrote:
> On Sat, Aug 13, 2022 at 04:32:15PM +0200, Oleksij Rempel wrote:
> > On Fri, Aug 05, 2022 at 04:42:34PM +0300, Vladimir Oltean wrote:
> > > On Fri, Aug 05, 2022 at 01:56:01PM +0200, Oleksij Rempel wrote:
> > > > Hm, if we will have any random not support OF property in the switch
> > > > node. We won't be able to warn about it anyway. So, if it is present
> > > > but not supported, we will just ignore it.
> > > >
> > > > I'll drop this patch.
> > >
> > > To continue, I think the right way to go about this is to edit the
> > > dt-schema to say that these properties are only applicable to certain
> > > compatible strings, rather than for all. Then due to the
> > > "unevaluatedProperties: false", you'd get the warnings you want, at
> > > validation time.
> >
> > Hm, with "unevaluatedProperties: false" i have no warnings. Even if I
> > create examples with random strings as properties. Are there some new
> > json libraries i should use?
>
> Try
>
> additionalProperties: False
Yes, it works. But in this case I'll do more changes. Just wont to make
sure I do not fix not broken things.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2 7/7] dt-bindings: net: dsa: mediatek,mt7530: update binding description
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
In-Reply-To: <20220813154415.349091-1-arinc.unal@arinc9.com>
Update the description of the binding.
- Describe the switches, which SoCs they are in, or if they are standalone.
- Explain the various ways of configuring MT7530's port 5.
- Remove phy-mode = "rgmii-txid" from description. Same code path is
followed for delayed rgmii and rgmii phy-mode on mtk_eth_soc.c.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
.../bindings/net/dsa/mediatek,mt7530.yaml | 97 ++++++++++++-------
1 file changed, 62 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index 530ef5a75a2f..cf6340d072df 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -13,41 +13,68 @@ maintainers:
- Sean Wang <sean.wang@mediatek.com>
description: |
- Port 5 of mt7530 and mt7621 switch is muxed between:
- 1. GMAC5: GMAC5 can interface with another external MAC or PHY.
- 2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC
- of the SOC. Used in many setups where port 0/4 becomes the WAN port.
- Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to
- GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not
- connected to external component!
-
- Port 5 modes/configurations:
- 1. Port 5 is disabled and isolated: An external phy can interface to the 2nd
- GMAC of the SOC.
- In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd
- GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC!
- 2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC.
- It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode
- and RGMII delay.
- 3. Port 5 is muxed to GMAC5 and can interface to an external phy.
- Port 5 becomes an extra switch port.
- Only works on platform where external phy TX<->RX lines are swapped.
- Like in the Ubiquiti ER-X-SFP.
- 4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port.
- Currently a 2nd CPU port is not supported by DSA code.
-
- Depending on how the external PHY is wired:
- 1. normal: The PHY can only connect to 2nd GMAC but not to the switch
- 2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as
- a ethernet port. But can't interface to the 2nd GMAC.
-
- Based on the DT the port 5 mode is configured.
-
- Driver tries to lookup the phy-handle of the 2nd GMAC of the master device.
- When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2.
- phy-mode must be set, see also example 2 below!
- * mt7621: phy-mode = "rgmii-txid";
- * mt7623: phy-mode = "rgmii";
+ There are two versions of MT7530, standalone and in a multi-chip module.
+
+ MT7530 is a part of the multi-chip module in MT7620AN, MT7620DA, MT7620DAN,
+ MT7620NN, MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs.
+
+ MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has got 10/100 PHYs
+ and the switch registers are directly mapped into SoC's memory map rather than
+ using MDIO. There is currently no support for this.
+
+ There is only the standalone version of MT7531.
+
+ Port 5 on MT7530 has got various ways of configuration.
+
+ For standalone MT7530:
+
+ - Port 5 can be used as a CPU port.
+
+ - PHY 0 or 4 of the switch can be muxed to connect to the gmac of the SoC
+ which port 5 is wired to. Usually used for connecting the wan port
+ directly to the CPU to achieve 2 Gbps routing in total.
+
+ The driver looks up the reg on the ethernet-phy node which the phy-handle
+ property refers to on the gmac node to mux the specified phy.
+
+ The driver requires the gmac of the SoC to have "mediatek,eth-mac" as the
+ compatible string and the reg must be 1. So, for now, only gmac1 of an
+ MediaTek SoC can benefit this. Banana Pi BPI-R2 suits this.
+ Check out example 5 for a similar configuration.
+
+ - Port 5 can be wired to an external phy. Port 5 becomes a DSA slave.
+ Check out example 7 for a similar configuration.
+
+ For multi-chip module MT7530:
+
+ - Port 5 can be used as a CPU port.
+
+ - PHY 0 or 4 of the switch can be muxed to connect to gmac1 of the SoC.
+ Usually used for connecting the wan port directly to the CPU to achieve 2
+ Gbps routing in total.
+
+ The driver looks up the reg on the ethernet-phy node which the phy-handle
+ property refers to on the gmac node to mux the specified phy.
+
+ For the MT7621 SoCs, rgmii2 group must be claimed with rgmii2 function.
+ Check out example 5.
+
+ - In case of an external phy wired to gmac1 of the SoC, port 5 must not be
+ enabled.
+
+ In case of muxing PHY 0 or 4, the external phy must not be enabled.
+
+ For the MT7621 SoCs, rgmii2 group must be claimed with rgmii2 function.
+ Check out example 6.
+
+ - Port 5 can be muxed to an external phy. Port 5 becomes a DSA slave.
+ The external phy must be wired TX to TX to gmac1 of the SoC for this to
+ work. Ubiquiti EdgeRouter X SFP is wired this way.
+
+ Muxing PHY 0 or 4 won't work when the external phy is connected TX to TX.
+
+ For the MT7621 SoCs, rgmii2 group must be claimed with gpio function.
+ Check out example 7.
properties:
compatible:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/7] dt-bindings: net: dsa: mediatek,mt7530: define phy-mode for each compatible
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
In-Reply-To: <20220813154415.349091-1-arinc.unal@arinc9.com>
Define acceptable phy-mode values for CPU port of each compatible device.
Remove relevant information from the description of the binding.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
.../bindings/net/dsa/mediatek,mt7530.yaml | 103 ++++++++++++++++--
1 file changed, 92 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index a27cb4fa490f..530ef5a75a2f 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -49,17 +49,6 @@ description: |
* mt7621: phy-mode = "rgmii-txid";
* mt7623: phy-mode = "rgmii";
- CPU-Ports need a phy-mode property:
- Allowed values on mt7530 and mt7621:
- - "rgmii"
- - "trgmii"
- On mt7531:
- - "1000base-x"
- - "2500base-x"
- - "rgmii"
- - "sgmii"
-
-
properties:
compatible:
oneOf:
@@ -177,6 +166,36 @@ allOf:
items:
- const: cpu
then:
+ allOf:
+ - if:
+ properties:
+ reg:
+ const: 5
+ then:
+ properties:
+ phy-mode:
+ enum:
+ - gmii
+ - mii
+ - rgmii
+
+ - if:
+ properties:
+ reg:
+ const: 6
+ then:
+ properties:
+ phy-mode:
+ enum:
+ - rgmii
+ - trgmii
+
+ properties:
+ reg:
+ enum:
+ - 5
+ - 6
+
required:
- phy-mode
@@ -206,6 +225,38 @@ allOf:
items:
- const: cpu
then:
+ allOf:
+ - if:
+ properties:
+ reg:
+ const: 5
+ then:
+ properties:
+ phy-mode:
+ enum:
+ - 1000base-x
+ - 2500base-x
+ - rgmii
+ - sgmii
+
+ - if:
+ properties:
+ reg:
+ const: 6
+ then:
+ properties:
+ phy-mode:
+ enum:
+ - 1000base-x
+ - 2500base-x
+ - sgmii
+
+ properties:
+ reg:
+ enum:
+ - 5
+ - 6
+
required:
- phy-mode
@@ -235,6 +286,36 @@ allOf:
items:
- const: cpu
then:
+ allOf:
+ - if:
+ properties:
+ reg:
+ const: 5
+ then:
+ properties:
+ phy-mode:
+ enum:
+ - gmii
+ - mii
+ - rgmii
+
+ - if:
+ properties:
+ reg:
+ const: 6
+ then:
+ properties:
+ phy-mode:
+ enum:
+ - rgmii
+ - trgmii
+
+ properties:
+ reg:
+ enum:
+ - 5
+ - 6
+
required:
- phy-mode
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/7] dt-bindings: net: dsa: mediatek,mt7530: remove unnecesary lines
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
In-Reply-To: <20220813154415.349091-1-arinc.unal@arinc9.com>
Remove unnecessary lines as they are already included from the referred
dsa.yaml.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
.../bindings/net/dsa/mediatek,mt7530.yaml | 27 -------------------
1 file changed, 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index ff51a2f6875f..a27cb4fa490f 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -162,15 +162,8 @@ allOf:
patternProperties:
"^(ethernet-)?ports$":
- type: object
-
patternProperties:
"^(ethernet-)?port@[0-9]+$":
- type: object
- description: Ethernet switch ports
-
- unevaluatedProperties: false
-
properties:
reg:
description:
@@ -178,7 +171,6 @@ allOf:
0 to 5 for user ports.
allOf:
- - $ref: dsa-port.yaml#
- if:
properties:
label:
@@ -186,7 +178,6 @@ allOf:
- const: cpu
then:
required:
- - reg
- phy-mode
- if:
@@ -200,15 +191,8 @@ allOf:
patternProperties:
"^(ethernet-)?ports$":
- type: object
-
patternProperties:
"^(ethernet-)?port@[0-9]+$":
- type: object
- description: Ethernet switch ports
-
- unevaluatedProperties: false
-
properties:
reg:
description:
@@ -216,7 +200,6 @@ allOf:
0 to 5 for user ports.
allOf:
- - $ref: dsa-port.yaml#
- if:
properties:
label:
@@ -224,7 +207,6 @@ allOf:
- const: cpu
then:
required:
- - reg
- phy-mode
- if:
@@ -238,15 +220,8 @@ allOf:
patternProperties:
"^(ethernet-)?ports$":
- type: object
-
patternProperties:
"^(ethernet-)?port@[0-9]+$":
- type: object
- description: Ethernet switch ports
-
- unevaluatedProperties: false
-
properties:
reg:
description:
@@ -254,7 +229,6 @@ allOf:
0 to 5 for user ports.
allOf:
- - $ref: dsa-port.yaml#
- if:
properties:
label:
@@ -262,7 +236,6 @@ allOf:
- const: cpu
then:
required:
- - reg
- phy-mode
unevaluatedProperties: false
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/7] dt-bindings: net: dsa: mediatek,mt7530: define port binding per compatible
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
In-Reply-To: <20220813154415.349091-1-arinc.unal@arinc9.com>
Define DSA port binding under each compatible device as each device
requires different values for certain properties.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
.../bindings/net/dsa/mediatek,mt7530.yaml | 116 +++++++++++++-----
1 file changed, 87 insertions(+), 29 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index cc87f48d4d07..ff51a2f6875f 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -130,35 +130,6 @@ properties:
ethsys.
maxItems: 1
-patternProperties:
- "^(ethernet-)?ports$":
- type: object
-
- patternProperties:
- "^(ethernet-)?port@[0-9]+$":
- type: object
- description: Ethernet switch ports
-
- unevaluatedProperties: false
-
- properties:
- reg:
- description:
- Port address described must be 5 or 6 for CPU port and from 0
- to 5 for user ports.
-
- allOf:
- - $ref: dsa-port.yaml#
- - if:
- properties:
- label:
- items:
- - const: cpu
- then:
- required:
- - reg
- - phy-mode
-
required:
- compatible
- reg
@@ -189,6 +160,35 @@ allOf:
- core-supply
- io-supply
+ patternProperties:
+ "^(ethernet-)?ports$":
+ type: object
+
+ patternProperties:
+ "^(ethernet-)?port@[0-9]+$":
+ type: object
+ description: Ethernet switch ports
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ Port address described must be 5 or 6 for CPU port and from
+ 0 to 5 for user ports.
+
+ allOf:
+ - $ref: dsa-port.yaml#
+ - if:
+ properties:
+ label:
+ items:
+ - const: cpu
+ then:
+ required:
+ - reg
+ - phy-mode
+
- if:
properties:
compatible:
@@ -198,6 +198,35 @@ allOf:
properties:
mediatek,mcm: false
+ patternProperties:
+ "^(ethernet-)?ports$":
+ type: object
+
+ patternProperties:
+ "^(ethernet-)?port@[0-9]+$":
+ type: object
+ description: Ethernet switch ports
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ Port address described must be 5 or 6 for CPU port and from
+ 0 to 5 for user ports.
+
+ allOf:
+ - $ref: dsa-port.yaml#
+ - if:
+ properties:
+ label:
+ items:
+ - const: cpu
+ then:
+ required:
+ - reg
+ - phy-mode
+
- if:
properties:
compatible:
@@ -207,6 +236,35 @@ allOf:
required:
- mediatek,mcm
+ patternProperties:
+ "^(ethernet-)?ports$":
+ type: object
+
+ patternProperties:
+ "^(ethernet-)?port@[0-9]+$":
+ type: object
+ description: Ethernet switch ports
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ Port address described must be 5 or 6 for CPU port and from
+ 0 to 5 for user ports.
+
+ allOf:
+ - $ref: dsa-port.yaml#
+ - if:
+ properties:
+ label:
+ items:
+ - const: cpu
+ then:
+ required:
+ - reg
+ - phy-mode
+
unevaluatedProperties: false
examples:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/7] dt-bindings: net: dsa: mediatek,mt7530: update examples
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
In-Reply-To: <20220813154415.349091-1-arinc.unal@arinc9.com>
Update the examples on the binding.
- Add examples which include a wide variation of configurations.
- Make example comments YAML comment instead of DT binding comment.
- Define examples from platform to make the bindings clearer.
- Add interrupt controller to the examples. Include header file for
interrupt.
- Change reset line for MT7621 examples.
- Pretty formatting for the examples.
- Change switch reg to 0.
- Change port labels to fit the example, change port 4 label to wan.
- Change ethernet-ports to ports.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
.../bindings/net/dsa/mediatek,mt7530.yaml | 663 +++++++++++++-----
1 file changed, 502 insertions(+), 161 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index 4c99266ce82a..cc87f48d4d07 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -210,144 +210,374 @@ allOf:
unevaluatedProperties: false
examples:
+ # Example 1: Standalone MT7530
- |
#include <dt-bindings/gpio/gpio.h>
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- switch@0 {
- compatible = "mediatek,mt7530";
- reg = <0>;
-
- core-supply = <&mt6323_vpa_reg>;
- io-supply = <&mt6323_vemc3v3_reg>;
- reset-gpios = <&pio 33 GPIO_ACTIVE_HIGH>;
-
- ethernet-ports {
+
+ platform {
+ ethernet {
+ mdio {
#address-cells = <1>;
#size-cells = <0>;
- port@0 {
+
+ switch@0 {
+ compatible = "mediatek,mt7530";
reg = <0>;
- label = "lan0";
- };
- port@1 {
- reg = <1>;
- label = "lan1";
- };
+ reset-gpios = <&pio 33 0>;
- port@2 {
- reg = <2>;
- label = "lan2";
- };
+ core-supply = <&mt6323_vpa_reg>;
+ io-supply = <&mt6323_vemc3v3_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
- port@3 {
- reg = <3>;
- label = "lan3";
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
};
+ };
+ };
+ };
- port@4 {
- reg = <4>;
- label = "wan";
+ # Example 2: MT7530 in MT7623AI SoC
+ - |
+ #include <dt-bindings/reset/mt2701-resets.h>
+
+ platform {
+ ethernet {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "mediatek,mt7530";
+ reg = <0>;
+
+ mediatek,mcm;
+ resets = <ðsys MT2701_ETHSYS_MCM_RST>;
+ reset-names = "mcm";
+
+ core-supply = <&mt6323_vpa_reg>;
+ io-supply = <&mt6323_vemc3v3_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "trgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
};
+ };
+ };
+ };
+
+ # Example 3: Standalone MT7531
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ platform {
+ ethernet {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "mediatek,mt7531";
+ reg = <0>;
+
+ reset-gpios = <&pio 54 0>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&pio>;
+ interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
- port@6 {
- reg = <6>;
- label = "cpu";
- ethernet = <&gmac0>;
- phy-mode = "trgmii";
- fixed-link {
- speed = <1000>;
- full-duplex;
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "2500base-x";
+
+ fixed-link {
+ speed = <2500>;
+ full-duplex;
+ pause;
+ };
+ };
};
};
};
};
};
+ # Example 4: MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs
- |
- //Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
-
- ethernet {
- #address-cells = <1>;
- #size-cells = <0>;
- gmac0: mac@0 {
- compatible = "mediatek,eth-mac";
- reg = <0>;
- phy-mode = "rgmii";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- pause;
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/reset/mt7621-reset.h>
+
+ platform {
+ ethernet {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "mediatek,mt7621";
+ reg = <0>;
+
+ mediatek,mcm;
+ resets = <&sysc MT7621_RST_MCM>;
+ reset-names = "mcm";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SHARED 23 IRQ_TYPE_LEVEL_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "trgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
};
};
+ };
- gmac1: mac@1 {
- compatible = "mediatek,eth-mac";
- reg = <1>;
- phy-mode = "rgmii-txid";
- phy-handle = <&phy4>;
+ # Example 5: MT7621: mux MT7530's phy4 to SoC's gmac1
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/reset/mt7621-reset.h>
+
+ platform {
+ pinctrl {
+ example5_rgmii2_pins: rgmii2-pins {
+ pinmux {
+ groups = "rgmii2";
+ function = "rgmii2";
+ };
+ };
};
- mdio: mdio-bus {
+ ethernet {
#address-cells = <1>;
#size-cells = <0>;
- /* Internal phy */
- phy4: ethernet-phy@4 {
- reg = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&example5_rgmii2_pins>;
+
+ mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+
+ phy-mode = "rgmii";
+ phy-handle = <&example5_ethphy4>;
};
- mt7530: switch@1f {
- compatible = "mediatek,mt7621";
- reg = <0x1f>;
- mediatek,mcm;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- resets = <&rstctrl 2>;
- reset-names = "mcm";
+ /* MT7530's phy4 */
+ example5_ethphy4: ethernet-phy@4 {
+ reg = <4>;
+ };
- ethernet-ports {
- #address-cells = <1>;
- #size-cells = <0>;
+ switch@0 {
+ compatible = "mediatek,mt7621";
+ reg = <0>;
- port@0 {
- reg = <0>;
- label = "lan0";
- };
+ mediatek,mcm;
+ resets = <&sysc MT7621_RST_MCM>;
+ reset-names = "mcm";
- port@1 {
- reg = <1>;
- label = "lan1";
- };
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SHARED 23 IRQ_TYPE_LEVEL_HIGH>;
- port@2 {
- reg = <2>;
- label = "lan2";
- };
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
- port@3 {
- reg = <3>;
- label = "lan3";
- };
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
- /* Commented out. Port 4 is handled by 2nd GMAC.
- port@4 {
- reg = <4>;
- label = "lan4";
- };
- */
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
- port@6 {
- reg = <6>;
- label = "cpu";
- ethernet = <&gmac0>;
- phy-mode = "rgmii";
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
- fixed-link {
- speed = <1000>;
- full-duplex;
- pause;
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+
+ /* Commented out, phy4 is muxed to gmac1.
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+ */
+
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "trgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
};
};
};
@@ -355,87 +585,198 @@ examples:
};
};
+ # Example 6: MT7621: mux external phy to SoC's gmac1
- |
- //Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY.
-
- ethernet {
- #address-cells = <1>;
- #size-cells = <0>;
- gmac_0: mac@0 {
- compatible = "mediatek,eth-mac";
- reg = <0>;
- phy-mode = "rgmii";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- pause;
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/reset/mt7621-reset.h>
+
+ platform {
+ pinctrl {
+ example6_rgmii2_pins: rgmii2-pins {
+ pinmux {
+ groups = "rgmii2";
+ function = "rgmii2";
+ };
};
};
- mdio0: mdio-bus {
+ ethernet {
#address-cells = <1>;
#size-cells = <0>;
- /* External phy */
- ephy5: ethernet-phy@7 {
- reg = <7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&example6_rgmii2_pins>;
+
+ mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+
+ phy-mode = "rgmii";
+ phy-handle = <&example6_ethphy7>;
};
- switch@1f {
- compatible = "mediatek,mt7621";
- reg = <0x1f>;
- mediatek,mcm;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- resets = <&rstctrl 2>;
- reset-names = "mcm";
+ /* External PHY */
+ example6_ethphy7: ethernet-phy@7 {
+ reg = <7>;
+ phy-mode = "rgmii";
+ };
- ethernet-ports {
- #address-cells = <1>;
- #size-cells = <0>;
+ switch@0 {
+ compatible = "mediatek,mt7621";
+ reg = <0>;
- port@0 {
- reg = <0>;
- label = "lan0";
- };
+ mediatek,mcm;
+ resets = <&sysc MT7621_RST_MCM>;
+ reset-names = "mcm";
- port@1 {
- reg = <1>;
- label = "lan1";
- };
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SHARED 23 IRQ_TYPE_LEVEL_HIGH>;
- port@2 {
- reg = <2>;
- label = "lan2";
- };
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
- port@3 {
- reg = <3>;
- label = "lan3";
- };
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
- port@4 {
- reg = <4>;
- label = "lan4";
- };
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
- port@5 {
- reg = <5>;
- label = "lan5";
- phy-mode = "rgmii";
- phy-handle = <&ephy5>;
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "trgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
};
+ };
+ };
+ };
+ };
+
+ # Example 7: MT7621: mux external phy to MT7530's port 5
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/reset/mt7621-reset.h>
+
+ platform {
+ pinctrl {
+ example7_rgmii2_pins: rgmii2-pins {
+ pinmux {
+ groups = "rgmii2";
+ function = "gpio";
+ };
+ };
+ };
+
+ ethernet {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&example7_rgmii2_pins>;
- cpu_port0: port@6 {
- reg = <6>;
- label = "cpu";
- ethernet = <&gmac_0>;
- phy-mode = "rgmii";
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* External PHY */
+ example7_ethphy7: ethernet-phy@7 {
+ reg = <7>;
+ phy-mode = "rgmii";
+ };
+
+ switch@0 {
+ compatible = "mediatek,mt7621";
+ reg = <0>;
+
+ mediatek,mcm;
+ resets = <&sysc MT7621_RST_MCM>;
+ reset-names = "mcm";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SHARED 23 IRQ_TYPE_LEVEL_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "extphy";
+ phy-mode = "rgmii-txid";
+ phy-handle = <&example7_ethphy7>;
+ };
- fixed-link {
- speed = <1000>;
- full-duplex;
- pause;
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "trgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
};
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/7] dt-bindings: net: dsa: mediatek,mt7530: fix reset lines
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
In-Reply-To: <20220813154415.349091-1-arinc.unal@arinc9.com>
- Fix description of mediatek,mcm. mediatek,mcm is not used on MT7623NI.
- Add description for reset-gpios.
- Invalidate reset-gpios if mediatek,mcm is used.
- Invalidate mediatek,mcm if the compatible device is mediatek,mt7531.
- Require mediatek,mcm for the described MT7621 SoCs as the compatible
string is only used for MT7530 which is a part of the multi-chip module.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
.../bindings/net/dsa/mediatek,mt7530.yaml | 31 +++++++++++++++++--
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index edf48e917173..4c99266ce82a 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -110,11 +110,15 @@ properties:
mediatek,mcm:
type: boolean
description:
- if defined, indicates that either MT7530 is the part on multi-chip
- module belong to MT7623A has or the remotely standalone chip as the
- function MT7623N reference board provided for.
+ Used for MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs which the MT7530
+ switch is a part of the multi-chip module.
reset-gpios:
+ description:
+ GPIO to reset the switch. Use this if mediatek,mcm is not used.
+ This property is optional because some boards share the reset line with
+ other components which makes it impossible to probe the switch if the
+ reset line is used.
maxItems: 1
reset-names:
@@ -165,6 +169,9 @@ allOf:
required:
- mediatek,mcm
then:
+ properties:
+ reset-gpios: false
+
required:
- resets
- reset-names
@@ -182,6 +189,24 @@ allOf:
- core-supply
- io-supply
+ - if:
+ properties:
+ compatible:
+ items:
+ - const: mediatek,mt7531
+ then:
+ properties:
+ mediatek,mcm: false
+
+ - if:
+ properties:
+ compatible:
+ items:
+ - const: mediatek,mt7621
+ then:
+ required:
+ - mediatek,mcm
+
unevaluatedProperties: false
examples:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/7] dt-bindings: net: dsa: mediatek,mt7530: make trivial changes
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
In-Reply-To: <20220813154415.349091-1-arinc.unal@arinc9.com>
Make trivial changes on the binding.
- Update title to include MT7531 switch.
- Add me as a maintainer. List maintainers in alphabetical order by first
name.
- Add description to compatible strings.
- Stretch descriptions up to the 80 character limit.
- Remove quotes from $ref: "dsa.yaml#".
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
.../bindings/net/dsa/mediatek,mt7530.yaml | 36 ++++++++++++-------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index 17ab6c69ecc7..edf48e917173 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -4,12 +4,13 @@
$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7530.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT7530 Ethernet switch
+title: Mediatek MT7530 and MT7531 Ethernet Switches
maintainers:
- - Sean Wang <sean.wang@mediatek.com>
+ - Arınç ÜNAL <arinc.unal@arinc9.com>
- Landen Chao <Landen.Chao@mediatek.com>
- DENG Qingfang <dqfext@gmail.com>
+ - Sean Wang <sean.wang@mediatek.com>
description: |
Port 5 of mt7530 and mt7621 switch is muxed between:
@@ -61,10 +62,21 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt7530
- - mediatek,mt7531
- - mediatek,mt7621
+ oneOf:
+ - description:
+ Standalone MT7530 and multi-chip module MT7530 in MT7623AI SoC
+ items:
+ - const: mediatek,mt7530
+
+ - description:
+ Standalone MT7531
+ items:
+ - const: mediatek,mt7531
+
+ - description:
+ Multi-chip module MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs
+ items:
+ - const: mediatek,mt7621
reg:
maxItems: 1
@@ -79,7 +91,7 @@ properties:
gpio-controller:
type: boolean
description:
- if defined, MT7530's LED controller will run on GPIO mode.
+ If defined, MT7530's LED controller will run on GPIO mode.
"#interrupt-cells":
const: 1
@@ -92,8 +104,8 @@ properties:
io-supply:
description:
Phandle to the regulator node necessary for the I/O power.
- See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
- for details for the regulator setup on these boards.
+ See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt for
+ details for the regulator setup on these boards.
mediatek,mcm:
type: boolean
@@ -110,8 +122,8 @@ properties:
resets:
description:
- Phandle pointing to the system reset controller with line index for
- the ethsys.
+ Phandle pointing to the system reset controller with line index for the
+ ethsys.
maxItems: 1
patternProperties:
@@ -148,7 +160,7 @@ required:
- reg
allOf:
- - $ref: "dsa.yaml#"
+ - $ref: dsa.yaml#
- if:
required:
- mediatek,mcm
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/7] completely rework mediatek,mt7530 binding
From: Arınç ÜNAL @ 2022-08-13 15:44 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger, Sean Wang,
Landen Chao, DENG Qingfang, Frank Wunderlich,
Luiz Angelo Daros de Luca, Sander Vanheule, René van Dorst,
Daniel Golle, erkin.bozoglu, Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Arınç ÜNAL
Hello.
This patch series brings complete rework of the mediatek,mt7530 binding.
The binding is checked with "make dt_binding_check
DT_SCHEMA_FILES=mediatek,mt7530.yaml".
If anyone knows the GIC bit for interrupt for multi-chip module MT7530 in
MT7623AI SoC, let me know. I'll add it to the examples.
If anyone got a Unielec U7623 or another MT7623AI board, please reach out.
v2:
- Change the way of adding descriptions for each compatible string.
- Split the patch for updating the json-schema.
- Make slight changes on the patch for the binding description.
Arınç ÜNAL (7):
dt-bindings: net: dsa: mediatek,mt7530: make trivial changes
dt-bindings: net: dsa: mediatek,mt7530: fix reset lines
dt-bindings: net: dsa: mediatek,mt7530: update examples
dt-bindings: net: dsa: mediatek,mt7530: define port binding per compatible
dt-bindings: net: dsa: mediatek,mt7530: remove unnecesary lines
dt-bindings: net: dsa: mediatek,mt7530: define phy-mode for each compatible
dt-bindings: net: dsa: mediatek,mt7530: update binding description
.../bindings/net/dsa/mediatek,mt7530.yaml | 1017 +++++++++++++-----
1 file changed, 767 insertions(+), 250 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v1 07/10] net: dsa: microchip: warn about not supported synclko properties on KSZ9893 chips
From: Andrew Lunn @ 2022-08-13 15:11 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Vladimir Oltean, Woojung Huh, UNGLinuxDriver, Vivien Didelot,
Florian Fainelli, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, kernel, linux-kernel, netdev
In-Reply-To: <20220813143215.GA12534@pengutronix.de>
On Sat, Aug 13, 2022 at 04:32:15PM +0200, Oleksij Rempel wrote:
> On Fri, Aug 05, 2022 at 04:42:34PM +0300, Vladimir Oltean wrote:
> > On Fri, Aug 05, 2022 at 01:56:01PM +0200, Oleksij Rempel wrote:
> > > Hm, if we will have any random not support OF property in the switch
> > > node. We won't be able to warn about it anyway. So, if it is present
> > > but not supported, we will just ignore it.
> > >
> > > I'll drop this patch.
> >
> > To continue, I think the right way to go about this is to edit the
> > dt-schema to say that these properties are only applicable to certain
> > compatible strings, rather than for all. Then due to the
> > "unevaluatedProperties: false", you'd get the warnings you want, at
> > validation time.
>
> Hm, with "unevaluatedProperties: false" i have no warnings. Even if I
> create examples with random strings as properties. Are there some new
> json libraries i should use?
Try
additionalProperties: False
Andrew
^ permalink raw reply
* Re: [PATCH net-next v1 07/10] net: dsa: microchip: warn about not supported synclko properties on KSZ9893 chips
From: Oleksij Rempel @ 2022-08-13 14:32 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, kernel, linux-kernel, netdev
In-Reply-To: <20220805134234.ps4qfjiachzm7jv4@skbuf>
On Fri, Aug 05, 2022 at 04:42:34PM +0300, Vladimir Oltean wrote:
> On Fri, Aug 05, 2022 at 01:56:01PM +0200, Oleksij Rempel wrote:
> > Hm, if we will have any random not support OF property in the switch
> > node. We won't be able to warn about it anyway. So, if it is present
> > but not supported, we will just ignore it.
> >
> > I'll drop this patch.
>
> To continue, I think the right way to go about this is to edit the
> dt-schema to say that these properties are only applicable to certain
> compatible strings, rather than for all. Then due to the
> "unevaluatedProperties: false", you'd get the warnings you want, at
> validation time.
Hm, with "unevaluatedProperties: false" i have no warnings. Even if I
create examples with random strings as properties. Are there some new
json libraries i should use?
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH AUTOSEL 4.9 08/12] can: sja1000: Add Quirk for RZ/N1 SJA1000 CAN controller
From: Pavel Machek @ 2022-08-13 13:44 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Biju Das, Marc Kleine-Budde, wg, davem,
edumazet, kuba, pabeni, mailhol.vincent, stefan.maetje, socketcan,
linux-can, netdev
In-Reply-To: <20220811161144.1543598-8-sashal@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
Hi!
> As per Chapter 6.5.16 of the RZ/N1 Peripheral Manual, The SJA1000
> CAN controller does not support Clock Divider Register compared to
> the reference Philips SJA1000 device.
>
> This patch adds a device quirk to handle this difference.
I don't think this is suitable for stable (at least 5.10.X and older)
as we don't have user of the quirk queued up.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox