On 23.04.24 00:15, Mauro Carvalho Chehab wrote:
>> sta...@kernel.org is there to route to /dev/null on purpose so that
>> developers/maintainers who only want their patches to get picked up when
>> they hit Linus's tree, will have happen and not notify anyone else.
>> This is especially good
Em Tue, 23 Apr 2024 00:04:01 +0200
Greg KH escreveu:
> On Mon, Apr 22, 2024 at 10:46:37PM +0100, Mauro Carvalho Chehab wrote:
> > Em Mon, 22 Apr 2024 15:25:18 -0400
> > Konstantin Ryabitsev escreveu:
> >
> > > On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > > >
On Mon, Apr 22, 2024 at 10:46:37PM +0100, Mauro Carvalho Chehab wrote:
> Em Mon, 22 Apr 2024 15:25:18 -0400
> Konstantin Ryabitsev escreveu:
>
> > On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > > @Greg, BTW: should this be stable+noauto...@kernel.org or have a
> > >
Em Mon, 22 Apr 2024 15:25:18 -0400
Konstantin Ryabitsev escreveu:
> On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > @Greg, BTW: should this be stable+noauto...@kernel.org or have a
> > 'vger.'
>
> No vger, just stable+whate...@kernel.org.
>
> > in it, e.g.
On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> @Greg, BTW: should this be stable+noauto...@kernel.org or have a
> 'vger.'
No vger, just stable+whate...@kernel.org.
> in it, e.g. stable+noauto...@vger.kernel.org? I assume without 'vger.'
> is fine, just wanted to be sure,
[CCing Sasha]
On 18.04.24 15:20, Greg KH wrote:
> On Thu, Apr 18, 2024 at 09:04:53AM +0200, Thorsten Leemhuis wrote:
>> On 17.04.24 15:38, Greg KH wrote:
>>> On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> On Wed, Apr
+0200, Thorsten Leemhuis wrote:
> >>>> Could you please create the email alias
> >>>> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> >>>> just like sta...@kernel.org does?
> >>>>
> >>>>
On 17.04.24 15:38, Greg KH wrote:
> On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
>> On 17.04.24 14:52, Konstantin Ryabitsev wrote:
>>> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>>>> Could you please create the email
ot;do-not-apply-to-stable", typing
instead things like:
do_not_apply_to_stable
dont-apply-to-stable
and other variants.
I want this very explicit that someone does not want this applied, and
that it has a reason to do so. And if getting the email right to do so
is the issue with th
Could you please create the email alias
> > > do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> > > just like sta...@kernel.org does?
> > >
> > > That's an idea GregKH brought up a few days ago here:
> > > https://lore.kernel.or
On Wed, Apr 17, 2024 at 03:38:28PM +0200, Greg KH wrote:
> > That afaics makes them useless for the stable team (Greg may correct
> > me
> > if I'm wrong here), as they deal with the commits and have no easy,
> > fast, and reliable way to look up the patch posting to query this. Or is
> > the
On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
> On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> > On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> >>
> >> Could you please create the email alias
> >> do-not-apply-to-s
On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
> > In general, I feel this information belongs in the patch basement
> > (the place where change-id, base-commit, etc goes). E.g.:
> >
> > stable-autosel: ignore
> > [This fix requires a feature that is only present in
On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>>
>> Could you please create the email alias
>> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
>> just like sta...@kernel.org
On 4/17/24 2:52 PM, Konstantin Ryabitsev wrote:
> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>> Hi kernel.org helpdesk!
>>
>> Could you please create the email alias
>> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
>
On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> just like sta...@kernel.org does?
>
> That's an idea GregKH
On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote:
> > at the scripts used by stable developers - and maybe at the ML server - to
> > catch different variations won't hurt, as it sounds likely that people will
> > end messing up with a big name like "do-not-a
On Wed, Apr 17, 2024 at 09:09:26AM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 17 Apr 2024 09:48:18 +0200
> Thorsten Leemhuis escreveu:
>
> > Hi kernel.org helpdesk!
> >
> > Could you please create the email alias
> > do-not-apply-to-sta...@kernel.org whic
Em Wed, 17 Apr 2024 09:48:18 +0200
Thorsten Leemhuis escreveu:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> just like sta...@kernel.org does?
>
> That's an idea GregKH
On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> just like sta...@kernel.org does?
>
> That's an idea GregKH
Hi kernel.org helpdesk!
Could you please create the email alias
do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
just like sta...@kernel.org does?
That's an idea GregKH brought up a few days ago here:
https://lore.kernel.org/all/2024041123-earthling-primarily-4656@gregkh
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
The patch below does not apply to the 6.7-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
Thanks,
Sasha
-- original commit in Linus's tree --
>F
On Thu, Feb 29, 2024 at 02:34:35PM +0100, Linus Walleij wrote:
> On Wed, Jan 31, 2024 at 7:27 AM Yan Zhao wrote:
>
> > Apply the page shift to PFN to get physical address for final VA.
> > The macro __va should take physical address instead of PFN as input.
> >
>
On Wed, Jan 31, 2024 at 7:27 AM Yan Zhao wrote:
> Apply the page shift to PFN to get physical address for final VA.
> The macro __va should take physical address instead of PFN as input.
>
> Fixes: 2d78057f0dd4 ("asm-generic/page.h: Make pfn accessors static inlines")
>
From: Hyeongtak Ji
This patch changes DAMOS_PROMOTE and DAMOS_DEMOTE to use target_nid of
sysfs as the destination NUMA node of migration. This has been tested
on qemu as follows:
$ cd /sys/kernel/mm/damon/admin/kdamonds/
$ cat contexts//schemes//action
promote
$ echo 1 >
On Wed, Jan 31, 2024 at 2:28 PM Yan Zhao wrote:
>
> Apply the page shift to PFN to get physical address for final VA.
> The macro __va should take physical address instead of PFN as input.
>
> Fixes: c1884e1e1164 ("csky: Make pfn accessors static inlines")
> Signed-off
On Wed, Jan 31, 2024 at 2:27 PM Yan Zhao wrote:
>
> Apply the page shift to PFN to get physical address for final VA.
> The macro __va should take physical address instead of PFN as input.
>
> Fixes: 2d78057f0dd4 ("asm-generic/page.h: Make pfn accessors static inlines")
On Fri, Feb 02, 2024 at 08:04:34AM +0100, Arnd Bergmann wrote:
> On Fri, Feb 2, 2024, at 02:02, Yan Zhao wrote:
> > On Thu, Feb 01, 2024 at 06:46:46AM +0100, Arnd Bergmann wrote:
> >>
> >> I think it's fair to assume we won't need asm-generic/page.h any
> >> more, as we likely won't be adding new
On Thu, Feb 1, 2024, at 11:46, Geert Uytterhoeven wrote:
> Hi Arnd,
>
> On Thu, Feb 1, 2024 at 11:11 AM Arnd Bergmann wrote:
>> I think it's fair to assume we won't need asm-generic/page.h any
>> more, as we likely won't be adding new NOMMU architectures.
>
> So you think riscv-nommu (k210) was
On Fri, Feb 2, 2024, at 02:02, Yan Zhao wrote:
> On Thu, Feb 01, 2024 at 06:46:46AM +0100, Arnd Bergmann wrote:
>>
>> I think it's fair to assume we won't need asm-generic/page.h any
>> more, as we likely won't be adding new NOMMU architectures.
>> I can have a look myself at removing any such
On Thu, Feb 01, 2024 at 06:46:46AM +0100, Arnd Bergmann wrote:
> On Thu, Feb 1, 2024, at 01:01, Yan Zhao wrote:
> > On Wed, Jan 31, 2024 at 12:48:38PM +0100, Arnd Bergmann wrote:
> >> On Wed, Jan 31, 2024, at 06:51, Yan Zhao wrote:
> >>
> >> How exactly did you notice the function being wrong,
>
Hi Arnd,
On Thu, Feb 1, 2024 at 11:11 AM Arnd Bergmann wrote:
> I think it's fair to assume we won't need asm-generic/page.h any
> more, as we likely won't be adding new NOMMU architectures.
So you think riscv-nommu (k210) was the last one we will ever see?
Gr{oetje,eeting}s,
On Thu, Feb 1, 2024, at 01:01, Yan Zhao wrote:
> On Wed, Jan 31, 2024 at 12:48:38PM +0100, Arnd Bergmann wrote:
>> On Wed, Jan 31, 2024, at 06:51, Yan Zhao wrote:
>>
>> How exactly did you notice the function being wrong,
>> did you try to add a user somewhere, or just read through
>> the code?
>
macro __va, with PAGE_SHIFT applying to the converted VA, which
> > is not right under most conditions, especially when there's an offset in
> > __va.
> >
> >
> > Yan Zhao (4):
> > asm-generic/page.h: apply page shift to PFN instead of VA in
> > pfn_to_
most conditions, especially when there's an offset in
> __va.
>
>
> Yan Zhao (4):
> asm-generic/page.h: apply page shift to PFN instead of VA in
> pfn_to_virt
> csky: apply page shift to PFN instead of VA in pfn_to_virt
> Hexagon: apply page shift to PFN instead o
On Wed, Jan 31, 2024 at 7:25 AM Yan Zhao wrote:
> This is a tiny fix to pfn_to_virt() for some platforms.
>
> The original implementaion of pfn_to_virt() takes PFN instead of PA as the
> input to macro __va, with PAGE_SHIFT applying to the converted VA, which
> is not right under most
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: 232ba1630c66 ("openrisc: Make pfn accessors statics inlines")
Signed-off-by: Yan Zhao
---
arch/openrisc/include/asm/page.h | 2 +-
1 file
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: d6e81532b10d ("Hexagon: Make pfn accessors statics inlines")
Signed-off-by: Yan Zhao
---
arch/hexagon/include/asm/page.h | 2 +-
1 file
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: c1884e1e1164 ("csky: Make pfn accessors static inlines")
Signed-off-by: Yan Zhao
---
arch/csky/include/asm/page.h | 2 +-
1 file changed, 1
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: 2d78057f0dd4 ("asm-generic/page.h: Make pfn accessors static inlines")
Signed-off-by: Yan Zhao
---
include/asm-generic/page.h | 2 +-
1 file
):
asm-generic/page.h: apply page shift to PFN instead of VA in
pfn_to_virt
csky: apply page shift to PFN instead of VA in pfn_to_virt
Hexagon: apply page shift to PFN instead of VA in pfn_to_virt
openrisc: apply page shift to PFN instead of VA in pfn_to_virt
arch/csky/include/asm
On Wed, 20 Dec 2023 17:15:06 +0800
Dongliang Cui wrote:
> I found that in the latest version, the nodes of
> tracefs have been changed to dynamically created.
>
> This has caused me to encounter a problem where
> the gid I specified in the mounting parameters
> cannot
I found that in the latest version, the nodes of
tracefs have been changed to dynamically created.
This has caused me to encounter a problem where
the gid I specified in the mounting parameters
cannot apply to all files, as in the following
situation:
/data/tmp/events # mount | grep tracefs
On Wed, 13 Sep 2023 02:20:49 +
SeongJae Park wrote:
> DAMON provides damon_aggregated tracepoint, which exposes details of
> each region and its access monitoring results. It is useful for
> getting whole monitoring results, e.g., for recording purposes.
>
> For investigations of DAMOS,
DAMON provides damon_aggregated tracepoint, which exposes details of
each region and its access monitoring results. It is useful for
getting whole monitoring results, e.g., for recording purposes.
For investigations of DAMOS, DAMON Sysfs interface provides DAMOS
statistics and tried_regions
DAMON provides damon_aggregated tracepoint, which exposes details of
each region and its access monitoring results. It is useful for
getting whole monitoring results, e.g., for recording purposes.
For investigations of DAMOS, DAMON Sysfs interface provides DAMOS
statistics and tried_regions
On Mon, 11 Sep 2023 20:36:42 +
SeongJae Park wrote:
> > Then tracing is fully enabled here, and now we enter:
> >
> > if (trace_damos_before_apply_enabled()) {
> > trace_damos_before_apply(cidx, sidx, tidx, r,
> > damon_nr_regions(t));
> > }
>
On Tue, 12 Sep 2023 01:43:08 +
SeongJae Park wrote:
> Nevertheless, since the variable is unsigned int, I would need to use UINT_MAX
> instead. To make the code easier to understand, I'd prefer to add a third
> parameter, as you suggested as another option at the original reply, like
>
On Mon, 11 Sep 2023 16:51:44 -0400 Steven Rostedt wrote:
> On Mon, 11 Sep 2023 20:36:42 +
> SeongJae Park wrote:
>
> > > Then tracing is fully enabled here, and now we enter:
> > >
> > > if (trace_damos_before_apply_enabled()) {
> > > trace_damos_before_apply(cidx, sidx, tidx,
Hi Steven,
On Mon, 11 Sep 2023 14:19:55 -0400 Steven Rostedt wrote:
> On Mon, 11 Sep 2023 04:59:07 +
> SeongJae Park wrote:
>
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -950,6 +950,28 @@ static void damos_apply_scheme(struct damon_ctx *c,
> > struct damon_target *t,
> >
On Mon, 11 Sep 2023 04:59:07 +
SeongJae Park wrote:
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -950,6 +950,28 @@ static void damos_apply_scheme(struct damon_ctx *c,
> struct damon_target *t,
> struct timespec64 begin, end;
> unsigned long sz_applied = 0;
> int
On Mon, 11 Sep 2023 16:31:27 -0400 Steven Rostedt wrote:
> On Mon, 11 Sep 2023 19:05:04 +
> SeongJae Park wrote:
>
> > > Also, this if statement is only done when the trace event is enabled, so
> > > it's equivalent to:
> > >
> > > if (trace_damos_before_apply_enabled()) {
> > >
On Mon, 11 Sep 2023 19:05:04 +
SeongJae Park wrote:
> > Also, this if statement is only done when the trace event is enabled, so
> > it's equivalent to:
> >
> > if (trace_damos_before_apply_enabled()) {
> > if (sdx >= 0)
> > trace_damos_before_apply(cidx,
DAMON provides damon_aggregated tracepoint, which exposes details of
each region and its access monitoring results. It is useful for
getting whole monitoring results, e.g., for recording purposes.
For investigations of DAMOS, DAMON Sysfs interface provides DAMOS
statistics and tried_regions
: Peter Zijlstra
CommitterDate: Fri, 16 Apr 2021 16:32:40 +02:00
perf: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES to children
As with other ioctls (such as PERF_EVENT_IOC_{ENABLE,DISABLE}), fix up
handling of PERF_EVENT_IOC_MODIFY_ATTRIBUTES to also apply to children.
Suggested-by: Dmitry Vyukov
From: Takashi Iwai
commit c6423ed2da6214a68527446b5f8e09cf7162b2ce upstream.
There is another HP ZBook G5 model with the PCI SSID 103c:844f that
requires the same quirk for controlling the mute LED. Add the
corresponding entry to the quirk table.
BugLink:
From: Takashi Iwai
commit c6423ed2da6214a68527446b5f8e09cf7162b2ce upstream.
There is another HP ZBook G5 model with the PCI SSID 103c:844f that
requires the same quirk for controlling the mute LED. Add the
corresponding entry to the quirk table.
BugLink:
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and
As with other ioctls (such as PERF_EVENT_IOC_{ENABLE,DISABLE}), fix up
handling of PERF_EVENT_IOC_MODIFY_ATTRIBUTES to also apply to children.
Suggested-by: Dmitry Vyukov
Reviewed-by: Dmitry Vyukov
Signed-off-by: Marco Elver
---
kernel/events/core.c | 22 +-
1 file changed
Reviewed-by: Chia-Wei Wang
> -Original Message-
> From: Andrew Jeffery
> Sent: Friday, March 19, 2021 2:28 PM
> To: openipmi-develo...@lists.sourceforge.net; open...@lists.ozlabs.org;
> miny...@acm.org
> Subject: [PATCH v2 21/21] ipmi: kcs_bmc_aspeed: Optionally appl
Hi,
On Thu, Feb 11, 2021 at 08:36:03AM +0100, Krzysztof Kozlowski wrote:
> On Wed, Feb 10, 2021 at 04:56:45PM -0600, Ricardo Rivera-Matos wrote:
> > The latest datasheet revision for BQ25980, BQ25975, and BQ25960 changed
> >
> > various register step sizes and offset values.
> >
> > This patch
From: Ikjoon Jang
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds
From: Ikjoon Jang
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds
From: Ikjoon Jang
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds
From: Ikjoon Jang
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds
From: Ikjoon Jang
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds
From: Ikjoon Jang
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds
From: Ikjoon Jang
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds
From: Jiahua Yu
spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Signed-off-by: Jiahua Yu
---
drivers/video/fbdev/omap2/omapfb/dss/apply.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
On Fri, Mar 19, 2021 at 01:27:52AM CDT, Andrew Jeffery wrote:
>Some Aspeed KCS devices can derive the status register address from the
>address of the data register. As such, the address of the status
>register can be implicit in the configuration if desired. On the other
>hand, sometimes address
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and
On Mon, 29 Mar 2021 08:23:52 +0200,
Ikjoon Jang wrote:
>
> On Wed, Mar 24, 2021 at 8:49 PM Takashi Iwai wrote:
> >
> > On Wed, 24 Mar 2021 13:03:14 +0100,
> > Ikjoon Jang wrote:
> > >
> > > On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund
> > >
> > > wrote:
> > >
> > > On Wed, 2021-03-24 at
On Wed, Mar 24, 2021 at 8:49 PM Takashi Iwai wrote:
>
> On Wed, 24 Mar 2021 13:03:14 +0100,
> Ikjoon Jang wrote:
> >
> > On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund
> >
> > wrote:
> >
> > On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote:
> > > Logitech ConferenceCam Connect is a
On Wed, 2021-03-24 at 13:49 +0100, Takashi Iwai wrote:
> On Wed, 24 Mar 2021 13:03:14 +0100,
> Ikjoon Jang wrote:
> >
> > On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund
> >
> > wrote:
> >
>
> The Logitech devices with 046d:* should be covered generally in
> snd_usb_ctl_msg_quirk(), so I guess
On Wed, 24 Mar 2021 13:03:14 +0100,
Ikjoon Jang wrote:
>
> On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund
> wrote:
>
> On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote:
> > Logitech ConferenceCam Connect is a compound USB device with UVC and
> > UAC. Not 100% reproducible but
As with other ioctls (such as PERF_EVENT_IOC_{ENABLE,DISABLE}), fix up
handling of PERF_EVENT_IOC_MODIFY_ATTRIBUTES to also apply to children.
Link: https://lkml.kernel.org/r/ybqvay8atmyto...@hirez.programming.kicks-ass.net
Suggested-by: Dmitry Vyukov
Reviewed-by: Dmitry Vyukov
Signed-off
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote:
> Logitech ConferenceCam Connect is a compound USB device with UVC and
> UAC. Not 100% reproducible but sometimes it keeps responding STALL to
> every control transfer once it receives get_freq request.
>
> This patch adds 046d:0x084c to a
Logitech ConferenceCam Connect is a compound USB device with UVC and
UAC. Not 100% reproducible but sometimes it keeps responding STALL to
every control transfer once it receives get_freq request.
This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list.
Bugzilla:
Apply the HW constraint rules added by the BE DAIs. The constraint rules
are applied after the fixup is called for the HW parameters. This way, if
the HW parameters do not correspond with the HW capabilities, the
constraint rules will return an error. The mask and the interval
constraints
From: Xiaoliang Yu
commit e1c86210fe27428399643861b81b080eccd79f87 upstream.
There is another fix for headset-mic problem on Redmibook (1d72:1602),
it also works on Redmibook Air (1d72:1947), which has the same issue.
Signed-off-by: Xiaoliang Yu
Cc:
Link:
From: Xiaoliang Yu
commit b95bc12e0412d14d5fc764f0b82631c7bcaf1959 upstream.
Built-in microphone and combojack on Xiaomi Notebook Pro (1d72:1701) needs
to be fixed, the existing quirk for Dell works well on that machine.
Signed-off-by: Xiaoliang Yu
Cc:
Link:
From: Xiaoliang Yu
commit e1c86210fe27428399643861b81b080eccd79f87 upstream.
There is another fix for headset-mic problem on Redmibook (1d72:1602),
it also works on Redmibook Air (1d72:1947), which has the same issue.
Signed-off-by: Xiaoliang Yu
Cc:
Link:
From: Xiaoliang Yu
commit b95bc12e0412d14d5fc764f0b82631c7bcaf1959 upstream.
Built-in microphone and combojack on Xiaomi Notebook Pro (1d72:1701) needs
to be fixed, the existing quirk for Dell works well on that machine.
Signed-off-by: Xiaoliang Yu
Cc:
Link:
From: Xiaoliang Yu
commit b95bc12e0412d14d5fc764f0b82631c7bcaf1959 upstream.
Built-in microphone and combojack on Xiaomi Notebook Pro (1d72:1701) needs
to be fixed, the existing quirk for Dell works well on that machine.
Signed-off-by: Xiaoliang Yu
Cc:
Link:
From: Xiaoliang Yu
commit e1c86210fe27428399643861b81b080eccd79f87 upstream.
There is another fix for headset-mic problem on Redmibook (1d72:1602),
it also works on Redmibook Air (1d72:1947), which has the same issue.
Signed-off-by: Xiaoliang Yu
Cc:
Link:
Some Aspeed KCS devices can derive the status register address from the
address of the data register. As such, the address of the status
register can be implicit in the configuration if desired. On the other
hand, sometimes address schemes might be requested that are incompatible
with the default
Barry Song writes:
> BATCHED_UNMAP_TLB_FLUSH is used on x86 to do batched tlb shootdown by
> sending one IPI to TLB flush all entries after unmapping pages rather
> than sending an IPI to flush each individual entry.
> On arm64, tlb shootdown is done by hardware. Flush instructions are
>
1 - 100 of 4625 matches
Mail list logo
