On Thu, 2024-04-11 at 17:04 +0200, Thorsten Blum wrote:
> Use `find . -type f -exec sed -i 's/\/the/g' {} +` to find all
> occurrences of "the the" and replace them with a single "the".
I estimated that this misses at least ~50 instances split across lines:
$ git grep -ih -A1 -e 'the$'|grep -vi '
ally necessary, you can set it in the
core and merge the other patches in the next cycle; those drivers that
_have_ an .owner aren't broken after all.
Acked-by: Johannes Berg
johannes
On Tue, 2023-07-25 at 22:09 +0200, Andrew Lunn wrote:
>
>
> It could well be that AMD based machine has a different ACPI extension
> to indicate this policy to what Intel machine has. As far as i
> understand it, you have not submitted this yet for formal approval,
> this is all vendor specific,
On Wed, 2023-06-21 at 21:25 +0200, Andrew Lunn wrote:
> > ACPI core does has notifiers that are used, but they don't work the same.
> > If you look at patch 4, you'll see amdgpu registers and unregisters using
> > both
> >
> > acpi_install_notify_handler()
> > and
> > acpi_remove_notify_handler()
On Wed, 2023-06-21 at 18:14 +0200, Andrew Lunn wrote:
> > > Do only ACPI based systems have:
> > >
> > > interference of relatively high-powered harmonics of the (G-)DDR
> > > memory clocks with local radio module frequency bands used by
> > > Wifi 6/6e/7."
> > >
> > > Could Device Tree
On Wed, 2023-06-21 at 17:36 +0200, Andrew Lunn wrote:
> On Wed, Jun 21, 2023 at 01:45:56PM +0800, Evan Quan wrote:
> > From: Mario Limonciello
> >
> > Due to electrical and mechanical constraints in certain platform designs
> > there may be likely interference of relatively high-powered harmonics
On Wed, 2023-06-21 at 09:12 -0500, Limonciello, Mario wrote:
> >
> > But then the next question anyway is how we merge this? The wifi parts
> > sort of depend on the first patch, although technically I guess I could
> > merge them since it's all hidden behind the CONFIG_ symbol, assuming you
> > g
On Wed, 2023-06-21 at 13:45 +0800, Evan Quan wrote:
> To support AMD's WBRF interference mitigation mechanism, Wifi adapters
> utilized in the system must register the frequencies in use(or unregister
> those frequencies no longer used) via the dedicated APCI calls. So that,
> other drivers respond
On Sun, 2023-06-18 at 21:17 -0500, Mario Limonciello wrote:
>
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
> > cfg80211_chandef_compatible(const struct cfg80211_chan_def *chandef1,
> > const st
On Fri, 2023-06-09 at 15:28 +0800, Evan Quan wrote:
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -5551,6 +5551,10 @@ struct wiphy {
>
> u16 hw_timestamp_max_peers;
>
> +#ifdef CONFIG_ACPI_WBRF
> + bool wbrf_supported;
> +#endif
This should be in some private st
On Tue, 2022-11-22 at 08:55 -0500, Alex Deucher wrote:
> >
> >+ /kisskb/src/arch/um/include/asm/processor-generic.h: error: called
> > object is not a function or function pointer: => 94:18
> >+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:
> > error: control reaches
On Tue, 2022-03-01 at 09:45 -0800, Rob Clark wrote:
> On Mon, Feb 28, 2022 at 10:49 PM David Laight wrote:
> >
> > From: Abhinav Kumar
> > > Sent: 28 February 2022 21:38
> > ...
> > > We also did some profiling around how much increasing the block size
> > > helps and here is the data:
> > >
> >
On Mon, 2022-02-28 at 20:16 +, Matthew Wilcox wrote:
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_ 'p
On Sat, 2022-02-19 at 16:00 +0800, David Gow wrote:
> On Fri, Feb 18, 2022 at 8:26 PM Johannes Berg
> wrote:
> >
> > On Fri, 2022-02-18 at 15:57 +0800, David Gow wrote:
> > >
> > > Note that, while this does build again, it still segfaults on startup,
&
On Fri, 2022-02-18 at 15:57 +0800, David Gow wrote:
>
> Note that, while this does build again, it still segfaults on startup,
> so more work remains to be done.
That's probably just a lot more stuff getting included somehow?
> They are:
> - CONFIG_VFIO_PCI: Needs ioport_map/ioport_unmap.
> - CO
On Fri, 2022-02-11 at 23:52 -0800, Abhinav Kumar wrote:
>
> The thread is writing the data to a file in local storage. From our
> profiling, the read is the one taking the time not the write.
>
That seems kind of hard to believe, let's say it's a 4/3 split (4
minutes reading, 3 minutes writing,
On Tue, 2022-02-08 at 17:55 -0800, Abhinav Kumar wrote:
>
> Are you suggesting something like below?
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 42dcf96..14203d0 100644
> --- a/fs/sysfs/file.c
>
No, for sure not, but I guess from the looks of this patch there's no
way to do somet
On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
> >
> I am checking what usermode sees and will get back ( I didnt see an
> error do most likely it was EOF ). I didnt follow the second part.
I think probably it got -ENODEV, looking at kernfs_file_read_iter().
> If the file descriptor re
On Tue, 2022-02-08 at 13:04 -0800, Abhinav Kumar wrote:
>
> It opened the file rightaway but could not finish reading.
>
> The device gets deleted so the corresponding /data will disappear too (
> as the data node is under devcd*/data)
Yeah but even if the file disappears, the open file descrip
On Tue, 2022-02-08 at 11:44 -0800, Abhinav Kumar wrote:
> There are cases where depending on the size of the devcoredump and the speed
> at which the usermode reads the dump, it can take longer than the current 5
> mins
> timeout.
>
> This can lead to incomplete dumps as the device is deleted onc
From: Johannes Berg
Even if it's probably not really useful, it can get selected
by e.g. randconfig builds, and then failing to compile is an
annoyance. Unfortunately, it's hard to fix in Kconfig, since
DRM_TTM is selected by many things that don't really depend
on any specific ar
On Thu, 2021-09-02 at 09:10 +0100, Anton Ivanov wrote:
> On 02/09/2021 08:43, Johannes Berg wrote:
> > On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
> > > > >
> > > > > I have a question though - why all of DRM is not !UML in config. Not
> > &
On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
> > >
> > > I have a question though - why all of DRM is not !UML in config. Not
> > > like we can use them.
> >
> > I have no idea about that.
> > Hopefully one of the (other) UML maintainers can answer you.
>
> Touche.
>
> We will discus
On Wed, 2021-09-01 at 19:17 -0700, Randy Dunlap wrote:
> Fix a build error on CONFIG_UML, which does not support (provide)
> wbinvd(). UML can use the generic mb() instead.
>
> ../drivers/gpu/drm/r128/ati_pcigart.c: In function ‘drm_ati_pcigart_init’:
> ../drivers/gpu/drm/r128/ati_pcigart.c:218:2:
On Wed, 2021-08-18 at 09:08 +0200, Johannes Berg wrote:
> On Tue, 2021-08-17 at 23:05 -0700, Kees Cook wrote:
> >
> > @@ -275,12 +275,11 @@ static void carl9170_tx_release(struct kref *ref)
> > if (WARN_ON_ONCE(!ar))
> > return;
> >
&g
On Tue, 2021-08-17 at 23:05 -0700, Kees Cook wrote:
>
> @@ -275,12 +275,11 @@ static void carl9170_tx_release(struct kref *ref)
> if (WARN_ON_ONCE(!ar))
> return;
>
>
>
>
> - BUILD_BUG_ON(
> - offsetof(struct ieee80211_tx_info, status.ack_signal) != 20);
> -
>
On Fri, 2021-08-13 at 08:49 -0700, Kees Cook wrote:
>
> Ah! Yes, thanks for pointing this out. During earlier development I split
> the "cross-field write" changes from the "cross-field read" changes, and
> it looks like I missed moving lib80211_crypt_ccmp.c into that portion of
> the series (whic
On Fri, 2021-08-13 at 09:08 -0700, Kees Cook wrote:
> >
> > The common helper should also clear ack_signal, but that was broken by
> > commit e3e1a0bcb3f1 ("mac80211: reduce IEEE80211_TX_MAX_RATES"), because
> > that commit changed the order of the fields and updated carl9170 and p54
> > properly
On Sat, 2021-07-31 at 08:55 -0700, Kees Cook wrote:
>
> > @@ -278,9 +278,7 @@ static void carl9170_tx_release(struct kref *ref)
> > BUILD_BUG_ON(
> > offsetof(struct ieee80211_tx_info, status.ack_signal) != 20);
> >
> >
> > - memset(&txinfo->status.ack_signal, 0,
> > - si
On Sat, 2021-07-31 at 08:55 -0700, Kees Cook wrote:
> On Tue, Jul 27, 2021 at 01:58:30PM -0700, Kees Cook wrote:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
> >
> > Use
On Tue, 2021-07-27 at 13:58 -0700, Kees Cook wrote:
>
> +++ b/include/linux/ieee80211.h
> @@ -297,9 +297,11 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
> struct ieee80211_hdr {
> __le16 frame_control;
> __le16 duration_id;
> - u8 addr1[ETH_ALEN];
> - u8 addr2[ETH_A
On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote:
> These GENMASK uses are inverted argument order and the
> actual masks produced are incorrect. Fix them.
>
> Add checkpatch tests to help avoid more misuses too.
>
> Joe Perches (12):
> checkpatch: Add GENMASK tests
IMHO this doesn't make
On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is
On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
> It seems that there should be a better way to do it,
> but this works too.
In some cases there might be:
> --- a/drivers/s390/virtio/Makefile
> +++ b/drivers/s390/virtio/Makefile
> @@ -6,6 +6,8 @@
> Â # it under the terms of the GNU
> Initial testing says that the change below must precede the change
> to the definition of lockless_dereference(), so the two should go
> together.
Indeed.
> If my upcoming testing of the two changes together pans out, I will
> give you a Tested-by -- I am guessing that you don't want to wait
>
From: Johannes Berg
After Peter's commit (see below) we get a lot of sparse warnings
(one for every rcu_dereference, and more) since the expression
here is assigning to the wrong address space.
Instead of validating that 'p' is a pointer this way, instead make
it fail compilatio
From: Johannes Berg
This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
As Peter explained:
[...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
[...]
Also, clue is in the name: 'dereference', you don't actually dereference
the pointer her
On Wed, 2014-11-19 at 05:28 -0800, Amitkumar Karwar wrote:
> if "CONFIG_DEV_COREDUMP=y" is added to configuration file, it
> gets removed when final configuration file is generated. The
> reason is it requires CONFIG_WANT_DEV_COREDUMP to be enabled.
>
> Currently "make menuconfig" doesn't display
From: Johannes Berg
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware sta
On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
> > + /*
> > +* this seems racy, but I don't see a notifier or such on
> > +* a struct device to know when it goes away?
> > +*/
> > + if (devcd->failing_dev->kobj.sd)
> > + sysfs_delete_link(&devcd->failing_dev
On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
> > +MODULE_AUTHOR("Johannes Berg ");
> > +MODULE_DESCRIPTION("Device Coredump support");
> > +MODULE_LICENSE("GPL");
>
> As you only allow Y or N as build options, it's no
On Fri, 2014-09-05 at 11:40 +0200, Jonas Gorski wrote:
> On Fri, Sep 5, 2014 at 10:50 AM, Johannes Berg
> wrote:
> > From: Johannes Berg
>
> Can't you just send from the correct address? ;p
Not easily :)
> How about the following to avoid negative options
From: Johannes Berg
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware sta
On Tue, 2014-06-24 at 09:27 +1000, Julian Calaby wrote:
> > - x = (T)pci_alloc_consistent(E1,E2,E3);
> > + x = pci_zalloc_consistent(E1,E2,E3);
> > if ((x==NULL) || ...) S
> > - memset((T2)x,0,E2);
>
> I don't know much about SmPL, but wouldn't having that if statement
> there reduce your match
Hi,
I didn't find this reported, but maybe it has been, I didn't search for
too long. I'm using 3.8.0-rc4 (plus wireless bits), and lockdep is
unhappy. Note that I am booting with "no_console_suspend".
[ 73.320586] ==
[ 73.320587] [ INFO: po
Hi,
I didn't find this reported, but maybe it has been, I didn't search for
too long. I'm using 3.8.0-rc4 (plus wireless bits), and lockdep is
unhappy. Note that I am booting with "no_console_suspend".
[ 73.320586] ==
[ 73.320587] [ INFO: po
On Sun, 2011-07-10 at 12:19 +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38702
> Subject : 3.0.0-rc4-git6 - INFO: possible circular locking
> dependency detected - (&rdev->mtx){+.+.+.}, at: []
> cfg80211_netdev_notifier_call+0x275/0x4
On Sun, 2011-07-10 at 12:19 +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=38702
> Subject : 3.0.0-rc4-git6 - INFO: possible circular locking
> dependency detected - (&rdev->mtx){+.+.+.}, at: []
> cfg80211_netdev_notifier_call+0x275/0x4
On Wed, 2010-09-01 at 14:09 +0200, Francisco Jerez wrote:
> > [ 75.430015] ==
> > [ 75.430015] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> Yes, that's a known issue, the scenario where it actually dead locks is
> impossibl
Francisco,
The patch you pointed me works, but now, although it's probably not due
to that patch, I get a lockdep warning:
[ 75.428119] [drm] nouveau :02:00.0: nouveau_channel_free: freeing fifo 2
[ 75.430015]
[ 75.430015] ==
[ 75.4
On Wed, 2010-09-01 at 14:09 +0200, Francisco Jerez wrote:
> > [ 75.430015] ==
> > [ 75.430015] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> Yes, that's a known issue, the scenario where it actually dead locks is
> impossibl
Francisco,
The patch you pointed me works, but now, although it's probably not due
to that patch, I get a lockdep warning:
[ 75.428119] [drm] nouveau :02:00.0: nouveau_channel_free: freeing fifo 2
[ 75.430015]
[ 75.430015] ==
[ 75.4
On Mon, 2010-08-30 at 21:54 +0200, Johannes Berg wrote:
> > >> Sure, try 5a5608adff833bad37c56278b6194c5b0a5b36bf.
> > >
> > > An actual url would help ... What is "the nouveau kernel tree"?
> > >
> > Ah sorry, git://anongit.freedesktop.org/
On Mon, 2010-08-30 at 21:54 +0200, Johannes Berg wrote:
> > >> Sure, try 5a5608adff833bad37c56278b6194c5b0a5b36bf.
> > >
> > > An actual url would help ... What is "the nouveau kernel tree"?
> > >
> > Ah sorry, git://anongit.freedesktop.org/
On Mon, 2010-08-30 at 21:55 +0200, Francisco Jerez wrote:
> Johannes Berg writes:
>
> > On Mon, 2010-08-30 at 21:33 +0200, Francisco Jerez wrote:
> >> Johannes Berg writes:
> >>
> >> > On Mon, 2010-08-30 at 21:08 +0200, Francisco Jerez wrote:
>
On Mon, 2010-08-30 at 21:33 +0200, Francisco Jerez wrote:
> Johannes Berg writes:
>
> > On Mon, 2010-08-30 at 21:08 +0200, Francisco Jerez wrote:
> >
> >> > This problem persists in -rc3, where I'd hoped the nouveau changes would
> >> > actually f
On Mon, 2010-08-30 at 21:08 +0200, Francisco Jerez wrote:
> > This problem persists in -rc3, where I'd hoped the nouveau changes would
> > actually fix it :-( In fact, it seems I was either "lucky" or it was
> > made easier to trigger, this time it already happened during my login.
> That's alrea
On Wed, 2010-08-25 at 15:55 +0200, Johannes Berg wrote:
> Since 2.6.36-rc kernels (both rc1 and rc2) I've had X lockups where X
> sits in a loop just using CPU.
>
> The only kernel message I got this time was this one:
>
> [22290.792075] [drm] nouveau :02:00.0:
On Mon, 2010-08-30 at 21:55 +0200, Francisco Jerez wrote:
> Johannes Berg writes:
>
> > On Mon, 2010-08-30 at 21:33 +0200, Francisco Jerez wrote:
> >> Johannes Berg writes:
> >>
> >> > On Mon, 2010-08-30 at 21:08 +0200, Francisco Jerez wrote:
>
On Mon, 2010-08-30 at 21:33 +0200, Francisco Jerez wrote:
> Johannes Berg writes:
>
> > On Mon, 2010-08-30 at 21:08 +0200, Francisco Jerez wrote:
> >
> >> > This problem persists in -rc3, where I'd hoped the nouveau changes would
> >> > actually f
On Mon, 2010-08-30 at 21:08 +0200, Francisco Jerez wrote:
> > This problem persists in -rc3, where I'd hoped the nouveau changes would
> > actually fix it :-( In fact, it seems I was either "lucky" or it was
> > made easier to trigger, this time it already happened during my login.
> That's alrea
On Wed, 2010-08-25 at 15:55 +0200, Johannes Berg wrote:
> Since 2.6.36-rc kernels (both rc1 and rc2) I've had X lockups where X
> sits in a loop just using CPU.
>
> The only kernel message I got this time was this one:
>
> [22290.792075] [drm] nouveau :02:00.0:
Since 2.6.36-rc kernels (both rc1 and rc2) I've had X lockups where X
sits in a loop just using CPU.
The only kernel message I got this time was this one:
[22290.792075] [drm] nouveau :02:00.0: PFIFO_DMA_PUSHER - Ch 2
stracing X just repeats, in a loop,
ioctl(9, 0x40086482, 0x7fff6a873af0)
Since 2.6.36-rc kernels (both rc1 and rc2) I've had X lockups where X
sits in a loop just using CPU.
The only kernel message I got this time was this one:
[22290.792075] [drm] nouveau :02:00.0: PFIFO_DMA_PUSHER - Ch 2
stracing X just repeats, in a loop,
ioctl(9, 0x40086482, 0x7fff6a873af0)
64 matches
Mail list logo
