- Linux-stable-mirror - lists.linaro.org

Re: Patch "x86/kexec: Allocate 8k PGDs for PTI" has been added to the 3.18-stable tree

by Hugh Dickins

On Mon, 17 Sep 2018, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > x86/kexec: Allocate 8k PGDs for PTI > > to the 3.18-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > x86-kexec-allocate-8k-pgds-for-pti.patch > and it can be found in the queue-3.18 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. I believe this commit is an example of the auto-selector being too eager, and this should not be in *any* of the stable trees. As the commit message indicates, it's a fix by Joerg for his PTI-x86-32 implementation - which has not been backported to any of the stable trees (yet), has it? In several of the recent stable trees, I think this will not do any actual harm; but it looks as if it will prevent relevant x86-32 configs from building on 3.18 (I see no definition of PGD_ALLOCATION_ORDER in linux-3.18.y - you preferred not to have any PTI in that tree), and I haven't checked whether its definition in older backports will build correctly here or not. Hugh > > > From foo@baz Mon Sep 17 11:45:57 CEST 2018 > From: Joerg Roedel <jroedel(a)suse.de> > Date: Wed, 25 Jul 2018 17:48:03 +0200 > Subject: x86/kexec: Allocate 8k PGDs for PTI > > From: Joerg Roedel <jroedel(a)suse.de> > > [ Upstream commit ca38dc8f2724d101038b1205122c93a1c7f38f11 ] > > Fuzzing the PTI-x86-32 code with trinity showed unhandled > kernel paging request oops-messages that looked a lot like > silent data corruption. > > Lot's of debugging and testing lead to the kexec-32bit code, > which is still allocating 4k PGDs when PTI is enabled. But > since it uses native_set_pud() to build the page-table, it > will unevitably call into __pti_set_user_pgtbl(), which > writes beyond the allocated 4k page. > > Use PGD_ALLOCATION_ORDER to allocate PGDs in the kexec code > to fix the issue. > > Signed-off-by: Joerg Roedel <jroedel(a)suse.de> > Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> > Tested-by: David H. Gutteridge <dhgutteridge(a)sympatico.ca> > Cc: "H . Peter Anvin" <hpa(a)zytor.com> > Cc: linux-mm(a)kvack.org > Cc: Linus Torvalds <torvalds(a)linux-foundation.org> > Cc: Andy Lutomirski <luto(a)kernel.org> > Cc: Dave Hansen <dave.hansen(a)intel.com> > Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> > Cc: Juergen Gross <jgross(a)suse.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Borislav Petkov <bp(a)alien8.de> > Cc: Jiri Kosina <jkosina(a)suse.cz> > Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> > Cc: Brian Gerst <brgerst(a)gmail.com> > Cc: David Laight <David.Laight(a)aculab.com> > Cc: Denys Vlasenko <dvlasenk(a)redhat.com> > Cc: Eduardo Valentin <eduval(a)amazon.com> > Cc: Greg KH <gregkh(a)linuxfoundation.org> > Cc: Will Deacon <will.deacon(a)arm.com> > Cc: aliguori(a)amazon.com > Cc: daniel.gruss(a)iaik.tugraz.at > Cc: hughd(a)google.com > Cc: keescook(a)google.com > Cc: Andrea Arcangeli <aarcange(a)redhat.com> > Cc: Waiman Long <llong(a)redhat.com> > Cc: Pavel Machek <pavel(a)ucw.cz> > Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org> > Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> > Cc: Jiri Olsa <jolsa(a)redhat.com> > Cc: Namhyung Kim <namhyung(a)kernel.org> > Cc: joro(a)8bytes.org > Link: https://lkml.kernel.org/r/1532533683-5988-4-git-send-email-joro@8bytes.org > Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > arch/x86/kernel/machine_kexec_32.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > --- a/arch/x86/kernel/machine_kexec_32.c > +++ b/arch/x86/kernel/machine_kexec_32.c > @@ -69,7 +69,7 @@ static void load_segments(void) > > static void machine_kexec_free_page_tables(struct kimage *image) > { > - free_page((unsigned long)image->arch.pgd); > + free_pages((unsigned long)image->arch.pgd, PGD_ALLOCATION_ORDER); > image->arch.pgd = NULL; > #ifdef CONFIG_X86_PAE > free_page((unsigned long)image->arch.pmd0); > @@ -85,7 +85,8 @@ static void machine_kexec_free_page_tabl > > static int machine_kexec_alloc_page_tables(struct kimage *image) > { > - image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL); > + image->arch.pgd = (pgd_t *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, > + PGD_ALLOCATION_ORDER); > #ifdef CONFIG_X86_PAE > image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL); > image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL); > > > Patches currently in stable-queue which might be from jroedel(a)suse.de are > > queue-3.18/x86-kexec-allocate-8k-pgds-for-pti.patch > queue-3.18/x86-mm-remove-in_nmi-warning-from-vmalloc_fault.patch >

