* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Joe Perches @ 2020-06-16 18:53 UTC (permalink / raw)
To: Waiman Long, Andrew Morton, David Howells, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, Linus Torvalds, Matthew Wilcox,
David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <20200616015718.7812-1-longman@redhat.com>
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> v4:
> - Break out the memzero_explicit() change as suggested by Dan Carpenter
> so that it can be backported to stable.
> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> now as there can be a bit more discussion on what is best. It will be
> introduced as a separate patch later on after this one is merged.
To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
Are there _any_ fastpath uses of kfree or vfree?
Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.
To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?
Something like the below:
void kfree(const void *addr)
{
if (is_kernel_rodata((unsigned long)addr))
return;
if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
}
#define kvfree kfree
#define vfree kfree
#define kfree_const kfree
^ permalink raw reply
* Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
From: Bhupesh Sharma @ 2020-06-16 19:24 UTC (permalink / raw)
To: Bharat Gooty
Cc: Mark Rutland, Ard Biesheuvel, Linux Doc Mailing List,
Catalin Marinas, x86, kexec mailing list,
Linux Kernel Mailing List, Ray Jui, linuxppc-dev, Kazuhito Hagio,
James Morse, linux-arm-kernel, Amit Kachhap, Dave Anderson,
bhupesh linux, Will Deacon, Scott Branden, Steve Capper
In-Reply-To: <f644ddb6fdb926606bb376a9f491ee79@mail.gmail.com>
Hello Bharat,
On Wed, Jun 10, 2020 at 10:17 PM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>
> Hello Bhupesh,
> V6 patch set on Linux 5.7, did not help.
> I have applied makedump file
> http://lists.infradead.org/pipermail/kexec/2019-November/023963.html changes
> also (makedump-1.6.6). Tried to apply it on makedumpfile 1.6.7. Patch set_2
> failed. Would like to know, if you have V5 patch set for makedump file
> changes. With makedump 1.6.6, able to collect the vmore file.
> I used latest crash utility
> (https://www.redhat.com/archives/crash-utility/2019-November/msg00014.html
> changes are present)
> When I used crash utility, following is the error:
>
> Thanks,
> -Bharat
>
>
> -----Original Message-----
> From: Scott Branden [mailto:scott.branden@broadcom.com]
> Sent: Thursday, April 30, 2020 4:34 AM
> To: Bhupesh Sharma; Amit Kachhap
> Cc: Mark Rutland; x86@kernel.org; Will Deacon; Linux Doc Mailing List;
> Catalin Marinas; Ard Biesheuvel; kexec mailing list; Linux Kernel Mailing
> List; Kazuhito Hagio; James Morse; Dave Anderson; bhupesh linux;
> linuxppc-dev@lists.ozlabs.org; linux-arm-kernel; Steve Capper; Ray Jui;
> Bharat Gooty
> Subject: Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ
> in vmcoreinfo
>
> Hi Bhupesh,
>
> On 2020-02-23 10:25 p.m., Bhupesh Sharma wrote:
> > Hi Amit,
> >
> > On Fri, Feb 21, 2020 at 2:36 PM Amit Kachhap <amit.kachhap@arm.com> wrote:
> >> Hi Bhupesh,
> >>
> >> On 1/13/20 5:44 PM, Bhupesh Sharma wrote:
> >>> Hi James,
> >>>
> >>> On 01/11/2020 12:30 AM, Dave Anderson wrote:
> >>>> ----- Original Message -----
> >>>>> Hi Bhupesh,
> >>>>>
> >>>>> On 25/12/2019 19:01, Bhupesh Sharma wrote:
> >>>>>> On 12/12/2019 04:02 PM, James Morse wrote:
> >>>>>>> On 29/11/2019 19:59, Bhupesh Sharma wrote:
> >>>>>>>> vabits_actual variable on arm64 indicates the actual VA space size,
> >>>>>>>> and allows a single binary to support both 48-bit and 52-bit VA
> >>>>>>>> spaces.
> >>>>>>>>
> >>>>>>>> If the ARMv8.2-LVA optional feature is present, and we are running
> >>>>>>>> with a 64KB page size; then it is possible to use 52-bits of
> >>>>>>>> address
> >>>>>>>> space for both userspace and kernel addresses. However, any kernel
> >>>>>>>> binary that supports 52-bit must also be able to fall back to
> >>>>>>>> 48-bit
> >>>>>>>> at early boot time if the hardware feature is not present.
> >>>>>>>>
> >>>>>>>> Since TCR_EL1.T1SZ indicates the size offset of the memory region
> >>>>>>>> addressed by TTBR1_EL1 (and hence can be used for determining the
> >>>>>>>> vabits_actual value) it makes more sense to export the same in
> >>>>>>>> vmcoreinfo rather than vabits_actual variable, as the name of the
> >>>>>>>> variable can change in future kernel versions, but the
> >>>>>>>> architectural
> >>>>>>>> constructs like TCR_EL1.T1SZ can be used better to indicate
> >>>>>>>> intended
> >>>>>>>> specific fields to user-space.
> >>>>>>>>
> >>>>>>>> User-space utilities like makedumpfile and crash-utility, need to
> >>>>>>>> read/write this value from/to vmcoreinfo
> >>>>>>> (write?)
> >>>>>> Yes, also write so that the vmcoreinfo from an (crashing) arm64
> >>>>>> system can
> >>>>>> be used for
> >>>>>> analysis of the root-cause of panic/crash on say an x86_64 host using
> >>>>>> utilities like
> >>>>>> crash-utility/gdb.
> >>>>> I read this as as "User-space [...] needs to write to vmcoreinfo".
> >>> That's correct. But for writing to vmcore dump in the kdump kernel, we
> >>> need to read the symbols from the vmcoreinfo in the primary kernel.
> >>>
> >>>>>>>> for determining if a virtual address lies in the linear map range.
> >>>>>>> I think this is a fragile example. The debugger shouldn't need to
> >>>>>>> know
> >>>>>>> this.
> >>>>>> Well that the current user-space utility design, so I am not sure we
> >>>>>> can
> >>>>>> tweak that too much.
> >>>>>>
> >>>>>>>> The user-space computation for determining whether an address lies
> >>>>>>>> in
> >>>>>>>> the linear map range is the same as we have in kernel-space:
> >>>>>>>>
> >>>>>>>> #define __is_lm_address(addr) (!(((u64)addr) &
> >>>>>>>> BIT(vabits_actual -
> >>>>>>>> 1)))
> >>>>>>> This was changed with 14c127c957c1 ("arm64: mm: Flip kernel VA
> >>>>>>> space"). If
> >>>>>>> user-space
> >>>>>>> tools rely on 'knowing' the kernel memory layout, they must have to
> >>>>>>> constantly be fixed
> >>>>>>> and updated. This is a poor argument for adding this to something
> >>>>>>> that
> >>>>>>> ends up as ABI.
> >>>>>> See above. The user-space has to rely on some ABI/guaranteed
> >>>>>> hardware-symbols which can be
> >>>>>> used for 'determining' the kernel memory layout.
> >>>>> I disagree. Everything and anything in the kernel will change. The
> >>>>> ABI rules apply to
> >>>>> stuff exposed via syscalls and kernel filesystems. It does not apply
> >>>>> to kernel internals,
> >>>>> like the memory layout we used yesterday. 14c127c957c1 is a case in
> >>>>> point.
> >>>>>
> >>>>> A debugger trying to rely on this sort of thing would have to play
> >>>>> catchup whenever it
> >>>>> changes.
> >>>> Exactly. That's the whole point.
> >>>>
> >>>> The crash utility and makedumpfile are not in the same league as other
> >>>> user-space tools.
> >>>> They have always had to "play catchup" precisely because they depend
> >>>> upon kernel internals,
> >>>> which constantly change.
> >>> I agree with you and DaveA here. Software user-space debuggers are
> >>> dependent on kernel internals (which can change from time-to-time) and
> >>> will have to play catch-up (which has been the case since the very
> >>> start).
> >>>
> >>> Unfortunately we don't have any clear ABI for software debugging tools -
> >>> may be something to look for in future.
> >>>
> >>> A case in point is gdb/kgdb, which still needs to run with KASLR
> >>> turned-off (nokaslr) for debugging, as it confuses gdb which resolve
> >>> kernel symbol address from symbol table of vmlinux. But we can
> >>> work-around the same in makedumpfile/crash by reading the 'kaslr_offset'
> >>> value. And I have several users telling me now they cannot use gdb on
> >>> KASLR enabled kernel to debug panics, but can makedumpfile + crash
> >>> combination to achieve the same.
> >>>
> >>> So, we should be looking to fix these utilities which are broken since
> >>> the 52-bit changes for arm64. Accordingly, I will try to send the v6
> >>> soon while incorporating the comments posted on the v5.
> >> Any update on the next v6 version. Since this patch series is fixing the
> >> current broken kdump so need this series to add some more fields in
> >> vmcoreinfo for Pointer Authentication work.
> > Sorry for the delay. I was caught up in some other urgent arm64
> > user-space issues.
> > I am preparing the v6 now and hopefully will be able to post it out
> > for review later today.
>
> Did v6 get sent out?
Like I mentioned in a different thread reply, I did not put out the
user-space changes just yet, since we are waiting for the kernel
patches to be accepted first.
In the last review cycle (v5) we had inconsistencies between the
user-space and kernel as user-space utilities like crash accepted the
v5 patches while we had to respin the v6 for the kernel side.
But since a few other Red Hat arm partners have asked for the same,
please find below my public github trees (with prescribed branches),
which you can use for testing the v6 kernel patchset:
1. makedumpfile:
<https://github.com/bhupesh-sharma/makedumpfile/tree/52-bit-va-support-via-vmcore-upstream-v6-rebase>
2. crash-utility:
<https://github.com/bhupesh-sharma/crash/tree/52-bit-va-support-via-vmcore-upstream-v6-rebase>
Hope this helps.
Thanks,
Bhupesh
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()
From: Andrew Morton @ 2020-06-16 19:43 UTC (permalink / raw)
To: Mike Rapoport
Cc: Christophe Leroy, linux-kernel, Mike Rapoport, linux-mm,
linuxppc-dev
In-Reply-To: <20200615092229.23142-1-rppt@kernel.org>
On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport <rppt@kernel.org> wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
> level to access a PMD entry. Since 8xx has only 2-level page table this can
> be simplified with pmd_off() shortcut.
>
> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
> and pgd_offset() that are no longer needed.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>
> I think it's powerpc material, but I won't mind if Andrew picks it up :)
Via the powerpc tree would be better, please.
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Waiman Long @ 2020-06-16 19:43 UTC (permalink / raw)
To: Joe Perches, Andrew Morton, David Howells, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, Linus Torvalds, Matthew Wilcox,
David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On 6/16/20 2:53 PM, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
>> v4:
>> - Break out the memzero_explicit() change as suggested by Dan Carpenter
>> so that it can be backported to stable.
>> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
>> now as there can be a bit more discussion on what is best. It will be
>> introduced as a separate patch later on after this one is merged.
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I am not sure about that, but both of them can be slow.
>
> Many patches have been posted recently to fix mispairings
> of specific types of alloc and free functions.
>
> To eliminate these mispairings at a runtime cost of four
> comparisons, should the kfree/vfree/kvfree/kfree_const
> functions be consolidated into a single kfree?
>
> Something like the below:
>
> void kfree(const void *addr)
> {
> if (is_kernel_rodata((unsigned long)addr))
> return;
>
> if (is_vmalloc_addr(addr))
> _vfree(addr);
> else
> _kfree(addr);
> }
>
is_kernel_rodata() is inlined, but is_vmalloc_addr() isn't. So the
overhead can be a bit bigger.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Jason A. Donenfeld @ 2020-06-16 19:46 UTC (permalink / raw)
To: Joe Perches
Cc: Michal Hocko, linux-btrfs, Jarkko Sakkinen, David Sterba,
David Howells, Linux-MM, linux-sctp, keyrings, kasan-dev,
linux-stm32, devel, linux-cifs, linux-scsi, James Morris,
Matthew Wilcox, linux-wpan, David Rientjes, Waiman Long,
Dan Carpenter, Serge E. Hallyn, Steffen Klassert, linux-pm,
ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-integrity, linux-nfs, Linus Torvalds,
linux-wireless, LKML, David Miller, linux-bluetooth,
linux-security-module, target-devel, tipc-discussion,
Linux Crypto Mailing List, Johannes Weiner, Andrew Morton,
linuxppc-dev, Netdev, WireGuard mailing list, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches <joe@perches.com> wrote:
>
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > now as there can be a bit more discussion on what is best. It will be
> > introduced as a separate patch later on after this one is merged.
>
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
The networking stack has various places where there will be a quick
kmalloc followed by a kfree for an incoming or outgoing packet. One
place that comes to mind would be esp_alloc_tmp, which does a quick
allocation of some temporary kmalloc memory, processes some packet
things inside of that, and then frees it, sometimes in the same
function, and sometimes later in an async callback. I don't know how
"fastpath" you consider this, but usually packet processing is
something people want to do with minimal overhead, considering how
fast NICs are these days.
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Waiman Long @ 2020-06-16 20:01 UTC (permalink / raw)
To: Joe Perches, Andrew Morton, David Howells, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, Linus Torvalds, Matthew Wilcox,
David Rientjes
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, linux-kernel,
linux-mm, linux-sctp, target-devel, linux-stm32, devel,
linux-cifs, linux-scsi, kasan-dev, linux-wpan, Dan Carpenter,
linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic,
virtualization, linux-nfs, netdev, linux-wireless, David Sterba,
linux-bluetooth, linux-security-module, keyrings, tipc-discussion,
linux-crypto, Johannes Weiner, linux-integrity, linuxppc-dev,
wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On 6/16/20 2:53 PM, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
>> v4:
>> - Break out the memzero_explicit() change as suggested by Dan Carpenter
>> so that it can be backported to stable.
>> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
>> now as there can be a bit more discussion on what is best. It will be
>> introduced as a separate patch later on after this one is merged.
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
>
> Many patches have been posted recently to fix mispairings
> of specific types of alloc and free functions.
>
> To eliminate these mispairings at a runtime cost of four
> comparisons, should the kfree/vfree/kvfree/kfree_const
> functions be consolidated into a single kfree?
>
> Something like the below:
>
> void kfree(const void *addr)
> {
> if (is_kernel_rodata((unsigned long)addr))
> return;
>
> if (is_vmalloc_addr(addr))
> _vfree(addr);
> else
> _kfree(addr);
> }
>
> #define kvfree kfree
> #define vfree kfree
> #define kfree_const kfree
>
>
How about adding CONFIG_DEBUG_VM code to check for invalid address
ranges in kfree() and vfree()? By doing this, we can catch unmatched
pairing in debug mode, but won't have the overhead when debug mode is off.
Thought?
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: James Bottomley @ 2020-06-16 15:34 UTC (permalink / raw)
To: Johannes Thumshirn, Bart Van Assche, Finn Thain, Chris Boot
Cc: Martin K . Petersen, linux-scsi@vger.kernel.org, Chuhong Yuan,
linux-kernel@vger.kernel.org, Nicholas Bellinger,
target-devel@vger.kernel.org,
linux1394-devel@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Stefan Richter
In-Reply-To: <SN4PR0401MB35982D889857E3C03E96E49D9B9D0@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Tue, 2020-06-16 at 14:13 +0000, Johannes Thumshirn wrote:
> On 16/06/2020 16:09, Bart Van Assche wrote:
> > On 2020-06-16 02:42, Finn Thain wrote:
> > > Martin said, "I'd appreciate a patch to remove it"
> > >
> > > And Bart said, "do you want to keep this driver in the kernel
> > > tree?"
> > >
> > > AFAICT both comments are quite ambiguous. I don't see an
> > > actionable request, just an expression of interest from people
> > > doing their jobs.
> > >
> > > Note well: there is no pay check associated with having a
> > > MAINTAINERS file
> > > entry.
> >
> > Hi Finn,
> >
> > As far as I know the sbp driver only has had one user ever and that
> > user is no longer user the sbp driver. So why to keep it in the
> > kernel tree? Restoring a kernel driver can be easy - the first step
> > is a "git revert".
>
> Why not move the driver to drivers/staging for 2 or 3 kernel releases
> and if noone steps up, delete it?
Because that's pretty much the worst of all worlds: If the driver is
simply going orphaned it can stay where it is to avoid confusion. If
it's being removed, it's better to remove it from where it is because
that makes the patch to restore it easy to find.
Chris, the thing is this: if this driver has just one user on a stable
distro who complains about its removal six months to two years from
now, Linus will descend on us from a great height (which won't matter
to you, since you'll be long gone). This makes everyone very wary of
outright removal. If you're really, really sure it has no users, it
can be deleted, but if there's the slightest chance it has just one, it
should get orphaned.
James
^ permalink raw reply
* Re: [PATCH] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes
From: Jarkko Sakkinen @ 2020-06-16 21:08 UTC (permalink / raw)
To: David Gibson
Cc: Nayna Jain, linux-kernel, Jason Gunthorpe, Paul Mackerras,
Peter Huewe, linuxppc-dev, linux-integrity, Stefan Berger
In-Reply-To: <20200605063719.456277-1-david@gibson.dropbear.id.au>
On Fri, Jun 05, 2020 at 04:37:19PM +1000, David Gibson wrote:
> The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
> which will need the use of the internal command/response buffer. But,
> we're issuing this *before* we've waited to make sure that buffer is
> allocated.
>
> This can result in intermittent failures to probe if the hypervisor / TPM
> implementation doesn't respond quickly enough. I find it fails almost
> every time with an 8 vcpu guest under KVM with software emulated TPM.
>
> Fixes: 18b3670d79ae9 "tpm: ibmvtpm: Add support for TPM2"
Should be Fixes: 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2")
Also briefly state what the commit does, not just the problem
description. The code change looks legit.
Please send v2 with these changes.
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> drivers/char/tpm/tpm_ibmvtpm.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> index 09fe45246b8c..994385bf37c0 100644
> --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -683,13 +683,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> if (rc)
> goto init_irq_cleanup;
>
> - if (!strcmp(id->compat, "IBM,vtpm20")) {
> - chip->flags |= TPM_CHIP_FLAG_TPM2;
> - rc = tpm2_get_cc_attrs_tbl(chip);
> - if (rc)
> - goto init_irq_cleanup;
> - }
> -
> if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
> ibmvtpm->rtce_buf != NULL,
> HZ)) {
> @@ -697,6 +690,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> goto init_irq_cleanup;
> }
>
> + if (!strcmp(id->compat, "IBM,vtpm20")) {
> + chip->flags |= TPM_CHIP_FLAG_TPM2;
> + rc = tpm2_get_cc_attrs_tbl(chip);
> + if (rc)
> + goto init_irq_cleanup;
> + }
> +
> return tpm_chip_register(chip);
> init_irq_cleanup:
> do {
> --
> 2.26.2
>
/Jarkko
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-16 21:14 UTC (permalink / raw)
To: Joe Perches
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, Jarkko Sakkinen,
David Sterba, David Howells, linux-mm, linux-sctp, keyrings,
linux-stm32, devel, linux-cifs, linux-scsi, James Morris,
kasan-dev, linux-wpan, David Rientjes, Waiman Long, Dan Carpenter,
Serge E. Hallyn, linux-pm, ecryptfs, linux-fscrypt,
linux-mediatek, linux-amlogic, virtualization, linux-integrity,
linux-nfs, Linus Torvalds, linux-wireless, linux-kernel,
linux-bluetooth, linux-security-module, target-devel,
tipc-discussion, linux-crypto, Johannes Weiner, Andrew Morton,
linuxppc-dev, netdev, wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I worked on adding a 'free' a couple of years ago. That was capable
of freeing percpu, vmalloc, kmalloc and alloc_pages memory. I ran into
trouble when I tried to free kmem_cache_alloc memory -- it works for slab
and slub, but not slob (because slob needs the size from the kmem_cache).
My motivation for this was to change kfree_rcu() to just free_rcu().
> To eliminate these mispairings at a runtime cost of four
> comparisons, should the kfree/vfree/kvfree/kfree_const
> functions be consolidated into a single kfree?
I would say to leave kfree() alone and just introduce free() as a new
default. There's some weird places in the kernel that have a 'free'
symbol of their own, but those should be renamed anyway.
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS c3405d517d606e965030026daec198d314f20195
From: kernel test robot @ 2020-06-16 22:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: c3405d517d606e965030026daec198d314f20195 Automatic merge of 'master', 'next' and 'fixes' (2020-06-17 00:21)
elapsed time: 490m
configs tested: 108
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm pxa_defconfig
um x86_64_defconfig
mips pic32mzda_defconfig
arm versatile_defconfig
ia64 gensparse_defconfig
mips ip28_defconfig
mips ip27_defconfig
c6x evmc6678_defconfig
arm netwinder_defconfig
sh se7721_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200615
i386 randconfig-a002-20200615
i386 randconfig-a001-20200615
i386 randconfig-a004-20200615
i386 randconfig-a005-20200615
i386 randconfig-a003-20200615
x86_64 randconfig-a015-20200615
x86_64 randconfig-a011-20200615
x86_64 randconfig-a016-20200615
x86_64 randconfig-a012-20200615
x86_64 randconfig-a014-20200615
x86_64 randconfig-a013-20200615
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS b2f7aff54d10f344bc8424ab98d29e028486ba26
From: kernel test robot @ 2020-06-16 22:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: b2f7aff54d10f344bc8424ab98d29e028486ba26 powerpc/ptdump: Fix build failure in hashpagetable.c
elapsed time: 489m
configs tested: 98
configs skipped: 105
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sh secureedge5410_defconfig
mips capcella_defconfig
sparc64 alldefconfig
arm s3c2410_defconfig
arc axs103_defconfig
powerpc pasemi_defconfig
mips bigsur_defconfig
arm cns3420vb_defconfig
i386 allnoconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200615
i386 randconfig-a002-20200615
i386 randconfig-a001-20200615
i386 randconfig-a004-20200615
i386 randconfig-a005-20200615
i386 randconfig-a003-20200615
x86_64 randconfig-a015-20200615
x86_64 randconfig-a011-20200615
x86_64 randconfig-a016-20200615
x86_64 randconfig-a012-20200615
x86_64 randconfig-a014-20200615
x86_64 randconfig-a013-20200615
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 0bdcfa182506526fbe4e088ff9ca86a31b81828d
From: kernel test robot @ 2020-06-16 22:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 0bdcfa182506526fbe4e088ff9ca86a31b81828d powerpc/64s: Fix KVM interrupt using wrong save area
elapsed time: 491m
configs tested: 87
configs skipped: 104
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm axm55xx_defconfig
mips bigsur_defconfig
mips bmips_stb_defconfig
sh migor_defconfig
i386 allnoconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: David Sterba @ 2020-06-16 23:01 UTC (permalink / raw)
To: Joe Perches
Cc: Jason A . Donenfeld, Michal Hocko, linux-btrfs, Jarkko Sakkinen,
David Sterba, David Howells, linux-mm, linux-sctp, keyrings,
kasan-dev, linux-stm32, devel, linux-cifs, linux-scsi,
James Morris, Matthew Wilcox, linux-wpan, David Rientjes,
Waiman Long, Dan Carpenter, Serge E. Hallyn, linux-pm, ecryptfs,
linux-fscrypt, linux-mediatek, linux-amlogic, virtualization,
linux-integrity, linux-nfs, linuxppc-dev, linux-wireless,
linux-kernel, linux-bluetooth, linux-security-module,
target-devel, tipc-discussion, linux-crypto, Johannes Weiner,
Andrew Morton, Linus Torvalds, netdev, wireguard, linux-ppp
In-Reply-To: <fe3b9a437be4aeab3bac68f04193cb6daaa5bee4.camel@perches.com>
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > now as there can be a bit more discussion on what is best. It will be
> > introduced as a separate patch later on after this one is merged.
>
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I'd consider kfree performance critical for cases where it is called
under locks. If possible the kfree is moved outside of the critical
section, but we have rbtrees or lists that get deleted under locks and
restructuring the code to do eg. splice and free it outside of the lock
is not always possible.
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()
From: Michael Ellerman @ 2020-06-16 23:21 UTC (permalink / raw)
To: Andrew Morton, Mike Rapoport
Cc: Christophe Leroy, linux-mm, linuxppc-dev, linux-kernel,
Mike Rapoport
In-Reply-To: <20200616124304.bbe36933fcd48c5f467f4be9@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport <rppt@kernel.org> wrote:
>
>> From: Mike Rapoport <rppt@linux.ibm.com>
>>
>> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
>> level to access a PMD entry. Since 8xx has only 2-level page table this can
>> be simplified with pmd_off() shortcut.
>>
>> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
>> and pgd_offset() that are no longer needed.
>>
>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>> ---
>>
>> I think it's powerpc material, but I won't mind if Andrew picks it up :)
>
> Via the powerpc tree would be better, please.
I'll take it into next for v5.9, unless there's a reason it needs to go
into v5.8.
cheers
^ permalink raw reply
* Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
From: Fenghua Yu @ 2020-06-16 23:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Dave Hansen, H Peter Anvin, Dave Jiang, Ashok Raj, Joerg Roedel,
x86, amd-gfx, Ingo Molnar, Ravi V Shankar, Yu-cheng Yu,
Andrew Donnellan, Borislav Petkov, Sohil Mehta, Thomas Gleixner,
Tony Luck, linuxppc-dev, Felix Kuehling, linux-kernel, iommu,
Jacob Jun Pan, Frederic Barrat, David Woodhouse, Lu Baolu
In-Reply-To: <20200615190928.GJ2531@hirez.programming.kicks-ass.net>
Hi, Peter,
On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
>
> Why thread_info? What's wrong with something simple like the below. It
> takes a bit from the 'strictly current' flags word.
>
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index b62e6aaf28f0..fca830b97055 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -801,6 +801,9 @@ struct task_struct {
> /* Stalled due to lack of memory */
> unsigned in_memstall:1;
> #endif
> +#ifdef CONFIG_PCI_PASID
> + unsigned has_valid_pasid:1;
> +#endif
>
> unsigned long atomic_flags; /* Flags requiring atomic access. */
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 142b23645d82..10b3891be99e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -955,6 +955,10 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
> tsk->use_memdelay = 0;
> #endif
>
> +#ifdef CONFIG_PCI_PASID
> + tsk->has_valid_pasid = 0;
> +#endif
> +
> #ifdef CONFIG_MEMCG
> tsk->active_memcg = NULL;
> #endif
Can I add "Signed-off-by: Peter Zijlstra <peterz@infradead.org>"
to this patch? I will send this patch in the next version of the series.
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl_spdif: Add support for imx6sx platform
From: Nicolin Chen @ 2020-06-16 23:28 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, Xiubo.Lee, lgirdwood, linuxppc-dev,
tiwai, robh+dt, perex, broonie, festevam, linux-kernel
In-Reply-To: <1592289761-29118-2-git-send-email-shengjiu.wang@nxp.com>
On Tue, Jun 16, 2020 at 02:42:41PM +0800, Shengjiu Wang wrote:
> The one difference on imx6sx platform is that the root clock
> is shared with ASRC module, so we add a new flags "ind_root_clk"
> which means the root clock is independent, then we will not
> do the clk_set_rate and clk_round_rate to avoid impact ASRC
> module usage.
>
> As add a new flags, we include the soc specific data struct.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> sound/soc/fsl/fsl_spdif.c | 43 +++++++++++++++++++++++++++++++++++----
> 1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
> index 1b2e516f9162..00e06803d32f 100644
> --- a/sound/soc/fsl/fsl_spdif.c
> +++ b/sound/soc/fsl/fsl_spdif.c
> @@ -42,6 +42,17 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4, 0xa, 0xb };
>
> #define DEFAULT_RXCLK_SRC 1
>
> +/**
> + * struct fsl_spdif_soc_data: soc specific data
> + *
> + * @imx: for imx platform
> + * @ind_root_clk: flag for round clk rate
> + */
> +struct fsl_spdif_soc_data {
> + bool imx;
> + bool ind_root_clk;
"ind" doesn't look very straightforward; maybe "shared_root_clock"?
And for its comments:
* @shared_root_clock: flag of sharing a clock source with others;
* so the driver shouldn't set root clock rate
> +};
> +
> /*
> * SPDIF control structure
> * Defines channel status, subcode and Q sub
> @@ -93,6 +104,7 @@ struct fsl_spdif_priv {
> struct snd_soc_dai_driver cpu_dai_drv;
> struct platform_device *pdev;
> struct regmap *regmap;
> + const struct fsl_spdif_soc_data *soc;
Looks better if we move it to the top of the list :)
> @@ -421,7 +448,7 @@ static int spdif_set_sample_rate(struct snd_pcm_substream *substream,
> sysclk_df = spdif_priv->sysclk_df[rate];
>
> /* Don't mess up the clocks from other modules */
> - if (clk != STC_TXCLK_SPDIF_ROOT)
> + if (clk != STC_TXCLK_SPDIF_ROOT || !spdif_priv->soc->ind_root_clk)
> goto clk_set_bypass;
>
> /* The S/PDIF block needs a clock of 64 * fs * txclk_df */
> @@ -1186,7 +1213,8 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv *spdif_priv,
> continue;
>
> ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
> - i == STC_TXCLK_SPDIF_ROOT);
> + i == STC_TXCLK_SPDIF_ROOT &&
> + spdif_priv->soc->ind_root_clk);
Having more than one place that checks the condition, we can add:
/* Check if clk is a root clock that does not share clock source with others */
static inline bool fsl_spdif_can_set_clk_rate(struct fsl_spdif_priv *spdif, int clk)
{
return (clk == STC_TXCLK_SPDIF_ROOT) && !spdif->soc->shared_root_clock;
}
^ permalink raw reply
* Re: [PATCH kernel] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
From: Michael Ellerman @ 2020-06-16 23:37 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy
In-Reply-To: <20200616104231.27805-1-aik@ozlabs.ru>
Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
> possible that not entire table is allocated if it is huge and multilevel
> so xchg may also allocate subtables. If failed, it returns H_HARDWARE
> for failed allocation and H_TOO_HARD if it needs it but cannot do because
> the alloc parameter is "false" (set when called with MMU=off to force
> retry with MMU=on).
>
> The problem is that having separate errors only matters in real mode
> (MMU=off) but the only caller with alloc="false" does not check the exact
> error code and simply returns H_TOO_HARD; and for every other mode
> alloc is "true". Also, the function is also called from the ioctl()
> handler of the VFIO SPAPR TCE IOMMU subdriver which does not expect
> hypervisor error codes (H_xxx) and will expose them to the userspace.
>
> This converts wrong error codes to a simple -1.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> I could make it "return alloc ? -ENOMEM : -EBUSY" but
> is EBUSY a good match for H_TOO_HARD?
I think -EAGAIN would be the best match.
But it would be simpler if it just returned -ENOMEM always. In both
cases the problem is that the function needs to allocate memory but
couldn't.
If a caller passes alloc=false, it knows that, so if it sees ENOMEM it
can retry with alloc=true.
cheers
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-17 0:37 UTC (permalink / raw)
To: dsterba, Joe Perches, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
David Rientjes, Michal Hocko, Johannes Weiner, Dan Carpenter,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200616230130.GJ27795@twin.jikos.cz>
On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote:
> On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > > v4:
> > > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > > so that it can be backported to stable.
> > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > > now as there can be a bit more discussion on what is best. It will be
> > > introduced as a separate patch later on after this one is merged.
> >
> > To this larger audience and last week without reply:
> > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
> >
> > Are there _any_ fastpath uses of kfree or vfree?
>
> I'd consider kfree performance critical for cases where it is called
> under locks. If possible the kfree is moved outside of the critical
> section, but we have rbtrees or lists that get deleted under locks and
> restructuring the code to do eg. splice and free it outside of the lock
> is not always possible.
Not just performance critical, but correctness critical. Since kvfree()
may allocate from the vmalloc allocator, I really think that kvfree()
should assert that it's !in_atomic(). Otherwise we can get into trouble
if we end up calling vfree() and have to take the mutex.
^ permalink raw reply
* Re: powerpc/pci: [PATCH 1/1 V3] PCIE PHB reset
From: Oliver O'Halloran @ 2020-06-17 0:45 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Brian King, Wen Xiong, linuxppc-dev, wenxiong
In-Reply-To: <87r1ufdy1x.fsf@mpe.ellerman.id.au>
On Tue, Jun 16, 2020 at 9:55 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> wenxiong@linux.vnet.ibm.com writes:
> > From: Wen Xiong <wenxiong@linux.vnet.ibm.com>
> >
> > Several device drivers hit EEH(Extended Error handling) when triggering
> > kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
> > in pci general code when triggering kdump.
>
> Actually it's in pseries specific PCI code, and the reset is done in the
> 2nd kernel as it boots, not when triggering the kdump.
>
> You're doing it as a:
>
> machine_postcore_initcall(pseries, pseries_phb_reset);
>
> But we do the EEH initialisation in:
>
> core_initcall_sync(eeh_init);
>
> Which happens first.
>
> So it seems to me that this should be called from pseries_eeh_init().
This happens to use some of the same RTAS calls as EEH, but it's
entirely orthogonal to it. Wedging the two together doesn't make any
real sense IMO since this should be usable even with !CONFIG_EEH.
> That would isolate the code in the right place, and allow you to use the
> existing ibm_get_config_addr_info.
>
> You probably can't use pseries_eeh_get_pe_addr(), because you won't have
> a "pe" structure yet.
>
> Instead you should add a helper that does the core of that logic but
> accepts config_addr/buid as parameters, and then have your code and
> pseries_eeh_get_pe_addr() call that.
I have a patch in my next pile of eeh reworks which kills off
pseries_eeh_get_pe_addr() entirely. It's used to implement
eeh_ops->get_pe_addr for pseries, but the only caller of
->get_pe_addr() is in pseries EEH code and the powernv version is a
stub so I was going to drop it from EEH ops and fold it into the
caller. We could do that in this patch, but it's just going to create
a merge conflict for you to deal with. Up to you.
> *snip*
> > + list_for_each_entry(phb, &hose_list, list_node) {
> > + config_addr = pseries_get_pdn_addr(phb);
> > + if (config_addr == -1)
> > + continue;
> > +
> > + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> > + config_addr, BUID_HI(phb->buid),
> > + BUID_LO(phb->buid), EEH_RESET_FUNDAMENTAL);
> > +
> > + /* If fundamental-reset not supported, try hot-reset */
> > + if (ret == -8)
>
> Where does -8 come from?
There's a comment right there.
It could be better explained I suppose, but you need to read
PAPR/LoPAPR to make sense of anything RTAS so what's it really buying
you?
> Oh I see, it's copied from pseries_eeh_reset().
> > + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> > + config_addr, BUID_HI(phb->buid),
> > + BUID_LO(phb->buid), EEH_RESET_HOT);
> > +
> > + if (ret) {
> > + pr_err("%s: PHB#%x-PE# failed with rtas_call activate reset=%d\n",
> ^
> again missing PE number.
>
> > + __func__, phb->global_number, ret);
> > + continue;
> > + }
> > + }
> > + msleep(EEH_PE_RST_SETTLE_TIME);
>
> So that loop is basically a copy of pseries_eeh_reset() but with the
> sleep hoisted out of the loop.
>
> I'd really prefer to see that refactored into a helper that takes the
> config_addr and buid and doesn't do the sleep.
>
> Then this loop could call that helper, and so could pseries_eeh_reset().
That's better so long as we're not requiring CONFIG_EEH being
selected. pseries_eeh_reset() uses the rtas token variables
initialised in pseries_eeh_init() which are static to the file so
they'd need to be initialised somewhere common.
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl-asoc-card: Add MQS support
From: Nicolin Chen @ 2020-06-17 0:48 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, Xiubo.Lee, lgirdwood, linuxppc-dev,
tiwai, robh+dt, perex, broonie, festevam, linux-kernel
In-Reply-To: <1592292637-25734-2-git-send-email-shengjiu.wang@nxp.com>
On Tue, Jun 16, 2020 at 03:30:37PM +0800, Shengjiu Wang wrote:
> The MQS codec isn't an i2c device, so add a new platform device for it.
>
> MQS only support playback, so add a new audio map.
>
> Add there maybe "model" property or no "audio-routing" property insertions
"Add" => "And"
> devicetree, so add some enhancement for these two property.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> sound/soc/fsl/fsl-asoc-card.c | 70 ++++++++++++++++++++++++++---------
> 1 file changed, 52 insertions(+), 18 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> index 00be73900888..2ac8cb9ddd10 100644
> --- a/sound/soc/fsl/fsl-asoc-card.c
> +++ b/sound/soc/fsl/fsl-asoc-card.c
> @@ -482,6 +489,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> {
> struct device_node *cpu_np, *codec_np, *asrc_np;
> struct device_node *np = pdev->dev.of_node;
> + struct platform_device *codec_pdev = NULL; /* used for non i2c device*/
Having both codec_pdev and codec_dev duplicates things. Actually
only a couple of places really need "codec_dev" -- most of them
need codec_dev->dev pointer instead. So we could have a cleanup:
- struct i2c_client *codec_dev;
+ struct device *codec_dev = NULL;
> @@ -512,10 +520,13 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> }
>
> codec_np = of_parse_phandle(np, "audio-codec", 0);
> - if (codec_np)
> + if (codec_np) {
> codec_dev = of_find_i2c_device_by_node(codec_np);
> - else
> + if (!codec_dev)
> + codec_pdev = of_find_device_by_node(codec_np);
> + } else {
> codec_dev = NULL;
> + }
Here can have something like (feel free to simplify):
if (codec_np) {
struct platform_device *codec_pdev;
struct i2c_client *codec_i2c;
codec_i2c = of_find_i2c_device_by_node(codec_np);
if (codec_i2c)
codec_dev = &codec_i2c->dev;
if (!codec_dev) {
codec_pdev = of_find_device_by_node(codec_np);
codec_dev = &codec_pdev->dev;
}
}
> asrc_np = of_parse_phandle(np, "audio-asrc", 0);
> if (asrc_np)
> @@ -525,6 +536,13 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> if (codec_dev) {
> struct clk *codec_clk = clk_get(&codec_dev->dev, NULL);
Then here:
- struct clk *codec_clk = clk_get(&codec_dev->dev, NULL);
+ struct clk *codec_clk = clk_get(codec_dev, NULL);
> @@ -538,6 +556,11 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> /* Assign a default DAI format, and allow each card to overwrite it */
> priv->dai_fmt = DAI_FMT_BASE;
>
> + memcpy(priv->dai_link, fsl_asoc_card_dai,
> + sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));
> @@ -573,13 +596,25 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> codec_dai_name = "ac97-hifi";
> priv->card.set_bias_level = NULL;
> priv->dai_fmt = SND_SOC_DAIFMT_AC97;
> + priv->card.dapm_routes = audio_map_ac97;
> + priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_ac97);
> + } else if (of_device_is_compatible(np, "fsl,imx-audio-mqs")) {
> + codec_dai_name = "fsl-mqs-dai";
> + priv->card.set_bias_level = NULL;
> + priv->dai_fmt = SND_SOC_DAIFMT_LEFT_J |
> + SND_SOC_DAIFMT_CBS_CFS |
> + SND_SOC_DAIFMT_NB_NF;
> + priv->dai_link[1].dpcm_playback = 1;
> + priv->dai_link[2].dpcm_playback = 1;
dpcm_playback = 1? That's the default value in fsl_asoc_card_dai.
> @@ -601,19 +636,18 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
> }
>
> - snprintf(priv->name, sizeof(priv->name), "%s-audio",
> - fsl_asoc_card_is_ac97(priv) ? "ac97" :
> - codec_dev->name);
> -
> /* Initialize sound card */
> priv->pdev = pdev;
> priv->card.dev = &pdev->dev;
> - priv->card.name = priv->name;
> + ret = snd_soc_of_parse_card_name(&priv->card, "model");
> + if (ret) {
> + snprintf(priv->name, sizeof(priv->name), "%s-audio",
> + fsl_asoc_card_is_ac97(priv) ? "ac97" :
> + (codec_dev ? codec_dev->name : codec_pdev->name));
We can just use dev_name() if codec_dev is struct device *
Or having a codec_dev_name to cache codec_pdev/i2c->name.
> - ret = snd_soc_of_parse_audio_routing(&priv->card, "audio-routing");
> - if (ret) {
> - dev_err(&pdev->dev, "failed to parse audio-routing: %d\n", ret);
> - goto asrc_fail;
> + if (of_property_read_bool(np, "audio-routing")) {
> + ret = snd_soc_of_parse_audio_routing(&priv->card, "audio-routing");
> + if (ret) {
> + dev_err(&pdev->dev, "failed to parse audio-routing: %d\n", ret);
> + goto asrc_fail;
Hmm...audio-routing is a required property in DT binding doc.
So you might need to update that too.
^ permalink raw reply
* [PATCH kernel v2] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
From: Alexey Kardashevskiy @ 2020-06-17 0:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy
The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
possible that not entire table is allocated if it is huge and multilevel
so xchg may also allocate subtables. If failed, it returns H_HARDWARE
for failed allocation and H_TOO_HARD if it needs it but cannot do because
the alloc parameter is "false" (set when called with MMU=off to force
retry with MMU=on).
The problem is that having separate errors only matters in real mode
(MMU=off) but the only caller with alloc="false" does not check the exact
error code and simply returns H_TOO_HARD; and for every other mode
alloc is "true". Also, the function is also called from the ioctl()
handler of the VFIO SPAPR TCE IOMMU subdriver which does not expect
hypervisor error codes (H_xxx) and will expose them to the userspace.
This converts wrong error codes to -ENOMEM.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* return -ENOMEM vs. -1
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index f923359d8afc..5218f5da2737 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -166,7 +166,7 @@ int pnv_tce_xchg(struct iommu_table *tbl, long index,
if (!ptce) {
ptce = pnv_tce(tbl, false, idx, alloc);
if (!ptce)
- return alloc ? H_HARDWARE : H_TOO_HARD;
+ return -ENOMEM;
}
if (newtce & TCE_PCI_WRITE)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: Finn Thain @ 2020-06-17 2:07 UTC (permalink / raw)
To: Bart Van Assche
Cc: Martin K . Petersen, linux-scsi, Chuhong Yuan, linux-kernel,
Nicholas Bellinger, target-devel, Chris Boot, linux1394-devel,
linuxppc-dev, Stefan Richter
In-Reply-To: <8cbab988-fba7-8e27-7faf-9f7aa36ca235@acm.org>
On Tue, 16 Jun 2020, Bart Van Assche wrote:
>
> As far as I know the sbp driver only has had one user ever and that user
> is no longer user the sbp driver.
So, you estimate the userbase at zero. Can you give a confidence level?
Actual measurement is hard because when end users encounter breakage, they
look for quick workarounds before they undertake post mortem, log
collection, bug reporting, mailing list discussions, analysis etc.
> So why to keep it in the kernel tree?
Answer: for the same reason it was added to the tree.
Here's a different question: "Why remove it from the kernel tree?"
If maintaining this code is a burden, is it not the kind of tax that all
developers/users pay to all developers/users? Does this driver impose an
unreasonably high burden for some reason?
The growth of a maintenance burden in general has lead to the invention of
design patterns and tooling to minize it. So a good argument for removal
would describe the nature of the problem, because some driver deficiencies
can be fixed automatically, and some tooling deficiencies can compound an
otherwise insignificant or common driver deficiency.
There are spin-off benefits from legacy code besides process improvements.
Building and testing this sort of code has regularly revealed erroneous
corner cases in commits elsewhere like API changes and refactoring.
Also, legacy code is used by new developers get experience in code
modernization. And it provides more training material for neural networks
that need to be taught to recognize patches that raise quality.
Ten or twenty years ago, I doubt that anyone predicted these (and other)
spin-off benefits. If we can't predict the benefit, how will we project
the cost, and use that to justify deletion?
Please see also,
http://www.mac.linux-m68k.org/docs/obsolete.php
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: Martin K. Petersen @ 2020-06-17 2:35 UTC (permalink / raw)
To: Finn Thain
Cc: Chris Boot, Bart Van Assche, linux-scsi, Chuhong Yuan,
linux-kernel, Nicholas Bellinger, target-devel,
Martin K . Petersen, linux1394-devel, linuxppc-dev,
Stefan Richter
In-Reply-To: <alpine.LNX.2.22.394.2006140934520.15@nippy.intranet>
Finn,
> I haven't used this driver for a long time, but I still own PowerMacs
> with firewire, and I know I'm not the only one.
I also have old 1394 hardware kicking around in the basement. But having
worked with FireWire shared storage targets in the past, I have zero
desire to ever touch any of that again.
I could understand an objection if we were to entertain removing
sbp2. But really, how many people are setting up FireWire targets?
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: Martin K. Petersen @ 2020-06-17 3:09 UTC (permalink / raw)
To: Chris Boot
Cc: Bart Van Assche, linux-scsi@vger.kernel.org, Johannes Thumshirn,
Chuhong Yuan, linux-kernel@vger.kernel.org, Finn Thain,
James Bottomley, target-devel@vger.kernel.org, Nicholas Bellinger,
Martin K . Petersen, linux1394-devel@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Stefan Richter
In-Reply-To: <5e512185-45d1-61eb-9bec-91e9f9d53ea3@boo.tc>
Chris,
> I don't especially want it to be gone, nor can I be sure there are no
> users of what is as far as I can tell a working piece of code. I can
> tell you that I never hear about it (other than the odd patch),
> whereas I do get emails out of the blue for some of my other (much
> smaller) stuff which clearly has users. I'd be just as happy for this
> to be orphaned or for nothing to happen to it.
>
> Honestly, I am totally ambivalent as to what happens to this code.
> Martin, however, clearly cares enough to have asked me to supply a
> patch to remove it.
I love it when people take ownership of old drivers. I think it's
wonderful that Finn and others are on the ball when it comes to the 5380
family. I don't care how old things are as long as they are being
actively used.
I am also very happy to keep things in the tree as long as there is a
healthy community around them. However, keeping code around is not
free. Core interfaces change frequently. Nobody enjoys having to tweak
host templates for 50 devices they have never even heard about. Also, we
now live in a reality where there is a constant barrage of build bots
and code analyzers sending mail. So the effective cost of keeping code
around in the tree is going up. I get a substantial amount of code
analysis mail about drivers nobody have touched in a decade or more.
Consequently, I am much more inclined to remove drivers than I have been
in the past. But I am also very happy to bring them back if somebody
uses them or - even better - are willing to step up and maintain them.
I don't particularly like the notion of a driver being orphaned because
all that really means is that the driver transitions from being (at
least partially) somebody else's problem to being mine and mine alone.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl-asoc-card: Add MQS support
From: Shengjiu Wang @ 2020-06-17 3:31 UTC (permalink / raw)
To: Nicolin Chen
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Liam Girdwood, Takashi Iwai, Rob Herring, Mark Brown,
linuxppc-dev, linux-kernel
In-Reply-To: <20200617004845.GB19896@Asurada-Nvidia>
On Wed, Jun 17, 2020 at 8:50 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Tue, Jun 16, 2020 at 03:30:37PM +0800, Shengjiu Wang wrote:
> > The MQS codec isn't an i2c device, so add a new platform device for it.
> >
> > MQS only support playback, so add a new audio map.
> >
> > Add there maybe "model" property or no "audio-routing" property insertions
>
> "Add" => "And"
>
> > devicetree, so add some enhancement for these two property.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > sound/soc/fsl/fsl-asoc-card.c | 70 ++++++++++++++++++++++++++---------
> > 1 file changed, 52 insertions(+), 18 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> > index 00be73900888..2ac8cb9ddd10 100644
> > --- a/sound/soc/fsl/fsl-asoc-card.c
> > +++ b/sound/soc/fsl/fsl-asoc-card.c
>
> > @@ -482,6 +489,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> > {
> > struct device_node *cpu_np, *codec_np, *asrc_np;
> > struct device_node *np = pdev->dev.of_node;
> > + struct platform_device *codec_pdev = NULL; /* used for non i2c device*/
>
> Having both codec_pdev and codec_dev duplicates things. Actually
> only a couple of places really need "codec_dev" -- most of them
> need codec_dev->dev pointer instead. So we could have a cleanup:
>
> - struct i2c_client *codec_dev;
> + struct device *codec_dev = NULL;
>
> > @@ -512,10 +520,13 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> > }
> >
> > codec_np = of_parse_phandle(np, "audio-codec", 0);
> > - if (codec_np)
> > + if (codec_np) {
> > codec_dev = of_find_i2c_device_by_node(codec_np);
> > - else
> > + if (!codec_dev)
> > + codec_pdev = of_find_device_by_node(codec_np);
> > + } else {
> > codec_dev = NULL;
> > + }
>
> Here can have something like (feel free to simplify):
>
> if (codec_np) {
> struct platform_device *codec_pdev;
> struct i2c_client *codec_i2c;
>
> codec_i2c = of_find_i2c_device_by_node(codec_np);
> if (codec_i2c)
> codec_dev = &codec_i2c->dev;
>
> if (!codec_dev) {
> codec_pdev = of_find_device_by_node(codec_np);
> codec_dev = &codec_pdev->dev;
> }
> }
> > asrc_np = of_parse_phandle(np, "audio-asrc", 0);
> > if (asrc_np)
> > @@ -525,6 +536,13 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> > if (codec_dev) {
> > struct clk *codec_clk = clk_get(&codec_dev->dev, NULL);
>
> Then here:
>
> - struct clk *codec_clk = clk_get(&codec_dev->dev, NULL);
> + struct clk *codec_clk = clk_get(codec_dev, NULL);
>
> > @@ -538,6 +556,11 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> > /* Assign a default DAI format, and allow each card to overwrite it */
> > priv->dai_fmt = DAI_FMT_BASE;
> >
> > + memcpy(priv->dai_link, fsl_asoc_card_dai,
> > + sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));
>
> > @@ -573,13 +596,25 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> > codec_dai_name = "ac97-hifi";
> > priv->card.set_bias_level = NULL;
> > priv->dai_fmt = SND_SOC_DAIFMT_AC97;
> > + priv->card.dapm_routes = audio_map_ac97;
> > + priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_ac97);
> > + } else if (of_device_is_compatible(np, "fsl,imx-audio-mqs")) {
> > + codec_dai_name = "fsl-mqs-dai";
> > + priv->card.set_bias_level = NULL;
> > + priv->dai_fmt = SND_SOC_DAIFMT_LEFT_J |
> > + SND_SOC_DAIFMT_CBS_CFS |
> > + SND_SOC_DAIFMT_NB_NF;
> > + priv->dai_link[1].dpcm_playback = 1;
> > + priv->dai_link[2].dpcm_playback = 1;
>
> dpcm_playback = 1? That's the default value in fsl_asoc_card_dai.
ah, should be dpcm_capture = 0.
>
> > @@ -601,19 +636,18 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> > priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
> > }
> >
> > - snprintf(priv->name, sizeof(priv->name), "%s-audio",
> > - fsl_asoc_card_is_ac97(priv) ? "ac97" :
> > - codec_dev->name);
> > -
> > /* Initialize sound card */
> > priv->pdev = pdev;
> > priv->card.dev = &pdev->dev;
> > - priv->card.name = priv->name;
> > + ret = snd_soc_of_parse_card_name(&priv->card, "model");
> > + if (ret) {
> > + snprintf(priv->name, sizeof(priv->name), "%s-audio",
> > + fsl_asoc_card_is_ac97(priv) ? "ac97" :
> > + (codec_dev ? codec_dev->name : codec_pdev->name));
>
> We can just use dev_name() if codec_dev is struct device *
> Or having a codec_dev_name to cache codec_pdev/i2c->name.
>
> > - ret = snd_soc_of_parse_audio_routing(&priv->card, "audio-routing");
> > - if (ret) {
> > - dev_err(&pdev->dev, "failed to parse audio-routing: %d\n", ret);
> > - goto asrc_fail;
> > + if (of_property_read_bool(np, "audio-routing")) {
> > + ret = snd_soc_of_parse_audio_routing(&priv->card, "audio-routing");
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to parse audio-routing: %d\n", ret);
> > + goto asrc_fail;
>
> Hmm...audio-routing is a required property in DT binding doc.
> So you might need to update that too.
will update them in v2.
best regards
wang shengjiu
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox