* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Alex Williamson @ 2018-07-24 1:57 UTC (permalink / raw)
To: Sinan Kaya; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <abc86e6b-7df5-a84c-7e98-107c605812c6@kernel.org>
On Mon, 23 Jul 2018 17:40:02 -0700
Sinan Kaya <okaya@kernel.org> wrote:
> On 7/23/2018 5:13 PM, Alex Williamson wrote:
> > + * The NVMe specification requires that controllers support PCIe FLR, but
> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
> > + * config space) unless the device is quiesced prior to FLR.
>
> Does disabling the memory bit in PCI config space as part of the FLR
> reset function help? (like the very first thing)
No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
call pcie_flr(), the Samsung controller dies just as it did previously.
> Can we do that in the pcie_flr() function to cover other endpoint types
> that might be pushing traffic while code is trying to do a reset?
Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY? I tried
that too, it doesn't work either. I'm not really sure the theory
behind clearing memory, clearing busmaster to stop DMA seems like a
sane thing to do, but doesn't help here. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Stephen Hemminger @ 2018-07-24 0:53 UTC (permalink / raw)
To: Caleb Raitto; +Cc: mst, jasowang, davem, netdev, Caleb Raitto
In-Reply-To: <20180723231119.142904-1-caleb.raitto@gmail.com>
On Mon, 23 Jul 2018 16:11:19 -0700
Caleb Raitto <caleb.raitto@gmail.com> wrote:
> From: Caleb Raitto <caraitto@google.com>
>
> The driver disables tx napi if it's not certain that completions will
> be processed affine with tx service.
>
> Its heuristic doesn't account for some scenarios where it is, such as
> when the queue pair count matches the core but not hyperthread count.
>
> Allow userspace to override the heuristic. This is an alternative
> solution to that in the linked patch. That added more logic in the
> kernel for these cases, but the agreement was that this was better left
> to user control.
>
> Do not expand the existing napi_tx variable to a ternary value,
> because doing so can break user applications that expect
> boolean ('Y'/'N') instead of integer output. Add a new param instead.
>
> Link: https://patchwork.ozlabs.org/patch/725249/
> Acked-by: Willem de Bruijn <willemb@google.com>
> Acked-by: Jon Olson <jonolson@google.com>
> Signed-off-by: Caleb Raitto <caraitto@google.com>
> ---
Not a fan of this.
Module parameters are frowned on by the distributions because they
never get well tested and they force the user to do magic things
to enable features. It looks like you are using it to paper
over a bug in this case.
^ permalink raw reply
* Re: [PATCH 2/2 v2] Add support for CPCAP regulators on Tegra devices.
From: Peter Geis @ 2018-07-24 1:57 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: broonie, lgirdwood, robh+dt, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <4588004.Gnq6nbUl2V@dimapc>
On 07/23/2018 08:27 PM, Dmitry Osipenko wrote:
> On Monday, 23 July 2018 22:38:48 MSK Peter Geis wrote:
>> Added support for the CPCAP power management regulator functions on
>> Tegra devices.
>> Added sw2_sw4 value tables, which provide power to the Tegra core and
>> aux devices.
>> Added the Tegra init tables and device tree compatibility match.
>>
>> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
>> ---
>> .../bindings/regulator/cpcap-regulator.txt | 1 +
>> drivers/regulator/cpcap-regulator.c | 80 +++++++++++++++++++
>> 2 files changed, 81 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
>> b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt index
>> 675f4437ce92..3e2d33ab1731 100644
>> --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
>> +++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
>> @@ -4,6 +4,7 @@ Motorola CPCAP PMIC voltage regulators
>> Requires node properties:
>> - "compatible" value one of:
>> "motorola,cpcap-regulator"
>> + "motorola,tegra-cpcap-regulator"
>> "motorola,mapphone-cpcap-regulator"
>>
>> Required regulator properties:
>> diff --git a/drivers/regulator/cpcap-regulator.c
>> b/drivers/regulator/cpcap-regulator.c index c0b1e04bd90f..cb3774be445d
>> 100644
>> --- a/drivers/regulator/cpcap-regulator.c
>> +++ b/drivers/regulator/cpcap-regulator.c
>> @@ -412,6 +412,82 @@ static struct cpcap_regulator omap4_regulators[] = {
>> { /* sentinel */ },
>> };
>>
>> +static struct cpcap_regulator tegra_regulators[] = {
>> + CPCAP_REG(SW1, CPCAP_REG_S1C1, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_SW1_SEL, unknown_val_tbl,
>> + 0, 0, 0, 0, 0, 0),
>> + CPCAP_REG(SW2, CPCAP_REG_S2C1, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_SW2_SEL, sw2_sw4_val_tbl,
>> + 0xf00, 0x7f, 0, 0x800, 0, 120),
>> + CPCAP_REG(SW3, CPCAP_REG_S3C, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_SW3_SEL, unknown_val_tbl,
>> + 0, 0, 0, 0, 0, 0),
>> + CPCAP_REG(SW4, CPCAP_REG_S4C1, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_SW4_SEL, sw2_sw4_val_tbl,
>> + 0xf00, 0x7f, 0, 0x900, 0, 100),
>> + CPCAP_REG(SW5, CPCAP_REG_S5C, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_SW5_SEL, sw5_val_tbl,
>> + 0x2a, 0, 0, 0x22, 0, 0),
>> + CPCAP_REG(SW6, CPCAP_REG_S6C, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_SW6_SEL, unknown_val_tbl,
>> + 0, 0, 0, 0, 0, 0),
>> + CPCAP_REG(VCAM, CPCAP_REG_VCAMC, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_VCAM_SEL, vcam_val_tbl,
>> + 0x87, 0x30, 4, 0x7, 0, 420),
>> + CPCAP_REG(VCSI, CPCAP_REG_VCSIC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VCSI_SEL, vcsi_val_tbl,
>> + 0x47, 0x10, 4, 0x7, 0, 350),
>> + CPCAP_REG(VDAC, CPCAP_REG_VDACC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VDAC_SEL, vdac_val_tbl,
>> + 0x87, 0x30, 4, 0x3, 0, 420),
>> + CPCAP_REG(VDIG, CPCAP_REG_VDIGC, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_VDIG_SEL, vdig_val_tbl,
>> + 0x87, 0x30, 4, 0x5, 0, 420),
>> + CPCAP_REG(VFUSE, CPCAP_REG_VFUSEC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VFUSE_SEL, vfuse_val_tbl,
>> + 0x80, 0xf, 0, 0x80, 0, 420),
>> + CPCAP_REG(VHVIO, CPCAP_REG_VHVIOC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VHVIO_SEL, vhvio_val_tbl,
>> + 0x17, 0, 0, 0x2, 0, 0),
>> + CPCAP_REG(VSDIO, CPCAP_REG_VSDIOC, CPCAP_REG_ASSIGN2,
>> + CPCAP_BIT_VSDIO_SEL, vsdio_val_tbl,
>> + 0x87, 0x38, 3, 0x2, 0, 420),
>> + CPCAP_REG(VPLL, CPCAP_REG_VPLLC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VPLL_SEL, vpll_val_tbl,
>> + 0x43, 0x18, 3, 0x1, 0, 420),
>> + CPCAP_REG(VRF1, CPCAP_REG_VRF1C, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VRF1_SEL, vrf1_val_tbl,
>> + 0xac, 0x2, 1, 0xc, 0, 10),
>> + CPCAP_REG(VRF2, CPCAP_REG_VRF2C, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VRF2_SEL, vrf2_val_tbl,
>> + 0x23, 0x8, 3, 0x3, 0, 10),
>> + CPCAP_REG(VRFREF, CPCAP_REG_VRFREFC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VRFREF_SEL, vrfref_val_tbl,
>> + 0x23, 0x8, 3, 0x3, 0, 420),
>> + CPCAP_REG(VWLAN1, CPCAP_REG_VWLAN1C, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VWLAN1_SEL, vwlan1_val_tbl,
>> + 0x47, 0x10, 4, 0x5, 0, 420),
>> + CPCAP_REG(VWLAN2, CPCAP_REG_VWLAN2C, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VWLAN2_SEL, vwlan2_val_tbl,
>> + 0x20c, 0xc0, 6, 0x8, 0, 420),
>> + CPCAP_REG(VSIM, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
>> + 0xffff, vsim_val_tbl,
>> + 0x23, 0x8, 3, 0x3, 0, 420),
>> + CPCAP_REG(VSIMCARD, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
>> + 0xffff, vsimcard_val_tbl,
>> + 0x1e80, 0x8, 3, 0x1e00, 0, 420),
>> + CPCAP_REG(VVIB, CPCAP_REG_VVIBC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VVIB_SEL, vvib_val_tbl,
>> + 0x1, 0xc, 2, 0, 0x1, 500),
>> + CPCAP_REG(VUSB, CPCAP_REG_VUSBC, CPCAP_REG_ASSIGN3,
>> + CPCAP_BIT_VUSB_SEL, vusb_val_tbl,
>> + 0x11c, 0x40, 6, 0xc, 0, 0),
>> + CPCAP_REG(VAUDIO, CPCAP_REG_VAUDIOC, CPCAP_REG_ASSIGN4,
>> + CPCAP_BIT_VAUDIO_SEL, vaudio_val_tbl,
>> + 0x16, 0x1, 0, 0x4, 0, 0),
>> + { /* sentinel */ },
>> +};
>> +
>> static const struct of_device_id cpcap_regulator_id_table[] = {
>> {
>> .compatible = "motorola,cpcap-regulator",
>> @@ -420,6 +496,10 @@ static const struct of_device_id
>> cpcap_regulator_id_table[] = { .compatible =
>> "motorola,mapphone-cpcap-regulator",
>> .data = omap4_regulators,
>> },
>> + {
>> + .compatible = "motorola,tegra-cpcap-regulator",
>> + .data = tegra_regulators,
>> + },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, cpcap_regulator_id_table);
>
> Are those cpcap_regulator values really common for all Tegra's? Probably
> better to name the DT compatible like "motorola,xoom-cpcap-regulator" or
> "motorola,mz602-cpcap-regulator".
>
> The DT binding documentation should be updated with the new compatible value
> in the Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
>
I see your point, from my research the only other device that ever
paired a Tegra with a cpcap was the Atrix 4g, and it has completely
different values.
For now I will change the value to "motorola,xoom-cpcap-regulator",
since these values are common across the entire Xoom line.
The DT binding documentation was updated as part of this patch, it will
be adjusted to the new value.
^ permalink raw reply
* [U-Boot] [PATCH 13/17] fs: fat: support mkdir
From: AKASHI Takahiro @ 2018-07-24 2:01 UTC (permalink / raw)
To: u-boot
In-Reply-To: <58f7f25d-33ec-bd3f-3a03-6dca27a39be9@gmx.de>
On Fri, Jul 20, 2018 at 07:14:21PM +0200, Heinrich Schuchardt wrote:
> On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> > In this patch, mkdir support is added to FAT file system.
> > A newly created directory contains only "." and ".." entries.
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>
> The patch does set the creation date of the directory according to the
> real time clock but to 1980-01-01T00:00:00Z.
>
> $ ls /mnt/dir1/ -la --full-time
> drwxr-xr-x 2 root root 2048 1980-01-01 01:00:00.000000000 +0100 dir3
>
> Please, set the time correctly if the real time clock is available.
Good point, but I'd like to put this issue into future TODO list
as it will end up introducing a new API, such as gettimeofday()?
(and this is not a FAT-specific issue.)
Thanks,
-Takahiro AKASHI
> Best regards
>
> Heinrich
>
> > ---
> > fs/fat/fat_write.c | 138 +++++++++++++++++++++++++++++++++++++++++++++
> > fs/fs.c | 3 +-
> > include/fat.h | 1 +
> > 3 files changed, 141 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> > index cc45a33876..781883c9f4 100644
> > --- a/fs/fat/fat_write.c
> > +++ b/fs/fat/fat_write.c
> > @@ -1185,3 +1185,141 @@ int file_fat_write(const char *filename, void *buffer, loff_t offset,
> > {
> > return file_fat_write_at(filename, offset, buffer, maxsize, actwrite);
> > }
> > +
> > +int fat_mkdir(const char *new_dirname)
> > +{
> > + dir_entry *retdent;
> > + fsdata datablock = { .fatbuf = NULL, };
> > + fsdata *mydata = &datablock;
> > + fat_itr *itr = NULL;
> > + char *dirname_copy, *parent, *dirname;
> > + char l_dirname[VFAT_MAXLEN_BYTES];
> > + int ret = -1;
> > + loff_t actwrite;
> > + unsigned int bytesperclust;
> > + dir_entry *dotdent = NULL;
> > +
> > + dirname_copy = strdup(new_dirname);
> > + if (!dirname_copy)
> > + goto exit;
> > +
> > + split_filename(dirname_copy, &parent, &dirname);
> > + if (!strlen(dirname)) {
> > + ret = -EINVAL;
> > + goto exit;
> > + }
> > +
> > + if (normalize_longname(l_dirname, dirname)) {
> > + printf("FAT: illegal filename (%s)\n", dirname);
> > + ret = -EINVAL;
> > + goto exit;
> > + }
> > +
> > + itr = malloc_cache_aligned(sizeof(fat_itr));
> > + if (!itr) {
> > + ret = -ENOMEM;
> > + goto exit;
> > + }
> > +
> > + ret = fat_itr_root(itr, &datablock);
> > + if (ret)
> > + goto exit;
> > +
> > + total_sector = datablock.bs_total_sect;
> > + if (total_sector == 0)
> > + total_sector = (int)cur_part_info.size; /* cast of lbaint_t */
> > +
> > + ret = fat_itr_resolve(itr, parent, TYPE_DIR);
> > + if (ret) {
> > + printf("%s: doesn't exist (%d)\n", parent, ret);
> > + goto exit;
> > + }
> > +
> > + retdent = find_directory_entry(itr, l_dirname);
> > +
> > + if (retdent) {
> > + printf("%s: already exists\n", l_dirname);
> > + ret = -EEXIST;
> > + goto exit;
> > + } else {
> > + if (itr->is_root) {
> > + /* root dir cannot have "." or ".." */
> > + if (!strcmp(l_dirname, ".") ||
> > + !strcmp(l_dirname, "..")) {
> > + ret = -EINVAL;
> > + goto exit;
> > + }
> > + }
> > +
> > + if (!itr->dent) {
> > + printf("Error: allocating new dir entry\n");
> > + ret = -EIO;
> > + goto exit;
> > + }
> > +
> > + memset(itr->dent, 0, sizeof(*itr->dent));
> > +
> > + /* Set short name to set alias checksum field in dir_slot */
> > + set_name(itr->dent, dirname);
> > + fill_dir_slot(itr, dirname);
> > +
> > + /* Set attribute as archieve for regular file */
> > + fill_dentry(itr->fsdata, itr->dent, dirname, 0, 0,
> > + ATTR_DIR | ATTR_ARCH);
> > +
> > + retdent = itr->dent;
> > + }
> > +
> > + /* Default entries */
> > + bytesperclust = mydata->clust_size * mydata->sect_size;
> > + dotdent = malloc_cache_aligned(bytesperclust);
> > + if (!dotdent) {
> > + ret = -ENOMEM;
> > + goto exit;
> > + }
> > + memset(dotdent, 0, bytesperclust);
> > +
> > + memcpy(dotdent[0].name, ". ", 8);
> > + memcpy(dotdent[0].ext, " ", 3);
> > + dotdent[0].attr = ATTR_DIR | ATTR_ARCH;
> > +
> > + memcpy(dotdent[1].name, ".. ", 8);
> > + memcpy(dotdent[1].ext, " ", 3);
> > + dotdent[1].attr = ATTR_DIR | ATTR_ARCH;
> > + set_start_cluster(mydata, &dotdent[1], itr->start_clust);
> > +
> > + ret = set_contents(mydata, retdent, 0, (__u8 *)dotdent, bytesperclust,
> > + &actwrite);
> > + if (ret < 0) {
> > + printf("Error: writing contents\n");
> > + goto exit;
> > + }
> > + /* Write twice for "." */
> > + set_start_cluster(mydata, &dotdent[0], START(retdent));
> > + ret = set_contents(mydata, retdent, 0, (__u8 *)dotdent, bytesperclust,
> > + &actwrite);
> > + if (ret < 0) {
> > + printf("Error: writing contents\n");
> > + goto exit;
> > + }
> > +
> > + /* Flush fat buffer */
> > + ret = flush_dirty_fat_buffer(mydata);
> > + if (ret) {
> > + printf("Error: flush fat buffer\n");
> > + goto exit;
> > + }
> > +
> > + /* Write directory table to device */
> > + ret = set_cluster(mydata, itr->clust, itr->block,
> > + mydata->clust_size * mydata->sect_size);
> > + if (ret)
> > + printf("Error: writing directory entry\n");
> > +
> > +exit:
> > + free(dirname_copy);
> > + free(mydata->fatbuf);
> > + free(itr);
> > + free(dotdent);
> > + return ret;
> > +}
> > diff --git a/fs/fs.c b/fs/fs.c
> > index 3cb6b21fe9..a92e060296 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -164,14 +164,15 @@ static struct fstype_info fstypes[] = {
> > .read = fat_read_file,
> > #ifdef CONFIG_FAT_WRITE
> > .write = file_fat_write,
> > + .mkdir = fat_mkdir,
> > #else
> > .write = fs_write_unsupported,
> > + .mkdir = fs_mkdir_unsupported,
> > #endif
> > .uuid = fs_uuid_unsupported,
> > .opendir = fat_opendir,
> > .readdir = fat_readdir,
> > .closedir = fat_closedir,
> > - .mkdir = fs_mkdir_unsupported,
> > },
> > #endif
> > #ifdef CONFIG_FS_EXT4
> > diff --git a/include/fat.h b/include/fat.h
> > index 295da0f243..039b6e03de 100644
> > --- a/include/fat.h
> > +++ b/include/fat.h
> > @@ -237,5 +237,6 @@ int fat_read_file(const char *filename, void *buf, loff_t offset, loff_t len,
> > int fat_opendir(const char *filename, struct fs_dir_stream **dirsp);
> > int fat_readdir(struct fs_dir_stream *dirs, struct fs_dirent **dentp);
> > void fat_closedir(struct fs_dir_stream *dirs);
> > +int fat_mkdir(const char *dirname);
> > void fat_close(void);
> > #endif /* _FAT_H_ */
> >
>
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register
From: Zhongmiao @ 2018-07-24 2:04 UTC (permalink / raw)
To: Jean-Philippe Brucker, Zhangshaokun,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Leizhen (ThunderTown)
Cc: Will Deacon
Hi ,
>"Note: In terms of delivering events, a queue in an unacknowledged overflow state does not behave any differently to normal queue state. If software were to consume events and free space but leave overflow unacknowledged, new events could be recorded."
Yeah, I agree with you . But I test priq , It's going to be a problem. And See the PRI queue overflow section of the SMMUv3 specification (IHI0070A):
" Note: On detection of overflow, ARM recommends that software processes the received PRI queue entries as quickly as possible, and follows this with a single write of SMMU_PRIQ_CONS to simultaneously move on the RD pointer and acknowledge receipt of the overflow condition by setting OVACKFLG to the value read from OVFLG."
Thanks,
Miao
^ permalink raw reply
* [PATCH v6 4/5] ARM: dts: imx7s: add i.MX7 messaging unit support
From: A.s. Dong @ 2018-07-24 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532365033.3163.107.camel@pengutronix.de>
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Tuesday, July 24, 2018 12:57 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel at lists.infradead.org;
> kernel at pengutronix.de; devicetree at vger.kernel.org
> Subject: Re: [PATCH v6 4/5] ARM: dts: imx7s: add i.MX7 messaging unit
> support
>
> Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> > Define the Messaging Unit (MU) for i.MX7 in the processor's dtsi.
> > The respective driver is added in the next commit.
> >
> > > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > ?arch/arm/boot/dts/imx7s.dtsi | 19 +++++++++++++++++++
> > ?1 file changed, 19 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > b/arch/arm/boot/dts/imx7s.dtsi index ce85b3ca1a55..191a0286fa3b 100644
> > --- a/arch/arm/boot/dts/imx7s.dtsi
> > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > @@ -1001,6 +1001,25 @@
> > > ? status = "disabled";
> > > ? };
> >
> > > > + mu0a: mailbox at 30aa0000 {
> > + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
>
> Those compatibles are missing documentation in the binding.
>
Sorry for the overlooking.
They seem to be got missed during a updated binding doc review.
Oleksij,
Would you add them back and resend the patch series?
Regards
Dong Aisheng
> > + reg = <0x30aa0000 0x10000>;
> > > + interrupts = <GIC_SPI 88
> IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > > + #mbox-cells = <1>;
> > > + status = "disabled";
> > > + };
> > +
> > > > + mu0b: mailbox at 30ab0000 {
> > > + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
> > > + reg = <0x30ab0000 0x10000>;
> > > + interrupts = <GIC_SPI 97
> IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > > + #mbox-cells = <1>;
> > > + fsl,mu-side-b;
> > > + status = "disabled";
> > > + };
> > +
> > > > ? usbotg1: usb at 30b10000 {
> > > ? compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > > ? reg = <0x30b10000 0x200>;
^ permalink raw reply
* RE: [PATCH v6 4/5] ARM: dts: imx7s: add i.MX7 messaging unit support
From: A.s. Dong @ 2018-07-24 2:04 UTC (permalink / raw)
To: Lucas Stach, Oleksij Rempel, Shawn Guo, Fabio Estevam,
Rob Herring, Mark Rutland, Vladimir Zapolskiy
Cc: kernel@pengutronix.de, devicetree@vger.kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1532365033.3163.107.camel@pengutronix.de>
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: Tuesday, July 24, 2018 12:57 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel@lists.infradead.org;
> kernel@pengutronix.de; devicetree@vger.kernel.org
> Subject: Re: [PATCH v6 4/5] ARM: dts: imx7s: add i.MX7 messaging unit
> support
>
> Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> > Define the Messaging Unit (MU) for i.MX7 in the processor's dtsi.
> > The respective driver is added in the next commit.
> >
> > > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > arch/arm/boot/dts/imx7s.dtsi | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > b/arch/arm/boot/dts/imx7s.dtsi index ce85b3ca1a55..191a0286fa3b 100644
> > --- a/arch/arm/boot/dts/imx7s.dtsi
> > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > @@ -1001,6 +1001,25 @@
> > > status = "disabled";
> > > };
> >
> > > > + mu0a: mailbox@30aa0000 {
> > + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
>
> Those compatibles are missing documentation in the binding.
>
Sorry for the overlooking.
They seem to be got missed during a updated binding doc review.
Oleksij,
Would you add them back and resend the patch series?
Regards
Dong Aisheng
> > + reg = <0x30aa0000 0x10000>;
> > > + interrupts = <GIC_SPI 88
> IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > > + #mbox-cells = <1>;
> > > + status = "disabled";
> > > + };
> > +
> > > > + mu0b: mailbox@30ab0000 {
> > > + compatible = "fsl,imx7s-mu", "fsl,imx6sx-mu";
> > > + reg = <0x30ab0000 0x10000>;
> > > + interrupts = <GIC_SPI 97
> IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> > > + #mbox-cells = <1>;
> > > + fsl,mu-side-b;
> > > + status = "disabled";
> > > + };
> > +
> > > > usbotg1: usb@30b10000 {
> > > compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > > reg = <0x30b10000 0x200>;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] tpm: add support for partial reads
From: Jason Gunthorpe @ 2018-07-24 2:05 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <ee0f0ccf-f757-a7d4-bf55-316f81fb490b@intel.com>
On Mon, Jul 23, 2018 at 04:42:38PM -0700, Tadeusz Struk wrote:
> On 07/23/2018 03:08 PM, Jason Gunthorpe wrote:
> > On Mon, Jul 23, 2018 at 03:00:20PM -0700, Tadeusz Struk wrote:
> >> On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
> >>> The proposed patch doesn't clear the data_pending if the entire buffer
> >>> is not consumed, so of course it is ABI breaking, that really isn't OK.
> >> The data_pending will be cleared by the timeout handler if the user doesn't
> >> read the response fully before the timeout expires. The is the same situation
> >> if the user would not read the response at all.
> > That causes write() to fail with EBUSY
> >
> > NAK from me on breaking the ABI like this
>
> What if we introduce this new behavior only for the non-blocking mode
> as James suggested? Or do you have some other suggestions?
I think you should do it entirely in userspace.
But something sensible linked to O_NONBLOCK could be OK.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Jakub Kicinski @ 2018-07-24 1:02 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-6-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> This allows NIC's XDP to redirect packets to veth. The destination veth
> device enqueues redirected packets to the napi ring of its peer, then
> they are processed by XDP on its peer veth device.
> This can be thought as calling another XDP program by XDP program using
> REDIRECT, when the peer enables driver XDP.
>
> Note that when the peer veth device does not set driver xdp, redirected
> packets will be dropped because the peer is not ready for NAPI.
Often we can't redirect to devices which don't have am xdp program
installed. In your case we can't redirect unless the peer of the
target doesn't have a program installed? :(
Perhaps it is time to reconsider what Saeed once asked for, a flag or
attribute to enable being the destination of a XDP_REDIRECT.
> v2:
> - Drop the part converting xdp_frame into skb when XDP is not enabled.
> - Implement bulk interface of ndo_xdp_xmit.
> - Implement XDP_XMIT_FLUSH bit and drop ndo_xdp_flush.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
> drivers/net/veth.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 4be75c58bc6a..57187e955fea 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -17,6 +17,7 @@
> #include <net/rtnetlink.h>
> #include <net/dst.h>
> #include <net/xfrm.h>
> +#include <net/xdp.h>
> #include <linux/veth.h>
> #include <linux/module.h>
> #include <linux/bpf.h>
> @@ -125,6 +126,11 @@ static void *veth_ptr_to_xdp(void *ptr)
> return (void *)((unsigned long)ptr & ~VETH_XDP_FLAG);
> }
>
> +static void *veth_xdp_to_ptr(void *ptr)
> +{
> + return (void *)((unsigned long)ptr | VETH_XDP_FLAG);
> +}
> +
> static void veth_ptr_free(void *ptr)
> {
> if (veth_is_xdp_frame(ptr))
> @@ -267,6 +273,44 @@ static struct sk_buff *veth_build_skb(void *head, int headroom, int len,
> return skb;
> }
>
> +static int veth_xdp_xmit(struct net_device *dev, int n,
> + struct xdp_frame **frames, u32 flags)
> +{
> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
> + struct net_device *rcv;
> + int i, drops = 0;
> +
> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
> + return -EINVAL;
> +
> + rcv = rcu_dereference(priv->peer);
> + if (unlikely(!rcv))
> + return -ENXIO;
> +
> + rcv_priv = netdev_priv(rcv);
> + /* xdp_ring is initialized on receive side? */
> + if (!rcu_access_pointer(rcv_priv->xdp_prog))
> + return -ENXIO;
> +
> + spin_lock(&rcv_priv->xdp_ring.producer_lock);
> + for (i = 0; i < n; i++) {
> + struct xdp_frame *frame = frames[i];
> + void *ptr = veth_xdp_to_ptr(frame);
> +
> + if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
> + __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
Would you mind sparing a few more words how this is safe vs the
.ndo_close() on the peer? Personally I'm a bit uncomfortable with the
IFF_UP check in xdp_ok_fwd_dev(), I'm not sure what's supposed to
guarantee the device doesn't go down right after that check, or is
already down, but netdev->flags are not atomic...
> + xdp_return_frame_rx_napi(frame);
> + drops++;
> + }
> + }
> + spin_unlock(&rcv_priv->xdp_ring.producer_lock);
> +
> + if (flags & XDP_XMIT_FLUSH)
> + __veth_xdp_flush(rcv_priv);
> +
> + return n - drops;
> +}
> +
> static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
> struct xdp_frame *frame)
> {
> @@ -760,6 +804,7 @@ static const struct net_device_ops veth_netdev_ops = {
> .ndo_features_check = passthru_features_check,
> .ndo_set_rx_headroom = veth_set_rx_headroom,
> .ndo_bpf = veth_xdp,
> + .ndo_xdp_xmit = veth_xdp_xmit,
> };
>
> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
^ permalink raw reply
* Re: [RFC PATCH 01/10] iommu/vt-d: Get iommu device for a mediated device
From: Lu Baolu @ 2018-07-24 2:06 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kumar, Sanjay K,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sun, Yi Y,
Pan, Jacob jun
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA141D-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi Yi,
Thank you for reviewing my patch.
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> Hi Baolu,
>
> Per my understanding, the subject is not accurate. I think this patch is
> to get parent device structure for a mediate device instead of iommu
> device. This may be misleading for reviewers.
Please check below.
>
> Thanks,
> Yi Liu
>
>> From: Lu Baolu [mailto:baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> This patch adds the support to get the iommu device for a mediated device. The
>> assumption is that each mediated device is a minimal assignable set of a physical PCI
>> device. Hence, we should use the iommu device of the parent PCI device to manage
>> the translation.
>>
>> Cc: Ashok Raj <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Kevin Tian <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Liu Yi L <yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> ---
>> drivers/iommu/intel-iommu.c | 6 ++++++ drivers/iommu/intel-pasid.h | 16
>> ++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> 7d198ea..fc3ac1c 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -767,6 +767,12 @@ static struct intel_iommu *device_to_iommu(struct device
>> *dev, u8 *bus, u8 *devf
>> if (iommu_dummy(dev))
>> return NULL;
>>
>> + if (dev_is_mdev(dev)) {
>> + dev = dev_mdev_parent(dev);
>> + if (WARN_ON(!dev_is_pci(dev)))
>> + return NULL;
>> + }
>> +
This gets the parent of a mediated device. And an iommu device will be
found which services the parent device. A mediated device should in the
same iommu scope as its parent.
Best regards,
Lu Baolu
>> if (dev_is_pci(dev)) {
>> struct pci_dev *pf_pdev;
>>
>> diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h index
>> 518df72..46cde66 100644
>> --- a/drivers/iommu/intel-pasid.h
>> +++ b/drivers/iommu/intel-pasid.h
>> @@ -35,6 +35,22 @@ struct pasid_table {
>> struct list_head dev; /* device list */
>> };
>>
>> +static inline bool dev_is_mdev(struct device *dev) {
>> + if (!dev)
>> + return false;
>> +
>> + return !strcmp(dev->bus->name, "mdev"); }
>> +
>> +static inline struct device *dev_mdev_parent(struct device *dev) {
>> + if (WARN_ON(!dev_is_mdev(dev)))
>> + return NULL;
>> +
>> + return dev->parent;
>> +}
>> +
>> extern u32 intel_pasid_max_id;
>> int intel_pasid_alloc_id(void *ptr, int start, int end, gfp_t gfp); void
>> intel_pasid_free_id(int pasid);
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 01/10] iommu/vt-d: Get iommu device for a mediated device
From: Lu Baolu @ 2018-07-24 2:06 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, Kumar, Sanjay K, Pan, Jacob jun, Tian, Kevin,
Sun, Yi Y, peterx@redhat.com, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jacob Pan
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA141D@SHSMSX104.ccr.corp.intel.com>
Hi Yi,
Thank you for reviewing my patch.
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> Hi Baolu,
>
> Per my understanding, the subject is not accurate. I think this patch is
> to get parent device structure for a mediate device instead of iommu
> device. This may be misleading for reviewers.
Please check below.
>
> Thanks,
> Yi Liu
>
>> From: Lu Baolu [mailto:baolu.lu@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> This patch adds the support to get the iommu device for a mediated device. The
>> assumption is that each mediated device is a minimal assignable set of a physical PCI
>> device. Hence, we should use the iommu device of the parent PCI device to manage
>> the translation.
>>
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> drivers/iommu/intel-iommu.c | 6 ++++++ drivers/iommu/intel-pasid.h | 16
>> ++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> 7d198ea..fc3ac1c 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -767,6 +767,12 @@ static struct intel_iommu *device_to_iommu(struct device
>> *dev, u8 *bus, u8 *devf
>> if (iommu_dummy(dev))
>> return NULL;
>>
>> + if (dev_is_mdev(dev)) {
>> + dev = dev_mdev_parent(dev);
>> + if (WARN_ON(!dev_is_pci(dev)))
>> + return NULL;
>> + }
>> +
This gets the parent of a mediated device. And an iommu device will be
found which services the parent device. A mediated device should in the
same iommu scope as its parent.
Best regards,
Lu Baolu
>> if (dev_is_pci(dev)) {
>> struct pci_dev *pf_pdev;
>>
>> diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h index
>> 518df72..46cde66 100644
>> --- a/drivers/iommu/intel-pasid.h
>> +++ b/drivers/iommu/intel-pasid.h
>> @@ -35,6 +35,22 @@ struct pasid_table {
>> struct list_head dev; /* device list */
>> };
>>
>> +static inline bool dev_is_mdev(struct device *dev) {
>> + if (!dev)
>> + return false;
>> +
>> + return !strcmp(dev->bus->name, "mdev"); }
>> +
>> +static inline struct device *dev_mdev_parent(struct device *dev) {
>> + if (WARN_ON(!dev_is_mdev(dev)))
>> + return NULL;
>> +
>> + return dev->parent;
>> +}
>> +
>> extern u32 intel_pasid_max_id;
>> int intel_pasid_alloc_id(void *ptr, int start, int end, gfp_t gfp); void
>> intel_pasid_free_id(int pasid);
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: To remove packages from busybox
From: Andre McCurdy @ 2018-07-24 2:06 UTC (permalink / raw)
To: Simon Chamlian; +Cc: Yocto discussion list
In-Reply-To: <CANmTPBZ7neRETjpdKtC+2MpPuhtKegeQQEPY_1=SSDJzmUbWBA@mail.gmail.com>
On Mon, Jul 23, 2018 at 1:29 PM, Simon Chamlian <simon.chamlian@mpbc.ca> wrote:
> Hi,
>
> In order to remove package from busybox, I used:
>
> $ bitbake -c menuconfig busybox
>
> Under 'System Logging Itilities -->' I unchecked syslogd
>
> Then ran
> $ bitbake busybox
>
> and I get the following error:
>
> WARNING: busybox-1.24.1-r0 do_package: busybox: alternative target
> (/etc/syslog.conf or /etc/syslog.conf.busybox) does not exist, skipping...
> WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative
> provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist
>
> ERROR: busybox-1.24.1-r0 do_package: SYSTEMD_SERVICE_busybox-syslog value
> busybox-syslog.service does not exist
>
>
> ERROR: busybox-1.24.1-r0 do_package: Function failed:
> systemd_populate_packages
>
>
> ERROR: Logfile of failure stored in:
> /opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.30881
>
> ERROR: Task
> (/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_package)
> failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 711 tasks of which 705 didn't need to be
> rerun and 1 failed.
>
> What am I doing wrong?
The "correct" way to disable syslog support in busybox would probably
be to create a .bbappend which contains:
SRC_URI_remove = "file://syslog.conf"
ie you would remove the config fragment which enables syslog from SRC_URI.
However, customising busybox like that gets almost no testing, so
there could certainly still be bugs.
^ permalink raw reply
* [U-Boot] [PATCH 14/17] cmd: fat: add fatmkdir command
From: AKASHI Takahiro @ 2018-07-24 2:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <fc8bb142-bc61-f814-c5ee-e0967b06dc47@gmx.de>
On Fri, Jul 20, 2018 at 07:09:17PM +0200, Heinrich Schuchardt wrote:
> On 07/20/2018 04:57 AM, AKASHI Takahiro wrote:
> > In this patch, a new command, fatmkdir, is added.
> >
> > Please note that, as there is no notion of "current directory" on u-boot,
> > a directory name specified must contains an absolute directory path as
> > a parent directory. Otherwise, "/" (root directory) is assumed.
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
>
> Please, provide a Python test with an additional patch.
Please see my reply to Simon's/Tom's comments.
> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Thanks a lot for your review.
-Takahiro AKASHI
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532366380.3163.109.camel@pengutronix.de>
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Tuesday, July 24, 2018 1:20 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel at lists.infradead.org;
> kernel at pengutronix.de; devicetree at vger.kernel.org
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
[...]
> > +}
> > +
> > +static int imx_mu_send_data(struct mbox_chan *chan, void *data) {
> > > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > > + struct imx_mu_con_priv *cp = chan->con_priv;
> > > + u32 *arg = data;
> > +
> > > + if (!imx_mu_last_tx_done(chan))
> > > + return -EBUSY;
> > +
> > > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
>
> In multi-channel mode this RMW cycle needs some kind of locking. As this
> register is also changed from the irq handler, this probably needs to be a
> irqsave spinlock.
>
Good catch!
They do need to be protected.
Regards
Dong Aisheng
^ permalink raw reply
* RE: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:09 UTC (permalink / raw)
To: Lucas Stach, Oleksij Rempel, Shawn Guo, Fabio Estevam,
Rob Herring, Mark Rutland, Vladimir Zapolskiy
Cc: kernel@pengutronix.de, devicetree@vger.kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1532366380.3163.109.camel@pengutronix.de>
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: Tuesday, July 24, 2018 1:20 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel@lists.infradead.org;
> kernel@pengutronix.de; devicetree@vger.kernel.org
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
[...]
> > +}
> > +
> > +static int imx_mu_send_data(struct mbox_chan *chan, void *data) {
> > > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > > + struct imx_mu_con_priv *cp = chan->con_priv;
> > > + u32 *arg = data;
> > +
> > > + if (!imx_mu_last_tx_done(chan))
> > > + return -EBUSY;
> > +
> > > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
>
> In multi-channel mode this RMW cycle needs some kind of locking. As this
> register is also changed from the irq handler, this probably needs to be a
> irqsave spinlock.
>
Good catch!
They do need to be protected.
Regards
Dong Aisheng
^ permalink raw reply
* Re: [RFC PATCH 02/10] iommu/vt-d: Alloc domain for a mediated device
From: Lu Baolu @ 2018-07-24 2:09 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kumar, Sanjay K,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sun, Yi Y,
Pan, Jacob jun
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA1432-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> The PASID-granular 2nd level address translation makes it possible to isolate and
>> protect a mediated device exposed by a real device which support PCI PASID
> "support" -> "supports"
Sure.
>
>> features. This patch adds support to allocate a domain for a mediated device. A
>> default pasid value will be allocated as well for the mediated device. This will be used
> This is not accurate, it is "a default pasid value will be allocated for the domain, and the
> mdev will be configed to use this pasid when it is added to this domain"
Looks better. Thank you.
Best regards,
Lu Baolu
>
> Regards,
> Yi Liu
>
>> by the mediated device attached to this domain for non-SVM DMA transactions.
>>
>> Cc: Ashok Raj <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Kevin Tian <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Liu Yi L <yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> ---
>> drivers/iommu/intel-iommu.c | 17 ++++++++++++++++- include/linux/intel-iommu.h
>> | 5 +++++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> fc3ac1c..3ede34a 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -1926,6 +1926,9 @@ static void domain_exit(struct dmar_domain *domain)
>> domain_remove_dev_info(domain);
>> rcu_read_unlock();
>>
>> + if (domain->default_pasid > 0)
>> + intel_pasid_free_id(domain->default_pasid);
>> +
>> /* destroy iovas */
>> put_iova_domain(&domain->iovad);
>>
>> @@ -2519,11 +2522,23 @@ static struct dmar_domain
>> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>> }
>> }
>>
>> + if (dev && dev_is_mdev(dev) && domain->default_pasid <= 0) {
>> + int max = intel_pasid_get_dev_max_id(dev_mdev_parent(dev));
>> +
>> + domain->default_pasid = intel_pasid_alloc_id(domain, PASID_MIN,
>> + max, GFP_KERNEL);
>> + if (domain->default_pasid < 0) {
>> + free_devinfo_mem(info);
>> + return NULL;
>> + }
>> + }
>> +
>> spin_lock_irqsave(&device_domain_lock, flags);
>> if (dev)
>> found = find_domain(dev);
>>
>> - if (!found) {
>> + /* A mediated device never has an DMA alias. Ignore searching. */
>> + if (!found && !dev_is_mdev(dev)) {
>> struct device_domain_info *info2;
>> info2 = dmar_search_domain_by_dev_info(iommu->segment, bus,
>> devfn);
>> if (info2) {
>> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h index
>> 7efc632..9f5dcf6 100644
>> --- a/include/linux/intel-iommu.h
>> +++ b/include/linux/intel-iommu.h
>> @@ -423,6 +423,11 @@ struct dmar_domain {
>> 2 == 1GiB, 3 == 512GiB, 4 == 1TiB */
>> u64 max_addr; /* maximum mapped address */
>>
>> + int default_pasid; /*
>> + * The default pasid used for non-SVM
>> + * traffic on mediated devices.
>> + */
>> +
>> struct iommu_domain domain; /* generic domain data structure for
>> iommu core */
>> };
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 02/10] iommu/vt-d: Alloc domain for a mediated device
From: Lu Baolu @ 2018-07-24 2:09 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, Kumar, Sanjay K, Pan, Jacob jun, Tian, Kevin,
Sun, Yi Y, peterx@redhat.com, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jacob Pan
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA1432@SHSMSX104.ccr.corp.intel.com>
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> The PASID-granular 2nd level address translation makes it possible to isolate and
>> protect a mediated device exposed by a real device which support PCI PASID
> "support" -> "supports"
Sure.
>
>> features. This patch adds support to allocate a domain for a mediated device. A
>> default pasid value will be allocated as well for the mediated device. This will be used
> This is not accurate, it is "a default pasid value will be allocated for the domain, and the
> mdev will be configed to use this pasid when it is added to this domain"
Looks better. Thank you.
Best regards,
Lu Baolu
>
> Regards,
> Yi Liu
>
>> by the mediated device attached to this domain for non-SVM DMA transactions.
>>
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> drivers/iommu/intel-iommu.c | 17 ++++++++++++++++- include/linux/intel-iommu.h
>> | 5 +++++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> fc3ac1c..3ede34a 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -1926,6 +1926,9 @@ static void domain_exit(struct dmar_domain *domain)
>> domain_remove_dev_info(domain);
>> rcu_read_unlock();
>>
>> + if (domain->default_pasid > 0)
>> + intel_pasid_free_id(domain->default_pasid);
>> +
>> /* destroy iovas */
>> put_iova_domain(&domain->iovad);
>>
>> @@ -2519,11 +2522,23 @@ static struct dmar_domain
>> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>> }
>> }
>>
>> + if (dev && dev_is_mdev(dev) && domain->default_pasid <= 0) {
>> + int max = intel_pasid_get_dev_max_id(dev_mdev_parent(dev));
>> +
>> + domain->default_pasid = intel_pasid_alloc_id(domain, PASID_MIN,
>> + max, GFP_KERNEL);
>> + if (domain->default_pasid < 0) {
>> + free_devinfo_mem(info);
>> + return NULL;
>> + }
>> + }
>> +
>> spin_lock_irqsave(&device_domain_lock, flags);
>> if (dev)
>> found = find_domain(dev);
>>
>> - if (!found) {
>> + /* A mediated device never has an DMA alias. Ignore searching. */
>> + if (!found && !dev_is_mdev(dev)) {
>> struct device_domain_info *info2;
>> info2 = dmar_search_domain_by_dev_info(iommu->segment, bus,
>> devfn);
>> if (info2) {
>> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h index
>> 7efc632..9f5dcf6 100644
>> --- a/include/linux/intel-iommu.h
>> +++ b/include/linux/intel-iommu.h
>> @@ -423,6 +423,11 @@ struct dmar_domain {
>> 2 == 1GiB, 3 == 512GiB, 4 == 1TiB */
>> u64 max_addr; /* maximum mapped address */
>>
>> + int default_pasid; /*
>> + * The default pasid used for non-SVM
>> + * traffic on mediated devices.
>> + */
>> +
>> struct iommu_domain domain; /* generic domain data structure for
>> iommu core */
>> };
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 1/3] [BUGFIX] tracing: Fix double free of event_trigger_data
From: Steven Rostedt @ 2018-07-24 2:10 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Ingo Molnar, Shuah Khan, Tom Zanussi, Hiraku Toyooka,
linux-kernel, stable
In-Reply-To: <153149926702.11274.12489440326560729788.stgit@devbox>
On Sat, 14 Jul 2018 01:27:47 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Fix a double free bug of event_trigger_data caused by
> calling unregister_trigger() from register_snapshot_trigger().
> This kicks a kernel BUG if double free checker is enabled
> as below;
>
> kernel BUG at /home/mhiramat/ksrc/linux/mm/slub.c:296!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 2 PID: 4312 Comm: ftracetest Not tainted 4.18.0-rc1+ #44
> Hardware name: ASUS All Series/B85M-G, BIOS 2108 08/11/2014
> RIP: 0010:set_freepointer.part.37+0x0/0x10
> Code: 41 b8 01 00 00 00 29 c8 4d 8d 0c 0c b9 10 00 00 00 50 e8 e3 28 23 00 8b 53 08 5e 5f 89 d1 81 e1 00 04 00 00 e9 e9 fe ff ff 90 <0f> 0b 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 c6 90 7f 0d
> RSP: 0018:ffffa799caa3bd90 EFLAGS: 00010246
> RAX: ffff9b825f8c8e80 RBX: ffff9b825f8c8e80 RCX: ffff9b825f8c8e80
> RDX: 0000000000021562 RSI: ffff9b830e9e70e0 RDI: 0000000000000202
> RBP: 0000000000000246 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff9b830e0072c0
> R13: ffffeb8e0d7e3200 R14: ffffffff961db7af R15: 00000000fffffffe
> FS: 00007f135ba9f700(0000) GS:ffff9b830e800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000563736b5f3a2 CR3: 0000000295916005 CR4: 00000000001606e0
> Call Trace:
> kfree+0x35d/0x380
> event_trigger_callback+0x13f/0x1c0
> event_trigger_write+0xf2/0x1a0
> ? lock_acquire+0x9f/0x200
> __vfs_write+0x26/0x170
> ? rcu_read_lock_sched_held+0x6b/0x80
> ? rcu_sync_lockdep_assert+0x2e/0x60
> ? __sb_start_write+0x13e/0x1a0
> ? vfs_write+0x18a/0x1b0
> vfs_write+0xc1/0x1b0
> ksys_write+0x45/0xa0
> do_syscall_64+0x60/0x200
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> unregister_trigger() will free given event_trigger_data
> at last. But that event_trigger_data will be freed again
> in event_trigger_callback() if register_snapshot_trigger()
> is failed, and causes a double free bug.
>
> Registering the data should be the final operation in the
> register function on normal path, because the trigger
> must be ready for taking action right after it is
> registered.
Nice catch. I can reproduce this. But this patch is fixing the symptom
and not the disease.
>
> Fixes: commit 93e31ffbf417 ("tracing: Add 'snapshot' event trigger command")
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
> Cc: stable@vger.kernel.org
> ---
> kernel/trace/trace.c | 5 +++++
> kernel/trace/trace.h | 2 ++
> kernel/trace/trace_events_trigger.c | 10 ++++++----
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index f054bd6a1c66..2556d8c097d2 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -980,6 +980,11 @@ static void free_snapshot(struct trace_array *tr)
> tr->allocated_snapshot = false;
> }
>
> +void tracing_free_snapshot_instance(struct trace_array *tr)
> +{
> + free_snapshot(tr);
> +}
> +
> /**
> * tracing_alloc_snapshot - allocate snapshot buffer.
> *
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index f8f86231ad90..03468bb8a79a 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -1823,12 +1823,14 @@ static inline void trace_event_eval_update(struct trace_eval_map **map, int len)
> #ifdef CONFIG_TRACER_SNAPSHOT
> void tracing_snapshot_instance(struct trace_array *tr);
> int tracing_alloc_snapshot_instance(struct trace_array *tr);
> +void tracing_free_snapshot_instance(struct trace_array *tr);
> #else
> static inline void tracing_snapshot_instance(struct trace_array *tr) { }
> static inline int tracing_alloc_snapshot_instance(struct trace_array *tr)
> {
> return 0;
> }
> +static inline void tracing_free_snapshot_instance(struct trace_array *tr) { }
> #endif
>
> extern struct trace_iterator *tracepoint_print_iter;
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index d18249683682..40e2f4406b2c 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -1079,11 +1079,13 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops,
> struct event_trigger_data *data,
> struct trace_event_file *file)
> {
> - int ret = register_trigger(glob, ops, data, file);
> + int free_if_fail = !file->tr->allocated_snapshot;
> + int ret = 0;
>
> - if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) {
> - unregister_trigger(glob, ops, data, file);
> - ret = 0;
> + if (!tracing_alloc_snapshot_instance(file->tr)) {
> + ret = register_trigger(glob, ops, data, file);
> + if (ret == 0 && free_if_fail)
> + tracing_free_snapshot_instance(file->tr);
> }
>
> return ret;
Really, when we register_trigger() we should be able to freely call
unresgister_trigger() with no side effects like the above happens.
Instead of doing the above, I believe this is a better approach:
Thoughts?
P.S. This brings up another minor bug. The failure should return ENOMEM
not ENOENT.
-- Steve
diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index d18249683682..d15a746bcdfb 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -679,6 +679,7 @@ event_trigger_callback(struct event_command *cmd_ops,
goto out_free;
out_reg:
+ event_trigger_init(trigger_ops, trigger_data);
ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
/*
* The above returns on success the # of functions enabled,
@@ -687,9 +688,9 @@ event_trigger_callback(struct event_command *cmd_ops,
*/
if (!ret) {
ret = -ENOENT;
- goto out_free;
+ goto out_free_trigger;
} else if (ret < 0)
- goto out_free;
+ goto out_free_trigger;
ret = 0;
out:
return ret;
@@ -699,6 +700,10 @@ event_trigger_callback(struct event_command *cmd_ops,
cmd_ops->set_filter(NULL, trigger_data, NULL);
kfree(trigger_data);
goto out;
+
+ out_free_trigger:
+ event_trigger_free(trigger_ops, trigger_data);
+ goto out;
}
/**
^ permalink raw reply related
* Re: [PATCH 6/7] x86/vdso: Add vDSO functions for user wait instructions
From: Andy Lutomirski @ 2018-07-24 2:11 UTC (permalink / raw)
To: Fenghua Yu, Thomas Gleixner, Ingo Molnar, H Peter Anvin
Cc: Ashok Raj, Alan Cox, Ravi V Shankar, linux-kernel, x86
In-Reply-To: <1532350557-98388-7-git-send-email-fenghua.yu@intel.com>
On 07/23/2018 05:55 AM, Fenghua Yu wrote:
> User wants to query if user wait instructions (umonitor, umwait, and
> tpause) are supported and use the instructions. The vDSO functions
> provides fast interface for user to check the support and use the
> instructions.
>
> waitpkg_supported and its alias __vdso_waitpkg_supported check if
> user wait instructions (a.k.a. wait package feature) are supported
>
> umonitor and its alias __vdso_umonitor provide user APIs for calling
> umonitor instruction.
>
> umwait and its alias __vdso_umwait provide user APIs for calling
> umwait instruction.
>
> tpause and its alias __vdso_tpause provide user APIs for calling
> tpause instruction.
>
> nsec_to_tsc and its alias __vdso_nsec_to_tsc converts nanoseconds
> to TSC counter if TSC frequency is known. It will fail if TSC frequency
> is unknown.
>
> The instructions can be implemented in intrinsic functions in future
> GCC. But the vDSO interfaces are available to user without the
> intrinsic functions support in GCC and the API waitpkg_supported and
> nsec_to_tsc cannot be implemented as GCC functions.
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> ---
> arch/x86/entry/vdso/Makefile | 2 +-
> arch/x86/entry/vdso/vdso.lds.S | 10 ++
> arch/x86/entry/vdso/vma.c | 9 ++
> arch/x86/entry/vdso/vuserwait.c | 233 +++++++++++++++++++++++++++++++++
> arch/x86/include/asm/vdso_funcs_data.h | 3 +
> 5 files changed, 256 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/entry/vdso/vuserwait.c
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index af4fcae5de83..fb0062b09b3c 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -17,7 +17,7 @@ VDSO32-$(CONFIG_X86_32) := y
> VDSO32-$(CONFIG_IA32_EMULATION) := y
>
> # files to link into the vdso
> -vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vdirectstore.o
> +vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vdirectstore.o vuserwait.o
>
> # files to link into kernel
> obj-y += vma.o
> diff --git a/arch/x86/entry/vdso/vdso.lds.S b/arch/x86/entry/vdso/vdso.lds.S
> index 097cdcda43a5..0942710608bf 100644
> --- a/arch/x86/entry/vdso/vdso.lds.S
> +++ b/arch/x86/entry/vdso/vdso.lds.S
> @@ -35,6 +35,16 @@ VERSION {
> __vdso_movdir64b_supported;
> movdir64b;
> __vdso_movdir64b;
> + waitpkg_supported;
> + __vdso_waitpkg_supported;
> + umonitor;
> + __vdso_umonitor;
> + umwait;
> + __vdso_umwait;
> + tpause;
> + __vdso_tpause;
> + nsec_to_tsc;
> + __vdso_nsec_to_tsc;
> local: *;
> };
> }
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index edbe5e63e5c2..006dfb5e5003 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -372,10 +372,19 @@ static int vgetcpu_online(unsigned int cpu)
>
> static void __init init_vdso_funcs_data(void)
> {
> + struct system_counterval_t sys_counterval;
> +
> if (static_cpu_has(X86_FEATURE_MOVDIRI))
> vdso_funcs_data.movdiri_supported = true;
> if (static_cpu_has(X86_FEATURE_MOVDIR64B))
> vdso_funcs_data.movdir64b_supported = true;
> + if (static_cpu_has(X86_FEATURE_WAITPKG))
> + vdso_funcs_data.waitpkg_supported = true;
> + if (static_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ)) {
> + vdso_funcs_data.tsc_known_freq = true;
> + sys_counterval = convert_art_ns_to_tsc(1);
> + vdso_funcs_data.tsc_per_nsec = sys_counterval.cycles;
> + }
You're losing a ton of precision here. You might even be losing *all*
of the precision and malfunctioning rather badly.
The correct way to do this is:
tsc_counts = ns * mul >> shift;
and the vclock code illustrates it. convert_art_ns_to_tsc() is a bad
example because it uses an expensive division operation for no good
reason except that no one bothered to optimize it.
> +notrace int __vdso_nsec_to_tsc(unsigned long nsec, unsigned long *tsc)
> +{
> + if (!_vdso_funcs_data->tsc_known_freq)
> + return -ENODEV;
> +
> + *tsc = _vdso_funcs_data->tsc_per_nsec * nsec;
> +
> + return 0;
> +}
Please don't expose this one at all. It would be nice for programs that
use waitpkg to be migratable using CRIU-like tools, and this export
actively harms any such effort. If you omit this function, then the
kernel could learn to abort an in-progress __vdso_umwait if preempted
(rseq-style) and CRIU would just work. It would be a bit of a hack, but
it solves a real problem.
> +notrace int __vdso_umwait(int state, unsigned long nsec)
__vdso_umwait_relative(), please. Because some day (possibly soon)
someone will want __vdso_umwait_absolute() and its friend
__vdso_read_art_ns() so they can do:
u64 start = __vdso_read_art_ns();
__vdso_umonitor(...);
... do something potentially slow or that might fault ...
__vdso_umwait_absolute(start + timeout);
Also, this patch appears to have a subtle but show-stopping race. Consider:
1. Task A does UMONITOR on CPU 1
2. Task A is preempted.
3. Task B does UMONITOR on CPU 1 at a different address
4. Task A resumes
5. Task A does UMWAIT
Now task A hangs, at least until the next external wakeup happens.
It's not entirely clear to me how you're supposed to fix this without
some abomination that's so bad that it torpedoes the entire feature.
Except that there is no chicken bit to turn this thing off. Sigh.
^ permalink raw reply
* Re: [PATCH] fsck.f2fs: rebuild qf_ino if quota node is corrupted
From: Sheng Yong @ 2018-07-24 2:11 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: hyojun, linux-f2fs-devel, miaoxie
In-Reply-To: <20180723124921.GC19644@jaegeuk-macbookpro.roam.corp.google.com>
Hi, Jaegeuk
On 2018/7/23 20:49, Jaegeuk Kim wrote:
> On 07/23, Sheng Yong wrote:
>> If a quota node is corrupted, it may be removed. But its qf_ino in
>> super blocks is not cleared. To keep quota feature available, let's
>> try to rebuild a new quota node.
>
> Hi Sheng,
>
> IIRC, we need to rebuild whole quota structures, no?
>
I'm afraid not. Fsck records all dquot entries to a dict during checking all files.
If a quota file is removed or quota content is corrupted, quota_write_inode (in
fsck_chk_quota_files) will rebuild quota structures for us according to data recorded
in the dict. We only have to make sure the inode of a quota file is correct.
In the scenario where a quota file is removed, I think, rebuilding the inode of the
unreachable quota file is enough. Am I missing something?
thanks,
Sheng
> Thanks,
>
>>
>> Signed-off-by: Sheng Yong <shengyong1@huawei.com>
>> ---
>> fsck/fsck.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++---
>> fsck/fsck.h | 1 +
>> fsck/mount.c | 7 +++--
>> 3 files changed, 84 insertions(+), 6 deletions(-)
>>
>> diff --git a/fsck/fsck.c b/fsck/fsck.c
>> index e95dedf..dd10182 100644
>> --- a/fsck/fsck.c
>> +++ b/fsck/fsck.c
>> @@ -10,6 +10,7 @@
>> */
>> #include "fsck.h"
>> #include "quotaio.h"
>> +#include "quotaio_v2.h"
>> #include <time.h>
>>
>> char *tree_mark;
>> @@ -1697,13 +1698,80 @@ int fsck_chk_quota_node(struct f2fs_sb_info *sbi)
>> }
>> ret = fsck_chk_node_blk(sbi, NULL, ino,
>> F2FS_FT_REG_FILE, TYPE_INODE, &blk_cnt, NULL);
>> - if (ret)
>> - ASSERT_MSG("wrong quota inode, qtype [%d] ino [0x%x]",
>> - qtype, ino);
>> + if (ret) {
>> + /* sanity_check_nid failed, node should be removed */
>> + ASSERT_MSG("[0x%x] wrong quota inode", ino);
>> + if (c.fix_on)
>> + F2FS_FSCK(sbi)->corrupt_quotas = 1 << qtype;
>> + }
>> }
>> return ret;
>> }
>>
>> +static nid_t prepare_rebuild_qf_inode(struct f2fs_sb_info *sbi, int qtype)
>> +{
>> + struct f2fs_checkpoint *cp = F2FS_CKPT(sbi);
>> + struct f2fs_summary sum;
>> + struct f2fs_node *qf_node;
>> + nid_t nid = QUOTA_INO(F2FS_RAW_SUPER(sbi), qtype);
>> + block_t node_blkaddr;
>> + int ret;
>> +
>> + DBG(1, "Rebuild Quota file (qtype [%3d] ino [0x%x])\n", qtype, nid);
>> +
>> + qf_node = calloc(F2FS_BLKSIZE, 1);
>> + if (!qf_node) {
>> + MSG(0, "\tError: calloc failed for qf_inode!!!\n");
>> + return 0;
>> + }
>> +
>> + /* prepare qf_node */
>> + qf_node->footer.nid = cpu_to_le32(nid);
>> + qf_node->footer.ino = cpu_to_le32(nid);
>> + qf_node->footer.cp_ver = cpu_to_le64(get_cp(checkpoint_ver));
>> +
>> + qf_node->i.i_mode = cpu_to_le16(0x8180);
>> + qf_node->i.i_links = cpu_to_le32(1);
>> + qf_node->i.i_uid = cpu_to_le32(getuid());
>> + qf_node->i.i_gid = cpu_to_le32(getgid());
>> + qf_node->i.i_size = 0;
>> + qf_node->i.i_blocks = 1;
>> + qf_node->i.i_atime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_atime_nsec = 0;
>> + qf_node->i.i_ctime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_ctime_nsec = 0;
>> + qf_node->i.i_mtime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_mtime_nsec = 0;
>> + qf_node->i.i_generation = 0;
>> + qf_node->i.i_xattr_nid = 0;
>> + qf_node->i.i_flags = FS_IMMUTABLE_FL;
>> + qf_node->i.i_current_depth = cpu_to_le32(1);
>> + qf_node->i.i_dir_level = DEF_DIR_LEVEL;
>> + if (c.feature & cpu_to_le32(F2FS_FEATURE_EXTRA_ATTR)) {
>> + qf_node->i.i_inline = F2FS_EXTRA_ATTR;
>> + qf_node->i.i_extra_isize =
>> + cpu_to_le16(F2FS_TOTAL_EXTRA_ATTR_SIZE);
>> + }
>> + if (c.feature & cpu_to_le32(F2FS_FEATURE_INODE_CRTIME)) {
>> + qf_node->i.i_crtime = cpu_to_le32(time(NULL));
>> + qf_node->i.i_crtime_nsec = 0;
>> + }
>> +
>> + /* write back qf inode */
>> + node_blkaddr = 0;
>> + set_summary(&sum, nid, 0, 0);
>> + reserve_new_block(sbi, &node_blkaddr, &sum, CURSEG_HOT_NODE);
>> + update_nat_blkaddr(sbi, nid, nid, node_blkaddr);
>> + DBG(1, "Write new qf_node to blk %#x\n", node_blkaddr);
>> +
>> + ret = dev_write_block(qf_node, node_blkaddr);
Ah.. It should be write_inode instead of dev_write_block.
>> + ASSERT(ret >= 0);
>> + f2fs_clear_bit(nid, F2FS_FSCK(sbi)->nat_area_bitmap);
>> +
>> + free(qf_node);
>> + return nid;
>> +}
>> +
>> int fsck_chk_quota_files(struct f2fs_sb_info *sbi)
>> {
>> struct f2fs_fsck *fsck = F2FS_FSCK(sbi);
>> @@ -1722,6 +1790,12 @@ int fsck_chk_quota_files(struct f2fs_sb_info *sbi)
>> if (!ino)
>> continue;
>>
>> + if (fsck->corrupt_quotas & (1 << qtype) && c.fix_on) {
>> + ino = prepare_rebuild_qf_inode(sbi, qtype);
>> + if (!ino)
>> + continue;
>> + }
>> +
>> DBG(1, "Checking Quota file ([%3d] ino [0x%x])\n", qtype, ino);
>> needs_writeout = 0;
>> ret = quota_compare_and_update(sbi, qtype, &needs_writeout,
>> @@ -1733,7 +1807,7 @@ int fsck_chk_quota_files(struct f2fs_sb_info *sbi)
>>
>> /* Something is wrong */
>> if (c.fix_on) {
>> - DBG(0, "Fixing Quota file ([%3d] ino [0x%x])\n",
>> + FIX_MSG("Fixing Quota file ([%3d] ino [0x%x])\n",
>> qtype, ino);
>> f2fs_filesize_update(sbi, ino, 0);
>> ret = quota_write_inode(sbi, qtype);
>> diff --git a/fsck/fsck.h b/fsck/fsck.h
>> index 580e851..393c995 100644
>> --- a/fsck/fsck.h
>> +++ b/fsck/fsck.h
>> @@ -91,6 +91,7 @@ struct f2fs_fsck {
>> u32 nat_valid_inode_cnt;
>>
>> struct quota_ctx *qctx;
>> + unsigned short corrupt_quotas;
>> };
>>
>> #define BLOCK_SZ 4096
>> diff --git a/fsck/mount.c b/fsck/mount.c
>> index 3c9607f..121b26a 100644
>> --- a/fsck/mount.c
>> +++ b/fsck/mount.c
>> @@ -2022,8 +2022,11 @@ int find_next_free_block(struct f2fs_sb_info *sbi, u64 *to, int left, int type)
>> if (se2->valid_blocks)
>> break;
>> }
>> - if (i == sbi->segs_per_sec)
>> + if (i == sbi->segs_per_sec) {
>> + /* find a free seg, init its type */
>> + se->orig_type = type;
>> return 0;
>> + }
>> }
>>
>> if (se->type == type &&
>> @@ -2244,7 +2247,7 @@ void write_superblock(struct f2fs_super_block *new_sb)
>> ASSERT(ret >= 0);
>> }
>> free(buf);
>> - DBG(0, "Info: Done to rebuild superblock\n");
>> + MSG(0, "Info: Done to rebuild superblock\n");
>> }
>>
>> void build_nat_area_bitmap(struct f2fs_sb_info *sbi)
>> --
>> 2.17.1
>
> .
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* [PATCH] init/Kconfig: fix its typos
From: Randy Dunlap @ 2018-07-24 2:11 UTC (permalink / raw)
To: LKML, Andrew Morton, Masahiro Yamada, Thomas Gleixner,
Ingo Molnar
From: Randy Dunlap <rdunlap@infradead.org>
Correct typos of "it's" to "its.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
init/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20180723.orig/init/Kconfig
+++ linux-next-20180723/init/Kconfig
@@ -428,7 +428,7 @@ config BSD_PROCESS_ACCT_V3
help
If you say Y here, the process accounting information is written
in a new file format that also logs the process IDs of each
- process and it's parent. Note that this file format is incompatible
+ process and its parent. Note that this file format is incompatible
with previous v0/v1/v2 file formats, so you will need updated tools
for processing it. A preliminary version of these tools is available
at <http://www.gnu.org/software/acct/>.
@@ -1684,7 +1684,7 @@ config MMAP_ALLOW_UNINITIALIZED
default n
help
Normally, and according to the Linux spec, anonymous memory obtained
- from mmap() has it's contents cleared before it is passed to
+ from mmap() has its contents cleared before it is passed to
userspace. Enabling this config option allows you to request that
mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
providing a huge performance boost. If this option is not enabled,
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <846bb908-f75e-1988-8f30-e49a537c7969@mleia.com>
> -----Original Message-----
> From: Vladimir Zapolskiy [mailto:vz at mleia.com]
> Sent: Tuesday, July 24, 2018 7:31 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
> Hi Oleksij,
>
> On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
> > The Mailbox controller is able to send messages (up to 4 32 bit words)
> > between the endpoints.
> >
> > This driver was tested using the mailbox-test driver sending messages
> > between the Cortex-A7 and the Cortex-M4.
> >
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> [snip]
>
> > +static int imx_mu_startup(struct mbox_chan *chan) {
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> > +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL,
> "imx_mu_chan[%i]",
> > + cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> > +
>
> Again I would suggest to move this allocation to the loop in .probe function.
>
> [snip]
>
+1
Good point.
> > +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> > +
> > + cp->idx = i;
> > + cp->irq = irq;
>
> ^^^^ right over here.
>
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> > +
>
> please feel free to add my technical side review tag to the next version:
>
> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>
> FWIW I find that review comments from Lucas are pretty valid, I would
> recommend to incorporate them.
+1
Regards
Dong Aisheng
>
> --
> Best wishes,
> Vladimir
^ permalink raw reply
* RE: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: A.s. Dong @ 2018-07-24 2:13 UTC (permalink / raw)
To: Vladimir Zapolskiy, Oleksij Rempel, Shawn Guo, Fabio Estevam,
Rob Herring, Mark Rutland, Vladimir Zapolskiy
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
kernel@pengutronix.de, dl-linux-imx
In-Reply-To: <846bb908-f75e-1988-8f30-e49a537c7969@mleia.com>
> -----Original Message-----
> From: Vladimir Zapolskiy [mailto:vz@mleia.com]
> Sent: Tuesday, July 24, 2018 7:31 AM
> To: Oleksij Rempel <o.rempel@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; A.s.
> Dong <aisheng.dong@nxp.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Cc: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
>
> Hi Oleksij,
>
> On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
> > The Mailbox controller is able to send messages (up to 4 32 bit words)
> > between the endpoints.
> >
> > This driver was tested using the mailbox-test driver sending messages
> > between the Cortex-A7 and the Cortex-M4.
> >
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> [snip]
>
> > +static int imx_mu_startup(struct mbox_chan *chan) {
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> > +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL,
> "imx_mu_chan[%i]",
> > + cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> > +
>
> Again I would suggest to move this allocation to the loop in .probe function.
>
> [snip]
>
+1
Good point.
> > +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> > +
> > + cp->idx = i;
> > + cp->irq = irq;
>
> ^^^^ right over here.
>
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> > +
>
> please feel free to add my technical side review tag to the next version:
>
> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>
> FWIW I find that review comments from Lucas are pretty valid, I would
> recommend to incorporate them.
+1
Regards
Dong Aisheng
>
> --
> Best wishes,
> Vladimir
^ permalink raw reply
* [PATCH v6 0/5] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-07-24 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY1r=Sg64t3j45XXSJu-_HYx2Uya0WLDHP82stiQ4vnM5A@mail.gmail.com>
> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar at gmail.com]
> Sent: Monday, July 23, 2018 11:33 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>; kernel at pengutronix.de;
> linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; dl-linux-
> imx <linux-imx@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Fabio
> Estevam <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Subject: Re: [PATCH v6 0/5] add mailbox support for i.MX7D
>
> On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> > Hi Oleksij,
> >
> > Thanks for the work.
> >
> > Hi Jassi,
> > Do you think if we can have your tag and let those patches go through
> > Shawn's tree as the later QXP support patches depends on them?
> >
> Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
I guess you are missed to be CC'ed.
Oleksij,
As there're some new review comments and may need a small change,
please do not miss to CC Jassi (Mailbox Maintainer) in the next version
of your patch series.
Regards
Dong Aisheng
>
> Dong Aisheng (2):
> dt-bindings: mailbox: allow mbox-cells to be equal to 0
> dt-bindings: arm: fsl: add mu binding doc
>
> Oleksij Rempel (3):
> dt-bindings: mailbox: imx-mu: add generic MU channel support
> ARM: dts: imx7s: add i.MX7 messaging unit support
> mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
* RE: [PATCH v6 0/5] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-07-24 2:18 UTC (permalink / raw)
To: Jassi Brar, Oleksij Rempel
Cc: Mark Rutland, devicetree@vger.kernel.org, Vladimir Zapolskiy,
Rob Herring, dl-linux-imx, kernel@pengutronix.de, Fabio Estevam,
Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY1r=Sg64t3j45XXSJu-_HYx2Uya0WLDHP82stiQ4vnM5A@mail.gmail.com>
> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar@gmail.com]
> Sent: Monday, July 23, 2018 11:33 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>; kernel@pengutronix.de;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; dl-linux-
> imx <linux-imx@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Fabio
> Estevam <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Subject: Re: [PATCH v6 0/5] add mailbox support for i.MX7D
>
> On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> > Hi Oleksij,
> >
> > Thanks for the work.
> >
> > Hi Jassi,
> > Do you think if we can have your tag and let those patches go through
> > Shawn's tree as the later QXP support patches depends on them?
> >
> Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
I guess you are missed to be CC'ed.
Oleksij,
As there're some new review comments and may need a small change,
please do not miss to CC Jassi (Mailbox Maintainer) in the next version
of your patch series.
Regards
Dong Aisheng
>
> Dong Aisheng (2):
> dt-bindings: mailbox: allow mbox-cells to be equal to 0
> dt-bindings: arm: fsl: add mu binding doc
>
> Oleksij Rempel (3):
> dt-bindings: mailbox: imx-mu: add generic MU channel support
> ARM: dts: imx7s: add i.MX7 messaging unit support
> mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.