7 years, 1 month

3
2
0 0

4.4.y build failure

by Dan Rue

I'm seeing the following i386 build failure with defconfig on 4.4-rc branch: $ make ARCH=i386 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h CC arch/x86/kernel/machine_kexec_32.o arch/x86/kernel/machine_kexec_32.c: In function ‘machine_kexec_free_page_tables’: arch/x86/kernel/machine_kexec_32.c:73:45: error: ‘PGD_ALLOCATION_ORDER’ undeclared (first use in this function); did you mean ‘PAGE_ALLOC_COSTLY_ORDER’? free_pages((unsigned long)image->arch.pgd, PGD_ALLOCATION_ORDER); ^~~~~~~~~~~~~~~~~~~~ PAGE_ALLOC_COSTLY_ORDER arch/x86/kernel/machine_kexec_32.c:73:45: note: each undeclared identifier is reported only once for each function it appears in arch/x86/kernel/machine_kexec_32.c: In function ‘machine_kexec_alloc_page_tables’: arch/x86/kernel/machine_kexec_32.c:90:11: error: ‘PGD_ALLOCATION_ORDER’ undeclared (first use in this function); did you mean ‘PAGE_ALLOC_COSTLY_ORDER’? PGD_ALLOCATION_ORDER); ^~~~~~~~~~~~~~~~~~~~ PAGE_ALLOC_COSTLY_ORDER scripts/Makefile.build:269: recipe for target 'arch/x86/kernel/machine_kexec_32.o' failed make[2]: *** [arch/x86/kernel/machine_kexec_32.o] Error 1 scripts/Makefile.build:476: recipe for target 'arch/x86/kernel' failed make[1]: *** [arch/x86/kernel] Error 2 Makefile:980: recipe for target 'arch/x86' failed make: *** [arch/x86] Error 2 Dan

7 years, 1 month

2
1
0 0

[PATCH] ALSA: fireworks: fix memory leak of response buffer at error path

by Takashi Sakamoto

After allocating memory object for response buffer, ALSA fireworks driver has leak of the memory object at error path. This commit releases the object at the error path. Fixes: 7d3c1d5901aa('ALSA: fireworks: delayed registration of sound card') Cc: <stable(a)vger.kernel.org> # v4.7+ Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/fireworks/fireworks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/firewire/fireworks/fireworks.c b/sound/firewire/fireworks/fireworks.c index 71a0613d3da0..f2d073365cf6 100644 --- a/sound/firewire/fireworks/fireworks.c +++ b/sound/firewire/fireworks/fireworks.c @@ -301,6 +301,8 @@ do_registration(struct work_struct *work) snd_efw_transaction_remove_instance(efw); snd_efw_stream_destroy_duplex(efw); snd_card_free(efw->card); + kfree(efw->resp_buf); + efw->resp_buf = NULL; dev_info(&efw->unit->device, "Sound card registration failed: %d\n", err); } -- 2.17.1

7 years, 1 month

2
1
0 0

[PATCH] ALSA: oxfw: fix memory leak of discovered stream formats at error path

by Takashi Sakamoto

