On Sat, 2020-11-21 at 14:03 -0800, Jakub Kicinski wrote:
> Applied to net with the typo fixed, thanks!
Thanks!
Is there any chance it'll be in 5.10 or will it have to wait for the 5.11
merge window?
Also it should be applied to all supported/stable kernels. I guess that'll
have to wait until
On Fri, 2020-11-20 at 12:15 +0300, Sergei Shtylyov wrote:
> > Investigation on the matter shows that UDP and ICMP traffic from the
> ^ "no" missing?
Yes indeed. Thanks and sorry for the typo.
Regards,
--
Yves-Alexis
-by: Matti Vuorela
Signed-off-by: Yves-Alexis Perez
Link:
https://lore.kernel.org/linux-usb/caan0qaxmysj9vx3zemkviv_b19ju-_exn8yn_usefxpjs6g...@mail.gmail.com/
Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038
Cc: sta...@vger.kernel.org
---
drivers/net/usb/ipheth.c | 2 +-
1
On Tue, 2019-01-01 at 13:33 +0100, Yves-Alexis Perez wrote:
> Hi,
>
> with the upgrade to 4.19 in Debian sid, I experienced a regression with CIFS
> filesystems.
>
> The server is running Debian stretch with samba, the clients are running
> Debian sid or stretch. With 4.
Hi,
with the upgrade to 4.19 in Debian sid, I experienced a regression with CIFS
filesystems.
The server is running Debian stretch with samba, the clients are running
Debian sid or stretch. With 4.18 kernels everything is fine, but with 4.19
while the mount succeeds, any read() syscall on a file
On Thu, 2018-02-22 at 13:02 +0100, Yves-Alexis Perez wrote:
> On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> > Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> > files there say?
>
> Unfortunately I don't have access to a powerpc
On Thu, 2018-02-22 at 13:02 +0100, Yves-Alexis Perez wrote:
> On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> > Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> > files there say?
>
> Unfortunately I don't have access to a powerpc
On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
> With the patches I just sent, for pseries and powernv, the mitigation
> should be in place. On machines with updated firmware we'll use the
> hardware-assisted L1 flush, otherwise we fallback to doing it in
> software.
So as of 4.9.82
On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
> With the patches I just sent, for pseries and powernv, the mitigation
> should be in place. On machines with updated firmware we'll use the
> hardware-assisted L1 flush, otherwise we fallback to doing it in
> software.
So as of 4.9.82
On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> files there say?
Unfortunately I don't have access to a powerpc box where I could run a new
kernel and try it on. I'll check with our ppc porters and see if I
On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> files there say?
Unfortunately I don't have access to a powerpc box where I could run a new
kernel and try it on. I'll check with our ppc porters and see if I
On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote:
> So I guess this patch is OK for now, but we do need a full back port of
> 222f20f to 4.9.
Hi,
in the light of this, do you know the full status of protections against
Meltdown on powerpc/ppc64el architecures on 4.9?
Regards,
--
On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote:
> So I guess this patch is OK for now, but we do need a full back port of
> 222f20f to 4.9.
Hi,
in the light of this, do you know the full status of protections against
Meltdown on powerpc/ppc64el architecures on 4.9?
Regards,
--
On Tue, 2018-02-20 at 14:25 -0800, Jacob Pan wrote:
> I didn't know about chipsec but reading the code seems to rely on an
> out-of-tree kernel module. I don't think it matches what we need here.
Yes good indeed, I had forgot about that. Maybe the userland part is still
useful, but there's
On Tue, 2018-02-20 at 14:25 -0800, Jacob Pan wrote:
> I didn't know about chipsec but reading the code seems to rely on an
> out-of-tree kernel module. I don't think it matches what we need here.
Yes good indeed, I had forgot about that. Maybe the userland part is still
useful, but there's
On Tue, 2018-02-13 at 13:40 -0800, Raj, Ashok wrote:
> This version has only hw dumps for now, but we plan to add some other things
> like walking 2nd level page-tables, or get some SVM specific data from the
> driver in the future.
Hi,
I'm not sure how much you know about chipsec [1], but
On Tue, 2018-02-13 at 13:40 -0800, Raj, Ashok wrote:
> This version has only hw dumps for now, but we plan to add some other things
> like walking 2nd level page-tables, or get some SVM specific data from the
> driver in the future.
Hi,
I'm not sure how much you know about chipsec [1], but
On Sat, 2018-02-17 at 09:35 -0800, Guenter Roeck wrote:
> Hmm, that chunk really doesn't do what the original patch is supposed to do,
> meaning it won't provide the vulnerability protection it is supposed to
> provide
> (AFAICS that is Meltdown). Just a note in case anyone is concerned about
>
On Sat, 2018-02-17 at 09:35 -0800, Guenter Roeck wrote:
> Hmm, that chunk really doesn't do what the original patch is supposed to do,
> meaning it won't provide the vulnerability protection it is supposed to
> provide
> (AFAICS that is Meltdown). Just a note in case anyone is concerned about
>
On Tue, 2018-02-13 at 16:29 +0100, Greg Kroah-Hartman wrote:
> > arch/powerpc/kernel/entry_64.S: Assembler messages:
> > arch/powerpc/kernel/entry_64.S:260: Error: unrecognized opcode:
> > `rfi_to_user'
> > arch/powerpc/kernel/entry_64.S:270: Error: unrecognized opcode:
> > `rfi_to_kernel'
> >
On Tue, 2018-02-13 at 16:29 +0100, Greg Kroah-Hartman wrote:
> > arch/powerpc/kernel/entry_64.S: Assembler messages:
> > arch/powerpc/kernel/entry_64.S:260: Error: unrecognized opcode:
> > `rfi_to_user'
> > arch/powerpc/kernel/entry_64.S:270: Error: unrecognized opcode:
> > `rfi_to_kernel'
> >
On Wed, 2018-02-07 at 20:46 +0100, Yves-Alexis Perez wrote:
> Maybe. I tried with removing the MTU setting, and I get (on ping again)
>
> févr. 07 20:44:01 scapa kernel: mtu: 1266
>
> which means I would get -EINVAL on standards kernels, which is not really good
> eithe
On Wed, 2018-02-07 at 20:46 +0100, Yves-Alexis Perez wrote:
> Maybe. I tried with removing the MTU setting, and I get (on ping again)
>
> févr. 07 20:44:01 scapa kernel: mtu: 1266
>
> which means I would get -EINVAL on standards kernels, which is not really good
> eithe
On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez <cor...@debian.org>
>
> Hi Yves-Alexis -
>
> I apologize for the problem. It seems to me that tunneling with an
> outer MTU that causes the inner MTU to
On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez
>
> Hi Yves-Alexis -
>
> I apologize for the problem. It seems to me that tunneling with an
> outer MTU that causes the inner MTU to be smaller than the min, is
> po
On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote:
> I'll try to printk the mtu before returning EINVAL to see why it's lower than
> 1280, but maybe the IP encapsulation is not correctly handled?
I did:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 3763dc
On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote:
> I'll try to printk the mtu before returning EINVAL to see why it's lower than
> 1280, but maybe the IP encapsulation is not correctly handled?
I did:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 3763dc
On Wed, 2018-02-07 at 17:38 +0100, Yves-Alexis Perez wrote:
> Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping
> to an IPv6 address I get:
>
> ping: sendmsg: Invalid argument
I forgot an important bit of information: due to the way routers usually broke
path M
On Wed, 2018-02-07 at 17:38 +0100, Yves-Alexis Perez wrote:
> Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping
> to an IPv6 address I get:
>
> ping: sendmsg: Invalid argument
I forgot an important bit of information: due to the way routers usually broke
path M
Hi Mike,
I noticed a regression in 4.14.16 stable kernel (I assume it's also
present in mainline).
I'm using an IPsec setup where I tunnel all my IP trafic to a gateway.
The tunnel can use either IPv6 or IPv4 (depending on what's available
locally) and will route both IPv4 and IPv6 (my gateway
Hi Mike,
I noticed a regression in 4.14.16 stable kernel (I assume it's also
present in mainline).
I'm using an IPsec setup where I tunnel all my IP trafic to a gateway.
The tunnel can use either IPv6 or IPv4 (depending on what's available
locally) and will route both IPv4 and IPv6 (my gateway
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> We don't refuse to load the affected microcodes; just refuse to use SPEC_CTRL
> if they're detected.
Hi David,
Are we sure those microcodes instability are only related to SPEC_CTRL?
Regards,
--
Yves-Alexis
signature.asc
Description:
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> We don't refuse to load the affected microcodes; just refuse to use SPEC_CTRL
> if they're detected.
Hi David,
Are we sure those microcodes instability are only related to SPEC_CTRL?
Regards,
--
Yves-Alexis
signature.asc
Description:
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> Some old Atoms, anything in family 5 or 4, and newer CPUs when they advertise
> the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, are not
> vulnerable.
>
> Roll the AMD exemption into the x86_match_cpu() table too.
>
>
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> Some old Atoms, anything in family 5 or 4, and newer CPUs when they advertise
> the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, are not
> vulnerable.
>
> Roll the AMD exemption into the x86_match_cpu() table too.
>
>
On Mon, 2018-01-08 at 19:26 +0100, Willy Tarreau wrote:
> You're totally right, I discovered during my later developments that
> indeed PCID is not exposed there. So we take the hit of a full TLB
> flush twice per syscall.
So I really think it might make sense to redo the tests with PCID, because
On Mon, 2018-01-08 at 19:26 +0100, Willy Tarreau wrote:
> You're totally right, I discovered during my later developments that
> indeed PCID is not exposed there. So we take the hit of a full TLB
> flush twice per syscall.
So I really think it might make sense to redo the tests with PCID, because
On Mon, 2018-01-08 at 18:07 +0100, Yves-Alexis Perez wrote:
> On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> > - the highest performance impact on VMs comes from having PTI on the
> > guest kernel (-45%). At this point it makes no difference whether
> >
On Mon, 2018-01-08 at 18:07 +0100, Yves-Alexis Perez wrote:
> On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> > - the highest performance impact on VMs comes from having PTI on the
> > guest kernel (-45%). At this point it makes no difference whether
> >
On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> - the highest performance impact on VMs comes from having PTI on the
> guest kernel (-45%). At this point it makes no difference whether
> the host kernel has it or not.
Hi Willy,
out of curiosity, is the pcid/invpcid flags
On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> - the highest performance impact on VMs comes from having PTI on the
> guest kernel (-45%). At this point it makes no difference whether
> the host kernel has it or not.
Hi Willy,
out of curiosity, is the pcid/invpcid flags
On Fri, 2018-01-05 at 15:26 +0100, Paolo Bonzini wrote:
> Those from November seem way too early to include IBRS/IBPB. Maybe the
> two from December 3rd, but I wouldn't be 100% sure.
So, for my CPU with updated microcode:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
On Fri, 2018-01-05 at 15:26 +0100, Paolo Bonzini wrote:
> Those from November seem way too early to include IBRS/IBPB. Maybe the
> two from December 3rd, but I wouldn't be 100% sure.
So, for my CPU with updated microcode:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
On Fri, 2018-01-05 at 14:28 +0100, Greg KH wrote:
> > iucode-tool -L -tr n10ur16w.iso |grep 2017-11
> >001/020: sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size
> > 18432
>
> That's been out for a while now:
>
On Fri, 2018-01-05 at 14:28 +0100, Greg KH wrote:
> > iucode-tool -L -tr n10ur16w.iso |grep 2017-11
> >001/020: sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size
> > 18432
>
> That's been out for a while now:
>
On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote:
> > Are there plans to make the corresponding microcode support available?
> >
>
> The microcode patches should be released soon.
In the meantime, Lenovo has started issuing BIOS/UEFI updates which include
microcode updates for this.
See for
On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote:
> > Are there plans to make the corresponding microcode support available?
> >
>
> The microcode patches should be released soon.
In the meantime, Lenovo has started issuing BIOS/UEFI updates which include
microcode updates for this.
See for
On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote:
> @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in,
> u32 ecx_in,
> "=S" (*esi)
> : "a" (func), "b" (ebx_in), "c" (ecx_in)
> : "memory", "cc");
> +
On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote:
> @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in,
> u32 ecx_in,
> "=S" (*esi)
> : "a" (func), "b" (ebx_in), "c" (ecx_in)
> : "memory", "cc");
> +
rds,
>
> --
>
> From: Yves-Alexis Perez <cor...@corsac.net>
>
> commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.
>
> When you use the firmware usermode helper fallback with a timeout value set
> to a
> value greater than INT_MAX (2147483647) a cast ov
rds,
>
> --
>
> From: Yves-Alexis Perez
>
> commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.
>
> When you use the firmware usermode helper fallback with a timeout value set
> to a
> value greater than INT_MAX (2147483647) a cast overflow issue causes t
e and only set retval in specific
cases.
Signed-off-by: Yves-Alexis Perez <cor...@corsac.net>
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez <mcg...@kernel.org>
Cc: Ming Lei <ming
e and only set retval in specific
cases.
Signed-off-by: Yves-Alexis Perez
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez
Cc: Ming Lei
Cc: Bjorn Andersson
Cc: Greg Kroah-Hartman
Cc: sta...@vger.kernel.
On Thu, 2016-11-10 at 11:48 -0800, Luis R. Rodriguez wrote:
> > I haven't verified that this particular use case actually worked before,
> > but this code works with lower timeout values (e.g. 60 in the fallback
> > case), so this looks isolated.
>
> This is true, but as I noted the broken aspect
On Thu, 2016-11-10 at 11:48 -0800, Luis R. Rodriguez wrote:
> > I haven't verified that this particular use case actually worked before,
> > but this code works with lower timeout values (e.g. 60 in the fallback
> > case), so this looks isolated.
>
> This is true, but as I noted the broken aspect
On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote:
> Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is
> not set. This happens *only* when the UMH was explicitly requested on the
> async call, when the second argument to request_firmware_nowait() is false.
>
On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote:
> Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is
> not set. This happens *only* when the UMH was explicitly requested on the
> async call, when the second argument to request_firmware_nowait() is false.
>
On Sun, 2016-10-30 at 15:50 +0100, Yves-Alexis Perez wrote:
> wait_for_completion_interruptible_timeout() return value is either
> -ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
> or the number of jiffies left until timeout. The return value is stored in
On Sun, 2016-10-30 at 15:50 +0100, Yves-Alexis Perez wrote:
> wait_for_completion_interruptible_timeout() return value is either
> -ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
> or the number of jiffies left until timeout. The return value is stored in
From: Yves-Alexis Perez <cor...@debian.org>
wait_for_completion_interruptible_timeout() return value is either
-ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
or the number of jiffies left until timeout. The return value is stored in
From: Yves-Alexis Perez
wait_for_completion_interruptible_timeout() return value is either
-ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
or the number of jiffies left until timeout. The return value is stored in
a long, but in _request_firmware_load() it's silently
Hi,
when trying to (ab)use the firmware loading interface in a local kernel module
(in order to load the EEPROM content into a PCIE card), I noticed that the
manual firmware loading interface (the one from
/sys/class/firmware//{loading,data}) was broken.
After instrumenting the kernel I noticed
Hi,
when trying to (ab)use the firmware loading interface in a local kernel module
(in order to load the EEPROM content into a PCIE card), I noticed that the
manual firmware loading interface (the one from
/sys/class/firmware//{loading,data}) was broken.
After instrumenting the kernel I noticed
On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote:
> > This security feature reduces the predictability of
> > the kernel slab allocator against heap overflows.
>
> I would add "... rendering attacks much less stable." And if you can
> find a specific example exploit that is foiled by this, I
On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote:
> > This security feature reduces the predictability of
> > the kernel slab allocator against heap overflows.
>
> I would add "... rendering attacks much less stable." And if you can
> find a specific example exploit that is foiled by this, I
On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote:
> So yeah, maybe swap partitions are still more common than I thought.
> And I didn't even consider the possibility that people would hibernate
> a desktop like you do.
To be fair, it's *my* use case, because suspend won't work but I'm
On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote:
> So yeah, maybe swap partitions are still more common than I thought.
> And I didn't even consider the possibility that people would hibernate
> a desktop like you do.
To be fair, it's *my* use case, because suspend won't work but I'm
On mer., 2016-04-06 at 11:43 -0700, Linus Torvalds wrote:
> Hibernation is really quite nasty when you have to have a fairly big
> special partition for it, and shrink your memory down. Writing things
> to disk was a whole lot more reasonable back in the days when laptops
> had 16MB of memory.
On mer., 2016-04-06 at 11:43 -0700, Linus Torvalds wrote:
> Hibernation is really quite nasty when you have to have a fairly big
> special partition for it, and shrink your memory down. Writing things
> to disk was a whole lot more reasonable back in the days when laptops
> had 16MB of memory.
On dim., 2015-10-18 at 20:41 -0500, Serge E. Hallyn wrote:
> We shouldn't need a long-term solution. Your concern is bugs. After
> some time surely we'll feel that we have achieved a stable solution?
But this is actually the whole point: we need a long term solution, because
they will always be
On dim., 2015-10-18 at 20:41 -0500, Serge E. Hallyn wrote:
> We shouldn't need a long-term solution. Your concern is bugs. After
> some time surely we'll feel that we have achieved a stable solution?
But this is actually the whole point: we need a long term solution, because
they will always be
On jeu., 2015-05-14 at 14:35 +0200, Yves-Alexis Perez wrote:
> +# Generate a change file
> +(cd $KBUILD_OUTPUT; dpkg-genchanges -b >
> ../linux_${packageversion}_${debarch}.changes)
> +
Actually cwd during the build is KBUILD_OUTPUT already, so the cd part
is unnecessary (I
On jeu., 2015-05-14 at 14:35 +0200, Yves-Alexis Perez wrote:
+# Generate a change file
+(cd $KBUILD_OUTPUT; dpkg-genchanges -b
../linux_${packageversion}_${debarch}.changes)
+
Actually cwd during the build is KBUILD_OUTPUT already, so the cd part
is unnecessary (I can resend a v2 if really
A changes file (also called Debian upload control file) contains
information about binary packages, including the changelog entry, the
maintainer, the package list and the checksums.
It can be used by various Debian tools like dput and dcmd to execute
action on all the build packages at once, for
A changes file (also called Debian upload control file) contains
information about binary packages, including the changelog entry, the
maintainer, the package list and the checksums.
It can be used by various Debian tools like dput and dcmd to execute
action on all the build packages at once, for
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
> At Sat, 11 Apr 2015 09:31:35 +0200,
> Yves-Alexis Perez wrote:
> >
> > This model uses the same dock port as the previous generation.
> >
> > Signed-off-by: Yves-Alexis Perez
>
> Thanks, applied w
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
At Sat, 11 Apr 2015 09:31:35 +0200,
Yves-Alexis Perez wrote:
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez cor...@debian.org
Thanks, applied with Cc to stable.
But, at the next
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
> At Sat, 11 Apr 2015 09:31:35 +0200,
> Yves-Alexis Perez wrote:
> >
> > This model uses the same dock port as the previous generation.
> >
> > Signed-off-by: Yves-Alexis Perez
>
> Thanks, applied w
On sam., 2015-04-11 at 11:40 +0200, Toralf Förster wrote:
> Hi,
>
> /me wonders why you didn't add the new line directly under "Thinkpad X240" :
>
> SND_PCI_QUIRK(0x17aa, 0x2214, "Thinkpad X240",
> ALC292_FIXUP_TPT440_DOCK),
> SND_PCI_QUIRK(0x17aa, 0x2215, "Thinkpad",
>
how the ALSA
maintainers stand on this, but similar previous patches have been targeted to
stable so it might be worth adding it.
Regards,
--
Yves-Alexis Perez
Yves-Alexis Perez (1):
ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226)
sound/pci/hda/patch_realtek.c | 1 +
1 file changed
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 7438213..2087728 100644
--- a/sound/pci/hda
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
At Sat, 11 Apr 2015 09:31:35 +0200,
Yves-Alexis Perez wrote:
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez cor...@debian.org
Thanks, applied with Cc to stable.
But, at the next
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez cor...@debian.org
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 7438213..2087728 100644
how the ALSA
maintainers stand on this, but similar previous patches have been targeted to
stable so it might be worth adding it.
Regards,
--
Yves-Alexis Perez
Yves-Alexis Perez (1):
ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226)
sound/pci/hda/patch_realtek.c | 1 +
1 file changed
On sam., 2015-04-11 at 11:40 +0200, Toralf Förster wrote:
Hi,
/me wonders why you didn't add the new line directly under Thinkpad X240 :
SND_PCI_QUIRK(0x17aa, 0x2214, Thinkpad X240,
ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2215, Thinkpad,
On jeu., 2015-03-19 at 11:58 -0400, Benjamin Tissoires wrote:
> >
> > Am I right? Thanks for the information, I'll also try to point our
> > kernel maintainers to that thread and ask them if it's possible to
> > backport them to the 3.16 kernel for Jessie.
>
> Yes, please do. For the record,
On jeu., 2015-03-19 at 11:58 -0400, Benjamin Tissoires wrote:
Am I right? Thanks for the information, I'll also try to point our
kernel maintainers to that thread and ask them if it's possible to
backport them to the 3.16 kernel for Jessie.
Yes, please do. For the record, they are
On Thu, Mar 19, 2015 at 01:06:49PM -0400, Benjamin Tissoires wrote:
> To solve your problem, your desktop environment must have a "disable
> touchpad" switch in the configuration panel. At least, gnome has. This
> way, your settings should come back at each login.
> And if this is not sufficient
On Thu, Mar 19, 2015 at 01:06:49PM -0400, Benjamin Tissoires wrote:
To solve your problem, your desktop environment must have a disable
touchpad switch in the configuration panel. At least, gnome has. This
way, your settings should come back at each login.
And if this is not sufficient enough,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 11:58:31AM -0400, Benjamin Tissoires wrote:
> On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
> > Am I right? Thanks for the information, I'll also try to point our
> > kernel maintainers to that thre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 10:46:27AM -0400, Benjamin Tissoires wrote:
> On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
> > So I have two questions/remarks about this:
> >
> > - if I don't use the touchpad, do I need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, Feb 06, 2015 at 03:04:28PM -0500, Benjamin Tissoires wrote:
> Hi,
>
> This is the second episode of the Lenovo 2015 party :)
>
> Thanks to Andrew, we now have an idea within the driver of what are the extra
> buttons aimed for, and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, Feb 06, 2015 at 03:04:28PM -0500, Benjamin Tissoires wrote:
Hi,
This is the second episode of the Lenovo 2015 party :)
Thanks to Andrew, we now have an idea within the driver of what are the extra
buttons aimed for, and the patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 10:46:27AM -0400, Benjamin Tissoires wrote:
On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
So I have two questions/remarks about this:
- if I don't use the touchpad, do I need xf86-input-synaptics at all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 11:58:31AM -0400, Benjamin Tissoires wrote:
On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
Am I right? Thanks for the information, I'll also try to point our
kernel maintainers to that thread and ask them
On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
> > On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu wrote:
> > > v5:
> > > 1 Introduce video.use_native_backlight module parameter and set its
> > > value to false by default as
On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote:
On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
v5:
1 Introduce video.use_native_backlight module parameter and set its
value to false by default
On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote:
> If we are to use a Kconfig option, why don't we use one instead of rather than
> in addition to a command line option? Say, we have
> CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like
> the previous version
On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote:
If we are to use a Kconfig option, why don't we use one instead of rather than
in addition to a command line option? Say, we have
CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like
the previous version of
On ven., 2013-09-27 at 15:05 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
> > On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> > > Some testing on a *60 (T60,X60...) would also be best, I cannot test
> >
1 - 100 of 135 matches
Mail list logo
