Re: [linux-next:master] BUILD REGRESSION 6dc544b66971c7f9909ff038b62149105272d26a
On Wed, 29 May 2024 02:19:47 +0800 kernel test robot wrote: > | `-- > net-ipv6-route.c-rt6_fill_node()-error:we-previously-assumed-dst-could-be-null-(see-line-) Is there a way for us to mark this as false positive?
Re: [PATCH v1 10/12] sfc: falcon: Make I2C terminology more inclusive
On Tue, 30 Apr 2024 17:38:09 + Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" > with more appropriate terms. Inspired by and following on to Wolfram's > series to fix drivers/i2c/[1], fix the terminology for users of > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > in the specification. > > Compile tested, no functionality changes intended FWIW we're assuming someone (Wolfram?) will take all of these, instead of area maintainers picking them individually. Please let us know if that's incorrect.
Re: [Intel-gfx] [PATCH v9 0/4] drm/i915: use ref_tracker library for tracking wakerefs
On Fri, 02 Jun 2023 12:21:32 +0200 Andrzej Hajda wrote: > This is reviewed series of ref_tracker patches, ready to merge > via network tree, rebased on net-next/main. > i915 patches will be merged later via intel-gfx tree. FWIW I'll try to merge these on top of the -rc4 tag so with a bit of luck you should be able to cross merge cleanly into another -next tree.
Re: [Intel-gfx] [PATCH v8 0/7] drm/i915: use ref_tracker library for tracking wakerefs
On Thu, 1 Jun 2023 19:14:50 +0200 Andrzej Hajda wrote: > Ping on the series, everything reviewed. > Eric, Dave, Jakub, could you take patches 1-4 via net tree? Sure thing, would you mind reposting them separately? Easier for us to apply and it's been over a month since posting, a fresh run of build bots won't hurt either.
Re: [Intel-gfx] [PATCH v7 0/7] drm/i915: use ref_tracker library for tracking wakerefs
On Fri, 21 Apr 2023 13:35:04 +0200 Andrzej Hajda wrote: > Gently ping for network developers, could you look at ref_tracker patches, > as the ref_tracker library was developed for network. Putting Eric in the To: field, I know email so hard and confusing...
Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
On Wed, 20 Apr 2022 08:13:47 +0300 Kalle Valo wrote: > Wireless drivers would also desperately need to pass device specific > parameters at (or before) probe time. And not only debug parameters but > also configuration parameters, for example firmware memory allocations > schemes (optimise for features vs number of clients etc) and whatnot. > > Any ideas how to implement that? Is there any prior work for anything > like this? This is pretty hard limiting usability of upstream wireless > drivers and I really want to find a proper solution. In netdev we have devlink which is used for all sort of device configuration. devlink-resource sounds like what you need, but it'd have to be extended to support configuration which requires reload/re-probe. Currently only devlink-params support that but params were a mistake so don't use that.
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, 28 Feb 2022 16:41:04 -0800 Linus Torvalds wrote:
> So yes, initially my idea had been to just move the iterator entirely
> inside the macro. But specifying the type got so ugly that I think
> that
>
> typeof (pos) pos
>
> trick inside the macro really ends up giving us the best of all worlds:
>
> (a) let's us keep the existing syntax and code for all the nice cases
> that did everything inside the loop anyway
>
> (b) gives us a nice warning for any normal use-after-loop case
> (unless you explicitly initialized it like that
> sgx_mmu_notifier_release() function did for no good reason
>
> (c) also guarantees that even if you don't get a warning,
> non-converted (or newly written) bad code won't actually _work_
>
> so you end up getting the new rules without any ambiguity or mistaken
I presume the goal is that we can do this without changing existing
code? Otherwise actually moving the iterator into the loop body would
be an option, by creating a different hidden variable:
#define list_iter(head) \
for (struct list head *_l = (head)->next; _l != (head); _l = _l->next)
#define list_iter_entry(var, member)\
list_entry(_l, typeof(*var), member)
list_iter(&p->a_head) {
struct entry *e = list_iter_entry(e, a_member);
/* use e->... */
}
Or we can slide into soft insanity and exploit one of Kees'es tricks
to encode the type of the entries "next to" the head:
#define LIST_HEAD_MEM(name, type) \
union { \
struct list_head name; \
type *name ## _entry; \
}
struct entry {
struct list_head a_member;
};
struct parent {
LIST_HEAD_MEM(a_head, struct entry);
};
#define list_for_each_magic(pos, head, member) \
for (typeof(**(head ## _entry)) *pos = list_first_entry(head,
typeof(**(head ## _entry)), member); \
&pos->member != (head);\
pos = list_next_entry(pos, member))
list_for_each_magic(e, &p->a_head, a_member) {
/* use e->... */
}
I'll show myself out...
[Intel-gfx] [PATCH bpf v2] treewide: add missing includes masked by cgroup -> bpf dependency
cgroup.h (therefore swap.h, therefore half of the universe) includes bpf.h which in turn includes module.h and slab.h. Since we're about to get rid of that dependency we need to clean things up. v2: drop the cpu.h include from cacheinfo.h, it's not necessary and it makes riscv sensitive to ordering of include files. Link: https://lore.kernel.org/all/20211120035253.72074-1-k...@kernel.org/ # v1 Link: https://lore.kernel.org/all/20211120165528.197359-1-k...@kernel.org/ # cacheinfo discussion Acked-by: Krzysztof Wilczyński Acked-by: Peter Chen Acked-by: SeongJae Park Acked-by: Jani Nikula Signed-off-by: Jakub Kicinski --- CC: ax...@kernel.dk CC: maarten.lankho...@linux.intel.com CC: mrip...@kernel.org CC: tzimmerm...@suse.de CC: airl...@linux.ie CC: dan...@ffwll.ch CC: jani.nik...@linux.intel.com CC: joonas.lahti...@linux.intel.com CC: rodrigo.v...@intel.com CC: yuq...@gmail.com CC: robdcl...@gmail.com CC: s...@poorly.run CC: christian.koe...@amd.com CC: ray.hu...@amd.com CC: sgout...@marvell.com CC: gak...@marvell.com CC: sbha...@marvell.com CC: hke...@marvell.com CC: jingooh...@gmail.com CC: lorenzo.pieral...@arm.com CC: r...@kernel.org CC: k...@linux.com CC: bhelg...@google.com CC: krzysztof.kozlow...@canonical.com CC: m...@kernel.org CC: paw...@cadence.com CC: peter.c...@kernel.org CC: rog...@kernel.org CC: a-govindr...@ti.com CC: gre...@linuxfoundation.org CC: a...@kernel.org CC: dan...@iogearbox.net CC: and...@kernel.org CC: ka...@fb.com CC: songliubrav...@fb.com CC: y...@fb.com CC: john.fastab...@gmail.com CC: kpsi...@kernel.org CC: s...@kernel.org CC: a...@linux-foundation.org CC: thomas.hellst...@linux.intel.com CC: matthew.a...@intel.com CC: colin.k...@intel.com CC: ge...@linux-m68k.org CC: linux-bl...@vger.kernel.org CC: dri-de...@lists.freedesktop.org CC: intel-gfx@lists.freedesktop.org CC: l...@lists.freedesktop.org CC: linux-arm-...@vger.kernel.org CC: freedr...@lists.freedesktop.org CC: linux-...@vger.kernel.org CC: linux-arm-ker...@lists.infradead.org CC: linux-samsung-...@vger.kernel.org CC: linux-...@vger.kernel.org CC: b...@vger.kernel.org CC: linux...@kvack.org --- block/fops.c | 1 + drivers/gpu/drm/drm_gem_shmem_helper.c| 1 + drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + drivers/gpu/drm/i915/i915_request.c | 1 + drivers/gpu/drm/lima/lima_device.c| 1 + drivers/gpu/drm/msm/msm_gem_shrinker.c| 1 + drivers/gpu/drm/ttm/ttm_tt.c | 1 + drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 1 + drivers/net/ethernet/marvell/octeontx2/nic/otx2_ptp.c | 2 ++ drivers/pci/controller/dwc/pci-exynos.c | 1 + drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 + drivers/usb/cdns3/host.c | 1 + include/linux/cacheinfo.h | 1 - include/linux/device/driver.h | 1 + include/linux/filter.h| 2 +- mm/damon/vaddr.c | 1 + mm/memory_hotplug.c | 1 + mm/swap_slots.c | 1 + 18 files changed, 18 insertions(+), 2 deletions(-) diff --git a/block/fops.c b/block/fops.c index ad732a36f9b3..3cb1e81929bc 100644 --- a/block/fops.c +++ b/block/fops.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "blk.h" static inline struct inode *bdev_file_inode(struct file *file) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 7b9f69f21f1e..bca0de92802e 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -9,6 +9,7 @@ #include #include #include +#include #ifdef CONFIG_X86 #include diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c index 67d14afa6623..b67f620c3d93 100644 --- a/drivers/gpu/drm/i915/gt/intel_gtt.c +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c @@ -6,6 +6,7 @@ #include /* fault-inject.h is not standalone! */ #include +#include #include "gem/i915_gem_lmem.h" #include "i915_trace.h" diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 820a1f38b271..89cccefeea63 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -29,6 +29,7 @@ #include #include #include +#include #include "gem/i915_gem_context.h" #include "gt/intel_breadcrumbs.h" diff --git a/drivers/gpu/drm/lima/lima_device.c b/drivers/gpu/drm/lima/lima_device.c index 65fdca366e41..f74f8048af8f 100644 --- a/drivers/gpu/drm/lima/lima_device.c +++ b/drivers/gpu/drm/lima/lima_device.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/ms
[Intel-gfx] [PATCH bpf] treewide: add missing includes masked by cgroup -> bpf dependency
cgroup.h (therefore swap.h, therefore half of the universe) includes bpf.h which in turn includes module.h and slab.h. Since we're about to get rid of that dependency we need to clean things up. Signed-off-by: Jakub Kicinski --- CC: ax...@kernel.dk CC: maarten.lankho...@linux.intel.com CC: mrip...@kernel.org CC: tzimmerm...@suse.de CC: airl...@linux.ie CC: dan...@ffwll.ch CC: jani.nik...@linux.intel.com CC: joonas.lahti...@linux.intel.com CC: rodrigo.v...@intel.com CC: yuq...@gmail.com CC: robdcl...@gmail.com CC: s...@poorly.run CC: christian.koe...@amd.com CC: ray.hu...@amd.com CC: sgout...@marvell.com CC: gak...@marvell.com CC: sbha...@marvell.com CC: hke...@marvell.com CC: jingooh...@gmail.com CC: lorenzo.pieral...@arm.com CC: r...@kernel.org CC: k...@linux.com CC: bhelg...@google.com CC: krzysztof.kozlow...@canonical.com CC: m...@kernel.org CC: paw...@cadence.com CC: peter.c...@kernel.org CC: rog...@kernel.org CC: a-govindr...@ti.com CC: gre...@linuxfoundation.org CC: a...@kernel.org CC: dan...@iogearbox.net CC: and...@kernel.org CC: ka...@fb.com CC: songliubrav...@fb.com CC: y...@fb.com CC: john.fastab...@gmail.com CC: kpsi...@kernel.org CC: s...@kernel.org CC: a...@linux-foundation.org CC: thomas.hellst...@linux.intel.com CC: matthew.a...@intel.com CC: colin.k...@intel.com CC: ge...@linux-m68k.org CC: linux-bl...@vger.kernel.org CC: dri-de...@lists.freedesktop.org CC: intel-gfx@lists.freedesktop.org CC: l...@lists.freedesktop.org CC: linux-arm-...@vger.kernel.org CC: freedr...@lists.freedesktop.org CC: linux-...@vger.kernel.org CC: linux-arm-ker...@lists.infradead.org CC: linux-samsung-...@vger.kernel.org CC: linux-...@vger.kernel.org CC: b...@vger.kernel.org CC: linux...@kvack.org Well, let's see if this makes it thru email servers... --- block/fops.c | 1 + drivers/gpu/drm/drm_gem_shmem_helper.c| 1 + drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + drivers/gpu/drm/i915/i915_request.c | 1 + drivers/gpu/drm/lima/lima_device.c| 1 + drivers/gpu/drm/msm/msm_gem_shrinker.c| 1 + drivers/gpu/drm/ttm/ttm_tt.c | 1 + drivers/net/ethernet/huawei/hinic/hinic_sriov.c | 1 + drivers/net/ethernet/marvell/octeontx2/nic/otx2_ptp.c | 2 ++ drivers/pci/controller/dwc/pci-exynos.c | 1 + drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 + drivers/usb/cdns3/host.c | 1 + include/linux/device/driver.h | 1 + include/linux/filter.h| 2 +- mm/damon/vaddr.c | 1 + mm/memory_hotplug.c | 1 + mm/swap_slots.c | 1 + 17 files changed, 18 insertions(+), 1 deletion(-) diff --git a/block/fops.c b/block/fops.c index ad732a36f9b3..3cb1e81929bc 100644 --- a/block/fops.c +++ b/block/fops.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "blk.h" static inline struct inode *bdev_file_inode(struct file *file) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 7b9f69f21f1e..bca0de92802e 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -9,6 +9,7 @@ #include #include #include +#include #ifdef CONFIG_X86 #include diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c index 67d14afa6623..b67f620c3d93 100644 --- a/drivers/gpu/drm/i915/gt/intel_gtt.c +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c @@ -6,6 +6,7 @@ #include /* fault-inject.h is not standalone! */ #include +#include #include "gem/i915_gem_lmem.h" #include "i915_trace.h" diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 820a1f38b271..89cccefeea63 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -29,6 +29,7 @@ #include #include #include +#include #include "gem/i915_gem_context.h" #include "gt/intel_breadcrumbs.h" diff --git a/drivers/gpu/drm/lima/lima_device.c b/drivers/gpu/drm/lima/lima_device.c index 65fdca366e41..f74f8048af8f 100644 --- a/drivers/gpu/drm/lima/lima_device.c +++ b/drivers/gpu/drm/lima/lima_device.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/msm/msm_gem_shrinker.c index 4a1420b05e97..086dacf2f26a 100644 --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c @@ -5,6 +5,7 @@ */ #include +#include #include "msm_drv.h" #include "msm_gem.h" diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 7e83c00a3f48..79c870a3bef8 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++
Re: [Intel-gfx] [PATCH bpf] treewide: add missing includes masked by cgroup -> bpf dependency
On Sat, 20 Nov 2021 15:30:11 +0800 Peter Chen wrote: > > diff --git a/drivers/usb/cdns3/host.c b/drivers/usb/cdns3/host.c > > index 84dadfa726aa..9643b905e2d8 100644 > > --- a/drivers/usb/cdns3/host.c > > +++ b/drivers/usb/cdns3/host.c > > @@ -10,6 +10,7 @@ > > */ > > > > #include > > +#include > > Should be "#include "? Why? Different files are missing different includes, this one needs slab.h: ../drivers/usb/cdns3/host.c: In function ‘__cdns_host_init’: ../drivers/usb/cdns3/host.c:86:2: error: implicit declaration of function ‘kfree’; did you mean ‘vfree’? [-Werror=implicit-function-declaration] kfree(cdns->xhci_plat_data); ^ vfree
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote: > I even agree that most of the churn comes from > > case 0: > ++x; > default: > break; And just to spell it out, case ENUM_VALUE1: bla(); break; case ENUM_VALUE2: bla(); default: break; is a fairly idiomatic way of indicating that not all values of the enum are expected to be handled by the switch statement. I really hope the Clang folks are reasonable and merge your patch. > If trivial patches are adding too much to your workload, consider > training a co-maintainer or asking for help from one of your reviewers > whom you trust. I don't doubt it's hard to find maintainers, but > existing maintainers should go out of their way to entrust > co-maintainers especially when they find their workload becomes too > high. And reviewing/picking up trivial patches is probably a great > way to get started. If we allow too much knowledge of any one > subsystem to collect with one maintainer, what happens when that > maintainer leaves the community (which, given a finite lifespan, is an > inevitability)? The burn out point is about enjoying your work and feeling that it matters. It really doesn't make much difference if you're doing something you don't like for 12 hours every day or only in shifts with another maintainer. You'll dislike it either way. Applying a real patch set and then getting a few follow ups the next day for trivial coding things like fallthrough missing or static missing, just because I didn't have the full range of compilers to check with before applying makes me feel pretty shitty, like I'm not doing a good job. YMMV. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
> >
>
> So looks like the bulk of these are:
> switch (x) {
> case 0:
> ++x;
> default:
> break;
> }
>
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895
😍
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > add multiple break/goto/return/fallthrough statements instead of just > letting the code fall through to the next case. > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > change[1] is meant to be reverted at some point. So, this patch helps > to move in that direction. > > Something important to mention is that there is currently a discrepancy > between GCC and Clang when dealing with switch fall-through to empty case > statements or to cases that only contain a break/continue/return > statement[2][3][4]. Are we sure we want to make this change? Was it discussed before? Are there any bugs Clangs puritanical definition of fallthrough helped find? IMVHO compiler warnings are supposed to warn about issues that could be bugs. Falling through to default: break; can hardly be a bug?! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > This series aims to fix almost all remaining fall-through warnings in > > > order to enable -Wimplicit-fallthrough for Clang. > > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > > add multiple break/goto/return/fallthrough statements instead of just > > > letting the code fall through to the next case. > > > > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > > > change[1] is meant to be reverted at some point. So, this patch helps > > > to move in that direction. > > > > > > Something important to mention is that there is currently a discrepancy > > > between GCC and Clang when dealing with switch fall-through to empty case > > > statements or to cases that only contain a break/continue/return > > > statement[2][3][4]. > > > > Are we sure we want to make this change? Was it discussed before? > > > > Are there any bugs Clangs puritanical definition of fallthrough helped > > find? > > > > IMVHO compiler warnings are supposed to warn about issues that could > > be bugs. Falling through to default: break; can hardly be a bug?! > > It's certainly a place where the intent is not always clear. I think > this makes all the cases unambiguous, and doesn't impact the machine > code, since the compiler will happily optimize away any behavioral > redundancy. If none of the 140 patches here fix a real bug, and there is no change to machine code then it sounds to me like a W=2 kind of a warning. I think clang is just being annoying here, but if I'm the only one who feels this way chances are I'm wrong :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 00/27]Fix several bad kernel-doc markups
On Mon, 16 Nov 2020 11:17:56 +0100 Mauro Carvalho Chehab wrote: > Kernel-doc has always be limited to a probably bad documented > rule: > > The kernel-doc markups should appear *imediatelly before* the > function or data structure that it documents. Applied 1-3 to net-next, thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
