[PATCH v2] tpm_tis_spi_main: set cs_change = 0 when timesout
when i reach TPM_RETRY, the cs cannot change back to 'high'.
So the TPM chips thinks this communication is not over.
And next times communication cannot be effective because
the communications mixed up with the last time.
v1 -> v2:
- fix spi_xfer->cs_change error
Signed-off-by: wanghongzhe
---
drivers/char/tpm/tpm_tis_spi_main.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis_spi_main.c
b/drivers/char/tpm/tpm_tis_spi_main.c
index 3856f6ebcb34..6c52cbb28881 100644
--- a/drivers/char/tpm/tpm_tis_spi_main.c
+++ b/drivers/char/tpm/tpm_tis_spi_main.c
@@ -64,8 +64,18 @@ static int tpm_tis_spi_flow_control(struct tpm_tis_spi_phy
*phy,
break;
}
- if (i == TPM_RETRY)
+ if (i == TPM_RETRY) {
+ /* change back to 'high',
+* So the TPM chips thinks the last communication
+* is done.
+*/
+ spi_xfer->cs_change = 0;
+ spi_xfer->len = 1;
+ spi_message_init();
+ spi_message_add_tail(spi_xfer, );
+ ret = spi_sync_locked(phy->spi_device, );
return -ETIMEDOUT;
+ }
}
return 0;
--
2.19.1
Re: [PATCH v3 2/2] dmabuf: Add dmabuf inode number to /proc/*/fdinfo
Am 05.02.21 um 03:23 schrieb Kalesh Singh:
If a FD refers to a DMA buffer add the DMA buffer inode number to
/proc//fdinfo/ and /proc//task//fdindo/.
The dmabuf inode number allows userspace to uniquely identify the buffer
and avoids a dependency on /proc//fd/* when accounting per-process
DMA buffer sizes.
BTW: Why do we make this DMA-buf specific? Couldn't we always print the
inode number for all fds?
Regards,
Christian.
Signed-off-by: Kalesh Singh
---
Changes in v3:
- Add documentation in proc.rst
Changes in v2:
- Update patch description
Documentation/filesystems/proc.rst | 17 +
drivers/dma-buf/dma-buf.c | 1 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/filesystems/proc.rst
b/Documentation/filesystems/proc.rst
index 2fa69f710e2a..fdd38676f57f 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -2031,6 +2031,23 @@ details]. 'it_value' is remaining time until the timer
expiration.
with TIMER_ABSTIME option which will be shown in 'settime flags', but
'it_value'
still exhibits timer's remaining time.
+DMA Buffer files
+
+
+::
+
+ pos:0
+ flags: 04002
+ mnt_id: 9
+ dmabuf_inode_no: 63107
+ size: 32768
+ count: 2
+ exp_name: system-heap
+
+where 'dmabuf_inode_no' is the unique inode number of the DMA buffer file.
+'size' is the size of the DMA buffer in bytes. 'count' is the file count of
+the DMA buffer file. 'exp_name' is the name of the DMA buffer exporter.
+
3.9 /proc//map_files - Information about memory mapped files
-
This directory contains symbolic links which represent memory mapped files
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 9ad6397aaa97..d869099ede83 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -414,6 +414,7 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct
file *file)
{
struct dma_buf *dmabuf = file->private_data;
+ seq_printf(m, "dmabuf_inode_no:\t%lu\n", file_inode(file)->i_ino);
seq_printf(m, "size:\t%zu\n", dmabuf->size);
/* Don't count the temporary reference taken inside procfs seq_show */
seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
Re: Possible deny of service with memfd_create()
Am 05.02.21 um 01:32 schrieb Hugh Dickins: On Thu, 4 Feb 2021, Michal Hocko wrote: On Thu 04-02-21 17:32:20, Christian Koenig wrote: Hi Michal, as requested in the other mail thread the following sample code gets my test system down within seconds. The issue is that the memory allocated for the file descriptor is not accounted to the process allocating it, so the OOM killer pics whatever process it things is good but never my small test program. Since memfd_create() doesn't need any special permission this is a rather nice deny of service and as far as I can see also works with a standard Ubuntu 5.4.0-65-generic kernel. Thanks for following up. This is really nasty but now that I am looking at it more closely, this is not really different from tmpfs in general. You are free to create files and eat the memory without being accounted for that memory because that is not seen as your memory from the sysstem POV. You would have to map that memory to be part of your rss. I mostly agree. The big difference is that tmpfs is only available when mounted. And tmpfs can be restricted in size per mount point as well as per user quotas IIRC. Looking at my desktop system those restrictions are actually exactly what I see there. But memfd_create() is just free for all, you don't have any size limit nor access restriction as far as I can see. The only existing protection right now is to use memoery cgroup controller because the tmpfs memory is accounted to the process which faults the memory in (or write to the file). Agreed, but having to rely on cgroup is not really satisfying when you have to maintain a hardened server. I am not sure there is a good way to handle this in general unfortunatelly. Shmem is is just tricky (e.g. how to you deal with left overs after the fd is closed?). Maybe memfd_create can be more clever and account memory to all owners of the fd but even that sounds far from trivial from the accounting POV. It is true that tmpfs can at least control who can write to it which is not the case for memfd but then we hit the backward compatibility wall. Yes, no solution satisfactory, and memcg best, but don't forget echo 2 >/proc/sys/vm/overcommit_memory Good point as well. Regards, Christian. Hugh
Re: [PATCH -next] RISCV: Add some depends for NUMA
On 2021/2/5 14:58, Palmer Dabbelt wrote: On Wed, 03 Feb 2021 06:23:43 PST (-0800), wangkefeng.w...@huawei.com wrote: The numa feature is useless for riscv32 platform(MAXPHYSMEM_1GB if 32bit), I'm not convinced of that. There's no reason NUMA shouldn't work on 32-bit, it doesn't depend on having a large amount of memory just having non-uniform memory. I could buy the argument that build a 32-bit NUMA system would be wacky, but IIUC it works now and I don't see any reason to throw that away. I think the RV32 won't benefit from NUMA, there's no too much memory support on RV32, and it may increase the Image size, so I decided to drop support for RV32. and it should depends on SMP feature, this also fix the build error, I can buy that CONFIG_NUMA doesn't really make sense without CONFIG_SMP, as there's not a whole lot to do, but I also don't see any reason from disallowing users from picking it. arm64 allows !SMP && NUMA, and I don't see any reason it wouldn't work just as well for us. ARM64 won' support !SMP after following patch, and for most architecture, the NUMA feature depends or select SMP feature. commit 4b3dc9679cf779339d9049800803dfc3c83433d1 Author: Will Deacon Date: Fri May 29 18:28:44 2015 +0100 arm64: force CONFIG_SMP=y and remove redundant #ifdefs riscv64-buildroot-linux-gnu-ld: mm/page_alloc.o: in function `.L0 ': page_alloc.c:(.text+0x4808): undefined reference to `node_reclaim_distance' The only instance of node_reclaim_distance I see in mm/page_alloc.c is already guarded with CONFIG_NUMA, but the definition of node_reclaim_distance isn't. I'll send out some patches to add the guard which might make sorting this out earlier, but I don't see it fixing any failures.
Re: [PATCH v1] tpm_tis_spi_main: set cs_change = 0 when timesout
Hi wanghongzhe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v5.11-rc6 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/wanghongzhe/tpm_tis_spi_main-set-cs_change-0-when-timesout/20210205-140104
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
3a11b0b5d8d2b3f7d4b44945ef9226a3115bb15f
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/42343d4238cfd18831ed331b153cc6d2c0a7bc33
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
wanghongzhe/tpm_tis_spi_main-set-cs_change-0-when-timesout/20210205-140104
git checkout 42343d4238cfd18831ed331b153cc6d2c0a7bc33
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=nios2
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/char/tpm/tpm_tis_spi_main.c: In function 'tpm_tis_spi_flow_control':
>> drivers/char/tpm/tpm_tis_spi_main.c:72:12: error: 'spi_xfer' is a pointer;
>> did you mean to use '->'?
72 |spi_xfer.cs_change = 0;
|^
|->
At top level:
drivers/char/tpm/tpm_tis_spi_main.c:288:36: warning: 'acpi_tis_spi_match'
defined but not used [-Wunused-const-variable=]
288 | static const struct acpi_device_id acpi_tis_spi_match[] = {
|^~
vim +72 drivers/char/tpm/tpm_tis_spi_main.c
40
41 /*
42 * TCG SPI flow control is documented in section 6.4 of the spec[1]. In
short,
43 * keep trying to read from the device until MISO goes high indicating
the
44 * wait state has ended.
45 *
46 * [1]
https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
47 */
48 static int tpm_tis_spi_flow_control(struct tpm_tis_spi_phy *phy,
49 struct spi_transfer *spi_xfer)
50 {
51 struct spi_message m;
52 int ret, i;
53
54 if ((phy->iobuf[3] & 0x01) == 0) {
55 // handle SPI wait states
56 for (i = 0; i < TPM_RETRY; i++) {
57 spi_xfer->len = 1;
58 spi_message_init();
59 spi_message_add_tail(spi_xfer, );
60 ret = spi_sync_locked(phy->spi_device, );
61 if (ret < 0)
62 return ret;
63 if (phy->iobuf[0] & 0x01)
64 break;
65 }
66
67 if (i == TPM_RETRY) {
68 /* change back to 'high',
69 * So the TPM chips thinks the last
communication
70 * is done.
71 */
> 72 spi_xfer.cs_change = 0;
73 spi_xfer->len = 1;
74 spi_message_init();
75 spi_message_add_tail(spi_xfer, );
76 ret = spi_sync_locked(phy->spi_device, );
77 return -ETIMEDOUT;
78 }
79 }
80
81 return 0;
82 }
83
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2] drm/qxl: do not run release if qxl failed to init
On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote: > if qxl_device_init() fail, drm device will not be registered, > in this case, do not run qxl_drm_release() How do you trigger this? take care, Gerd
Re: [PATCH] x86/sgx: Drop racy follow_pfn check
On Fri, Feb 5, 2021 at 3:26 AM Jarkko Sakkinen wrote: > > On Thu, Feb 04, 2021 at 07:45:19PM +0100, Daniel Vetter wrote: > > References: > > https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/ > > What is the difference between this and "Link:" anyway? Afaik References: is for other reading (bug reports, discussions, other patch series), Link: is for patch submission itself (which I think some subsystem do an entire chain of, on each revision). My scripts aren't good enough that they add the Link: before submitting, I add them when I apply patches (since most patches I get don't have them anyway). btw since the final patch to remove follow_pfn won't be ready for 5.12 merge window (kvm and vfio have some work to do) I think it's best if you just queue this up in your tree? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v3 3/4] drm_dp_mst_topology: export two functions
On Tue, 2 Feb 2021 at 09:03, Lyude Paul wrote:
>
> On Wed, 2020-09-23 at 12:13 +1000, Sam McNally wrote:
> > From: Hans Verkuil
> >
> > These are required for the CEC MST support.
> >
> > Signed-off-by: Hans Verkuil
> > Signed-off-by: Sam McNally
> > ---
> >
> > (no changes since v1)
> >
> > drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
> > include/drm/drm_dp_mst_helper.h | 4
> > 2 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 0d753201adbd..c783a2a1c114 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -62,8 +62,6 @@ struct drm_dp_pending_up_req {
> > static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
> > char *buf);
> >
> > -static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
> > -
> > static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> > int id,
> > struct drm_dp_payload *payload);
> > @@ -1864,7 +1862,7 @@ static void drm_dp_mst_topology_get_port(struct
> > drm_dp_mst_port *port)
> > * drm_dp_mst_topology_try_get_port()
> > * drm_dp_mst_topology_get_port()
> > */
> > -static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
> > +void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
>
> Mhh-can you think of some way around this? I really don't think it's a
> good
> idea for us to be exposing topology references to things as-is, the thing is
> they're really meant to be used for critical sections in code where it'd
> become
> very painful to deal with an mst port disappearing from under us. Outside of
> MST
> helpers, everyone else should be dealing with the expectation that these
> things
> can disappear as a result of hotplugs at any moment.
>
> Note that we do expose malloc refs, but that's intentional as holding a malloc
> ref to something doesn't cause it to stay around even when it's unplugged - it
> just stops it from being unallocated.
>
>
Yes, it turns out we won't need this after all.
> > {
> > topology_ref_history_lock(port->mgr);
> >
> > @@ -1935,7 +1933,7 @@ drm_dp_mst_topology_get_port_validated_locked(struct
> > drm_dp_mst_branch *mstb,
> > return NULL;
> > }
> >
> > -static struct drm_dp_mst_port *
> > +struct drm_dp_mst_port *
> > drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
> >struct drm_dp_mst_port *port)
> > {
> > diff --git a/include/drm/drm_dp_mst_helper.h
> > b/include/drm/drm_dp_mst_helper.h
> > index c7c79e0ced18..d036222e0d64 100644
> > --- a/include/drm/drm_dp_mst_helper.h
> > +++ b/include/drm/drm_dp_mst_helper.h
> > @@ -754,6 +754,10 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
> >struct drm_dp_mst_topology_mgr *mgr,
> >struct drm_dp_mst_port *port);
> >
> > +struct drm_dp_mst_port *drm_dp_mst_topology_get_port_validated
> > +(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
> > +void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
> > +
> > struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
> > drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
> >
> >
>
> --
> Sincerely,
>Lyude Paul (she/her)
>Software Engineer at Red Hat
>
> Note: I deal with a lot of emails and have a lot of bugs on my plate. If
> you've
> asked me a question, are waiting for a review/merge on a patch, etc. and I
> haven't responded in a while, please feel free to send me another email to
> check
> on my status. I don't bite!
>
Re: [PATCH 15/18] irqchip/apple-aic: Add support for the Apple Interrupt Controller
On 05/02/2021 08.04, Arnd Bergmann wrote: On Thu, Feb 4, 2021 at 11:06 PM Hector Martin 'marcan' wrote: If we split it up again, one of the two still needs to be the root, decide whether what fired is an IRQ or FIQ, and dispatch accordingly. Or we could have three nodes and have one root handler dispatch to IRQ and FIQ nodes, but that sounds like overkill... (?) Maybe I'm misreading the low-level entry code, but my impression was that the fiq and irq exception vectors could just be pointed to two different root drivers from the code in kernel_ventry Certainly, but we'd have to introduce a fiq handler global and duplicate the handler code; this is what was done in the previous submission, but I seem to recall someone (Marc?) mentioned it would be cleaner to just merge them into the single IRQ path and discriminate in the irqchip, which is what I did here. I can certainly go with either solution; I don't have a strong preference here. Advantages of split path: * More orthogonal Advantages of merged path: * Minimizes common vector changes needed for a single platform * Keeps FIQ/IRQ code common, so FIQs are less likely to be accidentally broken by people not testing on Apple platforms. Unclear: * Performance. Split path runs less code, merged path has lower icache pressure. Are you proposing just having different drivers/nodes in the same file, or implementing these as separate drivers in separate files? I was thinking of separate driver files. That's what I previously had then :) If this is the way to go I can certainly go back to that. I looked at other architectures, and found that at least powerpc and sparc64 have a really minimal timer tick, with their timer_interrupt() function getting called directly from the exception vector, and doing a minimum of accounting (irq_enter(), statistics, ...) manually. It's a different question if we want to do that, or if there should always be an irqchip for consistency. I think the issue here is that those platforms presumably have *one* timer hard wired to a specific exception vector (e.g. on PowerPC that's the decrementer). So, that setup is shared by all implementations in that platform. But on ARM64, the architectural timer is supposed to go through an irqchip (GIC in normal platforms), it's just that here it ended up hard-wired to FIQ - though not alone, since fast IPIs are also there, so we can't treat it as a strict "timer vector" either. So even if we could do this for Apple SoCs, it would be a non-standard setup, since every other ARM64 platform puts the timer behind an irqchip. Therefore, I think it makes sense to always go through an irqchip, rather than introduce a bypass for these SoCs. Also worth noting that we have at least two functional hardware timers here (not sure if there are more, we run with HCR_EL2.E2H=1 in m1n1 which maps the EL2 timer to be the EL1 timer; I'm not yet sure if setting that to 0 will expose extra HV timers or not) wired to the same FIQ. I confirmed that both the virtual and physical timers function independently in m1n1. I did confirm there are no secure timers, which is expected given that there is no EL3 on these chips. Benchmarking would at least help understand why there are two. Well, they call them "Fast IPIs" so *presumably* they are faster, but we'll see :) I don't think we have to pay too much attention to preparing the code design for it, we can always change it when needed. However, anything that impacts the DT binding here would have to be designed to not get in the way of adding it later. I think this shouldn't pose much of a problem, since IPIs aren't exposed in the DT anyway. As long as we decide how we're handling IRQs vs FIQs (one or two nodes/drivers), then either of them could take responsibility for handling IPIs depending on the platform. We should probably just add a "fast-ipi" property to both nodes on platforms that support that, so that the drivers can make the decision based on it. Or perhaps that should be done with different compatibles? -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub
Re: [PATCH v6 01/10] [hack] silence ttm fini WARNING
On Thu, Feb 04, 2021 at 03:58:33PM +0100, Christian König wrote:
> ?
>
> What's the background here?
>
> Christian.
>
> Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
> > kobject: '(null)' ((ptrval)): is not initialized, yet kobject_put()
> > is being called.
> > WARNING: CPU: 0 PID: 209 at lib/kobject.c:750 kobject_put+0x3a/0x60
> > [ ... ]
> > Call Trace:
> > ttm_device_fini+0x133/0x1b0 [ttm]
> > qxl_ttm_fini+0x2f/0x40 [qxl]
Happens on driver removal. Seen with both qxl and bochs (the later
using vram helpers).
Testcase: "drmtest --unbind" (https://git.kraxel.org/cgit/drminfo/).
static int try_unbind(int card)
{
char path[256];
char *device, *name;
int fd;
snprintf(path, sizeof(path), "/sys/class/drm/card%d/device", card);
device = realpath(path, NULL);
if (device == NULL) {
fprintf(stderr, "%s: can't resolve sysfs device path\n", __func__);
return -1;
}
snprintf(path, sizeof(path), "%s/driver/unbind", device);
fd = open(path, O_WRONLY);
if (fd < 0) {
fprintf(stderr, "open %s: %s\n", path, strerror(errno));
return -1;
}
name = strrchr(device, '/') + 1;
write(fd, name, strlen(name));
close(fd);
return 0;
}
take care,
Gerd
Re: ANNOUNCE: pahole v1.20 (gcc11 DWARF5's default, lots of ELF sections, BTF)
On Thu, Feb 4, 2021 at 8:34 PM Arnaldo Carvalho de Melo wrote: > > > > On February 4, 2021 9:01:51 PM GMT-03:00, Andrii Nakryiko > wrote: > >On Thu, Feb 4, 2021 at 2:09 PM Arnaldo Carvalho de Melo> > >wrote: > >> The v1.20 release of pahole and its friends is out, mostly > >> addressing problems related to gcc 11 defaulting to DWARF5 for -g, > >> available at the usual places: > > > >Great, thanks, Arnaldo! Do you plan to build RPMs soon as well? > > It's in rawhide already, I'll do it for f33, f32 later, > Do you have a link? I tried to find it, but only see 1.19 so far. > - Arnaldo > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH v2 2/2] of: property: Add fw_devlink support for interrupts
Hi Saravana,
On 04.02.2021 22:31, Saravana Kannan wrote:
> On Thu, Feb 4, 2021 at 3:52 AM Marek Szyprowski
> wrote:
>> On 21.01.2021 23:57, Saravana Kannan wrote:
>>> This allows fw_devlink to create device links between consumers of an
>>> interrupt and the supplier of the interrupt.
>>>
>>> Cc: Marc Zyngier
>>> Cc: Kevin Hilman
>>> Cc: Greg Kroah-Hartman
>>> Reviewed-by: Rob Herring
>>> Reviewed-by: Thierry Reding
>>> Reviewed-by: Linus Walleij
>>> Signed-off-by: Saravana Kannan
>> This patch landed some time ago in linux-next as commit 4104ca776ba3
>> ("of: property: Add fw_devlink support for interrupts"). It breaks MMC
>> host controller operation on ARM Juno R1 board (the mmci@5 device
>> defined in arch/arm64/boot/dts/arm/juno-motherboard.dtsi). I didn't
> I grepped around and it looks like the final board file is this or
> whatever includes it?
> arch/arm64/boot/dts/arm/juno-base.dtsi
The final board file is arch/arm64/boot/dts/arm/juno-r1.dts
> This patch just finds the interrupt-parent and then tries to use that
> as a supplier if "interrupts" property is listed. But the only
> interrupt parent I can see is:
> gic: interrupt-controller@2c01 {
> compatible = "arm,gic-400", "arm,cortex-a15-gic";
>
> And the driver uses IRQCHIP_DECLARE() and hence should be pretty much
> a NOP since those suppliers are never devices and are ignored.
> $ git grep "arm,gic-400" -- drivers/
> drivers/irqchip/irq-gic.c:IRQCHIP_DECLARE(gic_400, "arm,gic-400",
> gic_of_init);
>
> This doesn't make any sense. Am I looking at the right files? Am I
> missing something?
Okay, I've added displaying a list of deferred devices when mounting
rootfs fails and got following items:
Deferred devices:
1800.ethernet platform: probe deferral - supplier
bus@800:motherboard-bus not ready
1c05.mmci amba: probe deferral - supplier
bus@800:motherboard-bus not ready
1c1d.gpio amba: probe deferral - supplier
bus@800:motherboard-bus not ready
2b60.iommu platform: probe deferral - wait for supplier
scpi-power-domains
7ff5.hdlcd platform: probe deferral - wait for supplier scpi-clk
7ff6.hdlcd platform: probe deferral - wait for supplier scpi-clk
1c06.kmi amba: probe deferral - supplier
bus@800:motherboard-bus not ready
1c07.kmi amba: probe deferral - supplier
bus@800:motherboard-bus not ready
1c17.rtc amba: probe deferral - supplier
bus@800:motherboard-bus not ready
1c0f.wdt amba: probe deferral - supplier
bus@800:motherboard-bus not ready
gpio-keys
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
I don't see the 'bus@800:motherboard-bus' on the deferred devices
list, so it looks that device core added a link to something that is not
a platform device...
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
[RESEND PATH] ASoC: dmaengine_pcm: add peripheral configuration
The commit e7bbb7acabf4 ("dmaengine: add peripheral configuration")
adds peripheral configuration for dma_slave_config.
This configuration is useful for some audio peripherals, for
example, the peripheral supports multi fifos, we can
let the DMA know which fifos are selected. So also add
this configuration for snd_dmaengine_dai_dma_data.
Signed-off-by: Shengjiu Wang
---
include/sound/dmaengine_pcm.h | 5 +
sound/core/pcm_dmaengine.c| 2 ++
2 files changed, 7 insertions(+)
diff --git a/include/sound/dmaengine_pcm.h b/include/sound/dmaengine_pcm.h
index 8c5e38180fb0..9efddb39 100644
--- a/include/sound/dmaengine_pcm.h
+++ b/include/sound/dmaengine_pcm.h
@@ -66,6 +66,9 @@ struct dma_chan *snd_dmaengine_pcm_get_chan(struct
snd_pcm_substream *substream)
* @chan_name: Custom channel name to use when requesting DMA channel.
* @fifo_size: FIFO size of the DAI controller in bytes
* @flags: PCM_DAI flags, only SND_DMAENGINE_PCM_DAI_FLAG_PACK for now
+ * @peripheral_config: peripheral configuration for programming peripheral
+ * for dmaengine transfer
+ * @peripheral_size: peripheral configuration buffer size
*/
struct snd_dmaengine_dai_dma_data {
dma_addr_t addr;
@@ -76,6 +79,8 @@ struct snd_dmaengine_dai_dma_data {
const char *chan_name;
unsigned int fifo_size;
unsigned int flags;
+ void *peripheral_config;
+ size_t peripheral_size;
};
void snd_dmaengine_pcm_set_config_from_dai_data(
diff --git a/sound/core/pcm_dmaengine.c b/sound/core/pcm_dmaengine.c
index 4d0e8fe535a1..1fc2fa077574 100644
--- a/sound/core/pcm_dmaengine.c
+++ b/sound/core/pcm_dmaengine.c
@@ -125,6 +125,8 @@ void snd_dmaengine_pcm_set_config_from_dai_data(
}
slave_config->slave_id = dma_data->slave_id;
+ slave_config->peripheral_config = dma_data->peripheral_config;
+ slave_config->peripheral_size = dma_data->peripheral_size;
}
EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_set_config_from_dai_data);
--
2.27.0
Re: [PATCH v3 4/4] drm_dp_cec: add MST support
On Thu, 4 Feb 2021 at 21:42, Hans Verkuil wrote:
>
> On 23/09/2020 04:13, Sam McNally wrote:
> > With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> > topology.
> >
> > There are some minor differences for CEC tunneling through an MST
> > topology compared to CEC tunneling to an SST port:
> > - CEC IRQs are delivered via a sink event notify message
> > - CEC-related DPCD registers are accessed via remote DPCD reads and
> > writes.
> >
> > This results in the MST implementation diverging from the existing SST
> > implementation:
> > - sink event notify messages with CEC_IRQ ID set indicate CEC IRQ rather
> > than ESI1
> > - setting edid and handling CEC IRQs, which can be triggered from
> > contexts where locks held preclude HPD handling, are deferred to avoid
> > remote DPCD access which would block until HPD handling is performed
> > or a timeout
> >
> > Register and unregister for all MST connectors, ensuring their
> > drm_dp_aux_cec struct won't be accessed uninitialized.
> >
> > Reviewed-by: Hans Verkuil
> > Signed-off-by: Sam McNally
> > ---
> >
> > Changes in v3:
> > - Fixed whitespace in drm_dp_cec_mst_irq_work()
> > - Moved drm_dp_cec_mst_set_edid_work() with the other set_edid functions
> >
> > Changes in v2:
> > - Used aux->is_remote instead of aux->cec.is_mst, removing the need for
> > the previous patch in the series
> > - Added a defensive check for null edid in the deferred set_edid work,
> > in case the edid is no longer valid at that point
> >
> > drivers/gpu/drm/drm_dp_cec.c | 68 +--
> > drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++
> > include/drm/drm_dp_helper.h | 4 ++
> > 3 files changed, 91 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> > index 3ab2609f9ec7..1020b2cffdf0 100644
> > --- a/drivers/gpu/drm/drm_dp_cec.c
> > +++ b/drivers/gpu/drm/drm_dp_cec.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> > * Unfortunately it turns out that we have a chicken-and-egg situation
> > @@ -248,6 +249,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
> > if (!aux->transfer)
> > return;
> >
> > + if (aux->is_remote) {
> > + schedule_work(>cec.mst_irq_work);
> > + return;
> > + }
>
> Are these workqueues for cec_irq and cec_set_edid actually needed? They are
> called
> directly from drm_dp_mst_topology.c, and I think they can be handled
> identically to
> a normal, non-remote, aux device.
>
> Avoiding using a workqueue probably also means that there is no need for
> exporting
> drm_dp_mst_topology_get_port_validated and drm_dp_mst_topology_put_port.
>
> Provided that I am not missing something, this should simplify the code quite
> a bit.
Indeed; with commit 9408cc94eb04 ("drm/dp_mst: Handle UP requests
asynchronously") they're unnecessary. This all simplifies quite
nicely.
>
> Regards,
>
> Hans
>
> > mutex_lock(>cec.lock);
> > if (!aux->cec.adap)
> > goto unlock;
> > @@ -276,6 +281,23 @@ static bool drm_dp_cec_cap(struct drm_dp_aux *aux, u8
> > *cec_cap)
> > return true;
> > }
> >
> > +static void drm_dp_cec_mst_irq_work(struct work_struct *work)
> > +{
> > + struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
> > + cec.mst_irq_work);
> > + struct drm_dp_mst_port *port =
> > + container_of(aux, struct drm_dp_mst_port, aux);
> > +
> > + port = drm_dp_mst_topology_get_port_validated(port->mgr, port);
> > + if (!port)
> > + return;
> > + mutex_lock(>cec.lock);
> > + if (aux->cec.adap)
> > + drm_dp_cec_handle_irq(aux);
> > + mutex_unlock(>cec.lock);
> > + drm_dp_mst_topology_put_port(port);
> > +}
> > +
> > /*
> > * Called if the HPD was low for more than drm_dp_cec_unregister_delay
> > * seconds. This unregisters the CEC adapter.
> > @@ -297,7 +319,8 @@ static void drm_dp_cec_unregister_work(struct
> > work_struct *work)
> > * were unchanged and just update the CEC physical address. Otherwise
> > * unregister the old CEC adapter and create a new one.
> > */
> > -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> > +static void drm_dp_cec_handle_set_edid(struct drm_dp_aux *aux,
> > +const struct edid *edid)
> > {
> > struct drm_connector *connector = aux->cec.connector;
> > u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> > @@ -306,10 +329,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> > struct edid *edid)
> > unsigned int num_las = 1;
> > u8 cap;
> >
> > - /* No transfer function was set, so not a DP connector */
> > - if (!aux->transfer)
> > - return;
> > -
> > #ifndef CONFIG_MEDIA_CEC_RC
> > /*
> >* CEC_CAP_RC is part of
Re: [PATCH] mm/memtest: Add ARCH_USE_MEMTEST
On Thu, Feb 4, 2021 at 8:10 PM Anshuman Khandual wrote: > > early_memtest() does not get called from all architectures. Hence enabling > CONFIG_MEMTEST and providing a valid memtest=[1..N] kernel command line > option might not trigger the memory pattern tests as would be expected in > normal circumstances. This situation is misleading. > > The change here prevents the above mentioned problem after introducing a > new config option ARCH_USE_MEMTEST that should be subscribed on platforms > that call early_memtest(), in order to enable the config CONFIG_MEMTEST. > Conversely CONFIG_MEMTEST cannot be enabled on platforms where it would > not be tested anyway. > > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Thomas Bogendoerfer > Cc: Michael Ellerman > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Chris Zankel > Cc: Max Filippov > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-xte...@linux-xtensa.org > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual > --- > This patch applies on v5.11-rc6 and has been tested on arm64 platform. But > it has been just build tested on all other platforms. > > arch/arm/Kconfig | 1 + > arch/arm64/Kconfig | 1 + > arch/mips/Kconfig| 1 + > arch/powerpc/Kconfig | 1 + > arch/x86/Kconfig | 1 + > arch/xtensa/Kconfig | 1 + > lib/Kconfig.debug| 9 - > 7 files changed, 14 insertions(+), 1 deletion(-) Anshuman, entries in arch/*/Konfig files are sorted in alphabetical order, please keep them that way. Reviewed-by: Max Filippov -- Thanks. -- Max
Re: [PATCH v3 04/11] iio: core: rework iio device group creation
On Thu, Feb 4, 2021 at 7:39 PM Jonathan Cameron
wrote:
>
> On Mon, 1 Feb 2021 16:50:58 +0200
> Alexandru Ardelean wrote:
>
> > Up until now, the device groups that an IIO device had were limited to 6.
> > Two of these groups would account for buffer attributes (the buffer/ and
> > scan_elements/ directories).
> >
> > Since we want to add multiple buffers per IIO device, this number may not
> > be enough, when adding a second buffer. So, this change reallocates the
> > groups array whenever an IIO device group is added, via a
> > iio_device_register_sysfs_group() helper.
> >
> > This also means that the groups array should be assigned to
> > 'indio_dev.dev.groups' really late, right before {cdev_}device_add() is
> > called to do the entire setup.
> > And we also must take care to free this array when the sysfs resources are
> > being cleaned up.
> >
> > With this change we can also move the 'groups' & 'groupcounter' fields to
> > the iio_dev_opaque object. Up until now, this didn't make a whole lot of
> > sense (especially since we weren't sure how multibuffer support would look
> > like in the end).
> > But doing it now kills one birds with one stone.
> >
> > An alternative, would be to add a configurable Kconfig symbol
> > CONFIG_IIO_MAX_BUFFERS_PER_DEVICE (or something like that) and compute a
> > static maximum of the groups we can support per IIO device. But that would
> > probably annoy a few people since that would make the system less
> > configurable.
> >
> > Signed-off-by: Alexandru Ardelean
> Nice change irrespective of the rest of the series needing it.
>
> Few comments below.
>
> Jonathan
>
> > ---
> > drivers/iio/iio_core.h | 3 +++
> > drivers/iio/industrialio-buffer.c | 12 +--
> > drivers/iio/industrialio-core.c| 32 +++---
> > drivers/iio/industrialio-event.c | 5 -
> > drivers/iio/industrialio-trigger.c | 6 ++
> > include/linux/iio/iio-opaque.h | 4
> > include/linux/iio/iio.h| 5 -
> > 7 files changed, 52 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > index fced02cadcc3..7d5b179c1fe7 100644
> > --- a/drivers/iio/iio_core.h
> > +++ b/drivers/iio/iio_core.h
> > @@ -46,6 +46,9 @@ int __iio_add_chan_devattr(const char *postfix,
> > struct list_head *attr_list);
> > void iio_free_chan_devattr_list(struct list_head *attr_list);
> >
> > +int iio_device_register_sysfs_group(struct iio_dev *indio_dev,
> > + const struct attribute_group *group);
> > +
> > ssize_t iio_format_value(char *buf, unsigned int type, int size, int
> > *vals);
> >
> > /* Event interface flags */
> > diff --git a/drivers/iio/industrialio-buffer.c
> > b/drivers/iio/industrialio-buffer.c
> > index 2f7426a2f47c..cc846988fdb9 100644
> > --- a/drivers/iio/industrialio-buffer.c
> > +++ b/drivers/iio/industrialio-buffer.c
> > @@ -1287,7 +1287,9 @@ static int __iio_buffer_alloc_sysfs_and_mask(struct
> > iio_buffer *buffer,
> > buffer->buffer_group.name = "buffer";
> > buffer->buffer_group.attrs = attr;
> >
> > - indio_dev->groups[indio_dev->groupcounter++] = >buffer_group;
> > + ret = iio_device_register_sysfs_group(indio_dev,
> > >buffer_group);
> > + if (ret)
> > + goto error_free_buffer_attrs;
> >
> > attrcount = 0;
> > INIT_LIST_HEAD(>scan_el_dev_attr_list);
> > @@ -1330,14 +1332,20 @@ static int __iio_buffer_alloc_sysfs_and_mask(struct
> > iio_buffer *buffer,
> >
> > list_for_each_entry(p, >scan_el_dev_attr_list, l)
> > buffer->scan_el_group.attrs[attrn++] = >dev_attr.attr;
> > - indio_dev->groups[indio_dev->groupcounter++] = >scan_el_group;
> > +
> > + ret = iio_device_register_sysfs_group(indio_dev,
> > >scan_el_group);
> > + if (ret)
> > + goto error_free_scan_el_attrs;
> >
> > return 0;
> >
> > +error_free_scan_el_attrs:
> > + kfree(buffer->scan_el_group.attrs);
> > error_free_scan_mask:
> > bitmap_free(buffer->scan_mask);
> > error_cleanup_dynamic:
> > iio_free_chan_devattr_list(>scan_el_dev_attr_list);
> > +error_free_buffer_attrs:
> > kfree(buffer->buffer_group.attrs);
> >
> > return ret;
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index 0a6fd299a978..ccd7aaff6d13 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1452,6 +1452,25 @@ static ssize_t iio_store_timestamp_clock(struct
> > device *dev,
> > return len;
> > }
> >
> > +int iio_device_register_sysfs_group(struct iio_dev *indio_dev,
> > + const struct attribute_group *group)
> > +{
> > + struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
> > + const struct attribute_group **new, **old = iio_dev_opaque->groups;
> > + unsigned int cnt =
Re: [PATCH 2/2] block: avoid to drop & re-add partitions if partitions aren't changed
On Fri, Feb 05, 2021 at 08:14:29AM +0100, Christoph Hellwig wrote: > On Fri, Feb 05, 2021 at 10:17:08AM +0800, Ming Lei wrote: > > block ioctl(BLKRRPART) always drops current partitions and adds > > partitions again, even though there isn't any change in partitions table. > > > > ioctl(BLKRRPART) may be called by systemd-udevd and some disk utilities > > frequently. > > Err, why? We should probably fix udev to not do stupid things first. It is one standard syscall, and the command is just for re-read partition table, and it can be called by any application, fdisk calls it too even though no any change done on the disk data, same with parted, and there should be more. #define BLKRRPART _IO(0x12,95) /* re-read partition table */ IMO, this syscall isn't supposed to drop partitions if user doesn't touch the partition table, do you think it is one sane behavior to drop partitions at will? -- Ming
Re: [PATCH v14 6/8] mm: hugetlb: introduce nr_free_vmemmap_pages in the struct hstate
On 2021/2/4 11:50, Muchun Song wrote:
> All the infrastructure is ready, so we introduce nr_free_vmemmap_pages
> field in the hstate to indicate how many vmemmap pages associated with
> a HugeTLB page that can be freed to buddy allocator. And initialize it
> in the hugetlb_vmemmap_init(). This patch is actual enablement of the
> feature.
>
> Signed-off-by: Muchun Song
> Acked-by: Mike Kravetz
> Reviewed-by: Oscar Salvador
> ---
> include/linux/hugetlb.h | 3 +++
> mm/hugetlb.c| 1 +
> mm/hugetlb_vmemmap.c| 30 ++
> mm/hugetlb_vmemmap.h| 5 +
> 4 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index ad249e56ac49..775aea53669a 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -560,6 +560,9 @@ struct hstate {
> unsigned int nr_huge_pages_node[MAX_NUMNODES];
> unsigned int free_huge_pages_node[MAX_NUMNODES];
> unsigned int surplus_huge_pages_node[MAX_NUMNODES];
> +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP
> + unsigned int nr_free_vmemmap_pages;
> +#endif
> #ifdef CONFIG_CGROUP_HUGETLB
> /* cgroup control files */
> struct cftype cgroup_files_dfl[7];
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 5518283aa667..04dde2b71f3e 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3220,6 +3220,7 @@ void __init hugetlb_add_hstate(unsigned int order)
> h->next_nid_to_free = first_memory_node;
> snprintf(h->name, HSTATE_NAME_LEN, "hugepages-%lukB",
> huge_page_size(h)/1024);
> + hugetlb_vmemmap_init(h);
>
> parsed_hstate = h;
> }
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 224a3cb69bf9..36ebd677e606 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -208,13 +208,10 @@ early_param("hugetlb_free_vmemmap",
> early_hugetlb_free_vmemmap_param);
> /*
> * How many vmemmap pages associated with a HugeTLB page that can be freed
> * to the buddy allocator.
> - *
> - * Todo: Returns zero for now, which means the feature is disabled. We will
> - * enable it once all the infrastructure is there.
> */
> static inline unsigned int free_vmemmap_pages_per_hpage(struct hstate *h)
> {
> - return 0;
> + return h->nr_free_vmemmap_pages;
> }
>
> static inline unsigned long free_vmemmap_pages_size_per_hpage(struct hstate
> *h)
> @@ -269,3 +266,28 @@ void free_huge_page_vmemmap(struct hstate *h, struct
> page *head)
>*/
> vmemmap_remap_free(vmemmap_addr, vmemmap_end, vmemmap_reuse);
> }
> +
> +void __init hugetlb_vmemmap_init(struct hstate *h)
> +{
> + unsigned int nr_pages = pages_per_huge_page(h);
> + unsigned int vmemmap_pages;
> +
> + if (!hugetlb_free_vmemmap_enabled)
> + return;
> +
> + vmemmap_pages = (nr_pages * sizeof(struct page)) >> PAGE_SHIFT;
> + /*
> + * The head page and the first tail page are not to be freed to buddy
> + * allocator, the other pages will map to the first tail page, so they
> + * can be freed.
> + *
> + * Could RESERVE_VMEMMAP_NR be greater than @vmemmap_pages? It is true
> + * on some architectures (e.g. aarch64). See Documentation/arm64/
> + * hugetlbpage.rst for more details.
> + */
> + if (likely(vmemmap_pages > RESERVE_VMEMMAP_NR))
> + h->nr_free_vmemmap_pages = vmemmap_pages - RESERVE_VMEMMAP_NR;
Not a problem. Should we set h->nr_free_vmemmap_pages to 0 in 'else' case
explicitly ?
Anyway, looks good to me. Thanks.
Reviewed-by: Miaohe Lin
> +
> + pr_info("can free %d vmemmap pages for %s\n", h->nr_free_vmemmap_pages,
> + h->name);
> +}
> diff --git a/mm/hugetlb_vmemmap.h b/mm/hugetlb_vmemmap.h
> index 6f89a9eed02c..02a21604ef1d 100644
> --- a/mm/hugetlb_vmemmap.h
> +++ b/mm/hugetlb_vmemmap.h
> @@ -14,6 +14,7 @@
> int alloc_huge_page_vmemmap(struct hstate *h, struct page *head,
> gfp_t gfp_mask);
> void free_huge_page_vmemmap(struct hstate *h, struct page *head);
> +void hugetlb_vmemmap_init(struct hstate *h);
> #else
> static inline int alloc_huge_page_vmemmap(struct hstate *h, struct page
> *head,
> gfp_t gfp_mask)
> @@ -24,5 +25,9 @@ static inline int alloc_huge_page_vmemmap(struct hstate *h,
> struct page *head,
> static inline void free_huge_page_vmemmap(struct hstate *h, struct page
> *head)
> {
> }
> +
> +static inline void hugetlb_vmemmap_init(struct hstate *h)
> +{
> +}
> #endif /* CONFIG_HUGETLB_PAGE_FREE_VMEMMAP */
> #endif /* _LINUX_HUGETLB_VMEMMAP_H */
>
Re: [PATCH v14 7/8] mm: hugetlb: gather discrete indexes of tail page
On 2021/2/4 11:50, Muchun Song wrote:
> For HugeTLB page, there are more metadata to save in the struct page.
> But the head struct page cannot meet our needs, so we have to abuse
> other tail struct page to store the metadata. In order to avoid
> conflicts caused by subsequent use of more tail struct pages, we can
> gather these discrete indexes of tail struct page. In this case, it
> will be easier to add a new tail page index later.
>
> There are only (RESERVE_VMEMMAP_SIZE / sizeof(struct page)) struct
> page structs that can be used when CONFIG_HUGETLB_PAGE_FREE_VMEMMAP,
> so add a BUILD_BUG_ON to catch invalid usage of the tail struct page.
>
> Signed-off-by: Muchun Song
> Reviewed-by: Oscar Salvador
Thanks.
Reviewed-by: Miaohe Lin
> ---
> include/linux/hugetlb.h| 20 ++--
> include/linux/hugetlb_cgroup.h | 19 +++
> mm/hugetlb_vmemmap.c | 8
> 3 files changed, 37 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 775aea53669a..822ab2f5542a 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -28,6 +28,22 @@ typedef struct { unsigned long pd; } hugepd_t;
> #include
> #include
>
> +/*
> + * For HugeTLB page, there are more metadata to save in the struct page. But
> + * the head struct page cannot meet our needs, so we have to abuse other tail
> + * struct page to store the metadata. In order to avoid conflicts caused by
> + * subsequent use of more tail struct pages, we gather these discrete indexes
> + * of tail struct page here.
> + */
> +enum {
> + SUBPAGE_INDEX_SUBPOOL = 1, /* reuse page->private */
> +#ifdef CONFIG_CGROUP_HUGETLB
> + SUBPAGE_INDEX_CGROUP, /* reuse page->private */
> + SUBPAGE_INDEX_CGROUP_RSVD, /* reuse page->private */
> +#endif
> + NR_USED_SUBPAGE,
> +};
> +
> struct hugepage_subpool {
> spinlock_t lock;
> long count;
> @@ -607,13 +623,13 @@ extern unsigned int default_hstate_idx;
> */
> static inline struct hugepage_subpool *hugetlb_page_subpool(struct page
> *hpage)
> {
> - return (struct hugepage_subpool *)(hpage+1)->private;
> + return (void *)page_private(hpage + SUBPAGE_INDEX_SUBPOOL);
> }
>
> static inline void hugetlb_set_page_subpool(struct page *hpage,
> struct hugepage_subpool *subpool)
> {
> - set_page_private(hpage+1, (unsigned long)subpool);
> + set_page_private(hpage + SUBPAGE_INDEX_SUBPOOL, (unsigned long)subpool);
> }
>
> static inline struct hstate *hstate_file(struct file *f)
> diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
> index 2ad6e92f124a..c0cae6a704f2 100644
> --- a/include/linux/hugetlb_cgroup.h
> +++ b/include/linux/hugetlb_cgroup.h
> @@ -21,15 +21,16 @@ struct hugetlb_cgroup;
> struct resv_map;
> struct file_region;
>
> +#ifdef CONFIG_CGROUP_HUGETLB
> /*
> * Minimum page order trackable by hugetlb cgroup.
> * At least 4 pages are necessary for all the tracking information.
> - * The second tail page (hpage[2]) is the fault usage cgroup.
> - * The third tail page (hpage[3]) is the reservation usage cgroup.
> + * The second tail page (hpage[SUBPAGE_INDEX_CGROUP]) is the fault
> + * usage cgroup. The third tail page (hpage[SUBPAGE_INDEX_CGROUP_RSVD])
> + * is the reservation usage cgroup.
> */
> -#define HUGETLB_CGROUP_MIN_ORDER 2
> +#define HUGETLB_CGROUP_MIN_ORDER order_base_2(NR_USED_SUBPAGE)
>
> -#ifdef CONFIG_CGROUP_HUGETLB
> enum hugetlb_memory_event {
> HUGETLB_MAX,
> HUGETLB_NR_MEMORY_EVENTS,
> @@ -66,9 +67,9 @@ __hugetlb_cgroup_from_page(struct page *page, bool rsvd)
> if (compound_order(page) < HUGETLB_CGROUP_MIN_ORDER)
> return NULL;
> if (rsvd)
> - return (struct hugetlb_cgroup *)page[3].private;
> + return (void *)page_private(page + SUBPAGE_INDEX_CGROUP_RSVD);
> else
> - return (struct hugetlb_cgroup *)page[2].private;
> + return (void *)page_private(page + SUBPAGE_INDEX_CGROUP);
> }
>
> static inline struct hugetlb_cgroup *hugetlb_cgroup_from_page(struct page
> *page)
> @@ -90,9 +91,11 @@ static inline int __set_hugetlb_cgroup(struct page *page,
> if (compound_order(page) < HUGETLB_CGROUP_MIN_ORDER)
> return -1;
> if (rsvd)
> - page[3].private = (unsigned long)h_cg;
> + set_page_private(page + SUBPAGE_INDEX_CGROUP_RSVD,
> + (unsigned long)h_cg);
> else
> - page[2].private = (unsigned long)h_cg;
> + set_page_private(page + SUBPAGE_INDEX_CGROUP,
> + (unsigned long)h_cg);
> return 0;
> }
>
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 36ebd677e606..8efad9978821 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -272,6 +272,14 @@ void __init
Re: [patch 08/12] x86/entry: Use run_sysvec_on_irqstack_cond() for XEN upcall
Hi Thomas, I love your patch! Perhaps something to improve: [auto build test WARNING on tip/x86/asm] [also build test WARNING on tip/master linus/master tip/x86/core v5.11-rc6 next-20210125] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-irq-64-Inline-irq-stack-switching/20210205-091059 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 5c99720b28381bb400d4f546734c34ddaf608761 config: x86_64-rhel (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/ab3144e8d40d2a97101655f99804baa009bcdc36 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Thomas-Gleixner/x86-irq-64-Inline-irq-stack-switching/20210205-091059 git checkout ab3144e8d40d2a97101655f99804baa009bcdc36 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> arch/x86/entry/common.o: warning: objtool: xen_pv_evtchn_do_upcall()+0xa3: >> undefined stack state --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH 2/2] can: m_can: m_can_class_allocate_dev(): remove impossible error return judgment
If the previous can_net device has been successfully allocated, its
private data structure is impossible to be empty, remove this redundant
error return judgment. Otherwise, memory leaks for alloc_candev() will
be triggered.
Signed-off-by: Xulin Sun
---
drivers/net/can/m_can/m_can.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 02c5795b7393..042940088d41 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1797,11 +1797,6 @@ struct m_can_classdev *m_can_class_allocate_dev(struct
device *dev)
}
class_dev = netdev_priv(net_dev);
- if (!class_dev) {
- dev_err(dev, "Failed to init netdev cdevate");
- goto out;
- }
-
class_dev->net = net_dev;
class_dev->dev = dev;
SET_NETDEV_DEV(net_dev, dev);
--
2.17.1
[PATCH 1/2] can: m_can: m_can_plat_probe(): free can_net device in case probe fails
The can_net device is allocated through kvzalloc(), if the subsequent probe cases fail to initialize, it should free the can_net device that has been successfully allocated before. To fix below memory leaks call trace: unreferenced object 0xfc08418b (size 32768): comm "kworker/0:1", pid 22, jiffies 4294893966 (age 931.976s) hex dump (first 32 bytes): 63 61 6e 25 64 00 00 00 00 00 00 00 00 00 00 00 can%d... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<3faec9cc>] __kmalloc+0x1a4/0x3e0 [<560b1cad>] kvmalloc_node+0xa0/0xb0 [<93bada32>] alloc_netdev_mqs+0x60/0x380 [<41ddbb53>] alloc_candev_mqs+0x6c/0x14c [] m_can_class_allocate_dev+0x64/0x18c [<9fef1617>] m_can_plat_probe+0x2c/0x1f4 [<6fdcc497>] platform_drv_probe+0x5c/0xb0 [ ] really_probe+0xec/0x41c [<3ffa5158>] driver_probe_device+0x60/0xf0 [<5986c77e>] __device_attach_driver+0xb0/0x100 [<757823bc>] bus_for_each_drv+0x8c/0xe0 [<59253919>] __device_attach+0xdc/0x180 [<35c2b9f1>] device_initial_probe+0x28/0x34 [<82e2c85c>] bus_probe_device+0xa4/0xb0 [ ] deferred_probe_work_func+0x7c/0xb0 [<01b85f22>] process_one_work+0x1ec/0x480 Signed-off-by: Xulin Sun --- drivers/net/can/m_can/m_can_platform.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c index 38ea5e600fb8..0a2655c94018 100644 --- a/drivers/net/can/m_can/m_can_platform.c +++ b/drivers/net/can/m_can/m_can_platform.c @@ -67,8 +67,10 @@ static int m_can_plat_probe(struct platform_device *pdev) return -ENOMEM; priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL); - if (!priv) - return -ENOMEM; + if (!priv) { + ret = -ENOMEM; + goto failed_ret; + } mcan_class->device_data = priv; @@ -113,7 +115,11 @@ static int m_can_plat_probe(struct platform_device *pdev) ret = m_can_class_register(mcan_class); + return ret; + failed_ret: + free_candev(mcan_class->net); + return ret; } -- 2.17.1
Re: [PATCH v14 5/8] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap
Hi:
On 2021/2/4 11:50, Muchun Song wrote:
> Add a kernel parameter hugetlb_free_vmemmap to enable the feature of
> freeing unused vmemmap pages associated with each hugetlb page on boot.
>
> We disables PMD mapping of vmemmap pages for x86-64 arch when this
> feature is enabled. Because vmemmap_remap_free() depends on vmemmap
> being base page mapped.
>
> Signed-off-by: Muchun Song
> Reviewed-by: Oscar Salvador
> Reviewed-by: Barry Song
Looks good to me. Thanks.
Reviewed-by: Miaohe Lin
> ---
> Documentation/admin-guide/kernel-parameters.txt | 14 ++
> Documentation/admin-guide/mm/hugetlbpage.rst| 3 +++
> arch/x86/mm/init_64.c | 8 ++--
> include/linux/hugetlb.h | 19 +++
> mm/hugetlb_vmemmap.c| 22 ++
> 5 files changed, 64 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 5adf1e57e932..7db2591f3ad3 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1577,6 +1577,20 @@
> Documentation/admin-guide/mm/hugetlbpage.rst.
> Format: size[KMG]
>
> + hugetlb_free_vmemmap=
> + [KNL] When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set,
> + this controls freeing unused vmemmap pages associated
> + with each HugeTLB page. When this option is enabled,
> + we disable PMD/huge page mapping of vmemmap pages which
> + increase page table pages. So if a user/sysadmin only
> + uses a small number of HugeTLB pages (as a percentage
> + of system memory), they could end up using more memory
> + with hugetlb_free_vmemmap on as opposed to off.
> + Format: { on | off (default) }
> +
> + on: enable the feature
> + off: disable the feature
> +
> hung_task_panic=
> [KNL] Should the hung task detector generate panics.
> Format: 0 | 1
> diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst
> b/Documentation/admin-guide/mm/hugetlbpage.rst
> index f7b1c7462991..3a23c2377acc 100644
> --- a/Documentation/admin-guide/mm/hugetlbpage.rst
> +++ b/Documentation/admin-guide/mm/hugetlbpage.rst
> @@ -145,6 +145,9 @@ default_hugepagesz
>
> will all result in 256 2M huge pages being allocated. Valid default
> huge page size is architecture dependent.
> +hugetlb_free_vmemmap
> + When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set, this enables freeing
> + unused vmemmap pages associated with each HugeTLB page.
>
> When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages``
> indicates the current number of pre-allocated huge pages of the default size.
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 0435bee2e172..39f88c5faadc 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1557,7 +1558,8 @@ int __meminit vmemmap_populate(unsigned long start,
> unsigned long end, int node,
> {
> int err;
>
> - if (end - start < PAGES_PER_SECTION * sizeof(struct page))
> + if ((is_hugetlb_free_vmemmap_enabled() && !altmap) ||
> + end - start < PAGES_PER_SECTION * sizeof(struct page))
> err = vmemmap_populate_basepages(start, end, node, NULL);
> else if (boot_cpu_has(X86_FEATURE_PSE))
> err = vmemmap_populate_hugepages(start, end, node, altmap);
> @@ -1585,6 +1587,8 @@ void register_page_bootmem_memmap(unsigned long
> section_nr,
> pmd_t *pmd;
> unsigned int nr_pmd_pages;
> struct page *page;
> + bool base_mapping = !boot_cpu_has(X86_FEATURE_PSE) ||
> + is_hugetlb_free_vmemmap_enabled();
>
> for (; addr < end; addr = next) {
> pte_t *pte = NULL;
> @@ -1610,7 +1614,7 @@ void register_page_bootmem_memmap(unsigned long
> section_nr,
> }
> get_page_bootmem(section_nr, pud_page(*pud), MIX_SECTION_INFO);
>
> - if (!boot_cpu_has(X86_FEATURE_PSE)) {
> + if (base_mapping) {
> next = (addr + PAGE_SIZE) & PAGE_MASK;
> pmd = pmd_offset(pud, addr);
> if (pmd_none(*pmd))
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 37fd248ce271..ad249e56ac49 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -854,6 +854,20 @@ static inline void huge_ptep_modify_prot_commit(struct
> vm_area_struct *vma,
>
> void set_page_huge_active(struct page *page);
>
> +#ifdef
[PATCH] staging: bcm2835-audio: Replace unsafe strcpy() with strscpy()
Replace strcpy() with strscpy() in bcm2835-audio/bcm2835.c to prevent the
following when loading snd-bcm2835:
[ 58.480634] [ cut here ]
[ 58.485321] kernel BUG at lib/string.c:1149!
[ 58.489650] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 58.495214] Modules linked in: snd_bcm2835(COE+) snd_pcm snd_timer snd
dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua btsdio bluetooth
ecdh_generic ecc bcm2835_v4l2(CE) bcm2835_codec(CE) brcmfmac bcm2835_isp(CE)
bcm2835_mmal_vchiq(CE) brcmutil cfg80211 v4l2_mem2mem videobuf2_vmalloc
videobuf2_dma_contig videobuf2_memops raspberrypi_hwmon videobuf2_v4l2
videobuf2_common videodev bcm2835_gpiomem mc vc_sm_cma(CE) rpivid_mem
uio_pdrv_genirq uio sch_fq_codel drm ip_tables x_tables autofs4 btrfs
blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear
dwc2 roles spidev udc_core crct10dif_ce xhci_pci xhci_pci_renesas phy_generic
aes_neon_bs aes_neon_blk crypto_simd cryptd
[ 58.563787] CPU: 3 PID: 1959 Comm: insmod Tainted: G C OE
5.11.0-1001-raspi #1
[ 58.572172] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[ 58.578086] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 58.584178] pc : fortify_panic+0x20/0x24
[ 58.588161] lr : fortify_panic+0x20/0x24
[ 58.592136] sp : 800010a83990
[ 58.595491] x29: 800010a83990 x28: 0002
[ 58.600879] x27: b0b07cb72928 x26:
[ 58.606268] x25: 39e884973838 x24: b0b07cb74190
[ 58.611655] x23: b0b07cb72030 x22:
[ 58.617042] x21: 39e884973014 x20: 39e88b793010
[ 58.622428] x19: b0b07cb72670 x18: 0030
[ 58.627814] x17: x16: b0b092ce2c1c
[ 58.633200] x15: 39e88b901500 x14: 0720072007200720
[ 58.638588] x13: 0720072007200720 x12: 0720072007200720
[ 58.643979] x11: b0b0936cbdf0 x10: f000
[ 58.649366] x9 : b0b09220cfa8 x8 :
[ 58.654752] x7 : b0b093673df0 x6 : b0b09364e000
[ 58.660140] x5 : x4 : 39e93b7db948
[ 58.665526] x3 : 39e93b7ebcf0 x2 :
[ 58.670913] x1 : x0 : 0022
[ 58.676299] Call trace:
[ 58.678775] fortify_panic+0x20/0x24
[ 58.682402] snd_bcm2835_alsa_probe+0x5b8/0x7d8 [snd_bcm2835]
[ 58.688247] platform_probe+0x74/0xe4
[ 58.691963] really_probe+0xf0/0x510
[ 58.695585] driver_probe_device+0xe0/0x100
[ 58.699826] device_driver_attach+0xcc/0xd4
[ 58.704068] __driver_attach+0xb0/0x17c
[ 58.707956] bus_for_each_dev+0x7c/0xd4
[ 58.711843] driver_attach+0x30/0x40
[ 58.715467] bus_add_driver+0x154/0x250
[ 58.719354] driver_register+0x84/0x140
[ 58.723242] __platform_driver_register+0x34/0x40
[ 58.728013] bcm2835_alsa_driver_init+0x30/0x1000 [snd_bcm2835]
[ 58.734024] do_one_initcall+0x54/0x300
[ 58.737914] do_init_module+0x60/0x280
[ 58.741719] load_module+0x680/0x770
[ 58.745344] __do_sys_finit_module+0xbc/0x130
[ 58.749761] __arm64_sys_finit_module+0x2c/0x40
[ 58.754356] el0_svc_common.constprop.0+0x88/0x220
[ 58.759216] do_el0_svc+0x30/0xa0
[ 58.762575] el0_svc+0x28/0x70
[ 58.765669] el0_sync_handler+0x1a4/0x1b0
[ 58.769732] el0_sync+0x178/0x180
[ 58.773095] Code: aa0003e1 91366040 910003fd 97ffee21 (d421)
[ 58.779275] ---[ end trace 29be5b17497bd898 ]---
[ 58.783955] note: insmod[1959] exited with preempt_count 1
[ 58.791921] [ cut here ]
For the sake of it, replace all the other occurences of strcpy() under
bcm2835-audio/ as well.
Signed-off-by: Juerg Haefliger
---
drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 6 +++---
drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 2 +-
drivers/staging/vc04_services/bcm2835-audio/bcm2835.c | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index 4c2cae99776b..3703409715da 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -224,7 +224,7 @@ int snd_bcm2835_new_ctl(struct bcm2835_chip *chip)
{
int err;
- strcpy(chip->card->mixername, "Broadcom Mixer");
+ strscpy(chip->card->mixername, "Broadcom Mixer",
sizeof(chip->card->mixername));
err = create_ctls(chip, ARRAY_SIZE(snd_bcm2835_ctl), snd_bcm2835_ctl);
if (err < 0)
return err;
@@ -261,7 +261,7 @@ static const struct snd_kcontrol_new
snd_bcm2835_headphones_ctl[] = {
int snd_bcm2835_new_headphones_ctl(struct bcm2835_chip *chip)
{
- strcpy(chip->card->mixername, "Broadcom Mixer");
+ strscpy(chip->card->mixername, "Broadcom Mixer",
sizeof(chip->card->mixername));
return create_ctls(chip,
Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu
Hi Rob,
On Fri, 5 Feb 2021 at 07:25, Rob Herring wrote:
>
> On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> > From: Chunyan Zhang
> >
> > This iommu module can be used by Unisoc's multimedia devices, such as
> > display, Image codec(jpeg) and a few signal processors, including
> > VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
> >
> > Signed-off-by: Chunyan Zhang
> > ---
> > .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
> > 1 file changed, 72 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > new file mode 100644
> > index ..4fc99e81fa66
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > @@ -0,0 +1,72 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright 2020 Unisoc Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Unisoc IOMMU and Multi-media MMU
> > +
> > +maintainers:
> > + - Chunyan Zhang
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - sprd,iommu-v1
> > +
> > + "#iommu-cells":
> > +const: 0
> > +description:
> > + Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> > + additional information needs to associate with its master device.
> > + Please refer to the generic bindings document for more details,
> > + Documentation/devicetree/bindings/iommu/iommu.txt
> > +
> > + reg:
> > +maxItems: 1
> > +description:
> > + Not required if 'sprd,iommu-regs' is defined.
> > +
> > + clocks:
> > +description:
> > + Reference to a gate clock phandle, since access to some of IOMMUs are
> > + controlled by gate clock, but this is not required.
> > +
> > + sprd,iommu-regs:
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > +description:
> > + Reference to a syscon phandle plus 1 cell, the syscon defines the
> > + register range used by the iommu and the media device, the cell
> > + defines the offset for iommu registers. Since iommu module shares
> > + the same register range with the media device which uses it.
> > +
> > +required:
> > + - compatible
> > + - "#iommu-cells"
> > +
> > +oneOf:
> > + - required:
> > + - reg
> > + - required:
> > + - sprd,iommu-regs
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +iommu_disp: iommu-disp {
> > + compatible = "sprd,iommu-v1";
> > + sprd,iommu-regs = <_regs 0x800>;
>
> If the IOMMU is contained within another device, then it should just be
> a child node of that device.
Yes, actually IOMMU can be seen as a child of multimedia devices, I
considered moving IOMMU under into multimedia device node, but
multimedia devices need IOMMU when probe[1], so I dropped that idea.
And they share the same register base, e.g.
+ mm {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ dpu_regs: syscon@6300 {
+ compatible = "sprd,sc9863a-dpuregs", "syscon";
+ reg = <0 0x6300 0 0x1000>;
+ };
+
+ dpu: dpu@6300 {
+ compatible = "sprd,sharkl3-dpu";
+ sprd,disp-regs = <_regs>;
+ iommus = <_dispc>;
+ };
+
+ iommu_dispc: iommu@6300 {
+ compatible = "sprd,iommu-v1";
+ sprd,iommu-regs = <_regs 0x800>;
+ #iommu-cells = <0>;
+};
DPU use the registers from 0, IOMMU from 0x800, the purpose of using
syscon node was to avoid remapping register physical address.
> Or just make 'dpu_regs' an IOMMU provider
> (i.e. just add #iommu-cells to it).
xxx_regs(syscon node) defines the register range for IOMMU and a
multimedia device (such as dpu, image codec, etc.)
Hope I've explained the relationship of xxx_regs, multimedia device,
and iommu clearly :)
Any suggestion for this kind of cases?
Thanks,
Chunyan
[1]
https://elixir.bootlin.com/linux/v5.11-rc6/source/drivers/iommu/of_iommu.c#L145
>
> > + #iommu-cells = <0>;
> > +};
> > +
> > + - |
> > +iommu_jpg: iommu-jpg {
> > + compatible = "sprd,iommu-v1";
> > + sprd,iommu-regs = <_regs 0x300>;
> > + #iommu-cells = <0>;
> > + clocks = <_gate 1>;
> > +};
> > +
> > +...
> > --
> > 2.25.1
> >
Re: [PATCH] arch:powerpc simple_write_to_buffer return check
Please provide some description of the change. And please clarify the patch subject, because as far as I can see, the return is already checked allthough the check seams wrong. Le 04/02/2021 à 19:16, Mayank Suman a écrit : Signed-off-by: Mayank Suman --- arch/powerpc/kernel/eeh.c| 8 arch/powerpc/platforms/powernv/eeh-powernv.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c index 813713c9120c..2dbe1558a71f 100644 --- a/arch/powerpc/kernel/eeh.c +++ b/arch/powerpc/kernel/eeh.c @@ -1628,8 +1628,8 @@ static ssize_t eeh_force_recover_write(struct file *filp, char buf[20]; int ret; - ret = simple_write_to_buffer(buf, sizeof(buf), ppos, user_buf, count); - if (!ret) + ret = simple_write_to_buffer(buf, sizeof(buf)-1, ppos, user_buf, count); + if (ret <= 0) > return -EFAULT; Why return -EFAULT when the function has returned -EINVAL ? And why is it -EFAULT when ret is 0 ? EFAULT means error accessing memory. /* @@ -1696,7 +1696,7 @@ static ssize_t eeh_dev_check_write(struct file *filp, memset(buf, 0, sizeof(buf)); ret = simple_write_to_buffer(buf, sizeof(buf)-1, ppos, user_buf, count); - if (!ret) + if (ret <= 0) return -EFAULT; ret = sscanf(buf, "%x:%x:%x.%x", , , , ); @@ -1836,7 +1836,7 @@ static ssize_t eeh_dev_break_write(struct file *filp, memset(buf, 0, sizeof(buf)); ret = simple_write_to_buffer(buf, sizeof(buf)-1, ppos, user_buf, count); - if (!ret) + if (ret <= 0) return -EFAULT; ret = sscanf(buf, "%x:%x:%x.%x", , , , ); diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c index 89e22c460ebf..36ed2b8f7375 100644 --- a/arch/powerpc/platforms/powernv/eeh-powernv.c +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c @@ -76,8 +76,8 @@ static ssize_t pnv_eeh_ei_write(struct file *filp, return -ENXIO; /* Copy over argument buffer */ - ret = simple_write_to_buffer(buf, sizeof(buf), ppos, user_buf, count); - if (!ret) + ret = simple_write_to_buffer(buf, sizeof(buf)-1, ppos, user_buf, count); + if (ret <= 0) return -EFAULT; /* Retrieve parameters */
[PATCH v3 3/3] mailbox: cmdq: add mt8192 support
From: Yongqiang Niu
add mt8192 support
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
drivers/mailbox/mtk-cmdq-mailbox.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 5665b6ea8119f..de4793ef6798a 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -36,6 +36,8 @@
#define CMDQ_THR_WAIT_TOKEN0x30
#define CMDQ_THR_PRIORITY 0x40
+#define GCE_GCTL_VALUE 0x48
+
#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200
#define CMDQ_THR_ENABLED 0x1
#define CMDQ_THR_DISABLED 0x0
@@ -76,11 +78,13 @@ struct cmdq {
struct clk *clock;
boolsuspended;
u8 shift_pa;
+ boolcontrol_by_sw;
};
struct gce_plat {
u32 thread_nr;
u8 shift;
+ bool control_by_sw;
};
u8 cmdq_get_shift_pa(struct mbox_chan *chan)
@@ -121,6 +125,8 @@ static void cmdq_init(struct cmdq *cmdq)
int i;
WARN_ON(clk_enable(cmdq->clock) < 0);
+ if (cmdq->control_by_sw)
+ writel(0x7, cmdq->base + GCE_GCTL_VALUE);
writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
for (i = 0; i <= CMDQ_MAX_EVENT; i++)
writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
@@ -536,6 +542,7 @@ static int cmdq_probe(struct platform_device *pdev)
cmdq->thread_nr = plat_data->thread_nr;
cmdq->shift_pa = plat_data->shift;
+ cmdq->control_by_sw = plat_data->control_by_sw;
cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
"mtk_cmdq", cmdq);
@@ -601,11 +608,14 @@ static const struct dev_pm_ops cmdq_pm_ops = {
static const struct gce_plat gce_plat_v2 = {.thread_nr = 16};
static const struct gce_plat gce_plat_v3 = {.thread_nr = 24};
static const struct gce_plat gce_plat_v4 = {.thread_nr = 24, .shift = 3};
+static const struct gce_plat gce_plat_v5 = {.thread_nr = 24, .shift = 3,
+ .control_by_sw = true};
static const struct of_device_id cmdq_of_ids[] = {
{.compatible = "mediatek,mt8173-gce", .data = (void *)_plat_v2},
{.compatible = "mediatek,mt8183-gce", .data = (void *)_plat_v3},
{.compatible = "mediatek,mt6779-gce", .data = (void *)_plat_v4},
+ {.compatible = "mediatek,mt8192-gce", .data = (void *)_plat_v5},
{}
};
--
2.30.0.365.g02bc693789-goog
[PATCH v3 2/3] arm64: dts: mt8192: add gce node
From: Yongqiang Niu
add gce node for mt8192
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 9757138a8bbd8..1afa6ad06b2b8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -5,6 +5,7 @@
*/
/dts-v1/;
+#include
#include
#include
#include
@@ -291,6 +292,15 @@ systimer: timer@10017000 {
clock-names = "clk13m";
};
+ gce: mailbox@10228000 {
+ compatible = "mediatek,mt8192-gce";
+ reg = <0 0x10228000 0 0x4000>;
+ interrupts = ;
+ #mbox-cells = <3>;
+ clocks = < CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8192-uart",
"mediatek,mt6577-uart";
--
2.30.0.365.g02bc693789-goog
[PATCH v3 1/3] dt-binding: gce: add gce header file for mt8192
From: Yongqiang Niu Add documentation for the mt8192 gce. Add gce header file defined the gce hardware event, subsys number and constant for mt8192. Signed-off-by: Yongqiang Niu Reviewed-by: Rob Herring Signed-off-by: Hsin-Yi Wang --- .../devicetree/bindings/mailbox/mtk-gce.txt | 7 +- include/dt-bindings/gce/mt8192-gce.h | 419 ++ 2 files changed, 423 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8192-gce.h diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 7771ecaac5868..ac4245050d17d 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,8 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or - "mediatek,mt6779-gce". +- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce", + "mediatek,mt8192-gce" or "mediatek,mt6779-gce". - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -36,7 +36,8 @@ Optional properties for a client device: size: the total size of register address that GCE can access. Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', -'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as +'dt-binding/gce/mt8183-gce.h', 'dt-binding/gce/mt8192-gce.h' or +'dt-bindings/gce/mt6779-gce.h'. Such as sub-system ids, thread priority, event ids. Example: diff --git a/include/dt-bindings/gce/mt8192-gce.h b/include/dt-bindings/gce/mt8192-gce.h new file mode 100644 index 0..062754416bfda --- /dev/null +++ b/include/dt-bindings/gce/mt8192-gce.h @@ -0,0 +1,419 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2020 MediaTek Inc. + * Author: Yongqiang Niu + */ + +#ifndef _DT_BINDINGS_GCE_MT8192_H +#define _DT_BINDINGS_GCE_MT8192_H + +/* assign timeout 0 also means default */ +#define CMDQ_NO_TIMEOUT0x +#define CMDQ_TIMEOUT_DEFAULT 1000 + +/* GCE thread priority */ +#define CMDQ_THR_PRIO_LOWEST 0 +#define CMDQ_THR_PRIO_11 +#define CMDQ_THR_PRIO_22 +#define CMDQ_THR_PRIO_33 +#define CMDQ_THR_PRIO_44 +#define CMDQ_THR_PRIO_55 +#define CMDQ_THR_PRIO_66 +#define CMDQ_THR_PRIO_HIGHEST 7 + +/* CPR count in 32bit register */ +#define GCE_CPR_COUNT 1312 + +/* GCE subsys table */ +#define SUBSYS_13000 +#define SUBSYS_14001 +#define SUBSYS_14012 +#define SUBSYS_14023 +#define SUBSYS_15024 +#define SUBSYS_18805 +#define SUBSYS_18816 +#define SUBSYS_18827 +#define SUBSYS_18838 +#define SUBSYS_18849 +#define SUBSYS_100010 +#define SUBSYS_100111 +#define SUBSYS_100212 +#define SUBSYS_100313 +#define SUBSYS_100414 +#define SUBSYS_100515 +#define SUBSYS_102016 +#define SUBSYS_102817 +#define SUBSYS_170018 +#define SUBSYS_170119 +#define SUBSYS_170220 +#define SUBSYS_170321 +#define SUBSYS_180022 +#define SUBSYS_180123 +#define SUBSYS_180224 +#define SUBSYS_180425 +#define SUBSYS_180526 +#define SUBSYS_180827 +#define SUBSYS_180a28 +#define SUBSYS_180b29 +#define SUBSYS_NO_SUPPORT 99 + +/* GCE General Purpose Register (GPR) support + * Leave note for scenario usage here + */ +/* GCE: write mask */ +#define GCE_GPR_R000x00 +#define GCE_GPR_R010x01 +/* MDP: P1: JPEG dest */ +#define GCE_GPR_R020x02 +#define GCE_GPR_R030x03 +/* MDP: PQ color */ +#define GCE_GPR_R040x04 +/* MDP: 2D sharpness */ +#define GCE_GPR_R050x05 +/* DISP: poll esd */ +#define GCE_GPR_R060x06 +#define GCE_GPR_R070x07 +/* MDP: P4: 2D sharpness dst */ +#define GCE_GPR_R080x08 +#define GCE_GPR_R090x09 +/* VCU: poll with timeout for GPR timer */ +#define GCE_GPR_R100x0A +#define GCE_GPR_R110x0B +/* CMDQ: debug */ +#define GCE_GPR_R120x0C +#define GCE_GPR_R130x0D +/* CMDQ: P7: debug */ +#define GCE_GPR_R140x0E +#define GCE_GPR_R150x0F + +#define
[PATCH v3 0/3] support gce on mt8192 platform
Change since v2: - add controy_by_sw for mt8192 Change since v1: - move out shift jump patch - remove useless patch Yongqiang Niu (3): dt-binding: gce: add gce header file for mt8192 arm64: dts: mt8192: add gce node mailbox: cmdq: add mt8192 support .../devicetree/bindings/mailbox/mtk-gce.txt | 7 +- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 + drivers/mailbox/mtk-cmdq-mailbox.c| 10 + include/dt-bindings/gce/mt8192-gce.h | 419 ++ 4 files changed, 443 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8192-gce.h -- 2.30.0.365.g02bc693789-goog
Re: [PATCH 2/2] block: avoid to drop & re-add partitions if partitions aren't changed
On Fri, Feb 05, 2021 at 10:17:08AM +0800, Ming Lei wrote: > block ioctl(BLKRRPART) always drops current partitions and adds > partitions again, even though there isn't any change in partitions table. > > ioctl(BLKRRPART) may be called by systemd-udevd and some disk utilities > frequently. Err, why? We should probably fix udev to not do stupid things first.
Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree
On 05/02/2021 08.08, Arnd Bergmann wrote: On Thu, Feb 4, 2021 at 10:44 PM Hector Martin 'marcan' wrote: On 05/02/2021 06.29, Arnd Bergmann wrote: On Thu, Feb 4, 2021 at 9:39 PM Hector Martin wrote: We tend to split the dts file into one file per SoC and one for the specific board. I guess in this case the split can be slightly different, but it does feel better to be prepared for sharing a lot of the contents between the different products. In most cases, you'd want the 'aliases' and 'chosen' nodes to be in the board specific file. I thought about that, but wasn't sure if splitting it up at this early stage made much sense since I'm not sure what the split should be, given all supported hardware is the same for all 3 released devices. I'm happy to throw the aliases/chosen nodes into board specific files if you think that's a good starting point. Perhaps /memory too? Those properties are filled in/patched by the bootloader anyway... Yes, I think that would help make it more consistent with other platforms even if we don't care too much here. Ack, I'll split it up for v2. We don't really have overlays in the kernel sources (yet), though it is something that keeps coming up. For the moment, I'd just assume you can have one .dts file for each thing you want to support and keep the shared bits in .dtsi files. No problem. We'll experiment with overlays in m1n1 and see how that goes. One thing I wanted to ask: is there some kind of "experimental" policy for DT bindings? At early platform bring-up stages it seems like it could be valuable to allow for breaking DT changes while we flesh out the details (this is especially true of a reverse engineered platform like this, where we don't have knowledge of all the hardware details a priori). The dozen or so users we might have at this stage obviously won't complain too much :) -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub
Re: [PATCH] dt-bindings: pinctrl: Group tuples in pin control properties
On Thu, Feb 04, 2021 at 01:57:18PM +0100, Geert Uytterhoeven wrote: > To improve human readability and enable automatic validation, the tuples > in "pinctrl-*" properties should be grouped using angle brackets. > > Signed-off-by: Geert Uytterhoeven > --- > .../devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt| 2 +- > .../devicetree/bindings/pinctrl/brcm,nsp-pinmux.txt| 2 +- > .../devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt | 2 +- > .../devicetree/bindings/pinctrl/pinctrl-bindings.txt | 4 ++-- > .../devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt | 2 +- > .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt | 2 +- > .../devicetree/bindings/pinctrl/pinctrl-single.txt | 10 +- > .../devicetree/bindings/pinctrl/samsung-pinctrl.txt| 2 +- > 8 files changed, 13 insertions(+), 13 deletions(-) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH V4 2/2] power: supply: bq27xxx: Add support for BQ78Z100
Add support for TI BQ78Z100, I2C interface gas gauge.
It provides a fully integrated safety protection
and authentication for 1 to 2-series cell Li-Ion and
Li-Polymer battery packs.
The patch was tested with BQ78Z100 equipment.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: LI Qingwu
---
drivers/power/supply/bq27xxx_battery.c | 46 +-
drivers/power/supply/bq27xxx_battery_i2c.c | 2 +
include/linux/power/bq27xxx_battery.h | 1 +
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 315e0909e6a4..c8579ec7a4f8 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -39,6 +39,7 @@
* https://www.ti.com/product/bq27z561
* https://www.ti.com/product/bq28z610
* https://www.ti.com/product/bq34z100-g1
+ * https://www.ti.com/product/bq78z100
*/
#include
@@ -497,7 +498,27 @@ static u8
[BQ27XXX_REG_DCAP] = 0x3c,
[BQ27XXX_REG_AP] = 0x22,
BQ27XXX_DM_REG_ROWS,
- };
+ },
+ bq78z100_regs[BQ27XXX_REG_MAX] = {
+ [BQ27XXX_REG_CTRL] = 0x00,
+ [BQ27XXX_REG_TEMP] = 0x06,
+ [BQ27XXX_REG_INT_TEMP] = 0x28,
+ [BQ27XXX_REG_VOLT] = 0x08,
+ [BQ27XXX_REG_AI] = 0x14,
+ [BQ27XXX_REG_FLAGS] = 0x0a,
+ [BQ27XXX_REG_TTE] = 0x16,
+ [BQ27XXX_REG_TTF] = 0x18,
+ [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
+ [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
+ [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
+ [BQ27XXX_REG_FCC] = 0x12,
+ [BQ27XXX_REG_CYCT] = 0x2a,
+ [BQ27XXX_REG_AE] = 0x22,
+ [BQ27XXX_REG_SOC] = 0x2c,
+ [BQ27XXX_REG_DCAP] = 0x3c,
+ [BQ27XXX_REG_AP] = 0x22,
+ BQ27XXX_DM_REG_ROWS,
+};
static enum power_supply_property bq27000_props[] = {
POWER_SUPPLY_PROP_STATUS,
@@ -792,6 +813,27 @@ static enum power_supply_property bq34z100_props[] = {
POWER_SUPPLY_PROP_MANUFACTURER,
};
+static enum power_supply_property bq78z100_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+ POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
+ POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+ POWER_SUPPLY_PROP_CYCLE_COUNT,
+ POWER_SUPPLY_PROP_ENERGY_NOW,
+ POWER_SUPPLY_PROP_POWER_AVG,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_MANUFACTURER,
+};
+
struct bq27xxx_dm_reg {
u8 subclass_id;
u8 offset;
@@ -890,6 +932,7 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
#define bq27z561_dm_regs 0
#define bq28z610_dm_regs 0
#define bq34z100_dm_regs 0
+#define bq78z100_dm_regs 0
#define BQ27XXX_O_ZERO BIT(0)
#define BQ27XXX_O_OTDC BIT(1) /* has OTC/OTD overtemperature flags */
@@ -948,6 +991,7 @@ static struct {
[BQ28Z610] = BQ27XXX_DATA(bq28z610, 0 , BQ27Z561_O_BITS),
[BQ34Z100] = BQ27XXX_DATA(bq34z100, 0 , BQ27XXX_O_OTDC |
BQ27XXX_O_SOC_SI | \
BQ27XXX_O_HAS_CI |
BQ27XXX_O_MUL_CHEM),
+ [BQ78Z100] = BQ27XXX_DATA(bq78z100, 0x, BQ27Z561_O_BITS),
};
static DEFINE_MUTEX(bq27xxx_list_lock);
diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c
b/drivers/power/supply/bq27xxx_battery_i2c.c
index eb4f4284982f..46f078350fd3 100644
--- a/drivers/power/supply/bq27xxx_battery_i2c.c
+++ b/drivers/power/supply/bq27xxx_battery_i2c.c
@@ -248,6 +248,7 @@ static const struct i2c_device_id bq27xxx_i2c_id_table[] = {
{ "bq27z561", BQ27Z561 },
{ "bq28z610", BQ28Z610 },
{ "bq34z100", BQ34Z100 },
+ { "bq78z100", BQ78Z100 },
{},
};
MODULE_DEVICE_TABLE(i2c, bq27xxx_i2c_id_table);
@@ -284,6 +285,7 @@ static const struct of_device_id
bq27xxx_battery_i2c_of_match_table[] = {
{ .compatible = "ti,bq27z561" },
{ .compatible = "ti,bq28z610" },
{ .compatible = "ti,bq34z100" },
+ { .compatible = "ti,bq78z100" },
{},
};
MODULE_DEVICE_TABLE(of, bq27xxx_battery_i2c_of_match_table);
diff --git a/include/linux/power/bq27xxx_battery.h
b/include/linux/power/bq27xxx_battery.h
index 111a40d0d3d5..ac17618043b1 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -33,6 +33,7 @@ enum bq27xxx_chip {
BQ27Z561,
BQ28Z610,
BQ34Z100,
+ BQ78Z100,
};
struct bq27xxx_device_info;
--
2.17.1
[PATCH V4 0/2] power: bq27xxx: add bq78z100
Changes in V4: Correct the wrong part number in the subject, bq78z100 instead of bq78z10. LI Qingwu (2): dt-bindings: power: bq27xxx: add bq78z100 power: supply: bq27xxx: Add support for BQ78Z100 .../bindings/power/supply/bq27xxx.yaml| 1 + drivers/power/supply/bq27xxx_battery.c| 46 ++- drivers/power/supply/bq27xxx_battery_i2c.c| 2 + include/linux/power/bq27xxx_battery.h | 1 + 4 files changed, 49 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH V4 1/2] dt-bindings: power: bq27xxx: add bq78z100
Add bindings for TI BQ78Z100. An I2C interface gas gauge. It provides a fully integrated safety protection and authentication for 1 to 2-series cell Li-Ion and Li-Polymer battery packs. Acked-by: Rob Herring Signed-off-by: LI Qingwu --- Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml index 45beefccf31a..712e974b28b6 100644 --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml @@ -52,6 +52,7 @@ properties: - ti,bq27z561 - ti,bq28z610 - ti,bq34z100 + - ti,bq78z100 reg: maxItems: 1 -- 2.17.1
Re: [PATCH v3 01/11] docs: ioctl-number.rst: reserve IIO subsystem ioctl() space
On Thu, Feb 4, 2021 at 7:13 PM Jonathan Cameron wrote: > > On Mon, 1 Feb 2021 16:50:55 +0200 > Alexandru Ardelean wrote: > > > Currently, only the 'i' 0x90 ioctl() actually exists and is defined in > > 'uapi/linux/iio/events.h'. > > > > It's the IIO_GET_EVENT_FD_IOCTL, which is used to retrieve and FD for > > reading events from an IIO device. > > We will want to add more ioct() numbers, so with this change the 'i' > > 0x90-0x9F space is reserved for IIO ioctl() calls. > > > > Signed-off-by: Alexandru Ardelean > Hi Alex, > > Thanks for tidying this up. My bad from a long time ago to not register > this at the time. > > > --- > > Documentation/userspace-api/ioctl/ioctl-number.rst | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst > > b/Documentation/userspace-api/ioctl/ioctl-number.rst > > index a4c75a28c839..9ebde26b7e32 100644 > > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > > @@ -245,6 +245,7 @@ Code Seq#Include File > > Comments > > 'i' 00-3F linux/i2o-dev.h > > conflict! > > 'i' 0B-1F linux/ipmi.h > > conflict! > > 'i' 80-8F linux/i8k.h > > +'i' 90-9F `uapi/linux/iio/*.h`IIO > > I think the uapi/ bit is effectively implicit. I checked a few of them and the > definitions are in uapi/linux/ ack > > > 'j' 00-3F linux/joystick.h > > 'k' 00-0F linux/spi/spidev.h > > conflict! > > 'k' 00-05 video/kyro.h > > conflict! >
[PATCH 2/7] ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg
This is a dummy cpu dai driver for rpmsg audio use case,
which is mainly used for getting the user's configuration
from devicetree and configure the clocks which is used by
Cortex-M core.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/Kconfig | 7 ++
sound/soc/fsl/Makefile| 2 +
sound/soc/fsl/fsl_rpmsg.c | 258 ++
sound/soc/fsl/fsl_rpmsg.h | 38 ++
4 files changed, 305 insertions(+)
create mode 100644 sound/soc/fsl/fsl_rpmsg.c
create mode 100644 sound/soc/fsl/fsl_rpmsg.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index d7f30036d434..a688c3c2efbc 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -115,6 +115,13 @@ config SND_SOC_FSL_AUD2HTX
config SND_SOC_FSL_UTILS
tristate
+config SND_SOC_FSL_RPMSG
+ tristate "Audio Base on RPMSG support"
+ help
+ Say Y if you want to add rpmsg audio support for the Freescale CPUs.
+ This option is only useful for out-of-tree drivers since
+ in-tree drivers select it automatically.
+
config SND_SOC_IMX_PCM_DMA
tristate
select SND_SOC_GENERIC_DMAENGINE_PCM
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 8c5fa8a859c0..b63802f345cc 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -27,6 +27,7 @@ snd-soc-fsl-mqs-objs := fsl_mqs.o
snd-soc-fsl-easrc-objs := fsl_easrc.o
snd-soc-fsl-xcvr-objs := fsl_xcvr.o
snd-soc-fsl-aud2htx-objs := fsl_aud2htx.o
+snd-soc-fsl-rpmsg-objs := fsl_rpmsg.o
obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
@@ -42,6 +43,7 @@ obj-$(CONFIG_SND_SOC_FSL_EASRC) += snd-soc-fsl-easrc.o
obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
obj-$(CONFIG_SND_SOC_FSL_XCVR) += snd-soc-fsl-xcvr.o
obj-$(CONFIG_SND_SOC_FSL_AUD2HTX) += snd-soc-fsl-aud2htx.o
+obj-$(CONFIG_SND_SOC_FSL_RPMSG) += snd-soc-fsl-rpmsg.o
# MPC5200 Platform Support
obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c
new file mode 100644
index ..8a5e770ea34b
--- /dev/null
+++ b/sound/soc/fsl/fsl_rpmsg.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018-2021 NXP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fsl_rpmsg.h"
+#include "imx-pcm.h"
+
+#define FSL_RPMSG_RATES(SNDRV_PCM_RATE_8000 | \
+ SNDRV_PCM_RATE_16000 | \
+ SNDRV_PCM_RATE_48000)
+#define FSL_RPMSG_FORMATS SNDRV_PCM_FMTBIT_S16_LE
+
+static const unsigned int fsl_rpmsg_rates[] = {
+ 8000, 11025, 16000, 22050, 44100,
+ 32000, 48000, 96000, 88200, 176400, 192000,
+ 352800, 384000, 705600, 768000, 1411200, 2822400,
+};
+
+static const struct snd_pcm_hw_constraint_list fsl_rpmsg_rate_constraints = {
+ .count = ARRAY_SIZE(fsl_rpmsg_rates),
+ .list = fsl_rpmsg_rates,
+};
+
+static int fsl_rpmsg_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct fsl_rpmsg *rpmsg = snd_soc_dai_get_drvdata(dai);
+ struct clk *p = rpmsg->mclk, *pll = 0, *npll = 0;
+ unsigned int rate = params_rate(params);
+ int ret;
+
+ /* Get current pll parent */
+ while (p && rpmsg->pll8k && rpmsg->pll11k) {
+ struct clk *pp = clk_get_parent(p);
+
+ if (clk_is_match(pp, rpmsg->pll8k) ||
+ clk_is_match(pp, rpmsg->pll11k)) {
+ pll = pp;
+ break;
+ }
+ p = pp;
+ }
+
+ /* Switch to another pll parent if needed. */
+ if (pll) {
+ npll = (do_div(rate, 8000) ? rpmsg->pll11k : rpmsg->pll8k);
+ if (!clk_is_match(pll, npll)) {
+ ret = clk_set_parent(p, npll);
+ if (ret < 0)
+ dev_warn(dai->dev, "failed to set parent %s:
%d\n",
+__clk_get_name(npll), ret);
+ }
+ }
+
+ ret = clk_prepare_enable(rpmsg->mclk);
+ if (ret)
+ dev_err(dai->dev, "failed to enable mclk: %d\n", ret);
+
+ return ret;
+}
+
+static int fsl_rpmsg_hw_free(struct snd_pcm_substream *substream,
+struct snd_soc_dai *dai)
+{
+ struct fsl_rpmsg *rpmsg = snd_soc_dai_get_drvdata(dai);
+
+ clk_disable_unprepare(rpmsg->mclk);
+
+ return 0;
+}
+
+static int fsl_rpmsg_startup(struct snd_pcm_substream *substream,
+struct snd_soc_dai *cpu_dai)
+{
+ int ret;
+
+ ret = snd_pcm_hw_constraint_list(substream->runtime, 0,
+SNDRV_PCM_HW_PARAM_RATE,
+
[PATCH 4/7] ASoC: imx-audio-rpmsg: Add rpmsg_driver for audio channel
This driver is used to accept the message from rpmsg audio
channel, and if this driver is probed, it will help to register
the platform driver, the platform driver will use this
audio channel to send and receive message to and from Cortex-M
core.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/Kconfig | 4 +
sound/soc/fsl/Makefile | 1 +
sound/soc/fsl/imx-audio-rpmsg.c | 142
3 files changed, 147 insertions(+)
create mode 100644 sound/soc/fsl/imx-audio-rpmsg.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index a688c3c2efbc..84d9f0f1f75b 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -126,6 +126,10 @@ config SND_SOC_IMX_PCM_DMA
tristate
select SND_SOC_GENERIC_DMAENGINE_PCM
+config SND_SOC_IMX_AUDIO_RPMSG
+ tristate
+ depends on RPMSG
+
config SND_SOC_IMX_AUDMUX
tristate "Digital Audio Mux module support"
help
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index b63802f345cc..f08f3cd07ff5 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o
obj-$(CONFIG_SND_SOC_IMX_PCM_FIQ) += imx-pcm-fiq.o
obj-$(CONFIG_SND_SOC_IMX_PCM_DMA) += imx-pcm-dma.o
+obj-$(CONFIG_SND_SOC_IMX_AUDIO_RPMSG) += imx-audio-rpmsg.o
# i.MX Machine Support
snd-soc-eukrea-tlv320-objs := eukrea-tlv320.o
diff --git a/sound/soc/fsl/imx-audio-rpmsg.c b/sound/soc/fsl/imx-audio-rpmsg.c
new file mode 100644
index ..c88af99ec4d9
--- /dev/null
+++ b/sound/soc/fsl/imx-audio-rpmsg.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2017-2020 NXP
+
+#include
+#include
+#include "imx-pcm-rpmsg.h"
+
+/**
+ * struct imx_audio_rpmsg: private data
+ *
+ * @rpmsg_pdev: pointer of platform device
+ */
+struct imx_audio_rpmsg {
+ struct platform_device *rpmsg_pdev;
+};
+
+static int imx_audio_rpmsg_cb(struct rpmsg_device *rpdev, void *data, int len,
+ void *priv, u32 src)
+{
+ struct imx_audio_rpmsg *rpmsg = dev_get_drvdata(>dev);
+ struct rpmsg_info *info = platform_get_drvdata(rpmsg->rpmsg_pdev);
+ struct rpmsg_r_msg *r_msg = (struct rpmsg_r_msg *)data;
+ struct rpmsg_msg *msg;
+ unsigned long flags;
+
+ dev_dbg(>dev, "get from%d: cmd:%d. %d\n",
+ src, r_msg->header.cmd, r_msg->param.resp);
+
+ /* TYPE C is notification from M core */
+ if (r_msg->header.type == MSG_TYPE_C) {
+ if (r_msg->header.cmd == TX_PERIOD_DONE) {
+ spin_lock_irqsave(>lock[TX], flags);
+ msg = >msg[TX_PERIOD_DONE + MSG_TYPE_A_NUM];
+
+ /**
+* Low power mode: get the buffer pointer from
+* receive msg.
+*/
+ if (r_msg->header.major == 1 &&
+ r_msg->header.minor == 2)
+ msg->r_msg.param.buffer_tail =
+ r_msg->param.buffer_tail;
+ else
+ msg->r_msg.param.buffer_tail++;
+
+ msg->r_msg.param.buffer_tail %= info->num_period[TX];
+ spin_unlock_irqrestore(>lock[TX], flags);
+ info->callback[TX](info->callback_param[TX]);
+
+ } else if (r_msg->header.cmd == RX_PERIOD_DONE) {
+ spin_lock_irqsave(>lock[RX], flags);
+ msg = >msg[RX_PERIOD_DONE + MSG_TYPE_A_NUM];
+
+ if (r_msg->header.major == 1 &&
+ r_msg->header.minor == 2)
+ msg->r_msg.param.buffer_tail =
+ r_msg->param.buffer_tail;
+ else
+ msg->r_msg.param.buffer_tail++;
+
+ msg->r_msg.param.buffer_tail %= info->num_period[1];
+ spin_unlock_irqrestore(>lock[RX], flags);
+ info->callback[RX](info->callback_param[RX]);
+ }
+ }
+
+ /* TYPE B is response msg */
+ if (r_msg->header.type == MSG_TYPE_B) {
+ memcpy(>r_msg, r_msg, sizeof(struct rpmsg_r_msg));
+ complete(>cmd_complete);
+ }
+
+ return 0;
+}
+
+static int imx_audio_rpmsg_probe(struct rpmsg_device *rpdev)
+{
+ struct imx_audio_rpmsg *data;
+ int ret = 0;
+
+ dev_info(>dev, "new channel: 0x%x -> 0x%x!\n",
+rpdev->src, rpdev->dst);
+
+ data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ dev_set_drvdata(>dev, data);
+
+ /* Register platform driver for rpmsg routine */
+ data->rpmsg_pdev = platform_device_register_data(>dev,
+
[PATCH 5/7] ASoC: imx-pcm-rpmsg: Add platform driver for audio base on rpmsg
platform driver base on rpmsg is the interface for sending and
receiving rpmsg to and from M core. It will tell the Cortex-M core
sound format/rate/channel, where is the data buffer, where is
the period size, when to start, when to stop and when suspend
or resume happen, each this behavior there is defined rpmsg
command.
Especially we designed the low power audio case, that is to
allocate a large buffer and fill the data, then Cortex-A core can go
to sleep mode, Cortex-M core continue to play the sound, when the
buffer is consumed, Cortex-M core will trigger the Cortex-A core to
wakeup.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/Kconfig | 5 +
sound/soc/fsl/Makefile| 1 +
sound/soc/fsl/imx-pcm-rpmsg.c | 898 ++
sound/soc/fsl/imx-pcm-rpmsg.h | 512 +++
4 files changed, 1416 insertions(+)
create mode 100644 sound/soc/fsl/imx-pcm-rpmsg.c
create mode 100644 sound/soc/fsl/imx-pcm-rpmsg.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 84d9f0f1f75b..749c44fc0759 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -130,6 +130,11 @@ config SND_SOC_IMX_AUDIO_RPMSG
tristate
depends on RPMSG
+config SND_SOC_IMX_PCM_RPMSG
+ tristate
+ depends on SND_SOC_IMX_AUDIO_RPMSG
+ select SND_SOC_GENERIC_DMAENGINE_PCM
+
config SND_SOC_IMX_AUDMUX
tristate "Digital Audio Mux module support"
help
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index f08f3cd07ff5..ce4f4324c3a2 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o
obj-$(CONFIG_SND_SOC_IMX_PCM_FIQ) += imx-pcm-fiq.o
obj-$(CONFIG_SND_SOC_IMX_PCM_DMA) += imx-pcm-dma.o
obj-$(CONFIG_SND_SOC_IMX_AUDIO_RPMSG) += imx-audio-rpmsg.o
+obj-$(CONFIG_SND_SOC_IMX_PCM_RPMSG) += imx-pcm-rpmsg.o
# i.MX Machine Support
snd-soc-eukrea-tlv320-objs := eukrea-tlv320.o
diff --git a/sound/soc/fsl/imx-pcm-rpmsg.c b/sound/soc/fsl/imx-pcm-rpmsg.c
new file mode 100644
index ..48df864bc092
--- /dev/null
+++ b/sound/soc/fsl/imx-pcm-rpmsg.c
@@ -0,0 +1,898 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2017-2021 NXP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-pcm.h"
+#include "fsl_rpmsg.h"
+#include "imx-pcm-rpmsg.h"
+
+static struct snd_pcm_hardware imx_rpmsg_pcm_hardware = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_BLOCK_TRANSFER |
+ SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_NO_PERIOD_WAKEUP |
+ SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_RESUME,
+ .buffer_bytes_max = IMX_DEFAULT_DMABUF_SIZE,
+ .period_bytes_min = 512,
+ .period_bytes_max = 65536,
+ .periods_min = 2,
+ .periods_max = 6000,
+ .fifo_size = 0,
+};
+
+static int imx_rpmsg_pcm_send_message(struct rpmsg_msg *msg,
+ struct rpmsg_info *info)
+{
+ struct rpmsg_device *rpdev = info->rpdev;
+ int ret = 0;
+
+ mutex_lock(>msg_lock);
+ if (!rpdev) {
+ dev_err(info->dev, "rpmsg channel not ready\n");
+ mutex_unlock(>msg_lock);
+ return -EINVAL;
+ }
+
+ dev_dbg(>dev, "send cmd %d\n", msg->s_msg.header.cmd);
+
+ if (!(msg->s_msg.header.type == MSG_TYPE_C))
+ reinit_completion(>cmd_complete);
+
+ ret = rpmsg_send(rpdev->ept, (void *)>s_msg,
+sizeof(struct rpmsg_s_msg));
+ if (ret) {
+ dev_err(>dev, "rpmsg_send failed: %d\n", ret);
+ mutex_unlock(>msg_lock);
+ return ret;
+ }
+
+ /* No receive msg for TYPE_C command */
+ if (msg->s_msg.header.type == MSG_TYPE_C) {
+ mutex_unlock(>msg_lock);
+ return 0;
+ }
+
+ /* wait response from rpmsg */
+ ret = wait_for_completion_timeout(>cmd_complete,
+ msecs_to_jiffies(RPMSG_TIMEOUT));
+ if (!ret) {
+ dev_err(>dev, "rpmsg_send cmd %d timeout!\n",
+ msg->s_msg.header.cmd);
+ mutex_unlock(>msg_lock);
+ return -ETIMEDOUT;
+ }
+
+ memcpy(>r_msg, >r_msg, sizeof(struct rpmsg_r_msg));
+ memcpy(>msg[msg->r_msg.header.cmd].r_msg,
+ >r_msg, sizeof(struct rpmsg_r_msg));
+
+ /*
+* Reset the buffer pointer to be zero, actully we have
+* set the buffer pointer to be zero in imx_rpmsg_terminate_all
+* But if there is timer task queued in queue, after it is
+* executed the buffer pointer will be changed, so need to
+* reset it again with TERMINATE command.
+*/
+ switch (msg->s_msg.header.cmd) {
+ case TX_TERMINATE:
+
[PATCH 7/7] ASoC: dt-bindings: imx-rpmsg: Add binding doc for rpmsg machine driver
Imx-rpmsg is a new added machine driver for supporting audio on Cortex-M
core. The Cortex-M core will control the audio interface, DMA and audio
codec, setup the pipeline, the audio driver on Cortex-A core side is just
to communitcate with M core, it is a virtual sound card and don't touch
the hardware.
Signed-off-by: Shengjiu Wang
---
.../bindings/sound/imx-audio-rpmsg.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml
b/Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml
new file mode 100644
index ..b941aeb80678
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/imx-audio-rpmsg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX audio complex with rpmsg
+
+maintainers:
+ - Shengjiu Wang
+
+properties:
+ compatible:
+enum:
+ - fsl,imx-audio-rpmsg
+
+ model:
+$ref: /schemas/types.yaml#/definitions/string
+description: User specified audio sound card name
+
+ audio-cpu:
+description: The phandle of an CPU DAI controller
+
+ rpmsg-out:
+description: |
+ This is a boolean property. If present, the transmitting function
+ will be enabled,
+
+ rpmsg-in:
+description: |
+ This is a boolean property. If present, the receiving function
+ will be enabled.
+
+required:
+ - compatible
+ - model
+ - audio-cpu
+
+additionalProperties: false
+
+examples:
+ - |
+sound-rpmsg {
+compatible = "fsl,imx-audio-rpmsg";
+model = "ak4497-audio";
+audio-cpu = <_audio>;
+rpmsg-out;
+};
--
2.27.0
[PATCH 3/7] ASoC: dt-bindings: fsl_rpmsg: Add binding doc for rpmsg cpu dai driver
fsl_rpmsg cpu dai driver is dummy driver, which is mainly used for
getting the user's configuration from device tree and configure the
clocks which is used by Cortex-M core. So in this document define the
needed property.
Signed-off-by: Shengjiu Wang
---
.../devicetree/bindings/sound/fsl,rpmsg.yaml | 80 +++
1 file changed, 80 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
new file mode 100644
index ..1c2679fac31e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,rpmsg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Audio RPMSG Dummy Controller
+
+maintainers:
+ - Shengjiu Wang
+
+properties:
+ compatible:
+enum:
+ - fsl,imx7ulp-rpmsg
+ - fsl,imx8mn-rpmsg
+ - fsl,imx8mm-rpmsg
+ - fsl,imx8mp-rpmsg
+
+ clocks:
+items:
+ - description: Peripheral clock for register access
+ - description: Master clock
+ - description: DMA clock for DMA register access
+ - description: Parent clock for multiple of 8kHz sample rates
+ - description: Parent clock for multiple of 11kHz sample rates
+minItems: 5
+
+ clock-names:
+items:
+ - const: ipg
+ - const: mclk
+ - const: dma
+ - const: pll8k
+ - const: pll11k
+minItems: 5
+
+ power-domains:
+maxItems: 1
+
+ fsl,audioindex:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: instance index for rpmsg image
+
+ fsl,version:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: rpmsg image version index
+
+ fsl,buffer-size:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: pre allocate dma buffer size
+
+ fsl,enable-lpa:
+$ref: /schemas/types.yaml#/definitions/flag
+description: enable low power audio path.
+
+ fsl,codec-type:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Sometimes the codec is registered by
+ driver not the device tree, this items
+ can be used to distinguish codecs
+
+required:
+ - compatible
+ - fsl,audioindex
+ - fsl,version
+ - fsl,buffer-size
+
+additionalProperties: false
+
+examples:
+ - |
+rpmsg_audio: rpmsg_audio {
+compatible = "fsl,imx8mn-rpmsg";
+fsl,audioindex = <0> ;
+fsl,version = <2>;
+fsl,buffer-size = <0x600>;
+fsl,enable-lpa;
+status = "okay";
+};
--
2.27.0
[PATCH 6/7] ASoC: imx-rpmsg: Add machine driver for audio base on rpmsg
The platform device is not registered by device tree or
cpu dai driver, it is registered by the rpmsg channel,
So add a dedicated machine driver to handle this case.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/Kconfig | 12
sound/soc/fsl/Makefile| 2 +
sound/soc/fsl/imx-rpmsg.c | 148 ++
3 files changed, 162 insertions(+)
create mode 100644 sound/soc/fsl/imx-rpmsg.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 749c44fc0759..3557866d3fa2 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -334,6 +334,18 @@ config SND_SOC_IMX_HDMI
Say Y if you want to add support for SoC audio on an i.MX board with
IMX HDMI.
+config SND_SOC_IMX_RPMSG
+ tristate "SoC Audio support for i.MX boards with rpmsg"
+ depends on RPMSG
+ select SND_SOC_IMX_PCM_RPMSG
+ select SND_SOC_IMX_AUDIO_RPMSG
+ select SND_SOC_FSL_RPMSG
+ help
+ SoC Audio support for i.MX boards with rpmsg.
+ There should be rpmsg devices defined in other core (M core)
+ Say Y if you want to add support for SoC audio on an i.MX board with
+ a rpmsg devices.
+
endif # SND_IMX_SOC
endmenu
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ce4f4324c3a2..f146ce464acd 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -70,6 +70,7 @@ snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
snd-soc-imx-spdif-objs := imx-spdif.o
snd-soc-imx-audmix-objs := imx-audmix.o
snd-soc-imx-hdmi-objs := imx-hdmi.o
+snd-soc-imx-rpmsg-objs := imx-rpmsg.o
obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
obj-$(CONFIG_SND_SOC_IMX_ES8328) += snd-soc-imx-es8328.o
@@ -77,3 +78,4 @@ obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_AUDMIX) += snd-soc-imx-audmix.o
obj-$(CONFIG_SND_SOC_IMX_HDMI) += snd-soc-imx-hdmi.o
+obj-$(CONFIG_SND_SOC_IMX_RPMSG) += snd-soc-imx-rpmsg.o
diff --git a/sound/soc/fsl/imx-rpmsg.c b/sound/soc/fsl/imx-rpmsg.c
new file mode 100644
index ..a87dcbce4f36
--- /dev/null
+++ b/sound/soc/fsl/imx-rpmsg.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2017-2020 NXP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "imx-pcm-rpmsg.h"
+
+struct imx_rpmsg {
+ struct snd_soc_dai_link dai;
+ struct snd_soc_card card;
+};
+
+static int imx_rpmsg_probe(struct platform_device *pdev)
+{
+ struct snd_soc_dai_link_component *dlc;
+ struct platform_device *cpu_pdev;
+ struct of_phandle_args args;
+ struct device_node *cpu_np;
+ struct imx_rpmsg *data;
+ int ret;
+
+ dlc = devm_kzalloc(>dev, 3 * sizeof(*dlc), GFP_KERNEL);
+ if (!dlc)
+ return -ENOMEM;
+
+ cpu_np = of_parse_phandle(pdev->dev.of_node, "audio-cpu", 0);
+ if (!cpu_np) {
+ dev_err(>dev, "cpu dai phandle missing or invalid\n");
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ cpu_pdev = of_find_device_by_node(cpu_np);
+ if (!cpu_pdev) {
+ dev_err(>dev, "failed to find rpmsg platform device\n");
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ ret = of_reserved_mem_device_init_by_idx(>dev, pdev->dev.of_node,
0);
+ if (ret)
+ dev_warn(>dev, "no reserved DMA memory\n");
+
+ data->dai.cpus = [0];
+ data->dai.num_cpus = 1;
+ data->dai.platforms = [1];
+ data->dai.num_platforms = 1;
+ data->dai.codecs = [2];
+ data->dai.num_codecs = 1;
+
+ data->dai.name = "rpmsg hifi";
+ data->dai.stream_name = "rpmsg hifi";
+ data->dai.dai_fmt = SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBS_CFS;
+
+ /* Optional codec node */
+ ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
+ "audio-codec", 0, 0, );
+ if (ret) {
+ data->dai.codecs->dai_name = "snd-soc-dummy-dai";
+ data->dai.codecs->name = "snd-soc-dummy";
+ } else {
+ data->dai.codecs->of_node = args.np;
+ ret = snd_soc_get_dai_name(, >dai.codecs->dai_name);
+ if (ret) {
+ dev_err(>dev, "Unable to get codec_dai_name\n");
+ goto fail;
+ }
+ }
+
+ data->dai.cpus->dai_name = dev_name(_pdev->dev);
+ data->dai.platforms->name = IMX_PCM_DRV_NAME;
+ data->dai.playback_only = true;
+ data->dai.capture_only = true;
+ data->card.num_links = 1;
[PATCH 0/7] Add audio driver base on rpmsg on i.MX platform
On Asymmetric multiprocessor, there is Cortex-A core and Cortex-M core, Linux is running on A core, RTOS is running on M core. The audio hardware device can be controlled by Cortex-M device, So audio playback/capture can be handled by M core. Rpmsg is the interface for sending and receiving msg to and from M core, that we can create a virtual sound on Cortex-A core side. A core will tell the Cortex-M core sound format/rate/channel, where is the data buffer, what is the period size, when to start, when to stop and when suspend or resume happen, each of this behavior there is defined rpmsg command. Especially we designed the low power audio case, that is to allocate a large buffer and fill the data, then Cortex-A core can go to sleep mode, Cortex-M core continue to play the sound, when the buffer is consumed, Cortex-M core will trigger the Cortex-A core to wakeup to fill data. Shengjiu Wang (7): ASoC: soc-component: Add snd_soc_pcm_component_ack ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg ASoC: dt-bindings: fsl_rpmsg: Add binding doc for rpmsg cpu dai driver ASoC: imx-audio-rpmsg: Add rpmsg_driver for audio channel ASoC: imx-pcm-rpmsg: Add platform driver for audio base on rpmsg ASoC: imx-rpmsg: Add machine driver for audio base on rpmsg ASoC: dt-bindings: imx-rpmsg: Add binding doc for rpmsg machine driver .../devicetree/bindings/sound/fsl,rpmsg.yaml | 80 ++ .../bindings/sound/imx-audio-rpmsg.yaml | 48 + include/sound/soc-component.h | 3 + sound/soc/fsl/Kconfig | 28 + sound/soc/fsl/Makefile| 6 + sound/soc/fsl/fsl_rpmsg.c | 258 + sound/soc/fsl/fsl_rpmsg.h | 38 + sound/soc/fsl/imx-audio-rpmsg.c | 142 +++ sound/soc/fsl/imx-pcm-rpmsg.c | 898 ++ sound/soc/fsl/imx-pcm-rpmsg.h | 512 ++ sound/soc/fsl/imx-rpmsg.c | 148 +++ sound/soc/soc-component.c | 14 + sound/soc/soc-pcm.c | 2 + 13 files changed, 2177 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-rpmsg.yaml create mode 100644 sound/soc/fsl/fsl_rpmsg.c create mode 100644 sound/soc/fsl/fsl_rpmsg.h create mode 100644 sound/soc/fsl/imx-audio-rpmsg.c create mode 100644 sound/soc/fsl/imx-pcm-rpmsg.c create mode 100644 sound/soc/fsl/imx-pcm-rpmsg.h create mode 100644 sound/soc/fsl/imx-rpmsg.c -- 2.27.0
[PATCH 1/7] ASoC: soc-component: Add snd_soc_pcm_component_ack
Add snd_soc_pcm_component_ack back, which can be used to get updated
buffer pointer in platform driver.
On Asymmetric multiprocessor, this pointer can be sent to Cortex-M
core for audio processing.
Signed-off-by: Shengjiu Wang
---
include/sound/soc-component.h | 3 +++
sound/soc/soc-component.c | 14 ++
sound/soc/soc-pcm.c | 2 ++
3 files changed, 19 insertions(+)
diff --git a/include/sound/soc-component.h b/include/sound/soc-component.h
index 5b47768222b7..2dc8c7e3d1a6 100644
--- a/include/sound/soc-component.h
+++ b/include/sound/soc-component.h
@@ -146,6 +146,8 @@ struct snd_soc_component_driver {
int (*mmap)(struct snd_soc_component *component,
struct snd_pcm_substream *substream,
struct vm_area_struct *vma);
+ int (*ack)(struct snd_soc_component *component,
+ struct snd_pcm_substream *substream);
const struct snd_compress_ops *compress_ops;
@@ -498,5 +500,6 @@ int snd_soc_pcm_component_pm_runtime_get(struct
snd_soc_pcm_runtime *rtd,
void *stream);
void snd_soc_pcm_component_pm_runtime_put(struct snd_soc_pcm_runtime *rtd,
void *stream, int rollback);
+int snd_soc_pcm_component_ack(struct snd_pcm_substream *substream);
#endif /* __SOC_COMPONENT_H */
diff --git a/sound/soc/soc-component.c b/sound/soc/soc-component.c
index 159bf88b9f8c..a9fbb2d26412 100644
--- a/sound/soc/soc-component.c
+++ b/sound/soc/soc-component.c
@@ -1212,3 +1212,17 @@ void snd_soc_pcm_component_pm_runtime_put(struct
snd_soc_pcm_runtime *rtd,
soc_component_mark_pop(component, stream, pm);
}
}
+
+int snd_soc_pcm_component_ack(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = asoc_substream_to_rtd(substream);
+ struct snd_soc_component *component;
+ int i;
+
+ /* FIXME: use 1st pointer */
+ for_each_rtd_components(rtd, i, component)
+ if (component->driver->ack)
+ return component->driver->ack(component, substream);
+
+ return 0;
+}
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index b79f064887d4..605acec48971 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2830,6 +2830,8 @@ int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num)
rtd->ops.page = snd_soc_pcm_component_page;
if (drv->mmap)
rtd->ops.mmap = snd_soc_pcm_component_mmap;
+ if (drv->ack)
+ rtd->ops.ack= snd_soc_pcm_component_ack;
}
if (playback)
--
2.27.0
Re: [PATCH v1 2/2] cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there
On Thu, 2021-02-04 at 18:34 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> If the maximum performance level taken for computing the
> arch_max_freq_ratio value used in the x86 scale-invariance code is
> higher than the one corresponding to the cpuinfo.max_freq value
> coming from the acpi_cpufreq driver, the scale-invariant utilization
> falls below 100% even if the CPU runs at cpuinfo.max_freq or slightly
> faster, which causes the schedutil governor to select a frequency
> below cpuinfo.max_freq. That frequency corresponds to a frequency
> table entry below the maximum performance level necessary to get to
> the "boost" range of CPU frequencies which prevents "boost"
> frequencies from being used in some workloads.
>
> While this issue is related to scale-invariance, it may be amplified
> by commit db865272d9c4 ("cpufreq: Avoid configuring old governors as
> default with intel_pstate") from the 5.10 development cycle which
> made it extremely easy to default to schedutil even if the preferred
> driver is acpi_cpufreq as long as intel_pstate is built too, because
> the mere presence of the latter effectively removes the ondemand
> governor from the defaults. Distro kernels are likely to include
> both intel_pstate and acpi_cpufreq on x86, so their users who cannot
> use intel_pstate or choose to use acpi_cpufreq may easily be
> affectecd by this issue.
>
> If CPPC is available, it can be used to address this issue by
> extending the frequency tables created by acpi_cpufreq to cover the
> entire available frequency range (including "boost" frequencies) for
> each CPU, but if CPPC is not there, acpi_cpufreq has no idea what
> the maximum "boost" frequency is and the frequency tables created by
> it cannot be extended in a meaningful way, so in that case make it
> ask the arch scale-invariance code to to use the "nominal" performance
> level for CPU utilization scaling in order to avoid the issue at hand.
>
> Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default
> with intel_pstate")
> Signed-off-by: Rafael J. Wysocki
> ---
> arch/x86/kernel/smpboot.c |1 +
> drivers/cpufreq/acpi-cpufreq.c |8
> 2 files changed, 9 insertions(+)
>
> Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
> +++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
> @@ -806,6 +806,14 @@ static int acpi_cpufreq_cpu_init(struct
> state_count++;
> valid_states++;
> data->first_perf_state = valid_states;
> + } else {
> + /*
> + * If the maximum "boost" frequency is unknown, ask the arch
> + * scale-invariance code to use the "nominal" performance for
> + * CPU utilization scaling so as to prevent the schedutil
> + * governor from selecting inadequate CPU frequencies.
> + */
> + arch_set_max_freq_ratio(true);
> }
>
> freq_table = kcalloc(state_count, sizeof(*freq_table), GFP_KERNEL);
> Index: linux-pm/arch/x86/kernel/smpboot.c
> ===
> --- linux-pm.orig/arch/x86/kernel/smpboot.c
> +++ linux-pm/arch/x86/kernel/smpboot.c
> @@ -1833,6 +1833,7 @@ void arch_set_max_freq_ratio(bool turbo_
> arch_max_freq_ratio = turbo_disabled ? SCHED_CAPACITY_SCALE :
> arch_turbo_freq_ratio;
> }
> +EXPORT_SYMBOL_GPL(arch_set_max_freq_ratio);
>
> static bool turbo_disabled(void)
> {
Reviewed-by: Giovanni Gherdovich
Thanks,
Giovanni
Re: [PATCH] RISC-V: Add a non-void return for sbi v02 functions
On Wed, 03 Feb 2021 21:26:43 PST (-0800), Atish Patra wrote:
SBI v0.2 functions can return an error code from SBI implementation.
We are already processing the SBI error code and coverts it to the Linux
error code.
Propagate to the error code to the caller as well. As of now, kvm is the
only user of these error codes.
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/sbi.h | 10 +-
arch/riscv/kernel/sbi.c | 32
2 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 1b26ec8e6a15..3e7141a7d11f 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -116,13 +116,13 @@ int sbi_console_getchar(void);
void sbi_set_timer(uint64_t stime_value);
void sbi_shutdown(void);
void sbi_clear_ipi(void);
-void sbi_send_ipi(const unsigned long *hart_mask);
-void sbi_remote_fence_i(const unsigned long *hart_mask);
-void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+int sbi_send_ipi(const unsigned long *hart_mask);
+int sbi_remote_fence_i(const unsigned long *hart_mask);
+int sbi_remote_sfence_vma(const unsigned long *hart_mask,
unsigned long start,
unsigned long size);
-void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid);
@@ -163,7 +163,7 @@ static inline unsigned long sbi_minor_version(void)
int sbi_err_map_linux_errno(int err);
#else /* CONFIG_RISCV_SBI */
-static inline void sbi_remote_fence_i(const unsigned long *hart_mask) {}
+static inline int sbi_remote_fence_i(const unsigned long *hart_mask) {}
static inline void sbi_init(void) {}
#endif /* CONFIG_RISCV_SBI */
#endif /* _ASM_RISCV_SBI_H */
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index 8d60b2ebcad3..f904af48635d 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -352,7 +352,7 @@ static int __sbi_rfence_v02(int fid, const unsigned long
*hart_mask,
* sbi_set_timer() - Program the timer for next timer event.
* @stime_value: The value after which next timer event should fire.
*
- * Return: None
+ * Return: None.
*/
void sbi_set_timer(uint64_t stime_value)
{
@@ -363,11 +363,11 @@ void sbi_set_timer(uint64_t stime_value)
* sbi_send_ipi() - Send an IPI to any hart.
* @hart_mask: A cpu mask containing all the target harts.
*
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
*/
-void sbi_send_ipi(const unsigned long *hart_mask)
+int sbi_send_ipi(const unsigned long *hart_mask)
{
- __sbi_send_ipi(hart_mask);
+ return __sbi_send_ipi(hart_mask);
}
EXPORT_SYMBOL(sbi_send_ipi);
@@ -375,12 +375,12 @@ EXPORT_SYMBOL(sbi_send_ipi);
* sbi_remote_fence_i() - Execute FENCE.I instruction on given remote harts.
* @hart_mask: A cpu mask containing all the target harts.
*
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
*/
-void sbi_remote_fence_i(const unsigned long *hart_mask)
+int sbi_remote_fence_i(const unsigned long *hart_mask)
{
- __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
-hart_mask, 0, 0, 0, 0);
+ return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
+ hart_mask, 0, 0, 0, 0);
}
EXPORT_SYMBOL(sbi_remote_fence_i);
@@ -391,14 +391,14 @@ EXPORT_SYMBOL(sbi_remote_fence_i);
* @start: Start of the virtual address
* @size: Total size of the virtual address range.
*
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
*/
-void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma(const unsigned long *hart_mask,
unsigned long start,
unsigned long size)
{
- __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
-hart_mask, start, size, 0, 0);
+ return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
+ hart_mask, start, size, 0, 0);
}
EXPORT_SYMBOL(sbi_remote_sfence_vma);
@@ -411,15 +411,15 @@ EXPORT_SYMBOL(sbi_remote_sfence_vma);
* @size: Total size of the virtual address range.
* @asid: The value of address space identifier (ASID).
*
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
*/
-void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid)
{
- __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
-hart_mask, start, size, asid, 0);
+ return
Re: [PATCH] selftests/vDSO: fix ABI selftest on riscv
On Thu, 04 Feb 2021 06:50:42 PST (-0800), tklau...@distanz.ch wrote: Only older versions of the RISC-V GCC toolchain define __riscv__. Check for __riscv as well, which is used by newer GCC toolchains. Also set VDSO_32BIT based on __riscv_xlen. Before (on riscv64): $ ./vdso_test_abi [vDSO kselftest] VDSO_VERSION: LINUX_4 Could not find __vdso_gettimeofday Could not find __vdso_clock_gettime Could not find __vdso_clock_getres clock_id: CLOCK_REALTIME [PASS] Could not find __vdso_clock_gettime Could not find __vdso_clock_getres clock_id: CLOCK_BOOTTIME [PASS] Could not find __vdso_clock_gettime Could not find __vdso_clock_getres clock_id: CLOCK_TAI [PASS] Could not find __vdso_clock_gettime Could not find __vdso_clock_getres clock_id: CLOCK_REALTIME_COARSE [PASS] Could not find __vdso_clock_gettime Could not find __vdso_clock_getres clock_id: CLOCK_MONOTONIC [PASS] Could not find __vdso_clock_gettime Could not find __vdso_clock_getres clock_id: CLOCK_MONOTONIC_RAW [PASS] Could not find __vdso_clock_gettime Could not find __vdso_clock_getres clock_id: CLOCK_MONOTONIC_COARSE [PASS] Could not find __vdso_time After (on riscv32): $ ./vdso_test_abi [vDSO kselftest] VDSO_VERSION: LINUX_4.15 The time is 1612449376.015086 The time is 1612449376.18340784 The resolution is 0 1 clock_id: CLOCK_REALTIME [PASS] The time is 774.842586182 The resolution is 0 1 clock_id: CLOCK_BOOTTIME [PASS] The time is 1612449376.22536565 The resolution is 0 1 clock_id: CLOCK_TAI [PASS] The time is 1612449376.20885172 The resolution is 0 400 clock_id: CLOCK_REALTIME_COARSE [PASS] The time is 774.845491269 The resolution is 0 1 clock_id: CLOCK_MONOTONIC [PASS] The time is 774.849534200 The resolution is 0 1 clock_id: CLOCK_MONOTONIC_RAW [PASS] The time is 774.842139684 The resolution is 0 400 clock_id: CLOCK_MONOTONIC_COARSE [PASS] Could not find __vdso_time Signed-off-by: Tobias Klauser --- tools/testing/selftests/vDSO/vdso_config.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/vDSO/vdso_config.h b/tools/testing/selftests/vDSO/vdso_config.h index 6a6fe8d4ff55..6188b16827d1 100644 --- a/tools/testing/selftests/vDSO/vdso_config.h +++ b/tools/testing/selftests/vDSO/vdso_config.h @@ -47,10 +47,12 @@ #elif defined(__x86_64__) #define VDSO_VERSION 0 #define VDSO_NAMES 1 -#elif defined(__riscv__) +#elif defined(__riscv__) || defined(__riscv) #define VDSO_VERSION 5 #define VDSO_NAMES 1 +#if __riscv_xlen == 32 #define VDSO_32BIT 1 +#endif #else /* nds32 */ #define VDSO_VERSION 4 #define VDSO_NAMES 1 Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Not sure if you want this through the RISC-V tree, so I'm leaving it out for now and assuming it'll go through a kselftest tree. Thanks!
Re: [PATCH v1 1/2] cpufreq: ACPI: Extend frequency tables to cover boost frequencies
On Thu, 2021-02-04 at 18:25 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> A severe performance regression on AMD EPYC processors when using
> the schedutil scaling governor was discovered by Phoronix.com and
> attributed to the following commits:
>
> 41ea667227ba ("x86, sched: Calculate frequency invariance for
> AMD systems")
>
> 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P
> for frequency invariance on AMD EPYC")
>
> [snip]
>
> Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
> systems")
> Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
> frequency invariance on AMD EPYC")
> Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default
> with intel_pstate")
> Link:
> https://www.phoronix.com/scan.php?page=article=linux511-amd-schedutil=1
> Link:
> https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdov...@suse.cz/
> Reported-by: Michael Larabel
> Diagnosed-by: Giovanni Gherdovich
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/acpi-cpufreq.c | 107
> -
> 1 file changed, 95 insertions(+), 12 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
> +++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
> [...]
Tested-by: Giovanni Gherdovich
Reviewed-by: Giovanni Gherdovich
Note there is also the Tested-by: Michael, from the other thread
https://lore.kernel.org/lkml/5ea06dbe-255c-3d22-b9bd-6e627c5f9...@phoronix.com/
I tested this patch with the "NASA Parallel Benchmarks" from [link below], the
results confirms that the 5.10 performance is recovered:
Ratios of completion times, lower is better (5.10 is the baseline)
5.10 5.11-rc6 5.11-rc6-ggherdov
5.11-rc6-rafael
~
Integer Sort 1.001.210.91 0.93
Embarrassingly Parallel 1.001.601.00 1.00
Discrete FFT 1.001.680.67 0.67
CPU : MODEL: 2x AMD EPYC 7742
FREQUENCY TABLE : P2: 1.50 GHz
P1: 2.00 GHz
P0: 2.25 GHz
MAX BOOST: 3.40 GHz
[link] https://www.nas.nasa.gov/publications/npb.html
Thanks,
Giovanni
Re: [PATCH v2 1/1] powerpc/kvm: Save Timebase Offset to fix sched_clock() while running guest code.
Hey Nick, thanks for reviewing :)
On Fri, 2021-02-05 at 16:28 +1000, Nicholas Piggin wrote:
> Excerpts from Leonardo Bras's message of February 5, 2021 4:06 pm:
> > Before guest entry, TBU40 register is changed to reflect guest timebase.
> > After exitting guest, the register is reverted to it's original value.
> >
> > If one tries to get the timestamp from host between those changes, it
> > will present an incorrect value.
> >
> > An example would be trying to add a tracepoint in
> > kvmppc_guest_entry_inject_int(), which depending on last tracepoint
> > acquired could actually cause the host to crash.
> >
> > Save the Timebase Offset to PACA and use it on sched_clock() to always
> > get the correct timestamp.
>
> Ouch. Not sure how reasonable it is to half switch into guest registers
> and expect to call into the wider kernel, fixing things up as we go.
> What if mftb is used in other places?
IIUC, the CPU is not supposed to call anything as host between guest
entry and guest exit, except guest-related cases, like
kvmppc_guest_entry_inject_int(), but anyway, if something calls mftb it
will still get the same value as before.
This is only supposed to change stuff that depends on sched_clock, like
Tracepoints, that can happen in those exceptions.
> Especially as it doesn't seem like there is a reason that function _has_
> to be called after the timebase is switched to guest, that's just how
> the code is structured.
Correct, but if called, like in rb routines, used by tracepoints, the
difference between last tb and current (lower) tb may cause the CPU to
trap PROGRAM exception, crashing host.
> As a local hack to work out a bug okay. If you really need it upstream
> could you put it under a debug config option?
You mean something that is automatically selected whenever those
configs are enabled?
CONFIG_TRACEPOINT && CONFIG_KVM_BOOK3S_HANDLER && CONFIG_PPC_BOOK3S_64
Or something the user need to select himself in menuconfig?
>
> Thanks,
> Nick
>
Thank you!
Leonardo Bras
> > Signed-off-by: Leonardo Bras
> > Suggested-by: Paul Mackerras
> > ---
> > Changes since v1:
> > - Subtracts offset only when CONFIG_KVM_BOOK3S_HANDLER and
> > CONFIG_PPC_BOOK3S_64 are defined.
> > ---
> > arch/powerpc/include/asm/kvm_book3s_asm.h | 1 +
> > arch/powerpc/kernel/asm-offsets.c | 1 +
> > arch/powerpc/kernel/time.c| 8 +++-
> > arch/powerpc/kvm/book3s_hv.c | 2 ++
> > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 ++
> > 5 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
> > b/arch/powerpc/include/asm/kvm_book3s_asm.h
> > index 078f4648ea27..e2c12a10eed2 100644
> > --- a/arch/powerpc/include/asm/kvm_book3s_asm.h
> > +++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
> > @@ -131,6 +131,7 @@ struct kvmppc_host_state {
> > u64 cfar;
> > u64 ppr;
> > u64 host_fscr;
> > + u64 tb_offset; /* Timebase offset: keeps correct timebase
> > while on guest */
> > #endif
> > };
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > diff --git a/arch/powerpc/kernel/asm-offsets.c
> > b/arch/powerpc/kernel/asm-offsets.c
> > index b12d7c049bfe..0beb8fdc6352 100644
> > --- a/arch/powerpc/kernel/asm-offsets.c
> > +++ b/arch/powerpc/kernel/asm-offsets.c
> > @@ -706,6 +706,7 @@ int main(void)
> > HSTATE_FIELD(HSTATE_CFAR, cfar);
> > HSTATE_FIELD(HSTATE_PPR, ppr);
> > HSTATE_FIELD(HSTATE_HOST_FSCR, host_fscr);
> > + HSTATE_FIELD(HSTATE_TB_OFFSET, tb_offset);
> > #endif /* CONFIG_PPC_BOOK3S_64 */
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > #else /* CONFIG_PPC_BOOK3S */
> > diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> > index 67feb3524460..f27f0163792b 100644
> > --- a/arch/powerpc/kernel/time.c
> > +++ b/arch/powerpc/kernel/time.c
> > @@ -699,7 +699,13 @@ EXPORT_SYMBOL_GPL(tb_to_ns);
> > */
> > notrace unsigned long long sched_clock(void)
> > {
> > - return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
> > + u64 tb = get_tb() - boot_tb;
> > +
> > +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_KVM_BOOK3S_HANDLER)
> > + tb -= local_paca->kvm_hstate.tb_offset;
> > +#endif
> > +
> > + return mulhdu(tb, tb_to_ns_scale) << tb_to_ns_shift;
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
Re: [PATCH -next] RISCV: Add some depends for NUMA
On Wed, 03 Feb 2021 06:23:43 PST (-0800), wangkefeng.w...@huawei.com wrote:
The numa feature is useless for riscv32 platform(MAXPHYSMEM_1GB if 32bit),
I'm not convinced of that. There's no reason NUMA shouldn't work on 32-bit, it
doesn't depend on having a large amount of memory just having non-uniform
memory. I could buy the argument that build a 32-bit NUMA system would be
wacky, but IIUC it works now and I don't see any reason to throw that away.
and it should depends on SMP feature, this also fix the build error,
I can buy that CONFIG_NUMA doesn't really make sense without CONFIG_SMP, as
there's not a whole lot to do, but I also don't see any reason from disallowing
users from picking it. arm64 allows !SMP && NUMA, and I don't see any reason
it wouldn't work just as well for us.
riscv64-buildroot-linux-gnu-ld: mm/page_alloc.o: in function `.L0 ':
page_alloc.c:(.text+0x4808): undefined reference to `node_reclaim_distance'
The only instance of node_reclaim_distance I see in mm/page_alloc.c is already
guarded with CONFIG_NUMA, but the definition of node_reclaim_distance isn't.
I'll send out some patches to add the guard which might make sorting this out
earlier, but I don't see it fixing any failures.
Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
Signed-off-by: Kefeng Wang
---
arch/riscv/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 22fa17898d29..ac7f5801bd82 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -312,6 +312,8 @@ endchoice
# Common NUMA Features
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+ depends on SMP
+ depends on 64BIT
select GENERIC_ARCH_NUMA
select OF_NUMA
select ARCH_SUPPORTS_NUMA_BALANCING
[PATCH] ssb: Use true and false for bool variable
Fix the following coccicheck warnings:
./include/linux/ssb/ssb_driver_gige.h:89:8-9: WARNING: return of 0/1 in
function 'ssb_gige_one_dma_at_once' with return type bool.
./include/linux/ssb/ssb_driver_gige.h:79:8-9: WARNING: return of 0/1 in
function 'ssb_gige_have_roboswitch' with return type bool.
./include/linux/ssb/ssb_driver_gige.h:182:8-9: WARNING: return of 0/1 in
function 'ssb_gige_must_flush_posted_writes' with return type bool.
./include/linux/ssb/ssb_driver_gige.h:178:8-9: WARNING: return of 0/1 in
function 'ssb_gige_one_dma_at_once' with return type bool.
./include/linux/ssb/ssb_driver_gige.h:174:8-9: WARNING: return of 0/1 in
function 'ssb_gige_have_roboswitch' with return type bool.
./include/linux/ssb/ssb_driver_gige.h:170:8-9: WARNING: return of 0/1 in
function 'ssb_gige_is_rgmii' with return type bool.
./include/linux/ssb/ssb_driver_gige.h:162:8-9: WARNING: return of 0/1 in
function 'pdev_is_ssb_gige_core' with return type bool.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
include/linux/ssb/ssb_driver_gige.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/ssb/ssb_driver_gige.h
b/include/linux/ssb/ssb_driver_gige.h
index 31593b3..15ba0df 100644
--- a/include/linux/ssb/ssb_driver_gige.h
+++ b/include/linux/ssb/ssb_driver_gige.h
@@ -76,7 +76,7 @@ static inline bool ssb_gige_have_roboswitch(struct pci_dev
*pdev)
if (dev)
return !!(dev->dev->bus->sprom.boardflags_lo &
SSB_GIGE_BFL_ROBOSWITCH);
- return 0;
+ return false;
}
/* Returns whether we can only do one DMA at once. */
@@ -86,7 +86,7 @@ static inline bool ssb_gige_one_dma_at_once(struct pci_dev
*pdev)
if (dev)
return ((dev->dev->bus->chip_id == 0x4785) &&
(dev->dev->bus->chip_rev < 2));
- return 0;
+ return false;
}
/* Returns whether we must flush posted writes. */
@@ -159,7 +159,7 @@ static inline void ssb_gige_exit(void)
static inline bool pdev_is_ssb_gige_core(struct pci_dev *pdev)
{
- return 0;
+ return false;
}
static inline struct ssb_gige * pdev_to_ssb_gige(struct pci_dev *pdev)
{
@@ -167,19 +167,19 @@ static inline struct ssb_gige * pdev_to_ssb_gige(struct
pci_dev *pdev)
}
static inline bool ssb_gige_is_rgmii(struct pci_dev *pdev)
{
- return 0;
+ return false;
}
static inline bool ssb_gige_have_roboswitch(struct pci_dev *pdev)
{
- return 0;
+ return false;
}
static inline bool ssb_gige_one_dma_at_once(struct pci_dev *pdev)
{
- return 0;
+ return false;
}
static inline bool ssb_gige_must_flush_posted_writes(struct pci_dev *pdev)
{
- return 0;
+ return false;
}
static inline int ssb_gige_get_macaddr(struct pci_dev *pdev, u8 *macaddr)
{
--
1.8.3.1
[PATCH v5 1/2] nbd: Fix NULL pointer in flush_workqueue
Open /dev/nbdX first, the config_refs will be 1 and
the pointers in nbd_device are still null. Disconnect
/dev/nbdX, then reference a null recv_workq. The
protection by config_refs in nbd_genl_disconnect is useless.
[ 656.366194] BUG: kernel NULL pointer dereference, address: 0020
[ 656.368943] #PF: supervisor write access in kernel mode
[ 656.369844] #PF: error_code(0x0002) - not-present page
[ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0
[ 656.371693] Oops: 0002 [#1] SMP
[ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted
5.11.0-rc5-00040-g76c057c84d28 #1
[ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[ 656.375904] RIP: 0010:mutex_lock+0x29/0x60
[ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8
7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f
b1 55 d
[ 656.378934] RSP: 0018:c95eb9b0 EFLAGS: 00010246
[ 656.379350] RAX: RBX: RCX:
[ 656.379915] RDX: 888104cf2600 RSI: aae8f452 RDI: 0020
[ 656.380473] RBP: 0020 R08: R09: 88813bd6b318
[ 656.381039] R10: 00c7 R11: fefefefefefefeff R12: 888102710b40
[ 656.381599] R13: c95eb9e0 R14: b2930680 R15: 88810770ef00
[ 656.382166] FS: 7fdf117ebb40() GS:88813bd4()
knlGS:
[ 656.382806] CS: 0010 DS: ES: CR0: 80050033
[ 656.383261] CR2: 0020 CR3: 000100c84000 CR4: 06e0
[ 656.383819] DR0: DR1: DR2:
[ 656.384370] DR3: DR6: fffe0ff0 DR7: 0400
[ 656.384927] Call Trace:
[ 656.385111] flush_workqueue+0x92/0x6c0
[ 656.385395] nbd_disconnect_and_put+0x81/0xd0
[ 656.385716] nbd_genl_disconnect+0x125/0x2a0
[ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0
[ 656.386422] genl_rcv_msg+0xfc/0x2b0
[ 656.386685] ? nbd_ioctl+0x490/0x490
[ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0
[ 656.387354] netlink_rcv_skb+0x62/0x180
[ 656.387638] genl_rcv+0x34/0x60
[ 656.387874] netlink_unicast+0x26d/0x590
[ 656.388162] netlink_sendmsg+0x398/0x6c0
[ 656.388451] ? netlink_rcv_skb+0x180/0x180
[ 656.388750] sys_sendmsg+0x1da/0x320
[ 656.389038] ? sys_recvmsg+0x130/0x220
[ 656.389334] ___sys_sendmsg+0x8e/0xf0
[ 656.389605] ? ___sys_recvmsg+0xa2/0xf0
[ 656.389889] ? handle_mm_fault+0x1671/0x21d0
[ 656.390201] __sys_sendmsg+0x6d/0xe0
[ 656.390464] __x64_sys_sendmsg+0x23/0x30
[ 656.390751] do_syscall_64+0x45/0x70
[ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs")
Suggested-by: Markus Elfring
Signed-off-by: Sun Ke
---
v4: Share exception handling code for if branches
v3: Do not use unlock and add put_nbd.
v2: Use jump target unlock.
---
drivers/block/nbd.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index e6ea5d344f87..3c9b3bf3f4c2 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -2014,17 +2014,20 @@ static int nbd_genl_disconnect(struct sk_buff *skb,
struct genl_info *info)
mutex_lock(_index_mutex);
nbd = idr_find(_index_idr, index);
if (!nbd) {
- mutex_unlock(_index_mutex);
printk(KERN_ERR "nbd: couldn't find device at index %d\n",
index);
- return -EINVAL;
+ goto unlock_index;
}
- if (!refcount_inc_not_zero(>refs)) {
- mutex_unlock(_index_mutex);
+ mutex_lock(>config_lock);
+ if (!refcount_inc_not_zero(>refs) || !nbd->recv_workq) {
+ mutex_unlock(>config_lock);
printk(KERN_ERR "nbd: device at index %d is going down\n",
index);
+unlock_index:
+ mutex_unlock(_index_mutex);
return -EINVAL;
}
+ mutex_unlock(>config_lock);
mutex_unlock(_index_mutex);
if (!refcount_inc_not_zero(>config_refs)) {
nbd_put(nbd);
--
2.25.4
[PATCH v5 2/2] nbd: share nbd_put and return by goto put_nbd
Replace the following two statements by the statement “goto put_nbd;”
nbd_put(nbd);
return 0;
Suggested-by: Markus Elfring
Signed-off-by: Sun Ke
---
drivers/block/nbd.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 3c9b3bf3f4c2..ecae81e43122 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -2029,12 +2029,11 @@ static int nbd_genl_disconnect(struct sk_buff *skb,
struct genl_info *info)
}
mutex_unlock(>config_lock);
mutex_unlock(_index_mutex);
- if (!refcount_inc_not_zero(>config_refs)) {
- nbd_put(nbd);
- return 0;
- }
+ if (!refcount_inc_not_zero(>config_refs))
+ goto put_nbd;
nbd_disconnect_and_put(nbd);
nbd_config_put(nbd);
+put_nbd:
nbd_put(nbd);
return 0;
}
--
2.25.4
[PATCH v5 0/2] fix a NULL pointer bug and simplify the code
v5: Adjust the title and add “Suggested-by”. v4: Share exception handling code for if branches and move put_nbd adjustment to a separate patch. v3: Do not use unlock and add put_nbd. v2: Use jump target unlock. Sun Ke (2): nbd: Fix NULL pointer in flush_workqueue nbd: share nbd_put and return by goto put_nbd drivers/block/nbd.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) -- 2.25.4
Re: Linux 5.11-rc5
On Thu, Feb 04, 2021 at 10:32:56AM -0800, Linus Torvalds wrote:
> On Thu, Feb 4, 2021 at 10:19 AM Mike Rapoport wrote:
> >
> > On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> > >
> > > Mike: should we perhaps revert the first patch too (commit
> > > bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?
> >
> > Unfortunately, I was too optimistic and didn't take into account that this
> > commit changes the way /dev/mem sees the first page of memory.
> >
> > There were reports of slackware users about issues with lilo after upgrade
> > from 5.10.11 to 5.10.12
>
> Ok, applied to mainline.
>
> Greg & stable people - this is now commit 5c279c4cf206 ("Revert
> "x86/setup: don't remove E820_TYPE_RAM for pfn 0"") in my tree.
> Although maybe you just want to revert the commit in stable, rather
> than take it from upstream? Same difference.
Taking it from upstream makes it easier to track over time what happend.
I've queued it up now, thanks!
greg k-h
Re: Kernel version numbers after 4.9.255 and 4.4.255
On Thu, Feb 04, 2021 at 09:19:33PM +0100, Christoph Biedl wrote: > David Laight wrote... > > > A full wrap might catch checks for less than (say) 4.4.2 which > > might be present to avoid very early versions. > > So sticking at 255 or wrapping onto (say) 128 to 255 might be better. > > Hitting such version checks still might happen, though. By who? For what? > Also, any wrapping introduces a real risk package managers will see > version numbers running backwards and therefore will refrain from > installing an actually newer version. package managers do not take the version from this macro, do they? If they do, please show me which ones. thanks, greg k-h
Re: [PATCH v3 2/2] tpm: in tpm2_del_space check if ops pointer is still valid
On Fri, Feb 05, 2021 at 12:50:43AM +0100, Lino Sanfilippo wrote:
> From: Lino Sanfilippo
>
> In tpm2_del_space() chip->ops is used for flushing the sessions. However
> this function may be called after tpm_chip_unregister() which sets
> the chip->ops pointer to NULL.
> Avoid a possible NULL pointer dereference by checking if chip->ops is still
> valid before accessing it.
>
> Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()")
> Signed-off-by: Lino Sanfilippo
> ---
> drivers/char/tpm/tpm2-space.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
[PATCH] perf record: Fix continue profiling after draining the buffer
commit da231338ec9c098707c8a1e4d8a50e2400e2fe17 uses eventfd to solve rare race
where the setting and checking of 'done' which add done_fd to pollfd.
When draining buffer, revents of done_fd is 0 and evlist__filter_pollfd
function returns a non-zero value.
As a result, perf record does not stop profiling.
The following simple scenarios can trigger this condition:
sleep 10 &
perf record -p $!
After the sleep process exits, perf record should stop profiling and exit.
However, perf record keeps running.
If pollfd revents contains only POLLERR or POLLHUP,
perf record indicates that buffer is draining and need to stop profiling.
Use fdarray_flag__nonfilterable to set done eventfd to nonfilterable objects,
so that evlist__filter_pollfd does not filter and check done eventfd.
Fixes: da231338ec9c (perf record: Use an eventfd to wakeup when done)
Signed-off-by: Yang Jihong
---
tools/perf/builtin-record.c | 2 +-
tools/perf/util/evlist.c| 8
tools/perf/util/evlist.h| 4
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index fd3911650612..51e593e896ea 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1663,7 +1663,7 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
status = -1;
goto out_delete_session;
}
- err = evlist__add_pollfd(rec->evlist, done_fd);
+ err = evlist__add_wakeup_eventfd(rec->evlist, done_fd);
if (err < 0) {
pr_err("Failed to add wakeup eventfd to poll list\n");
status = err;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 05363a7247c4..fea4c1e8010d 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -572,6 +572,14 @@ int evlist__filter_pollfd(struct evlist *evlist, short
revents_and_mask)
return perf_evlist__filter_pollfd(>core, revents_and_mask);
}
+#ifdef HAVE_EVENTFD_SUPPORT
+int evlist__add_wakeup_eventfd(struct evlist *evlist, int fd)
+{
+ return perf_evlist__add_pollfd(>core, fd, NULL, POLLIN,
+ fdarray_flag__nonfilterable);
+}
+#endif
+
int evlist__poll(struct evlist *evlist, int timeout)
{
return perf_evlist__poll(>core, timeout);
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 1aae75895dea..6d4d62151bc8 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -142,6 +142,10 @@ struct evsel *evlist__find_tracepoint_by_name(struct
evlist *evlist, const char
int evlist__add_pollfd(struct evlist *evlist, int fd);
int evlist__filter_pollfd(struct evlist *evlist, short revents_and_mask);
+#ifdef HAVE_EVENTFD_SUPPORT
+int evlist__add_wakeup_eventfd(struct evlist *evlist, int fd);
+#endif
+
int evlist__poll(struct evlist *evlist, int timeout);
struct evsel *evlist__id2evsel(struct evlist *evlist, u64 id);
--
2.17.1
Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip
On Fri, Feb 05, 2021 at 12:50:42AM +0100, Lino Sanfilippo wrote:
> From: Lino Sanfilippo
>
> The following sequence of operations results in a refcount warning:
>
> 1. Open device /dev/tpmrm
> 2. Remove module tpm_tis_spi
> 3. Write a TPM command to the file descriptor opened at step 1.
>
> [ cut here ]
> WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
> refcount_t: addition on 0; use-after-free.
> Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
> sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
> brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
> raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
> snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
> CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
> Hardware name: BCM2711
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xc4/0xd8)
> [] (dump_stack) from [] (__warn+0x104/0x108)
> [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8)
> [] (warn_slowpath_fmt) from [] (kobject_get+0xa0/0xa4)
> [] (kobject_get) from [] (tpm_try_get_ops+0x14/0x54 [tpm])
> [] (tpm_try_get_ops [tpm]) from []
> (tpm_common_write+0x38/0x60 [tpm])
> [] (tpm_common_write [tpm]) from [] (vfs_write+0xc4/0x3c0)
> [] (vfs_write) from [] (ksys_write+0x58/0xcc)
> [] (ksys_write) from [] (ret_fast_syscall+0x0/0x4c)
> Exception stack(0xc226bfa8 to 0xc226bff0)
> bfa0: 000105b4 0003 beafe664 0014
> bfc0: 000105b4 000103f8 0004 b6f9c000 beafe684
> bfe0: 006c beafe648 0001056c b6eb6944
> ---[ end trace d4b8409def9b8b1f ]---
>
> The reason for this warning is the attempt to get the chip->dev reference
> in tpm_common_write() although the reference counter is already zero.
>
> Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the
> extra reference used to prevent a premature zero counter is never taken,
> because the required TPM_CHIP_FLAG_TPM2 flag is never set.
>
> Fix this by removing the flag condition.
>
> Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
> already introduced function tpm_devs_release() to release the extra
> reference but did not implement the required put on chip->devs that results
> in the call of this function.
>
> Fix this also by installing an action handler that puts chip->devs as soon
> as the chip is unregistered.
>
> Fixes: fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
> Fixes: 8979b02aaf1d ("tpm: Fix reference count to main device")
> Signed-off-by: Lino Sanfilippo
> ---
> drivers/char/tpm/tpm-chip.c | 18 +++---
> drivers/char/tpm/tpm_ftpm_tee.c | 2 ++
> drivers/char/tpm/tpm_vtpm_proxy.c | 1 +
> 3 files changed, 18 insertions(+), 3 deletions(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH] xhci-pci: Set AMD Renoir USB controller to D3 when shutdown
On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma wrote: > > > On 2/5/21 12:27 PM, Kai-Heng Feng wrote: > > Can you please test the following patch, which should address the root > > cause: > > https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furq...@google.com/ > > > > It also helps another AMD laptop on S5: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935 > > > > No, this patch doesn't help on ThinkPad AMD platform. Thanks for the confirmation! Acked-by: Kai-Heng Feng > > Aaron > > > We don't need to put bandage on drivers one by one once the patch with > > alternative approach is in upstream. > > > > Kai-Heng
Re: [PATCH][next] net/mlx5e: Fix spelling mistake "Unknouwn" -> "Unknown"
On Wed, 2021-02-03 at 14:57 -0800, Jesse Brandeburg wrote: > Colin King wrote: > > > From: Colin Ian King > > > > There is a spelling mistake in a netdev_warn message. Fix it. > > > > Signed-off-by: Colin Ian King > > Trivial patch, looks fine! > > Reviewed-by: Jesse Brandeburg Applied to net-next-mlx5. Thanks!
Re: [PATCH][next] net/mlx5e: Fix spelling mistake "channles" -> "channels"
On Thu, 2021-02-04 at 09:32 +, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in a netdev_warn message. Fix it. > > Signed-off-by: Colin Ian King > --- Applied to net-next-mlx5 thanks!
Re: [PATCH] xhci-pci: Set AMD Renoir USB controller to D3 when shutdown
On 2/5/21 12:27 PM, Kai-Heng Feng wrote: Can you please test the following patch, which should address the root cause: https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furq...@google.com/ It also helps another AMD laptop on S5: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935 No, this patch doesn't help on ThinkPad AMD platform. Aaron We don't need to put bandage on drivers one by one once the patch with alternative approach is in upstream. Kai-Heng
Re: [PATCH 0/6] Support second Image Signal Processor on rk3399
Hey Heiko, On 03.02.2021 20:54, Heiko Stübner wrote: Hi Sebastian, Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke: Hey Heiko, I have tested your patch set on my nanoPC-T4, here is a complete log with: - relevant kernel log entries - system information - media ctl output - sysfs entry information https://paste.debian.net/1183874/ Additionally, to your patchset I have applied the following patches: https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup And just to not cause confusion the `media_dev` entries come from this unmerged series: https://patchwork.kernel.org/project/linux-media/list/?series=426269 I have actually been able to stream with both of my cameras at the same time using the libcamera cam command. I would like to thank you a lot for making this possible. Thanks for testing a dual camera setup. On my board I could only test the second ISP. And really glad it works for you tool :-) . Out of curiosity, do you also see that green tint in the images the cameras produce? Yes, I do. Actually, I currently have two forms of a green tint, on my OV13850 everything is quite dark and greenish, which is caused by the missing 3A algorithms. On my OV4689, I have big patches of the image with bright green color and flickering, I investigated if this is connected to the 2nd ISP instance, but that doesn't seem to be the case as I have the same results when I switch the CSI ports of the cameras. I have found another issue, while testing I discovered following issue: When I start the system with an HDMI monitor connected, then the camera on the 2nd port doesn't work. This is probably because the RX/TX is reserved as a TX. But it made me wonder because if the system has an RX, a TX, and an RX/TX, why isn't the pure TX used by the monitor and the cameras take RX and RX/TX? Or do you think that this is maybe a malfunction of this patch? Thanks Heiko Greetings, Sebastian If you like to you can add: Tested-by: Sebastian Fricke On 02.02.2021 15:56, Heiko Stuebner wrote: >The rk3399 has two ISPs and right now only the first one is usable. >The second ISP is connected to the TXRX dphy on the soc. > >The phy of ISP1 is only accessible through the DSI controller's >io-memory, so this series adds support for simply using the dsi >controller is a phy if needed. > >That solution is needed at least on rk3399 and rk3288 but no-one >has looked at camera support on rk3288 at all, so right now >only implement the rk3399 specifics. > > >Heiko Stuebner (6): > drm/rockchip: dsi: add own additional pclk handling > dt-bindings: display: rockchip-dsi: add optional #phy-cells property > drm/rockchip: dsi: add ability to work as a phy instead of full dsi > arm64: dts: rockchip: add #phy-cells to mipi-dsi1 > arm64: dts: rockchip: add cif clk-control pinctrl for rk3399 > arm64: dts: rockchip: add isp1 node on rk3399 > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 ++ > drivers/gpu/drm/rockchip/Kconfig | 2 + > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 342 ++ > 4 files changed, 384 insertions(+) >
Re: [PATCH] drm/msm: Fix legacy relocs path
On 2/5/2021 4:26 AM, Rob Clark wrote:
From: Rob Clark
In moving code around, we ended up using the same pointer to
copy_from_user() the relocs tables as we used for the cmd table
entry, which is clearly not right. This went unnoticed because
modern mesa on non-ancent kernels does not actually use relocs.
But this broke ancient mesa on modern kernels.
Reported-by: Emil Velikov
Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index d04c349d8112..5480852bdeda 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -198,6 +198,8 @@ static int submit_lookup_cmds(struct msm_gem_submit *submit,
submit->cmd[i].idx = submit_cmd.submit_idx;
submit->cmd[i].nr_relocs = submit_cmd.nr_relocs;
+ userptr = u64_to_user_ptr(submit_cmd.relocs);
+
sz = array_size(submit_cmd.nr_relocs,
sizeof(struct drm_msm_gem_submit_reloc));
/* check for overflow: */
Reviewed-by: Akhil P Oommen
-Akhil.
Re: Small student project idea on appropriate integration trees in MAINTAINERS
On Fri, Jan 29, 2021 at 12:54 AM Jonathan Corbet wrote: > > On Fri, 22 Jan 2021 09:22:24 +0100 > Lukas Bulwahn wrote: > > > In this project, we can make use of: > > > > - gitdm [git://git.lwn.net/gitdm.git]: gitdm includes some scripts to > > parse MAINTAINERS and obtain the integration tree patch of a commit. > > Look also at the 'treeplot' tool there, which determines which tree(s) > each patch went through and makes pretty (OK, not hugely pretty) pictures > from the result. Thanks, we are well aware, and that is a good reminder for Basak and me to get our gitdm treeplot patches in shape for proper submission. > > I suspect you'll find that the tree information is mostly correct. Your suspicion, which is counter to my hypothesis, makes this investigation worthwhile just to see how correct that information really is. > Developers need to know that to be able to base their patches properly; an > incorrect entry would lead to a certain amount of maintainer misery. > Maybe the missing or wrong information in MAINTAINERS or the lack of clear recommendation for new developers to a kernel subsystem on which integration tree a patch shall apply to is one of the reasons for some maintainers' misery. Let us find someone interested to measure and investigate and then we will see... Lukas
Re: [PATCH] mm: cma: support sysfs
On 2/4/21 10:24 PM, Minchan Kim wrote: On Thu, Feb 04, 2021 at 09:49:54PM -0800, John Hubbard wrote: On 2/4/21 9:17 PM, Minchan Kim wrote: ... # cat vmstat | grep -i cma nr_free_cma 261718 # cat meminfo | grep -i cma CmaTotal:1048576 kB CmaFree: 1046872 kB OK, given that CMA is already in those two locations, maybe we should put this information in one or both of those, yes? Do you suggest something liks this, for example? cat vmstat | grep -i cma cma_a_success 125 cma_a_fail 25 cma_b_success 130 cma_b_fail 156 .. cma_f_fail xxx Yes, approximately. I was wondering if this would suffice at least as a baseline: cma_alloc_success 125 cma_alloc_failure 25 ...and then, to see if more is needed, some questions: a) Do you know of an upper bound on how many cma areas there can be (I think Matthew also asked that)? b) Is tracking the cma area really as valuable as other possibilities? We can put "a few" to "several" items here, so really want to get your very favorite bits of information in. If, for example, there can be *lots* of cma areas, then maybe tracking by a range of allocation sizes is better... thanks, -- John Hubbard NVIDIA
ERROR: modpost: "ioremap" undefined!
Hi Nick, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 61556703b610a104de324e4f061dc6cf7b218b46 commit: 1e1b6d63d6340764e00356873e5794225a2a03ea lib/string.c: implement stpcpy date: 4 months ago config: s390-randconfig-r014-20210205 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e1b6d63d6340764e00356873e5794225a2a03ea git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1e1b6d63d6340764e00356873e5794225a2a03ea # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "ioremap" [drivers/pcmcia/pcmcia.ko] undefined! >> ERROR: modpost: "iounmap" [drivers/pcmcia/pcmcia.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] selftests: breakpoints: Use correct error messages in breakpoint_test_arm64.c
When call ptrace(PTRACE_CONT, ...) failed, use correct error messages.
Signed-off-by: Tiezhu Yang
---
tools/testing/selftests/breakpoints/breakpoint_test_arm64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
index ad41ea6..e704181 100644
--- a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
+++ b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
@@ -145,7 +145,7 @@ static bool run_test(int wr_size, int wp_size, int wr, int
wp)
if (ptrace(PTRACE_CONT, pid, NULL, NULL) < 0) {
ksft_print_msg(
- "ptrace(PTRACE_SINGLESTEP) failed: %s\n",
+ "ptrace(PTRACE_CONT) failed: %s\n",
strerror(errno));
return false;
}
@@ -159,7 +159,7 @@ static bool run_test(int wr_size, int wp_size, int wr, int
wp)
}
alarm(0);
if (WIFEXITED(status)) {
- ksft_print_msg("child did not single-step\n");
+ ksft_print_msg("child exited prematurely\n");
return false;
}
if (!WIFSTOPPED(status)) {
--
2.1.0
Re: [PATCH 2/2] mmc: mmc_test: use erase_arg for mmc_erase command
On 4/02/21 2:05 pm, yann.gaut...@foss.st.com wrote:
> From: Yann Gautier
>
> Since [1], the erase argument for mmc_erase() function is saved in
> erase_arg field of card structure. It is preferable to use it instead of
> hard-coded MMC_SECURE_ERASE_ARG, which from eMMC 4.51 spec is not
> recommended:
> "6.6.16 Secure Erase
> NOTE Secure Erase is included for backwards compatibility. New system
> level implementations (based on v4.51 devices and beyond) should use
> Erase combined with Sanitize instead of secure erase."
>
> [1] commit 01904ff77676 ("mmc: core: Calculate the discard arg only once")
>
Did you experience an issue because of this? You could add that to the
commit message.
There does not seem to be a need for secure erase, so:
Acked-by: Adrian Hunter
> Signed-off-by: Yann Gautier
> ---
> drivers/mmc/core/mmc_test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c
> index 39a478874ca3..63524551a13a 100644
> --- a/drivers/mmc/core/mmc_test.c
> +++ b/drivers/mmc/core/mmc_test.c
> @@ -2110,7 +2110,7 @@ static int mmc_test_rw_multiple(struct mmc_test_card
> *test,
> if (mmc_can_erase(test->card) &&
> tdata->prepare & MMC_TEST_PREP_ERASE) {
> ret = mmc_erase(test->card, dev_addr,
> - size / 512, MMC_SECURE_ERASE_ARG);
> + size / 512, test->card->erase_arg);
> if (ret)
> ret = mmc_erase(test->card, dev_addr,
> size / 512, MMC_ERASE_ARG);
>
[PATCH] mm: memcontrol: remove rcu_read_lock from get_mem_cgroup_from_page
The get_mem_cgroup_from_page() is called under page lock, so the page
memcg cannot be changed under us. Also, css_get is enough because page
has a reference to the memcg.
If we really want to make the get_mem_cgroup_from_page() suitable for
arbitrary page, we should use page_memcg_rcu() instead of page_memcg()
and call it after rcu_read_lock().
Signed-off-by: Muchun Song
---
mm/memcontrol.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 87f01bc05d1f..6c7f1ea3955e 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1063,16 +1063,15 @@ EXPORT_SYMBOL(get_mem_cgroup_from_mm);
*/
struct mem_cgroup *get_mem_cgroup_from_page(struct page *page)
{
- struct mem_cgroup *memcg = page_memcg(page);
+ struct mem_cgroup *memcg;
if (mem_cgroup_disabled())
return NULL;
- rcu_read_lock();
/* Page should not get uncharged and freed memcg under us. */
- if (!memcg || WARN_ON_ONCE(!css_tryget(>css)))
- memcg = root_mem_cgroup;
- rcu_read_unlock();
+ memcg = page_memcg(page) ? : root_mem_cgroup;
+ css_get(>css);
+
return memcg;
}
EXPORT_SYMBOL(get_mem_cgroup_from_page);
--
2.11.0
[PATCH] selftests/bpf: Simplify the calculation of variables
Fix the following coccicheck warnings:
./tools/testing/selftests/bpf/xdpxceiver.c:954:28-30: WARNING !A || A &&
B is equivalent to !A || B.
./tools/testing/selftests/bpf/xdpxceiver.c:932:28-30: WARNING !A || A &&
B is equivalent to !A || B.
./tools/testing/selftests/bpf/xdpxceiver.c:909:28-30: WARNING !A || A &&
B is equivalent to !A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
tools/testing/selftests/bpf/xdpxceiver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/xdpxceiver.c
b/tools/testing/selftests/bpf/xdpxceiver.c
index 1e722ee..98ad4a2 100644
--- a/tools/testing/selftests/bpf/xdpxceiver.c
+++ b/tools/testing/selftests/bpf/xdpxceiver.c
@@ -906,7 +906,7 @@ static void *worker_testapp_validate(void *arg)
ksft_print_msg("Destroying socket\n");
}
- if (!opt_bidi || (opt_bidi && bidi_pass)) {
+ if (!opt_bidi || bidi_pass) {
xsk_socket__delete(((struct ifobject *)arg)->xsk->xsk);
(void)xsk_umem__delete(((struct ifobject *)arg)->umem->umem);
}
@@ -929,7 +929,7 @@ static void testapp_validate(void)
pthread_mutex_lock(_mutex);
/*Spawn RX thread */
- if (!opt_bidi || (opt_bidi && !bidi_pass)) {
+ if (!opt_bidi || !bidi_pass) {
if (pthread_create(, , worker_testapp_validate, (void
*)ifdict[1]))
exit_with_error(errno);
} else if (opt_bidi && bidi_pass) {
@@ -951,7 +951,7 @@ static void testapp_validate(void)
pthread_mutex_unlock(_mutex);
/*Spawn TX thread */
- if (!opt_bidi || (opt_bidi && !bidi_pass)) {
+ if (!opt_bidi || !bidi_pass) {
if (pthread_create(, , worker_testapp_validate, (void
*)ifdict[0]))
exit_with_error(errno);
} else if (opt_bidi && bidi_pass) {
--
1.8.3.1
Re: [PATCH v2 1/1] powerpc/kvm: Save Timebase Offset to fix sched_clock() while running guest code.
Excerpts from Leonardo Bras's message of February 5, 2021 4:06 pm:
> Before guest entry, TBU40 register is changed to reflect guest timebase.
> After exitting guest, the register is reverted to it's original value.
>
> If one tries to get the timestamp from host between those changes, it
> will present an incorrect value.
>
> An example would be trying to add a tracepoint in
> kvmppc_guest_entry_inject_int(), which depending on last tracepoint
> acquired could actually cause the host to crash.
>
> Save the Timebase Offset to PACA and use it on sched_clock() to always
> get the correct timestamp.
Ouch. Not sure how reasonable it is to half switch into guest registers
and expect to call into the wider kernel, fixing things up as we go.
What if mftb is used in other places?
Especially as it doesn't seem like there is a reason that function _has_
to be called after the timebase is switched to guest, that's just how
the code is structured.
As a local hack to work out a bug okay. If you really need it upstream
could you put it under a debug config option?
Thanks,
Nick
> Signed-off-by: Leonardo Bras
> Suggested-by: Paul Mackerras
> ---
> Changes since v1:
> - Subtracts offset only when CONFIG_KVM_BOOK3S_HANDLER and
> CONFIG_PPC_BOOK3S_64 are defined.
> ---
> arch/powerpc/include/asm/kvm_book3s_asm.h | 1 +
> arch/powerpc/kernel/asm-offsets.c | 1 +
> arch/powerpc/kernel/time.c| 8 +++-
> arch/powerpc/kvm/book3s_hv.c | 2 ++
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 ++
> 5 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
> b/arch/powerpc/include/asm/kvm_book3s_asm.h
> index 078f4648ea27..e2c12a10eed2 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_asm.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
> @@ -131,6 +131,7 @@ struct kvmppc_host_state {
> u64 cfar;
> u64 ppr;
> u64 host_fscr;
> + u64 tb_offset; /* Timebase offset: keeps correct timebase
> while on guest */
> #endif
> };
>
> diff --git a/arch/powerpc/kernel/asm-offsets.c
> b/arch/powerpc/kernel/asm-offsets.c
> index b12d7c049bfe..0beb8fdc6352 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -706,6 +706,7 @@ int main(void)
> HSTATE_FIELD(HSTATE_CFAR, cfar);
> HSTATE_FIELD(HSTATE_PPR, ppr);
> HSTATE_FIELD(HSTATE_HOST_FSCR, host_fscr);
> + HSTATE_FIELD(HSTATE_TB_OFFSET, tb_offset);
> #endif /* CONFIG_PPC_BOOK3S_64 */
>
> #else /* CONFIG_PPC_BOOK3S */
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 67feb3524460..f27f0163792b 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -699,7 +699,13 @@ EXPORT_SYMBOL_GPL(tb_to_ns);
> */
> notrace unsigned long long sched_clock(void)
> {
> - return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
> + u64 tb = get_tb() - boot_tb;
> +
> +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_KVM_BOOK3S_HANDLER)
> + tb -= local_paca->kvm_hstate.tb_offset;
> +#endif
> +
> + return mulhdu(tb, tb_to_ns_scale) << tb_to_ns_shift;
> }
>
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index b3731572295e..c08593c63353 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -3491,6 +3491,7 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
> *vcpu, u64 time_limit,
> if ((tb & 0xff) < (new_tb & 0xff))
> mtspr(SPRN_TBU40, new_tb + 0x100);
> vc->tb_offset_applied = vc->tb_offset;
> + local_paca->kvm_hstate.tb_offset = vc->tb_offset;
> }
>
> if (vc->pcr)
> @@ -3594,6 +3595,7 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
> *vcpu, u64 time_limit,
> if ((tb & 0xff) < (new_tb & 0xff))
> mtspr(SPRN_TBU40, new_tb + 0x100);
> vc->tb_offset_applied = 0;
> + local_paca->kvm_hstate.tb_offset = 0;
> }
>
> mtspr(SPRN_HDEC, 0x7fff);
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index b73140607875..8f7a9f7f4ee6 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -632,6 +632,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
> cmpdi r8,0
> beq 37f
> std r8, VCORE_TB_OFFSET_APPL(r5)
> + std r8, HSTATE_TB_OFFSET(r13)
> mftbr6 /* current host timebase */
> add r8,r8,r6
> mtspr SPRN_TBU40,r8 /* update upper 40 bits */
> @@ -1907,6 +1908,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> beq 17f
> li r0, 0
> std r0, VCORE_TB_OFFSET_APPL(r5)
> + std r0, HSTATE_TB_OFFSET(r13)
> mftbr6 /* current guest timebase */
> subf
[PATCH] net: core: Clean code style issues in `neighbour.c`
Do code format alignment to clean code style issues.
Signed-off-by: Zheng Yongjun
---
net/core/neighbour.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 9500d28a43b0..a742c918a09b 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -299,7 +299,7 @@ static void neigh_flush_dev(struct neigh_table *tbl, struct
net_device *dev,
struct neighbour __rcu **np = >hash_buckets[i];
while ((n = rcu_dereference_protected(*np,
- lockdep_is_held(>lock))) != NULL) {
+
lockdep_is_held(>lock))) != NULL) {
if (dev && n->dev != dev) {
np = >next;
continue;
@@ -309,7 +309,7 @@ static void neigh_flush_dev(struct neigh_table *tbl, struct
net_device *dev,
continue;
}
rcu_assign_pointer(*np,
- rcu_dereference_protected(n->next,
+ rcu_dereference_protected(n->next,
lockdep_is_held(>lock)));
write_lock(>lock);
neigh_del_timer(n);
@@ -634,7 +634,7 @@ static struct neighbour *___neigh_create(struct neigh_table
*tbl,
lockdep_is_held(>lock));
n1 != NULL;
n1 = rcu_dereference_protected(n1->next,
- lockdep_is_held(>lock))) {
+ lockdep_is_held(>lock))) {
if (dev == n1->dev && !memcmp(n1->primary_key, n->primary_key,
key_len)) {
if (want_ref)
neigh_hold(n1);
@@ -962,7 +962,7 @@ static void neigh_periodic_work(struct work_struct *work)
* BASE_REACHABLE_TIME.
*/
queue_delayed_work(system_power_efficient_wq, >gc_work,
- NEIGH_VAR(>parms, BASE_REACHABLE_TIME) >> 1);
+ NEIGH_VAR(>parms, BASE_REACHABLE_TIME) >> 1);
write_unlock_bh(>lock);
}
@@ -1620,8 +1620,7 @@ struct neigh_parms *neigh_parms_alloc(struct net_device
*dev,
if (p) {
p->tbl= tbl;
refcount_set(>refcnt, 1);
- p->reachable_time =
- neigh_rand_reach_time(NEIGH_VAR(p,
BASE_REACHABLE_TIME));
+ p->reachable_time = neigh_rand_reach_time(NEIGH_VAR(p,
BASE_REACHABLE_TIME));
dev_hold(dev);
p->dev = dev;
write_pnet(>net, net);
@@ -1693,7 +1692,7 @@ void neigh_table_init(int index, struct neigh_table *tbl)
#ifdef CONFIG_PROC_FS
if (!proc_create_seq_data(tbl->id, 0, init_net.proc_net_stat,
- _stat_seq_ops, tbl))
+ _stat_seq_ops, tbl))
panic("cannot create neighbour proc dir entry");
#endif
@@ -1714,10 +1713,10 @@ void neigh_table_init(int index, struct neigh_table
*tbl)
rwlock_init(>lock);
INIT_DEFERRABLE_WORK(>gc_work, neigh_periodic_work);
queue_delayed_work(system_power_efficient_wq, >gc_work,
- tbl->parms.reachable_time);
+ tbl->parms.reachable_time);
timer_setup(>proxy_timer, neigh_proxy_process, 0);
skb_queue_head_init_class(>proxy_queue,
- _table_proxy_queue_class);
+ _table_proxy_queue_class);
tbl->last_flush = now;
tbl->last_rand = now + tbl->parms.reachable_time * 20;
--
2.22.0
Re: [PATCH] mm: cma: support sysfs
On Thu, Feb 04, 2021 at 09:49:54PM -0800, John Hubbard wrote: > On 2/4/21 9:17 PM, Minchan Kim wrote: > ... > > > > > Presumably, having the source code, you can easily deduce that a > > > > > bluetooth > > > > > allocation failure goes directly to a CMA allocation failure, right? > > > > > > Still wondering about this... > > > > It would work if we have full source code and stack are not complicated for > > every usecases. Having said, having a good central place automatically > > popped up is also beneficial for not to add similar statistics for each > > call sites. > > > > Why do we have too many item in slab sysfs instead of creating each call > > site inventing on each own? > > > > I'm not sure I understand that question fully, but I don't think we need to > invent anything unique here. So far we've discussed debugfs, sysfs, and /proc, > none of which are new mechanisms. I thought you asked why we couldn't add those stat in their call site driver syfs instead of central place. Please clarify if I misunderstood your question. > > ... > > > > It's actually easier to monitor one or two simpler items than it is to > > > monitor > > > a larger number of complicated items. And I get the impression that this > > > is > > > sort of a top-level, production software indicator. > > > > Let me clarify one more time. > > > > What I'd like to get ultimately is per-CMA statistics instead of > > global vmstat for the usecase at this moment. Global vmstat > > could help the decision whether I should go deeper but it ends up > > needing per-CMA statistics. And I'd like to keep them in sysfs, > > not debugfs since it should be stable as a telemetric. > > > > What points do you disagree in this view? > > > No huge disagreements, I just want to get us down to the true essential > elements > of what is required--and find a good home for the data. Initial debugging > always > has excesses, and those should not end up in the more carefully vetted > production > code. > > If I were doing this, I'd probably consider HugeTLB pages as an example to > follow, > because they have a lot in common with CMA: it's another memory allocation > pool, and > people also want to monitor it. > > HugeTLB pages and THP pages are monitored in /proc: > /proc/meminfo and /proc/vmstat: > > # cat meminfo |grep -i huge > AnonHugePages: 88064 kB > ShmemHugePages:0 kB > FileHugePages: 0 kB > HugePages_Total: 500 > HugePages_Free: 500 > HugePages_Rsvd:0 > HugePages_Surp:0 > Hugepagesize: 2048 kB > Hugetlb: 1024000 kB > > # cat vmstat | grep -i huge > nr_shmem_hugepages 0 > nr_file_hugepages 0 > nr_anon_transparent_hugepages 43 > numa_huge_pte_updates 0 > > ...aha, so is CMA: > > # cat vmstat | grep -i cma > nr_free_cma 261718 > > # cat meminfo | grep -i cma > CmaTotal:1048576 kB > CmaFree: 1046872 kB > > OK, given that CMA is already in those two locations, maybe we should put > this information in one or both of those, yes? Do you suggest something liks this, for example? cat vmstat | grep -i cma cma_a_success 125 cma_a_fail 25 cma_b_success 130 cma_b_fail 156 .. cma_f_fail xxx
[PATCH] mm: memcontrol: fix missing wakeup oom task
We call memcg_oom_recover() in the uncharge_batch() to wakeup OOM task
when page uncharged, but for the slab pages, we do not do this when page
uncharged. When we drain per cpu stock, we also should do this.
The memcg_oom_recover() is small, so make it inline. And the parameter
of memcg cannot be NULL, so remove the check.
Signed-off-by: Muchun Song
---
mm/memcontrol.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8c035846c7a4..8569f4dbea2a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1925,7 +1925,7 @@ static int memcg_oom_wake_function(wait_queue_entry_t
*wait,
return autoremove_wake_function(wait, mode, sync, arg);
}
-static void memcg_oom_recover(struct mem_cgroup *memcg)
+static inline void memcg_oom_recover(struct mem_cgroup *memcg)
{
/*
* For the following lockless ->under_oom test, the only required
@@ -1935,7 +1935,7 @@ static void memcg_oom_recover(struct mem_cgroup *memcg)
* achieved by invoking mem_cgroup_mark_under_oom() before
* triggering notification.
*/
- if (memcg && memcg->under_oom)
+ if (memcg->under_oom)
__wake_up(_oom_waitq, TASK_NORMAL, 0, memcg);
}
@@ -2313,6 +2313,7 @@ static void drain_stock(struct memcg_stock_pcp *stock)
page_counter_uncharge(>memory, stock->nr_pages);
if (do_memsw_account())
page_counter_uncharge(>memsw, stock->nr_pages);
+ memcg_oom_recover(old);
stock->nr_pages = 0;
}
--
2.11.0
Re: [PATCH v5 5/5] arm64: dts: mt8192: add pwrap node
Hi Hsin-Hsiung, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on linux/master linus/master v5.11-rc6 next-20210125] [cannot apply to mediatek/for-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Hsin-Hsiung-Wang/Add-PMIC-wrapper-support-for-Mediatek-MT6873-8192-SoC-IC/20210205-093351 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: arm64-randconfig-r021-20210204 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/89327847fb3d72eb77dec4ea071dd03e95599a94 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Hsin-Hsiung-Wang/Add-PMIC-wrapper-support-for-Mediatek-MT6873-8192-SoC-IC/20210205-093351 git checkout 89327847fb3d72eb77dec4ea071dd03e95599a94 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/mediatek/mt8192.dtsi:255.24-25 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] arch:powerpc simple_write_to_buffer return check
On 05/02/21 4:05 am, Oliver O'Halloran wrote: > On Fri, Feb 5, 2021 at 5:17 AM Mayank Suman wrote: >> >> Signed-off-by: Mayank Suman > > commit messages aren't optional Sorry. I will include the commit message in PATCH v2. > >> --- >> arch/powerpc/kernel/eeh.c| 8 >> arch/powerpc/platforms/powernv/eeh-powernv.c | 4 ++-- >> 2 files changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c >> index 813713c9120c..2dbe1558a71f 100644 >> --- a/arch/powerpc/kernel/eeh.c >> +++ b/arch/powerpc/kernel/eeh.c >> @@ -1628,8 +1628,8 @@ static ssize_t eeh_force_recover_write(struct file >> *filp, >> char buf[20]; >> int ret; >> >> - ret = simple_write_to_buffer(buf, sizeof(buf), ppos, user_buf, >> count); >> - if (!ret) >> + ret = simple_write_to_buffer(buf, sizeof(buf)-1, ppos, user_buf, >> count); > > We should probably be zeroing the buffer. Reading to sizeof(buf) - 1 > is done in a few places to guarantee that the string is nul > terminated, but without the preceeding memset() that isn't actually > guaranteed. Yes, the buffer should be zeroed out first. I have included memset() in Patch v2. > >> + if (ret <= 0) >> return -EFAULT; > > EFAULT is supposed to be returned when the user supplies a buffer to > write(2) which is outside their address space. I figured letting the > sscanf() in the next step fail if the user passes writes a zero-length > buffer and returning EINVAL made more sense. That said, the exact > semantics around zero length writes are pretty handwavy so I guess > this isn't wrong, but I don't think it's better either. > simple_write_to_buffer may return negative value on fail. So, -EFAULT should be return in case of negative return value. The conditional (!ret) was not sufficient to catch negative return value.
Re: [PATCH v3 3/3] scsi: ufs: Fix wrong Task Tag used in task management request UPIUs
On 2021-02-01 10:39, Bart Van Assche wrote:
On 1/28/21 9:57 PM, Can Guo wrote:
On 2021-01-29 11:15, Bart Van Assche wrote:
On 1/27/21 8:16 PM, Can Guo wrote:
In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs +
req->tag as
the Task Tag in one TMR UPIU. Directly use req->tag as the Task Tag.
Why is the current code wrong and why is this patch the proper fix?
Please explain this in the patch description.
req->tag is the tag allocated for one TMR, no?
Hi Can,
Commit e293313262d3 ("scsi: ufs: Fix broken task management command
implementation") includes the following changes:
+ task_tag = hba->nutrs + free_slot;
task_req_upiup->header.dword_0 =
UPIU_HEADER_DWORD(UPIU_TRANSACTION_TASK_REQ, 0,
-lrbp->lun,
lrbp->task_tag);
+lun_id, task_tag);
task_req_upiup->header.dword_1 =
UPIU_HEADER_DWORD(0, tm_function, 0, 0);
As one can see the value written in dword_0 starts at hba->nutrs. Was
that code correct? If that code was correct, does your patch perhaps
break task management support?
That code is wrong. The Task Tag in Dword_0 should be the real tag we
allocated for TMR. The transfer request Task Tag which we are trying to
abort is given in Dword_5, which is the Input Parameter 3 of the TMR
UPIU.
I am not sure why the author gave hba->nutrs + req->tag as the Task Tag
of one TMR, the commit msg abot this part is not quite informative
Table 10.22 — Task Management Request UPIU
TASK MANAGEMENT REQUEST UPIU
--
|0 |1 |2 |3 |
--
|xx00 0100b| Flags |LUN |Task Tag|
--
...
16 (MSB) |17 |18 |19 (LSB)|
--
Input Parameter 2
--
Table 10.24 — Task Management Input Parameters
Field Description
Input Parameter 2 LSB: Task Tag of the task/command operated by the task
management function.
Thanks,
Can Guo.
Thanks,
Bart.
Re: [PATCH v2 2/3] fs/efs: Correct spacing after C keywords
On Thu, 2021-02-04 at 21:14 -0800, Amy Parker wrote:
> In EFS code, some C keywords (most commonly 'for') do not have spaces
> before their instructions, such as for() vs for (). The kernel style
> guide indicates that these should be of the latter variant. This patch
> updates them accordingly.
ok but:
> diff --git a/fs/efs/super.c b/fs/efs/super.c
[]
> @@ -169,7 +169,7 @@ static efs_block_t efs_validate_vh(struct volume_header
> *vh) {
> return 0;
>
>
> ui = ((__be32 *) (vh + 1)) - 1;
> - for(csum = 0; ui >= ((__be32 *) vh);) {
> + for (csum = 0; ui >= ((__be32 *) vh);) {
> cs = *ui--;
> csum += be32_to_cpu(cs);
> }
I think this loop is atypical. More common would be:
csum = 0;
for (ui = ((__be32 *)(vh + 1)) - 1; ui >= (__be32 *)vh; ui--)
csum += be32_to_cpu(*ui);
> @@ -198,9 +198,9 @@ static efs_block_t efs_validate_vh(struct volume_header
> *vh) {
> }
> #endif
>
>
> - for(i = 0; i < NPARTAB; i++) {
> + for (i = 0; i < NPARTAB; i++) {
> pt_type = (int) be32_to_cpu(vh->vh_pt[i].pt_type);
> - for(pt_entry = sgi_pt_types; pt_entry->pt_name; pt_entry++) {
> + for (pt_entry = sgi_pt_types; pt_entry->pt_name; pt_entry++) {
> if (pt_type == pt_entry->pt_type) break;
Also atypical is the break location, it should be on a separate line.
[PATCH v2 1/1] powerpc/kvm: Save Timebase Offset to fix sched_clock() while running guest code.
Before guest entry, TBU40 register is changed to reflect guest timebase.
After exitting guest, the register is reverted to it's original value.
If one tries to get the timestamp from host between those changes, it
will present an incorrect value.
An example would be trying to add a tracepoint in
kvmppc_guest_entry_inject_int(), which depending on last tracepoint
acquired could actually cause the host to crash.
Save the Timebase Offset to PACA and use it on sched_clock() to always
get the correct timestamp.
Signed-off-by: Leonardo Bras
Suggested-by: Paul Mackerras
---
Changes since v1:
- Subtracts offset only when CONFIG_KVM_BOOK3S_HANDLER and
CONFIG_PPC_BOOK3S_64 are defined.
---
arch/powerpc/include/asm/kvm_book3s_asm.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/time.c| 8 +++-
arch/powerpc/kvm/book3s_hv.c | 2 ++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 ++
5 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 078f4648ea27..e2c12a10eed2 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -131,6 +131,7 @@ struct kvmppc_host_state {
u64 cfar;
u64 ppr;
u64 host_fscr;
+ u64 tb_offset; /* Timebase offset: keeps correct timebase
while on guest */
#endif
};
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index b12d7c049bfe..0beb8fdc6352 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -706,6 +706,7 @@ int main(void)
HSTATE_FIELD(HSTATE_CFAR, cfar);
HSTATE_FIELD(HSTATE_PPR, ppr);
HSTATE_FIELD(HSTATE_HOST_FSCR, host_fscr);
+ HSTATE_FIELD(HSTATE_TB_OFFSET, tb_offset);
#endif /* CONFIG_PPC_BOOK3S_64 */
#else /* CONFIG_PPC_BOOK3S */
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 67feb3524460..f27f0163792b 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -699,7 +699,13 @@ EXPORT_SYMBOL_GPL(tb_to_ns);
*/
notrace unsigned long long sched_clock(void)
{
- return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
+ u64 tb = get_tb() - boot_tb;
+
+#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_KVM_BOOK3S_HANDLER)
+ tb -= local_paca->kvm_hstate.tb_offset;
+#endif
+
+ return mulhdu(tb, tb_to_ns_scale) << tb_to_ns_shift;
}
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index b3731572295e..c08593c63353 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3491,6 +3491,7 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
*vcpu, u64 time_limit,
if ((tb & 0xff) < (new_tb & 0xff))
mtspr(SPRN_TBU40, new_tb + 0x100);
vc->tb_offset_applied = vc->tb_offset;
+ local_paca->kvm_hstate.tb_offset = vc->tb_offset;
}
if (vc->pcr)
@@ -3594,6 +3595,7 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
*vcpu, u64 time_limit,
if ((tb & 0xff) < (new_tb & 0xff))
mtspr(SPRN_TBU40, new_tb + 0x100);
vc->tb_offset_applied = 0;
+ local_paca->kvm_hstate.tb_offset = 0;
}
mtspr(SPRN_HDEC, 0x7fff);
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index b73140607875..8f7a9f7f4ee6 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -632,6 +632,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
cmpdi r8,0
beq 37f
std r8, VCORE_TB_OFFSET_APPL(r5)
+ std r8, HSTATE_TB_OFFSET(r13)
mftbr6 /* current host timebase */
add r8,r8,r6
mtspr SPRN_TBU40,r8 /* update upper 40 bits */
@@ -1907,6 +1908,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
beq 17f
li r0, 0
std r0, VCORE_TB_OFFSET_APPL(r5)
+ std r0, HSTATE_TB_OFFSET(r13)
mftbr6 /* current guest timebase */
subfr8,r8,r6
mtspr SPRN_TBU40,r8 /* update upper 40 bits */
--
2.29.2
Re: [PATCH v2 1/3] fs/efs: Use correct brace styling for statements
On Thu, 2021-02-04 at 21:14 -0800, Amy Parker wrote:
> Many single-line statements have unnecessary braces, and some statement
> pairs have mismatched braces. This is a clear violation of the kernel
> style guide, which mandates that single line statements have no braces
> and that pairs with at least one multi-line block maintain their braces.
>
> This patch fixes these style violations. Single-line statements that
> have braces have had their braces stripped. Pair single-line statements
> have been formatted per the style guide. Pair mixed-line statements have
> had their braces updated to conform.
>
> Signed-off-by: Amy Parker
> ---
> fs/efs/inode.c | 10 ++
> fs/efs/super.c | 15 ++-
> 2 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/fs/efs/inode.c b/fs/efs/inode.c
> @@ -120,8 +120,10 @@ struct inode *efs_iget(struct super_block *super,
> unsigned long ino)
> device = 0;
> else
> device = MKDEV(sysv_major(rdev), sysv_minor(rdev));
> - } else
> + }
> + else {
Not the kernel specified style.
} else {
Try using checkpatch on your proposed patches.
Re: [PATCH v3 0/2] KVM: x86/mmu: Skip mmu_notifier changes when possible
These patches might be responsible for some instability in one of our stress tests. I'll send an update once I figure out what's going on. Thanks, David On Thu, Jan 28, 2021 at 9:48 PM Paolo Bonzini wrote: > > On 28/01/21 07:05, David Stevens wrote: > > These patches reduce how often mmu_notifier updates block guest page > > faults. The primary benefit of this is the reduction in the likelihood > > of extreme latency when handling a page fault due to another thread > > having been preempted while modifying host virtual addresses. > > > > v2 -> v3: > > - Added patch to skip check for MMIO page faults > > - Style changes > > > > David Stevens (1): > >KVM: x86/mmu: Consider the hva in mmu_notifier retry > > > > Sean Christopherson (1): > >KVM: x86/mmu: Skip mmu_notifier check when handling MMIO page fault > > > > arch/powerpc/kvm/book3s_64_mmu_hv.c| 2 +- > > arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +- > > arch/x86/kvm/mmu/mmu.c | 16 -- > > arch/x86/kvm/mmu/paging_tmpl.h | 7 --- > > include/linux/kvm_host.h | 25 +- > > virt/kvm/kvm_main.c| 29 ++ > > 6 files changed, 65 insertions(+), 16 deletions(-) > > > > Queued, thanks. > > Paolo >
[PATCH v1] tpm_tis_spi_main: set cs_change = 0 when timesout
when i reach TPM_RETRY, the cs cannot change back to 'high'.
So the TPM chips thinks this communication is not over.
And next times communication cannot be effective because
the communications mixed up with the last time.
Signed-off-by: wanghongzhe
---
drivers/char/tpm/tpm_tis_spi_main.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis_spi_main.c
b/drivers/char/tpm/tpm_tis_spi_main.c
index 3856f6ebcb34..6c52cbb28881 100644
--- a/drivers/char/tpm/tpm_tis_spi_main.c
+++ b/drivers/char/tpm/tpm_tis_spi_main.c
@@ -64,8 +64,18 @@ static int tpm_tis_spi_flow_control(struct tpm_tis_spi_phy
*phy,
break;
}
- if (i == TPM_RETRY)
+ if (i == TPM_RETRY) {
+ /* change back to 'high',
+* So the TPM chips thinks the last communication
+* is done.
+*/
+ spi_xfer.cs_change = 0;
+ spi_xfer->len = 1;
+ spi_message_init();
+ spi_message_add_tail(spi_xfer, );
+ ret = spi_sync_locked(phy->spi_device, );
return -ETIMEDOUT;
+ }
}
return 0;
--
2.19.1
Re: [PATCH] mm: cma: support sysfs
On 2/4/21 9:17 PM, Minchan Kim wrote: ... Presumably, having the source code, you can easily deduce that a bluetooth allocation failure goes directly to a CMA allocation failure, right? Still wondering about this... It would work if we have full source code and stack are not complicated for every usecases. Having said, having a good central place automatically popped up is also beneficial for not to add similar statistics for each call sites. Why do we have too many item in slab sysfs instead of creating each call site inventing on each own? I'm not sure I understand that question fully, but I don't think we need to invent anything unique here. So far we've discussed debugfs, sysfs, and /proc, none of which are new mechanisms. ... It's actually easier to monitor one or two simpler items than it is to monitor a larger number of complicated items. And I get the impression that this is sort of a top-level, production software indicator. Let me clarify one more time. What I'd like to get ultimately is per-CMA statistics instead of global vmstat for the usecase at this moment. Global vmstat could help the decision whether I should go deeper but it ends up needing per-CMA statistics. And I'd like to keep them in sysfs, not debugfs since it should be stable as a telemetric. What points do you disagree in this view? No huge disagreements, I just want to get us down to the true essential elements of what is required--and find a good home for the data. Initial debugging always has excesses, and those should not end up in the more carefully vetted production code. If I were doing this, I'd probably consider HugeTLB pages as an example to follow, because they have a lot in common with CMA: it's another memory allocation pool, and people also want to monitor it. HugeTLB pages and THP pages are monitored in /proc: /proc/meminfo and /proc/vmstat: # cat meminfo |grep -i huge AnonHugePages: 88064 kB ShmemHugePages:0 kB FileHugePages: 0 kB HugePages_Total: 500 HugePages_Free: 500 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 1024000 kB # cat vmstat | grep -i huge nr_shmem_hugepages 0 nr_file_hugepages 0 nr_anon_transparent_hugepages 43 numa_huge_pte_updates 0 ...aha, so is CMA: # cat vmstat | grep -i cma nr_free_cma 261718 # cat meminfo | grep -i cma CmaTotal:1048576 kB CmaFree: 1046872 kB OK, given that CMA is already in those two locations, maybe we should put this information in one or both of those, yes? thanks, -- John Hubbard NVIDIA
Re: [PATCH v2 7/7] Documentation: coresight: Add PID tracing description
On Thu, Feb 04, 2021 at 12:14:12PM +, Mike Leach wrote: [...] > > >>> +To support tracing PID for the kernel runs at different exception > > >>> levels, > > >>> +the PMU formats are defined as follow: > > >>> + > > >>> + "contextid1": Available on both EL1 kernel and EL2 kernel. When the > > >>> +kernel is running at EL1, "contextid1" enables the PID > > >>> +tracing; when the kernel is running at EL2, this > > >>> enables > > >>> +tracing the PID of guest applications. > > >>> + > > >>> + "contextid2": Only usable when the kernel is running at EL2. When > > >>> +selected, enables PID tracing on EL2 kernel. > > >>> + > > >>> + "contextid": Will be an alias for the option that enables PID > > >>> +tracing. I.e, > > >>> +contextid == contextid1, on EL1 kernel. > > >>> +contextid == contextid2, on EL2 kernel. > > >>> + > > >>> +The perf tool automatically sets corresponding bit for the "contextid" > > >>> config, > > >>> +therefore, the user doesn't have to bother which EL the kernel is > > >>> running. > > >>> + > > >>> + i.e, perf record -e cs_etm/contextid/u -- uname > > >>> +or perf record -e cs_etm//u -- uname > > >>> + > > >>> +will always do the "PID" tracing, independent of the kernel EL. > > >>> + > > >> > > >> This is telling me that both cs_etm// and cs_etm/contextid/ have the > > >> same effect - trace PID. Is this correct? > > > > > > > Just to make this clear, this is not a side effect of the patch. > > Which is fine - but the documentation should accurately reflect what > is happening on the system. > This is a new paragraph about the PID tracing or otherwise, Even if > some of the effects pre-date this patch, they have to be accurately > communicated. > I am also reading the new paragraph in the context of the rest of the > coresight.rst document - which is a user level document explaining the > basic operation of the coresight system and tools. > This document mentions no other perf command line parameters relevant > to coresight other than the @sink option.It actually calls out to the > OpenCSD docs to provide further information. > > > The perf > > tool driver automatically adds the "contextid" tracing and timestamp for > > "system wide" and process bound events, as they traces get mixed into > > the single sink. So these options are added implicitly by the perf tool > > to make the decoding easier. > > > > That's fine - I have no problem with contextID trace enabled by > default. Context ID is relatively low overhead - and only emitted at > start of trace / context changes. > But the explanation of the parameters currently reads as though they > always have an effect - and not putting them in there will omit the > effect - unless you spot the very subtle line at the end. > > The user does not need to know about parameters that have no effect! Thanks for the suggestion, Mike. > Perhaps a better approach would be to explain the above - an explicit > statement that "perf will always enable PID/ contextID tracing at the > relevant EL - but for EL2 it is possible to make specific adjustments > using parameters..." Usually users assume the PMU format has no effect if without set it; but this is not the case for the config "contextid", this config has been automatically enabled by perf tool. Based on your suggesiton, will refine the descrption for two things: clarify what's the common usage for EL1/EL2, and what's specific for EL2. Thanks, Leo
[PATCH] drivers: scsi: lpfc: Mundane spelling and sentence construction fixes throughout the file
Few spellings and sentence construction done throughout the file.
Signed-off-by: Bhaskar Chowdhury
---
drivers/scsi/lpfc/lpfc_init.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index ac67f420ec26..923fadb7945a 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -11022,7 +11022,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int
vectors)
/* We found a matching phys_id, so copy the IRQ info */
cpup->eq = new_cpup->eq;
- /* Bump start_cpu to the next slot to minmize the
+ /* Bump start_cpu to the next slot to minimize the
* chance of having multiple unassigned CPU entries
* selecting the same IRQ.
*/
@@ -11076,7 +11076,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int
vectors)
/* We found an available entry, copy the IRQ info */
cpup->eq = new_cpup->eq;
- /* Bump start_cpu to the next slot to minmize the
+ /* Bump start_cpu to the next slot to minimize the
* chance of having multiple unassigned CPU entries
* selecting the same IRQ.
*/
@@ -11246,14 +11246,14 @@ lpfc_cpuhp_get_eq(struct lpfc_hba *phba, unsigned int
cpu,
if (!maskp)
continue;
/*
-* if irq is not affinitized to the cpu going
+* if irq is not affinities to the cpu going
* then we don't need to poll the eq attached
* to it.
*/
if (!cpumask_and(tmp, maskp, cpumask_of(cpu)))
continue;
- /* get the cpus that are online and are affini-
-* tized to this irq vector. If the count is
+ /* get the cpus that are online and are affinities
+* to this irq vector. If the count is
* more than 1 then cpuhp is not going to shut-
* down this vector. Since this cpu has not
* gone offline yet, we need >1.
@@ -11367,7 +11367,7 @@ lpfc_irq_clear_aff(struct lpfc_hba_eq_hdl *eqhdl)
* online cpu on the phba's original_mask and migrate all offlining IRQ
* affinities.
*
- * If cpu is coming online, reaffinitize the IRQ back to the onlining cpu.
+ * If cpu is coming online, again affinities the IRQ back to the on lining cpu.
*
* Note: Call only if NUMA or NHT mode is enabled, otherwise rely on
* PCI_IRQ_AFFINITY to auto-manage IRQ affinity.
@@ -11401,7 +11401,7 @@ lpfc_irq_rebalance(struct lpfc_hba *phba, unsigned int
cpu, bool offline)
/* Found a valid CPU */
if ((cpu_select < nr_cpu_ids) && (cpu_select != cpu)) {
- /* Go through each eqhdl and ensure offlining
+ /* Go through each eqhdl and ensure off lining
* cpu aff_mask is migrated
*/
for (idx = 0; idx < phba->cfg_irq_chann; idx++) {
@@ -11597,7 +11597,7 @@ lpfc_sli4_enable_msix(struct lpfc_hba *phba)
* this vector, set LPFC_CPU_FIRST_IRQ.
*
* With certain platforms its possible that irq
-* vectors are affinitized to all the cpu's.
+* vectors are affinities to all the cpu's.
* This can result in each cpu_map.eq to be set
* to the last vector, resulting in overwrite
* of all the previous cpu_map.eq. Ensure that
@@ -11635,7 +11635,7 @@ lpfc_sli4_enable_msix(struct lpfc_hba *phba)
free_irq(eqhdl->irq, eqhdl);
}
- /* Unconfigure MSI-X capability structure */
+ /* Not configure MSI-X capability structure */
pci_free_irq_vectors(phba->pcidev);
vec_fail_out:
@@ -11744,7 +11744,7 @@ lpfc_sli4_enable_intr(struct lpfc_hba *phba, uint32_t
cfg_mode)
}
}
- /* Fallback to INTx if both MSI-X/MSI initalization failed */
+ /* Fallback to INTx if both MSI-X/MSI initialization failed */
if (phba->intr_type == NONE) {
retval = request_irq(phba->pcidev->irq, lpfc_sli4_intr_handler,
IRQF_SHARED, LPFC_DRIVER_NAME, phba);
@@ -12479,7 +12479,7 @@ lpfc_pci_probe_one_s3(struct pci_dev *pdev, const
struct pci_device_id *pid)
* lpfc_pci_remove_one_s3 - PCI func to unreg SLI-3 device from PCI subsystem.
* @pdev: pointer to PCI device
*
- * This routine is to be called to disattach a device with
Re: [PATCH RESEND v2 4/5] iommu/tegra-smmu: Rework tegra_smmu_probe_device()
Hi Guillaume, On Thu, Feb 04, 2021 at 11:10:15AM +, Guillaume Tucker wrote: > Hi Nicolin, > > A regression was detected by kernelci.org in IGT's drm_read tests > on mainline, it was first seen on 17th December 2020. You can > find some details here: > > https://kernelci.org/test/case/id/600b82dc1e3208f123d3dffc/ Thanks for reporting the issue. We did test on Tegra210 and Tegra30 yet not on Tegra124. I am wondering what could go wrong... > Please let us know if you need any help debugging this issue or > to try a fix on this platform. Yes, I don't have any Tegra124 platform to run. It'd be very nice if you can run some debugging patch (I can provide you) and a fix after I root cause the issue. Thanks Nicolin
Re: [PATCH] mm: cma: support sysfs
On Fri, Feb 05, 2021 at 02:55:26AM +, Matthew Wilcox wrote:
> On Wed, Feb 03, 2021 at 07:50:01AM -0800, Minchan Kim wrote:
> > +++ b/mm/Makefile
> > @@ -106,6 +106,7 @@ obj-$(CONFIG_ZSMALLOC) += zsmalloc.o
> > obj-$(CONFIG_Z3FOLD) += z3fold.o
> > obj-$(CONFIG_GENERIC_EARLY_IOREMAP) += early_ioremap.o
> > obj-$(CONFIG_CMA) += cma.o
> > +obj-$(CONFIG_SYSFS) += cma_sysfs.o
>
> ehh ... if we have a kernel build with CMA=n, SYSFS=y, we'll get
> cma_sysfs built in with no cma to report on.
OMG. Let me fix it.
>
> > +static ssize_t cma_alloc_attempt_show(struct kobject *kobj,
> > + struct kobj_attribute *attr, char *buf)
> > +{
> > + unsigned long val;
> > + struct cma_stat *stat = container_of(kobj, struct cma_stat, kobj);
> > +
> > + val = stat->alloc_attempt;
> > +
> > + return sysfs_emit(buf, "%lu\n", val);
>
> Why not more simply:
>
> {
> struct cma_stat *stat = container_of(kobj, struct cma_stat, kobj);
> return sysfs_emit(buf, "%lu\n", stat->alloc_attempt);
It's a legacy when I used the lock there but removed finally.
Will follow your suggestion.
> }
>
> > + for (i = 0; i < cma_area_count; i++) {
> > + cma = _areas[i];
> > + stat = kzalloc(sizeof(*stat), GFP_KERNEL);
> > + if (!stat)
> > + goto out;
>
> How many cma areas are there going to be? do we really want to allocate
> their stat individually?
I am not sure what could be in the end but at least, I have
5+ candidates (but could be shrink or extend) and yes,
want to keep track them individually.
Re: [PATCH net-next 7/7] net: marvell: prestera: fix port event handling on init
On Wed, 3 Feb 2021 18:54:58 +0200 Vadym Kochan wrote:
> For some reason there might be a crash during ports creation if port
> events are handling at the same time because fw may send initial
> port event with down state.
>
> The crash points to cancel_delayed_work() which is called when port went
> is down. Currently I did not find out the real cause of the issue, so
> fixed it by cancel port stats work only if previous port's state was up
> & runnig.
Maybe you just need to move the DELAYED_WORK_INIT() earlier?
Not sure why it's at the end of prestera_port_create(), it
just initializes some fields.
> [ 28.489791] Call trace:
> [ 28.492259] get_work_pool+0x48/0x60
> [ 28.495874] cancel_delayed_work+0x38/0xb0
> [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera]
> [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera]
> [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci]
> [ 28.516660] process_one_work+0x1e8/0x360
> [ 28.520710] worker_thread+0x44/0x480
> [ 28.524412] kthread+0x154/0x160
> [ 28.527670] ret_from_fork+0x10/0x38
> [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020)
> [ 28.537429] ---[ end trace 5eced933df3a080b ]---
>
> Signed-off-by: Vadym Kochan
> ---
> drivers/net/ethernet/marvell/prestera/prestera_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/prestera/prestera_main.c
> b/drivers/net/ethernet/marvell/prestera/prestera_main.c
> index 39465e65d09b..122324dae47d 100644
> --- a/drivers/net/ethernet/marvell/prestera/prestera_main.c
> +++ b/drivers/net/ethernet/marvell/prestera/prestera_main.c
> @@ -433,7 +433,8 @@ static void prestera_port_handle_event(struct
> prestera_switch *sw,
> netif_carrier_on(port->dev);
> if (!delayed_work_pending(caching_dw))
> queue_delayed_work(prestera_wq, caching_dw, 0);
> - } else {
> + } else if (netif_running(port->dev) &&
> +netif_carrier_ok(port->dev)) {
> netif_carrier_off(port->dev);
> if (delayed_work_pending(caching_dw))
> cancel_delayed_work(caching_dw);
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
>
> On 01/02/2021 23:13, Ville Syrjälä wrote:
> > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> >> From: Hans Verkuil
> >>
> >> For adapters behind an MST hub use the correct AUX channel.
> >>
> >> Signed-off-by: Hans Verkuil
> >> [sa...@chromium.org: rebased, removing redundant changes]
> >> Signed-off-by: Sam McNally
> >> ---
> >>
> >> (no changes since v1)
> >>
> >> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> >> 1 file changed, 36 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> index 15b6cc39a754..0d753201adbd 100644
> >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> >> drm_dp_mst_topology_mgr *mgr,
> >> drm_dp_mst_topology_put_port(port);
> >> }
> >>
> >> +static ssize_t
> >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> >> *msg);
> >> +
> >> static struct drm_dp_mst_port *
> >> drm_dp_mst_add_port(struct drm_device *dev,
> >> struct drm_dp_mst_topology_mgr *mgr,
> >> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> >> port->port_num = port_number;
> >> port->mgr = mgr;
> >> port->aux.name = "DPMST";
> >> +mutex_init(>aux.hw_mutex);
> >> +mutex_init(>aux.cec.lock);
> >> port->aux.dev = dev->dev;
> >> port->aux.is_remote = true;
> >>
> >> +port->aux.transfer = drm_dp_mst_aux_transfer;
> >> +
> >
> > This was supposed to be handled via higher levels checking for
> > is_remote==true.
>
> Ah, I suspect this patch can be dropped entirely: it predates commit
> 2f221a5efed4
> ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
>
> It looks like that commit basically solved what this older patch attempts to
> do
> as well.
>
> Sam, can you test if it works without this patch?
It almost just works; drm_dp_cec uses whether aux.transfer is non-null
to filter out non-DP connectors. Using aux.is_remote as another signal
indicating a DP connector seems plausible. We can drop this patch.
Thanks all!
>
> Regards,
>
> Hans
>
> >
> >> /* initialize the MST downstream port's AUX crc work queue */
> >> drm_dp_remote_aux_init(>aux);
> >>
> >> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> >> drm_dp_mst_topology_mgr *mgr,
> >> return 0;
> >> }
> >>
> >> +static ssize_t
> >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> >> *msg)
> >> +{
> >> +struct drm_dp_mst_port *port =
> >> +container_of(aux, struct drm_dp_mst_port, aux);
> >> +int ret;
> >> +
> >> +switch (msg->request & ~DP_AUX_I2C_MOT) {
> >> +case DP_AUX_NATIVE_WRITE:
> >> +case DP_AUX_I2C_WRITE:
> >> +case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> >> +ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> >> + msg->size, msg->buffer);
> >
> > That doesn't make sense to me. I2c writes and DPCD writes
> > are definitely not the same thing.
> >
> > aux->transfer is a very low level thing. I don't think it's the
> > correct level of abstraction for sideband.
> >
> >> +break;
> >> +
> >> +case DP_AUX_NATIVE_READ:
> >> +case DP_AUX_I2C_READ:
> >> +ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> >> +msg->size, msg->buffer);
> >> +break;
> >> +
> >> +default:
> >> +ret = -EINVAL;
> >> +break;
> >> +}
> >> +
> >> +return ret;
> >> +}
> >> +
> >> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> >> {
> >> if (dp_link_bw == 0 || dp_link_count == 0)
> >> --
> >> 2.28.0.681.g6f77f65b4e-goog
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-de...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote: > From: Serhiy Boiko > > The following features are supported: > > - LAG basic operations > - create/delete LAG > - add/remove a member to LAG > - enable/disable member in LAG > - LAG Bridge support > - LAG VLAN support > - LAG FDB support > > Limitations: > > - Only HASH lag tx type is supported > - The Hash parameters are not configurable. They are applied > during the LAG creation stage. > - Enslaving a port to the LAG device that already has an > upper device is not supported. Tobias, Vladimir, you worked on LAG support recently, would you mind taking a look at this one?
Re: [PATCH] mm: cma: support sysfs
On Thu, Feb 04, 2021 at 06:52:01PM -0800, John Hubbard wrote: > On 2/4/21 5:44 PM, Minchan Kim wrote: > > On Thu, Feb 04, 2021 at 04:24:20PM -0800, John Hubbard wrote: > > > On 2/4/21 4:12 PM, Minchan Kim wrote: > > > ... > > > > > > Then, how to know how often CMA API failed? > > > > > > > > > > Why would you even need to know that, *in addition* to knowing > > > > > specific > > > > > page allocation numbers that failed? Again, there is no real-world > > > > > motivation > > > > > cited yet, just "this is good data". Need more stories and support > > > > > here. > > > > > > > > Let me give an example. > > > > > > > > Let' assume we use memory buffer allocation via CMA for bluetooth > > > > enable of device. > > > > If user clicks the bluetooth button in the phone but fail to allocate > > > > the memory from CMA, user will still see bluetooth button gray. > > > > User would think his touch was not enough powerful so he try clicking > > > > again and fortunately CMA allocation was successful this time and > > > > they will see bluetooh button enabled and could listen the music. > > > > > > > > Here, product team needs to monitor how often CMA alloc failed so > > > > if the failure ratio is steadily increased than the bar, > > > > it means engineers need to go investigation. > > > > > > > > Make sense? > > > > > > > > > > Yes, except that it raises more questions: > > > > > > 1) Isn't this just standard allocation failure? Don't you already have a > > > way > > > to track that? > > > > > > Presumably, having the source code, you can easily deduce that a bluetooth > > > allocation failure goes directly to a CMA allocation failure, right? > > Still wondering about this... It would work if we have full source code and stack are not complicated for every usecases. Having said, having a good central place automatically popped up is also beneficial for not to add similar statistics for each call sites. Why do we have too many item in slab sysfs instead of creating each call site inventing on each own? > > > > > > > Anyway, even though the above is still a little murky, I expect you're > > > right > > > that it's good to have *some* indication, somewhere about CMA behavior... > > > > > > Thinking about this some more, I wonder if this is really /proc/vmstat > > > sort > > > of data that we're talking about. It seems to fit right in there, yes? > > > > Thing is CMA instance are multiple, cma-A, cma-B, cma-C and each of CMA > > heap has own specific scenario. /proc/vmstat could be bloated a lot > > while CMA instance will be increased. > > > > Yes, that would not fit in /proc/vmstat...assuming that you really require > knowing--at this point--which CMA heap is involved. And that's worth poking > at. If you get an overall indication in vmstat that CMA is having trouble, > then maybe that's all you need to start digging further. I agree it could save to decide whether I should go digging further but anyway, I need to go though each of instance once it happens. In that, what I need is per-CMA statistics, not global. I am happy to implement it but I'd like to say it's not my case. > > It's actually easier to monitor one or two simpler items than it is to monitor > a larger number of complicated items. And I get the impression that this is > sort of a top-level, production software indicator. Let me clarify one more time. What I'd like to get ultimately is per-CMA statistics instead of global vmstat for the usecase at this moment. Global vmstat could help the decision whether I should go deeper but it ends up needing per-CMA statistics. And I'd like to keep them in sysfs, not debugfs since it should be stable as a telemetric. What points do you disagree in this view?
[PATCH v2 3/3] fs/efs: Fix line breakage for C keywords
Some statements - such as if statements - are not broken into their
lines correctly. For example, some are expressed on a single line.
Single line if statements are expressely prohibited by the style guide.
This patch corrects these violations.
Signed-off-by: Amy Parker
---
fs/efs/inode.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/fs/efs/inode.c b/fs/efs/inode.c
index 2cc55d514421..0099e6ad529a 100644
--- a/fs/efs/inode.c
+++ b/fs/efs/inode.c
@@ -193,7 +193,8 @@ efs_extent_check(efs_extent *ptr, efs_block_t block, struct
efs_sb_info *sb) {
if ((block >= offset) && (block < offset+length)) {
return(sb->fs_start + start + block - offset);
- } else {
+ }
+ else {
return 0;
}
}
@@ -264,7 +265,8 @@ efs_block_t efs_map_block(struct inode *inode, efs_block_t
block) {
/* should never happen */
pr_err("couldn't find direct extent for indirect extent
%d (block %u)\n",
cur, block);
- if (bh) brelse(bh);
+ if (bh)
+ brelse(bh);
return 0;
}
@@ -276,7 +278,8 @@ efs_block_t efs_map_block(struct inode *inode, efs_block_t
block) {
(EFS_BLOCKSIZE / sizeof(efs_extent));
if (first || lastblock != iblock) {
- if (bh) brelse(bh);
+ if (bh)
+ brelse(bh);
bh = sb_bread(inode->i_sb, iblock);
if (!bh) {
@@ -297,17 +300,20 @@ efs_block_t efs_map_block(struct inode *inode,
efs_block_t block) {
if (ext.cooked.ex_magic != 0) {
pr_err("extent %d has bad magic number in block %d\n",
cur, iblock);
- if (bh) brelse(bh);
+ if (bh)
+ brelse(bh);
return 0;
}
if ((result = efs_extent_check(, block, sb))) {
- if (bh) brelse(bh);
+ if (bh)
+ brelse(bh);
in->lastextent = cur;
return result;
}
}
- if (bh) brelse(bh);
+ if (bh)
+ brelse(bh);
pr_err("%s() failed to map block %u (indir)\n", __func__, block);
return 0;
}
--
2.29.2
[PATCH v2 0/3] fs/efs: Follow kernel style guide
As the EFS driver is old and non-maintained, many kernel style guide rules have not been followed, and their violations have not been noticed. This patchset corrects those violations. v2: - Corrected commit message line breaking v1: - Fixed brace styling - Corrected C keyword spacing - Corrected line breakage for C keywords Amy Parker (3): fs/efs: Use correct brace styling for statements fs/efs: Correct spacing after C keywords fs/efs: Fix line breakage for C keywords fs/efs/inode.c | 36 ++-- fs/efs/namei.c | 2 +- fs/efs/super.c | 25 +++-- 3 files changed, 34 insertions(+), 29 deletions(-) -- 2.29.2
Re: [PATCH 1/3] fs/efs: Use correct brace styling for statements
On Thu, Feb 4, 2021 at 9:09 PM Chaitanya Kulkarni wrote: > > On 2/4/21 21:01, Amy Parker wrote: > >> Commit message is too long. Follow the style present in the tree. > > Are you referring to the per-line length? That was supposed to have > > been broken up, my apologies. Or is it the overall length that is the > > issue? > > > >-Amy IP > > > Per line length. I think it should be < 73. Alright. Working on it, expect the v2 patchset soon - sorry about that! -Amy IP
[PATCH v2 2/3] fs/efs: Correct spacing after C keywords
In EFS code, some C keywords (most commonly 'for') do not have spaces
before their instructions, such as for() vs for (). The kernel style
guide indicates that these should be of the latter variant. This patch
updates them accordingly.
Signed-off-by: Amy Parker
---
fs/efs/inode.c | 8
fs/efs/namei.c | 2 +-
fs/efs/super.c | 10 +-
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/efs/inode.c b/fs/efs/inode.c
index 36d6c45046e2..2cc55d514421 100644
--- a/fs/efs/inode.c
+++ b/fs/efs/inode.c
@@ -130,7 +130,7 @@ struct inode *efs_iget(struct super_block *super, unsigned
long ino)
in->lastextent = 0;
/* copy the extents contained within the inode to memory */
- for(i = 0; i < EFS_DIRECTEXTENTS; i++) {
+ for (i = 0; i < EFS_DIRECTEXTENTS; i++) {
extent_copy(&(efs_inode->di_u.di_extents[i]),
&(in->extents[i]));
if (i < in->numextents && in->extents[i].cooked.ex_magic != 0) {
pr_warn("extent %d has bad magic number in inode %lu\n",
@@ -227,7 +227,7 @@ efs_block_t efs_map_block(struct inode *inode, efs_block_t
block) {
* check the stored extents in the inode
* start with next extent and check forwards
*/
- for(dirext = 1; dirext < direxts; dirext++) {
+ for (dirext = 1; dirext < direxts; dirext++) {
cur = (last + dirext) % in->numextents;
if ((result = efs_extent_check(>extents[cur],
block, sb))) {
in->lastextent = cur;
@@ -244,7 +244,7 @@ efs_block_t efs_map_block(struct inode *inode, efs_block_t
block) {
direxts = in->extents[0].cooked.ex_offset;
indexts = in->numextents;
- for(indext = 0; indext < indexts; indext++) {
+ for (indext = 0; indext < indexts; indext++) {
cur = (last + indext) % indexts;
/*
@@ -255,7 +255,7 @@ efs_block_t efs_map_block(struct inode *inode, efs_block_t
block) {
*
*/
ibase = 0;
- for(dirext = 0; cur < ibase && dirext < direxts; dirext++) {
+ for (dirext = 0; cur < ibase && dirext < direxts; dirext++) {
ibase += in->extents[dirext].cooked.ex_length *
(EFS_BLOCKSIZE / sizeof(efs_extent));
}
diff --git a/fs/efs/namei.c b/fs/efs/namei.c
index 38961ee1d1af..65d9c7f4d0c0 100644
--- a/fs/efs/namei.c
+++ b/fs/efs/namei.c
@@ -28,7 +28,7 @@ static efs_ino_t efs_find_entry(struct inode *inode, const
char *name, int len)
pr_warn("%s(): directory size not a multiple of EFS_DIRBSIZE\n",
__func__);
- for(block = 0; block < inode->i_blocks; block++) {
+ for (block = 0; block < inode->i_blocks; block++) {
bh = sb_bread(inode->i_sb, efs_bmap(inode, block));
if (!bh) {
diff --git a/fs/efs/super.c b/fs/efs/super.c
index 874d82096b2f..dd97a071f971 100644
--- a/fs/efs/super.c
+++ b/fs/efs/super.c
@@ -169,7 +169,7 @@ static efs_block_t efs_validate_vh(struct volume_header
*vh) {
return 0;
ui = ((__be32 *) (vh + 1)) - 1;
- for(csum = 0; ui >= ((__be32 *) vh);) {
+ for (csum = 0; ui >= ((__be32 *) vh);) {
cs = *ui--;
csum += be32_to_cpu(cs);
}
@@ -181,11 +181,11 @@ static efs_block_t efs_validate_vh(struct volume_header
*vh) {
#ifdef DEBUG
pr_debug("bf: \"%16s\"\n", vh->vh_bootfile);
- for(i = 0; i < NVDIR; i++) {
+ for (i = 0; i < NVDIR; i++) {
int j;
charname[VDNAMESIZE+1];
- for(j = 0; j < VDNAMESIZE; j++) {
+ for (j = 0; j < VDNAMESIZE; j++) {
name[j] = vh->vh_vd[i].vd_name[j];
}
name[j] = (char) 0;
@@ -198,9 +198,9 @@ static efs_block_t efs_validate_vh(struct volume_header
*vh) {
}
#endif
- for(i = 0; i < NPARTAB; i++) {
+ for (i = 0; i < NPARTAB; i++) {
pt_type = (int) be32_to_cpu(vh->vh_pt[i].pt_type);
- for(pt_entry = sgi_pt_types; pt_entry->pt_name; pt_entry++) {
+ for (pt_entry = sgi_pt_types; pt_entry->pt_name; pt_entry++) {
if (pt_type == pt_entry->pt_type) break;
}
#ifdef DEBUG
--
2.29.2
[PATCH v2 1/3] fs/efs: Use correct brace styling for statements
Many single-line statements have unnecessary braces, and some statement
pairs have mismatched braces. This is a clear violation of the kernel
style guide, which mandates that single line statements have no braces
and that pairs with at least one multi-line block maintain their braces.
This patch fixes these style violations. Single-line statements that
have braces have had their braces stripped. Pair single-line statements
have been formatted per the style guide. Pair mixed-line statements have
had their braces updated to conform.
Signed-off-by: Amy Parker
---
fs/efs/inode.c | 10 ++
fs/efs/super.c | 15 ++-
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/fs/efs/inode.c b/fs/efs/inode.c
index 89e73a6f0d36..36d6c45046e2 100644
--- a/fs/efs/inode.c
+++ b/fs/efs/inode.c
@@ -107,11 +107,11 @@ struct inode *efs_iget(struct super_block *super,
unsigned long ino)
inode->i_atime.tv_nsec = inode->i_mtime.tv_nsec =
inode->i_ctime.tv_nsec = 0;
/* this is the number of blocks in the file */
- if (inode->i_size == 0) {
+ if (inode->i_size == 0)
inode->i_blocks = 0;
- } else {
+ else
inode->i_blocks = ((inode->i_size - 1) >> EFS_BLOCKSIZE_BITS) +
1;
- }
+
rdev = be16_to_cpu(efs_inode->di_u.di_dev.odev);
if (rdev == 0x) {
@@ -120,8 +120,10 @@ struct inode *efs_iget(struct super_block *super, unsigned
long ino)
device = 0;
else
device = MKDEV(sysv_major(rdev), sysv_minor(rdev));
- } else
+ }
+ else {
device = old_decode_dev(rdev);
+ }
/* get the number of extents for this object */
in->numextents = be16_to_cpu(efs_inode->di_numextents);
diff --git a/fs/efs/super.c b/fs/efs/super.c
index 62b155b9366b..874d82096b2f 100644
--- a/fs/efs/super.c
+++ b/fs/efs/super.c
@@ -160,14 +160,13 @@ static efs_block_t efs_validate_vh(struct volume_header
*vh) {
struct pt_types *pt_entry;
int pt_type, slice = -1;
- if (be32_to_cpu(vh->vh_magic) != VHMAGIC) {
+ if (be32_to_cpu(vh->vh_magic) != VHMAGIC)
/*
* assume that we're dealing with a partition and allow
* read_super() to try and detect a valid superblock
* on the next block.
*/
return 0;
- }
ui = ((__be32 *) (vh + 1)) - 1;
for(csum = 0; ui >= ((__be32 *) vh);) {
@@ -191,11 +190,11 @@ static efs_block_t efs_validate_vh(struct volume_header
*vh) {
}
name[j] = (char) 0;
- if (name[0]) {
+ if (name[0])
pr_debug("vh: %8s block: 0x%08x size: 0x%08x\n",
name, (int) be32_to_cpu(vh->vh_vd[i].vd_lbn),
(int) be32_to_cpu(vh->vh_vd[i].vd_nbytes));
- }
+
}
#endif
@@ -219,15 +218,14 @@ static efs_block_t efs_validate_vh(struct volume_header
*vh) {
}
}
- if (slice == -1) {
+ if (slice == -1)
pr_notice("partition table contained no EFS partitions\n");
#ifdef DEBUG
- } else {
+ else
pr_info("using slice %d (type %s, offset 0x%x)\n", slice,
(pt_entry->pt_name) ? pt_entry->pt_name : "unknown",
sblock);
#endif
- }
return sblock;
}
@@ -284,9 +282,8 @@ static int efs_fill_super(struct super_block *s, void *d,
int silent)
sb->fs_start = efs_validate_vh((struct volume_header *) bh->b_data);
brelse(bh);
- if (sb->fs_start == -1) {
+ if (sb->fs_start == -1)
return -EINVAL;
- }
bh = sb_bread(s, sb->fs_start + EFS_SUPER);
if (!bh) {
--
2.29.2
Re: [PATCH v2 4/4] hugetlb: Do early cow when page pinned on src mm
On 2/4/21 5:43 PM, Peter Xu wrote:
> On Thu, Feb 04, 2021 at 03:25:37PM -0800, Mike Kravetz wrote:
>> On 2/4/21 6:50 AM, Peter Xu wrote:
>>> This is the last missing piece of the COW-during-fork effort when there're
>>> pinned pages found. One can reference 70e806e4e645 ("mm: Do early cow for
>>> pinned pages during fork() for ptes", 2020-09-27) for more information,
>>> since
>>> we do similar things here rather than pte this time, but just for hugetlb.
>>>
>>> Signed-off-by: Peter Xu
>>> ---
>>> mm/hugetlb.c | 61 +++-
>>> 1 file changed, 56 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>> index 9e6ea96bf33b..5793936e00ef 100644
>>> --- a/mm/hugetlb.c
>>> +++ b/mm/hugetlb.c
>>> + __SetPageUptodate(new_page);
>>> + ClearPagePrivate(new_page);
>>> + set_page_huge_active(new_page);
>>
>> Code to replace the above ClearPagePrivate and set_page_huge_active is
>> in Andrew's tree. With changes in Andrew's tree, this would be:
>>
>> ClearHPageRestoreReserve(new_page);
>> SetHPageMigratable(new_page);
>
> Indeed these names are much better than using the default ones. At the
> meantime I'll rebase to linux-next/akpm. Sorry it's always not easy for me to
> find the right branch...
No worries. I only know because I recently changed these.
...
>>> @@ -3787,7 +3803,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst,
>>> struct mm_struct *src,
>>> dst_entry = huge_ptep_get(dst_pte);
>>> if ((dst_pte == src_pte) || !huge_pte_none(dst_entry))
>>> continue;
>>> -
>>> +again:
>>> dst_ptl = huge_pte_lock(h, dst, dst_pte);
>>> src_ptl = huge_pte_lockptr(h, src, src_pte);
>>> spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
>
> Side question: Mike, do you know why we need this lock_nested()? Could the
> src
> lock be taken due to any reason already? It confused me when I read the
> chunk.
I see that it was added with commit 4647875819aa. That was when huge pages
used the single per-mm ptl. Lockdep seemed to complain about taking
>page_table_lock twice. Certainly, source and destination mm can not
be the same. Right? I do not have the full history, but it 'looks' like
lockdep might have been confused and this was added to keep it quiet.
BTW - Copy page range for 'normal' pages has the same spin_lock_nested().
--
Mike Kravetz