After finishing discover of stream formats, ALSA OXFW driver has memory leak of allocated memory object at error path. This commit releases the memory object at the error path. Fixes: 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card') Cc: <stable(a)vger.kernel.org> # v4.7+ Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/oxfw/oxfw.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index 1e5b2c802635..63b3e1ce986e 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -207,6 +207,7 @@ static int detect_quirks(struct snd_oxfw *oxfw) static void do_registration(struct work_struct *work) { struct snd_oxfw *oxfw = container_of(work, struct snd_oxfw, dwork.work); + int i; int err; if (oxfw->registered) @@ -269,6 +270,12 @@ static void do_registration(struct work_struct *work) snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->rx_stream); if (oxfw->has_output) snd_oxfw_stream_destroy_simplex(oxfw, &oxfw->tx_stream); + for (i = 0; i < SND_OXFW_STREAM_FORMAT_ENTRIES; ++i) { + kfree(oxfw->tx_stream_formats[i]); + oxfw->tx_stream_formats[i] = NULL; + kfree(oxfw->rx_stream_formats[i]); + oxfw->rx_stream_formats[i] = NULL; + } snd_card_free(oxfw->card); dev_info(&oxfw->unit->device, "Sound card registration failed: %d\n", err); -- 2.17.1

7 years, 1 month

2
1
0 0

[PATCH] ALSA: oxfw: fix memory leak for model-dependent data at error path

by Takashi Sakamoto

After allocating model-dependent data, ALSA OXFW driver has memory leak of the data at error path. This commit releases the data at the error path. Fixes: 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card') Cc: <stable(a)vger.kernel.org> # v4.7+ Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/oxfw/oxfw.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index 63b3e1ce986e..9c8c527ebff9 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -277,6 +277,8 @@ static void do_registration(struct work_struct *work) oxfw->rx_stream_formats[i] = NULL; } snd_card_free(oxfw->card); + kfree(oxfw->spec); + oxfw->spec = NULL; dev_info(&oxfw->unit->device, "Sound card registration failed: %d\n", err); } -- 2.17.1

7 years, 1 month

2
1
0 0

[PATCH] ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path

by Takashi Sakamoto

After allocating model-dependent data for M-Audio FW1814 and ProjectMix I/O, ALSA bebob driver has memory leak at error path. This commit releases the allocated data at the error path. Fixes: 04a2c73c97eb('ALSA: bebob: delayed registration of sound card') Cc: <stable(a)vger.kernel.org> # v4.7+ Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/bebob/bebob.c | 2 ++ sound/firewire/bebob/bebob_maudio.c | 4 ---- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c index 730ea91d9be8..93676354f87f 100644 --- a/sound/firewire/bebob/bebob.c +++ b/sound/firewire/bebob/bebob.c @@ -263,6 +263,8 @@ do_registration(struct work_struct *work) error: mutex_unlock(&devices_mutex); snd_bebob_stream_destroy_duplex(bebob); + kfree(bebob->maudio_special_quirk); + bebob->maudio_special_quirk = NULL; snd_card_free(bebob->card); dev_info(&bebob->unit->device, "Sound card registration failed: %d\n", err); diff --git a/sound/firewire/bebob/bebob_maudio.c b/sound/firewire/bebob/bebob_maudio.c index bd55620c6a47..164f2126a676 100644 --- a/sound/firewire/bebob/bebob_maudio.c +++ b/sound/firewire/bebob/bebob_maudio.c @@ -290,10 +290,6 @@ snd_bebob_maudio_special_discover(struct snd_bebob *bebob, bool is1814) bebob->midi_output_ports = 2; } end: - if (err < 0) { - kfree(params); - bebob->maudio_special_quirk = NULL; - } mutex_unlock(&bebob->mutex); return err; } -- 2.17.1

7 years, 1 month

2
1
0 0

FAILED: patch "[PATCH] x86/mm: Use WRITE_ONCE() when setting PTEs" failed to apply to 4.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.18-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 <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 9bc4f28af75a91aea0ae383f50b0a430c4509303 Mon Sep 17 00:00:00 2001 From: Nadav Amit <namit(a)vmware.com> Date: Sun, 2 Sep 2018 11:14:50 -0700 Subject: [PATCH] x86/mm: Use WRITE_ONCE() when setting PTEs When page-table entries are set, the compiler might optimize their assignment by using multiple instructions to set the PTE. This might turn into a security hazard if the user somehow manages to use the interim PTE. L1TF does not make our lives easier, making even an interim non-present PTE a security hazard. Using WRITE_ONCE() to set PTEs and friends should prevent this potential security hazard. I skimmed the differences in the binary with and without this patch. The differences are (obviously) greater when CONFIG_PARAVIRT=n as more code optimizations are possible. For better and worse, the impact on the binary with this patch is pretty small. Skimming the code did not cause anything to jump out as a security hazard, but it seems that at least move_soft_dirty_pte() caused set_pte_at() to use multiple writes. Signed-off-by: Nadav Amit <namit(a)vmware.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Sean Christopherson <sean.j.christopherson(a)intel.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lkml.kernel.org/r/20180902181451.80520-1-namit@vmware.com diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index e4ffa565a69f..690c0307afed 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -1195,7 +1195,7 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma, return xchg(pmdp, pmd); } else { pmd_t old = *pmdp; - *pmdp = pmd; + WRITE_ONCE(*pmdp, pmd); return old; } } diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h index f773d5e6c8cc..ce2b59047cb8 100644 --- a/arch/x86/include/asm/pgtable_64.h +++ b/arch/x86/include/asm/pgtable_64.h @@ -55,15 +55,15 @@ struct mm_struct; void set_pte_vaddr_p4d(p4d_t *p4d_page, unsigned long vaddr, pte_t new_pte); void set_pte_vaddr_pud(pud_t *pud_page, unsigned long vaddr, pte_t new_pte); -static inline void native_pte_clear(struct mm_struct *mm, unsigned long addr, - pte_t *ptep) +static inline void native_set_pte(pte_t *ptep, pte_t pte) { - *ptep = native_make_pte(0); + WRITE_ONCE(*ptep, pte); } -static inline void native_set_pte(pte_t *ptep, pte_t pte) +static inline void native_pte_clear(struct mm_struct *mm, unsigned long addr, + pte_t *ptep) { - *ptep = pte; + native_set_pte(ptep, native_make_pte(0)); } static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte) @@ -73,7 +73,7 @@ static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte) static inline void native_set_pmd(pmd_t *pmdp, pmd_t pmd) { - *pmdp = pmd; + WRITE_ONCE(*pmdp, pmd); } static inline void native_pmd_clear(pmd_t *pmd) @@ -109,7 +109,7 @@ static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp) static inline void native_set_pud(pud_t *pudp, pud_t pud) { - *pudp = pud; + WRITE_ONCE(*pudp, pud); } static inline void native_pud_clear(pud_t *pud) @@ -137,13 +137,13 @@ static inline void native_set_p4d(p4d_t *p4dp, p4d_t p4d) pgd_t pgd; if (pgtable_l5_enabled() || !IS_ENABLED(CONFIG_PAGE_TABLE_ISOLATION)) { - *p4dp = p4d; + WRITE_ONCE(*p4dp, p4d); return; } pgd = native_make_pgd(native_p4d_val(p4d)); pgd = pti_set_user_pgtbl((pgd_t *)p4dp, pgd); - *p4dp = native_make_p4d(native_pgd_val(pgd)); + WRITE_ONCE(*p4dp, native_make_p4d(native_pgd_val(pgd))); } static inline void native_p4d_clear(p4d_t *p4d) @@ -153,7 +153,7 @@ static inline void native_p4d_clear(p4d_t *p4d) static inline void native_set_pgd(pgd_t *pgdp, pgd_t pgd) { - *pgdp = pti_set_user_pgtbl(pgdp, pgd); + WRITE_ONCE(*pgdp, pti_set_user_pgtbl(pgdp, pgd)); } static inline void native_pgd_clear(pgd_t *pgd) diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index e848a4811785..ae394552fb94 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -269,7 +269,7 @@ static void mop_up_one_pmd(struct mm_struct *mm, pgd_t *pgdp) if (pgd_val(pgd) != 0) { pmd_t *pmd = (pmd_t *)pgd_page_vaddr(pgd); - *pgdp = native_make_pgd(0); + pgd_clear(pgdp); paravirt_release_pmd(pgd_val(pgd) >> PAGE_SHIFT); pmd_free(mm, pmd); @@ -494,7 +494,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, int changed = !pte_same(*ptep, entry); if (changed && dirty) - *ptep = entry; + set_pte(ptep, entry); return changed; } @@ -509,7 +509,7 @@ int pmdp_set_access_flags(struct vm_area_struct *vma, VM_BUG_ON(address & ~HPAGE_PMD_MASK); if (changed && dirty) { - *pmdp = entry; + set_pmd(pmdp, entry); /* * We had a write-protection fault here and changed the pmd * to to more permissive. No need to flush the TLB for that, @@ -529,7 +529,7 @@ int pudp_set_access_flags(struct vm_area_struct *vma, unsigned long address, VM_BUG_ON(address & ~HPAGE_PUD_MASK); if (changed && dirty) { - *pudp = entry; + set_pud(pudp, entry); /* * We had a write-protection fault here and changed the pud * to to more permissive. No need to flush the TLB for that,

7 years, 1 month

3
3
0 0

[git:media_tree/master] media: em28xx: make v4l2-compliance happier by starting sequence on zero

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: em28xx: make v4l2-compliance happier by starting sequence on zero Author: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> Date: Thu Sep 13 22:46:29 2018 -0400 The v4l2-compliance tool complains if a video doesn't start with a zero sequence number. While this shouldn't cause any real problem for apps, let's make it happier, in order to better check the v4l2-compliance differences before and after patchsets. This is actually an old issue. It is there since at least its videobuf2 conversion, e. g. changeset 3829fadc461 ("[media] em28xx: convert to videobuf2"), if VB1 wouldn't suffer from the same issue. Cc: stable(a)vger.kernel.org Fixes: d3829fadc461 ("[media] em28xx: convert to videobuf2") Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/usb/em28xx/em28xx-video.c | 2 ++ 1 file changed, 2 insertions(+) --- diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index 4b08da45032d..f43717ea831d 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -1093,6 +1093,8 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq, unsigned int count) em28xx_videodbg("%s\n", __func__); + dev->v4l2->field_count = 0; + /* * Make sure streaming is not already in progress for this type * of filehandle (e.g. video, vbi)

7 years, 1 month

1
0
0 0

[git:media_tree/master] media: em28xx: fix input name for Terratec AV 350

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: em28xx: fix input name for Terratec AV 350 Author: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> Date: Fri Sep 14 00:20:21 2018 -0400 Instead of using a register value, use an AMUX name, as otherwise VIDIOC_G_AUDIO would fail. Cc: stable(a)vger.kernel.org Fixes: 766ed64de554 ("V4L/DVB (11827): Add support for Terratec Grabster AV350") Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/usb/em28xx/em28xx-cards.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c index 06a7e09ded6e..87b887b7604e 100644 --- a/drivers/media/usb/em28xx/em28xx-cards.c +++ b/drivers/media/usb/em28xx/em28xx-cards.c @@ -2141,13 +2141,13 @@ const struct em28xx_board em28xx_boards[] = { .input = { { .type = EM28XX_VMUX_COMPOSITE, .vmux = TVP5150_COMPOSITE1, - .amux = EM28XX_AUDIO_SRC_LINE, + .amux = EM28XX_AMUX_LINE_IN, .gpio = terratec_av350_unmute_gpio, }, { .type = EM28XX_VMUX_SVIDEO, .vmux = TVP5150_SVIDEO, - .amux = EM28XX_AUDIO_SRC_LINE, + .amux = EM28XX_AMUX_LINE_IN, .gpio = terratec_av350_unmute_gpio, } }, },

7 years, 1 month

1
0
0 0

[git:media_tree/master] media: em28xx: use a default format if TRY_FMT fails

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: em28xx: use a default format if TRY_FMT fails Author: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> Date: Thu Sep 13 23:22:40 2018 -0400 Follow the V4L2 spec, as warned by v4l2-compliance: warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an invalid pixelformat. warn: v4l2-test-formats.cpp(733): This may or may not be a problem. For more information see: warn: v4l2-test-formats.cpp(734): http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html Cc: stable(a)vger.kernel.org Fixes: bddcf63313c6 ("V4L/DVB (9927): em28xx: use a more standard way to specify video formats") Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/usb/em28xx/em28xx-video.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index fbdfe6762cb2..4b08da45032d 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -1471,9 +1471,9 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv, fmt = format_by_fourcc(f->fmt.pix.pixelformat); if (!fmt) { - em28xx_videodbg("Fourcc format (%08x) invalid.\n", - f->fmt.pix.pixelformat); - return -EINVAL; + fmt = &format[0]; + em28xx_videodbg("Fourcc format (%08x) invalid. Using default (%08x).\n", + f->fmt.pix.pixelformat, fmt->fourcc); } if (dev->board.is_em2800) {

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror