Re: [PATCH] drivers: platform: goldfish_sync: add a driver
Hi Roman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/rkir-google-com/drivers-platform-goldfish_sync-add-a-driver/20190105-123342
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> drivers/platform/goldfish/goldfish_sync.c:807:34: error: array type has
>> incomplete element type 'struct of_device_id'
static const struct of_device_id goldfish_sync_of_match[] = {
^~
>> drivers/platform/goldfish/goldfish_sync.c:808:4: error: field name not in
>> record or union initializer
{ .compatible = "google,goldfish-sync", },
^
drivers/platform/goldfish/goldfish_sync.c:808:4: note: (near initialization
for 'goldfish_sync_of_match')
>> drivers/platform/goldfish/goldfish_sync.c:813:36: error: array type has
>> incomplete element type 'struct acpi_device_id'
static const struct acpi_device_id goldfish_sync_acpi_match[] = {
^~~~
vim +807 drivers/platform/goldfish/goldfish_sync.c
806
> 807 static const struct of_device_id goldfish_sync_of_match[] = {
> 808 { .compatible = "google,goldfish-sync", },
809 {},
810 };
811 MODULE_DEVICE_TABLE(of, goldfish_sync_of_match);
812
> 813 static const struct acpi_device_id goldfish_sync_acpi_match[] = {
814 { "GFSH0006", 0 },
815 { },
816 };
817 MODULE_DEVICE_TABLE(acpi, goldfish_sync_acpi_match);
818
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH RFC lora-next 1/4] net: lora: sx125x sx1301: correct style warnings
Hi Andreas, On 29/12/2018 09:05, Andreas Färber wrote: Hi Ben, Am 19.12.18 um 16:56 schrieb Ben Whitten: Checkpatch highlights some style issues which need to be addressed. Signed-off-by: Ben Whitten --- drivers/net/lora/sx125x.c | 20 +-- drivers/net/lora/sx1301.c | 52 ++- drivers/net/lora/sx1301.h | 7 +++--- 3 files changed, 45 insertions(+), 34 deletions(-) Thanks for splitting this off from the functional changes. This will need some more explanations and discussion. In particular the comment changes look wrong to me. Also please don't butcher code just because checkpatch.pl may warn about line length at this early stage. Yeh they seemed odd but checkpatch doesn't like a /* on a line by its self it seems. A good catch in there was the unsigned casts, which are no longer necessary since the regmap conversion, so we should just squash that into the earlier commits. Note that I used to run checkpatch.pl as git commit hook: http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html But since some git update that started to break git rebase -i in case of false positives (with rebase stopping and on trying to continue commits unintentionally getting squashed), so I deactivated it again and don't manually check each commit I stage anymore, in favor of slowly completing implementations to a working point. Good to know, I'll avoid running it for the time and drop this from the v2 Thanks! Ben Whitten
[PATCH v2 3/3] scsi: ufs: Add HI3670 SoC UFS driver support
Add HI3670 SoC UFS driver support by extending the common ufs-hisi
driver. One major difference between HI3660 ad HI3670 SoCs interms of
UFS is the PHY. HI3670 has a 10nm variant PHY and hence this parameter is
used to distinguish the configuration.
Signed-off-by: Manivannan Sadhasivam
---
drivers/scsi/ufs/ufs-hisi.c | 127 +---
drivers/scsi/ufs/ufs-hisi.h | 4 ++
2 files changed, 109 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 452e19f8fb47..f2d3df357a97 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -66,7 +66,7 @@ static int ufs_hisi_check_hibern8(struct ufs_hba *hba)
return err;
}
-static void ufs_hi3660_clk_init(struct ufs_hba *hba)
+static void ufs_hisi_clk_init(struct ufs_hba *hba)
{
struct ufs_hisi_host *host = ufshcd_get_variant(hba);
@@ -80,7 +80,7 @@ static void ufs_hi3660_clk_init(struct ufs_hba *hba)
ufs_sys_ctrl_set_bits(host, BIT_SYSCTRL_REF_CLOCK_EN, PHY_CLK_CTRL);
}
-static void ufs_hi3660_soc_init(struct ufs_hba *hba)
+static void ufs_hisi_soc_init(struct ufs_hba *hba)
{
struct ufs_hisi_host *host = ufshcd_get_variant(hba);
u32 reg;
@@ -139,6 +139,7 @@ static void ufs_hi3660_soc_init(struct ufs_hba *hba)
static int ufs_hisi_link_startup_pre_change(struct ufs_hba *hba)
{
+ struct ufs_hisi_host *host = ufshcd_get_variant(hba);
int err;
uint32_t value;
uint32_t reg;
@@ -153,6 +154,14 @@ static int ufs_hisi_link_startup_pre_change(struct ufs_hba
*hba)
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8121, 0x0), 0x2D);
/* MPHY CBOVRCTRL3 */
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8122, 0x0), 0x1);
+
+ if (host->caps & UFS_HISI_CAP_PHY10nm) {
+ /* MPHY CBOVRCTRL4 */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8127, 0x0), 0x98);
+ /* MPHY CBOVRCTRL5 */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8128, 0x0), 0x1);
+ }
+
/* Unipro VS_MphyCfgUpdt */
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0xD085, 0x0), 0x1);
/* MPHY RXOVRCTRL4 rx0 */
@@ -173,10 +182,21 @@ static int ufs_hisi_link_startup_pre_change(struct
ufs_hba *hba)
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x8113, 0x0), 0x1);
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0xD085, 0x0), 0x1);
- /* Tactive RX */
- ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x4), 0x7);
- /* Tactive RX */
- ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x5), 0x7);
+ if (host->caps & UFS_HISI_CAP_PHY10nm) {
+ /* RX_Hibern8Time_Capability*/
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x0092, 0x4), 0xA);
+ /* RX_Hibern8Time_Capability*/
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x0092, 0x5), 0xA);
+ /* RX_Min_ActivateTime */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008f, 0x4), 0xA);
+ /* RX_Min_ActivateTime*/
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008f, 0x5), 0xA);
+ } else {
+ /* Tactive RX */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x4), 0x7);
+ /* Tactive RX */
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x008F, 0x5), 0x7);
+ }
/* Gear3 Synclength */
ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x0095, 0x4), 0x4F);
@@ -208,7 +228,8 @@ static int ufs_hisi_link_startup_pre_change(struct ufs_hba
*hba)
if (err)
dev_err(hba->dev, "ufs_hisi_check_hibern8 error\n");
- ufshcd_writel(hba, UFS_HCLKDIV_NORMAL_VALUE, UFS_REG_HCLKDIV);
+ if (!(host->caps & UFS_HISI_CAP_PHY10nm))
+ ufshcd_writel(hba, UFS_HCLKDIV_NORMAL_VALUE, UFS_REG_HCLKDIV);
/* disable auto H8 */
reg = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
@@ -253,7 +274,7 @@ static int ufs_hisi_link_startup_post_change(struct ufs_hba
*hba)
return 0;
}
-static int ufs_hi3660_link_startup_notify(struct ufs_hba *hba,
+static int ufs_hisi_link_startup_notify(struct ufs_hba *hba,
enum ufs_notify_change_status status)
{
int err = 0;
@@ -391,6 +412,28 @@ static void ufs_hisi_set_dev_cap(struct
ufs_hisi_dev_params *hisi_param)
static void ufs_hisi_pwr_change_pre_change(struct ufs_hba *hba)
{
+ struct ufs_hisi_host *host = ufshcd_get_variant(hba);
+
+ if (host->caps & UFS_HISI_CAP_PHY10nm) {
+ /*
+* Boston platform need to set SaveConfigTime to 0x13,
+* and change sync length to maximum value
+*/
+ /* VS_DebugSaveConfigTime */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0xD0A0), 0x13);
+ /* g1 sync length */
+ ufshcd_dme_set(hba, UIC_ARG_MIB((u32)0x1552), 0x4f);
+ /* g2 sync length */
+ ufshcd_dme_set(hba,
[PATCH v2 2/3] arm64: dts: hisilicon: hi3670: Add UFS controller support
Add UFS controller support for HiSilicon HI3670 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
index 6ccdf5040ffd..285219dd657f 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
@@ -654,6 +654,24 @@
clock-names = "apb_pclk";
};
+ /* UFS */
+ ufs: ufs@ff3c {
+ compatible = "hisilicon,hi3670-ufs", "jedec,ufs-2.1";
+ /* 0: HCI standard */
+ /* 1: UFS SYS CTRL */
+ reg = <0x0 0xff3c 0x0 0x1000>,
+ <0x0 0xff3e 0x0 0x1000>;
+ interrupt-parent = <>;
+ interrupts = ;
+ clocks = <_ctrl HI3670_CLK_GATE_UFSIO_REF>,
+ <_ctrl HI3670_CLK_GATE_UFS_SUBSYS>;
+ clock-names = "ref_clk", "phy_clk";
+ freq-table-hz = <0 0>, <0 0>;
+ /* offset: 0x84; bit: 12 */
+ resets = <_rst 0x84 12>;
+ reset-names = "rst";
+ };
+
/* SD */
dwmmc1: dwmmc1@ff37f000 {
compatible = "hisilicon,hi3670-dw-mshc";
--
2.17.1
[PATCH v2 0/3] Add UFS controller support for HI3670 SoC
Hello, This patchset adds UFS controller support for HiSilicon HI3670 SoC. HI3760 SoC is very similar to HI3660 SoC with almost same IPs, hence the same driver is extended to provide UFS support. Only major difference is the PHY. HI3670 has 10nm PHY, hence that parameter is used to distinguish the difference between two in driver. Thanks, Mani Changes in v2: As per Rob's review: * Removed interrupt-parent property from binding. * Fixed the bindings patch commit message. Manivannan Sadhasivam (3): dt-bindings: ufs: Add HI3670 UFS controller binding arm64: dts: hisilicon: hi3670: Add UFS controller support scsi: ufs: Add HI3670 SoC UFS driver support .../devicetree/bindings/ufs/ufs-hisi.txt | 5 +- arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 18 +++ drivers/scsi/ufs/ufs-hisi.c | 127 +++--- drivers/scsi/ufs/ufs-hisi.h | 4 + 4 files changed, 130 insertions(+), 24 deletions(-) -- 2.17.1
[PATCH v2 1/3] dt-bindings: ufs: Add HI3670 UFS controller binding
Add devicetree binding for HI3670 UFS controller. HI3760 SoC is very similar to HI3660 SoC with almost same IPs. Only major difference in terms of UFS is the PHY. HI3670 has 10nm PHY. But since the original driver (HI3660 UFS) cannot make HI3670 UFS functional, a separate compatible is added for HI3670 without any fallback. Signed-off-by: Manivannan Sadhasivam --- Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt index a48c44817367..0b83df1a5418 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt @@ -6,9 +6,10 @@ Each UFS Host Controller should have its own node. Required properties: - compatible: compatible list, contains one of the following - "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs - host controller present on Hi36xx chipset. + host controller present on Hi3660 chipset. + "hisilicon,hi3670-ufs", "jedec,ufs-2.1" for hisi ufs + host controller present on Hi3670 chipset. - reg : should contain UFS register address space & UFS SYS CTRL register address, -- interrupt-parent : interrupt device - interrupts: interrupt number - clocks : List of phandle and clock specifier pairs - clock-names : List of clock input name strings sorted in the same -- 2.17.1
Re: [PATCH 2/2] ARM: integrator: impd1: use struct_size() in devm_kzalloc()
Hi Gustavo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm-soc/for-next]
[also build test ERROR on v4.20 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Gustavo-A-R-Silva/Fix-NULL-pointer-dereference-and-use-struct_size/20190105-033105
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/mach-integrator/impd1.c: In function 'impd1_probe':
>> arch/arm/mach-integrator/impd1.c:392:32: error: 'struct lm_device' has no
>> member named 'deva'; did you mean 'dev'?
lookup = devm_kzalloc(>deva,
^~~~
dev
vim +392 arch/arm/mach-integrator/impd1.c
320
321 /*
322 * As this module is bool, it is OK to have this as __ref() - no
323 * probe calls will be done after the initial system bootup, as devices
324 * are discovered as part of the machine startup.
325 */
326 static int __ref impd1_probe(struct lm_device *dev)
327 {
328 struct impd1_module *impd1;
329 int irq_base;
330 int i;
331
332 if (dev->id != module_id)
333 return -EINVAL;
334
335 if (!devm_request_mem_region(>dev, dev->resource.start,
336 SZ_4K, "LM registers"))
337 return -EBUSY;
338
339 impd1 = devm_kzalloc(>dev, sizeof(struct impd1_module),
340 GFP_KERNEL);
341 if (!impd1)
342 return -ENOMEM;
343
344 impd1->base = devm_ioremap(>dev, dev->resource.start,
SZ_4K);
345 if (!impd1->base)
346 return -ENOMEM;
347
348 integrator_impd1_clk_init(impd1->base, dev->id);
349
350 if (!devm_request_mem_region(>dev,
351 dev->resource.start + 0x0300,
352 SZ_4K, "VIC"))
353 return -EBUSY;
354
355 impd1->vic_base = devm_ioremap(>dev,
356 dev->resource.start + 0x0300,
357 SZ_4K);
358 if (!impd1->vic_base)
359 return -ENOMEM;
360
361 irq_base = vic_init_cascaded(impd1->vic_base, dev->irq,
362 IMPD1_VALID_IRQS, 0);
363
364 lm_set_drvdata(dev, impd1);
365
366 dev_info(>dev, "IM-PD1 found at 0x%08lx\n",
367 (unsigned long)dev->resource.start);
368
369 for (i = 0; i < ARRAY_SIZE(impd1_devs); i++) {
370 struct impd1_device *idev = impd1_devs + i;
371 struct amba_device *d;
372 unsigned long pc_base;
373 char devname[32];
374 int irq1 = idev->irq[0];
375 int irq2 = idev->irq[1];
376
377 /* Translate IRQs to IM-PD1 local numberspace */
378 if (irq1)
379 irq1 += irq_base;
380 if (irq2)
381 irq2 += irq_base;
382
383 pc_base = dev->resource.start + idev->offset;
384 snprintf(devname, 32, "lm%x:%5.5lx", dev->id,
idev->offset >> 12);
385
386 /* Add GPIO descriptor lookup table for the PL061 block
*/
387 if (idev->offset == 0x0040) {
388 struct gpiod_lookup_table *lookup;
389 char *chipname;
390 char *mmciname;
391
> 392 lookup = devm_kzalloc(>deva,
393struct_size(lookup,
table, 3),
394GFP_KERNEL);
395 if (!lookup)
396 return -ENOMEM;
397
398 chipname = devm_kstrdup(>dev, devname,
GFP_KERNEL);
399 mmciname = kasprintf(GFP_KERNEL, "lm%x:00700",
dev->id);
400 lookup->dev_id = mmciname;
401 /*
402 * Offsets on GPIO block 1:
403 * 3 =
[PATCH v2 2/2] ARM: integrator: impd1: use struct_size() in devm_kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = devm_kzalloc(dev, sizeof(struct foo) + sizeof(void *) * count,
GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Fix devm_kzalloc parameter reported by kbuild test robot.
arch/arm/mach-integrator/impd1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index eb0149561be2..a0a1e2acdb5e 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -390,7 +390,7 @@ static int __ref impd1_probe(struct lm_device *dev)
char *mmciname;
lookup = devm_kzalloc(>dev,
- sizeof(*lookup) + 3 *
sizeof(struct gpiod_lookup),
+ struct_size(lookup, table, 3),
GFP_KERNEL);
if (!lookup)
return -ENOMEM;
--
2.20.1
[PATCH v2 1/2] ARM: integrator: impd1: fix NULL pointer dereference
There is a potential NULL pointer dereference in case devm_kzalloc()
fails and returns NULL.
Fix this by adding a NULL check on lookup.
This issue was detected with the help of Coccinelle.
Fixes: 684284b64aae ("ARM: integrator: add MMCI device to IM-PD1")
Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- None.
arch/arm/mach-integrator/impd1.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index a109f6482413..eb0149561be2 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -392,6 +392,9 @@ static int __ref impd1_probe(struct lm_device *dev)
lookup = devm_kzalloc(>dev,
sizeof(*lookup) + 3 *
sizeof(struct gpiod_lookup),
GFP_KERNEL);
+ if (!lookup)
+ return -ENOMEM;
+
chipname = devm_kstrdup(>dev, devname, GFP_KERNEL);
mmciname = kasprintf(GFP_KERNEL, "lm%x:00700", dev->id);
lookup->dev_id = mmciname;
--
2.20.1
[PATCH v2 0/2] Fix NULL pointer dereference and use struct_size
Hi, The first patch in this series fixes a potential NULL pointer dereference by adding a NULL check. A tag for stable has been added for this patch. The second patch promotes the use of struct_size() in devm_kzalloc(). Both issues were detected with the help of Coccinelle. Thanks Changes in v2: - Fix bug in patch 2/2 reported by kbuild test robot. Gustavo A. R. Silva (2): ARM: integrator: impd1: fix NULL pointer dereference ARM: integrator: impd1: use struct_size() in devm_kzalloc() arch/arm/mach-integrator/impd1.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.20.1
Re: [PATCH 3/8 v2] dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware
On Fri, Jan 04, 2019 at 09:44:17PM -0800, John Stultz wrote:
> On Fri, Jan 4, 2019 at 9:39 PM Manivannan Sadhasivam
> wrote:
> >
> > On Fri, Jan 04, 2019 at 09:22:46PM -0800, John Stultz wrote:
> > > On Fri, Jan 4, 2019 at 7:42 PM Manivannan Sadhasivam
> > > wrote:
> > > > On Fri, Jan 04, 2019 at 12:56:23PM -0800, John Stultz wrote:
> > > > > From: Youlin Wang
> > > > >
> > > > > There is an new "hisi-pcm-asp-dma-1.0" device added in
> > > > > "arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
> > > > > So we have to add a matching id in the driver file:
> > > > > .compatible = "hisilicon,hisi-pcm-asp-dma-1.0"
> > > > >
> > > > > And also hisi-pcm-asp dma device needs no setting to the clock.
> > > > > So we skip this by adding and using soc data flags.
> > > > >
> > > > > After above this driver will support both k3 and hisi_asp dma
> > > > > hardware.
> > > > >
> > > >
> > > > Small description about the hardware (ASP DMAC) would be really helpful.
> > >
> > > I've taken a shot at this (along with integrating your other feedback
> > > - thanks again for the review!), though as I don't have direct
> > > documentation, my knowledge is a bit second hand.
> > >
> > > See here:
> > > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey960-mainline-WIP=754a79facf1af0b59a7f8fd63050da12ebf5521e
> > >
> > > Let me know if you have suggestions for more specific changes!
> >
> > Description looks good to me. But looks like you are not protecting the
> > other clk APIs like clk_prepare_enable and clk_disable_unprepare. Don't
> > they fail when the relevant clk is not found?
>
> No, those calls just return 0 if null clock is passed
>
> int clk_prepare(struct clk *clk)
> {
> if (!clk)
> return 0;
> ...
Ah, okay. Didn't look into the definition.
So with the change in description,
Acked-by: Manivannan Sadhasivam
Thanks,
Mani
>
> thanks
> -john
[PATCH] signal: allow the null signal in rt_sigqueueinfo()
Running the trinity fuzzer triggered this,
UBSAN: Undefined behaviour in kernel/signal.c:2946:7
shift exponent 4294967295 is too large for 64-bit type 'long unsigned
int'
[ 3752.406618] dump_stack+0xe0/0x17a
[ 3752.419817] ubsan_epilogue+0xd/0x4e
[ 3752.423429] __ubsan_handle_shift_out_of_bounds+0x1d6/0x227
[ 3752.447269] known_siginfo_layout.cold.9+0x16/0x1b
[ 3752.452105] __copy_siginfo_from_user+0x4b/0x70
[ 3752.466620] do_syscall_64+0x164/0x7ea
[ 3752.565030] entry_SYSCALL_64_after_hwframe+0x49/0xbe
This is because signo is 0 from userspace, and then it ends up calling
(1UL << -1) in sig_specific_sicodes(). Since the null signal (0) is
allowed in the spec, just deal with it accordingly.
Signed-off-by: Qian Cai
---
kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index e1d7ad8e6ab1..970bb36837a9 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2943,7 +2943,7 @@ static bool known_siginfo_layout(unsigned sig, int
si_code)
if (si_code == SI_KERNEL)
return true;
else if ((si_code > SI_USER)) {
- if (sig_specific_sicodes(sig)) {
+ if (sig && sig_specific_sicodes(sig)) {
if (si_code <= sig_sicodes[sig].limit)
return true;
}
--
2.17.2 (Apple Git-113)
Re: [PATCH 3/8 v2] dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware
On Fri, Jan 4, 2019 at 9:39 PM Manivannan Sadhasivam
wrote:
>
> On Fri, Jan 04, 2019 at 09:22:46PM -0800, John Stultz wrote:
> > On Fri, Jan 4, 2019 at 7:42 PM Manivannan Sadhasivam
> > wrote:
> > > On Fri, Jan 04, 2019 at 12:56:23PM -0800, John Stultz wrote:
> > > > From: Youlin Wang
> > > >
> > > > There is an new "hisi-pcm-asp-dma-1.0" device added in
> > > > "arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
> > > > So we have to add a matching id in the driver file:
> > > > .compatible = "hisilicon,hisi-pcm-asp-dma-1.0"
> > > >
> > > > And also hisi-pcm-asp dma device needs no setting to the clock.
> > > > So we skip this by adding and using soc data flags.
> > > >
> > > > After above this driver will support both k3 and hisi_asp dma hardware.
> > > >
> > >
> > > Small description about the hardware (ASP DMAC) would be really helpful.
> >
> > I've taken a shot at this (along with integrating your other feedback
> > - thanks again for the review!), though as I don't have direct
> > documentation, my knowledge is a bit second hand.
> >
> > See here:
> > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey960-mainline-WIP=754a79facf1af0b59a7f8fd63050da12ebf5521e
> >
> > Let me know if you have suggestions for more specific changes!
>
> Description looks good to me. But looks like you are not protecting the
> other clk APIs like clk_prepare_enable and clk_disable_unprepare. Don't
> they fail when the relevant clk is not found?
No, those calls just return 0 if null clock is passed
int clk_prepare(struct clk *clk)
{
if (!clk)
return 0;
...
thanks
-john
Re: [PATCH 3/8 v2] dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware
On Fri, Jan 04, 2019 at 09:22:46PM -0800, John Stultz wrote: > On Fri, Jan 4, 2019 at 7:42 PM Manivannan Sadhasivam > wrote: > > On Fri, Jan 04, 2019 at 12:56:23PM -0800, John Stultz wrote: > > > From: Youlin Wang > > > > > > There is an new "hisi-pcm-asp-dma-1.0" device added in > > > "arch/arm64/boot/dts/hisilicon/hi3660.dtsi". > > > So we have to add a matching id in the driver file: > > > .compatible = "hisilicon,hisi-pcm-asp-dma-1.0" > > > > > > And also hisi-pcm-asp dma device needs no setting to the clock. > > > So we skip this by adding and using soc data flags. > > > > > > After above this driver will support both k3 and hisi_asp dma hardware. > > > > > > > Small description about the hardware (ASP DMAC) would be really helpful. > > I've taken a shot at this (along with integrating your other feedback > - thanks again for the review!), though as I don't have direct > documentation, my knowledge is a bit second hand. > > See here: > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey960-mainline-WIP=754a79facf1af0b59a7f8fd63050da12ebf5521e > > Let me know if you have suggestions for more specific changes! Description looks good to me. But looks like you are not protecting the other clk APIs like clk_prepare_enable and clk_disable_unprepare. Don't they fail when the relevant clk is not found? Thanks, Mani > thanks > -john
Re: [PATCH 6/8 v2] arm64: dts: hi3660: Add dma to uart nodes
On Fri, Jan 4, 2019 at 8:34 PM John Stultz wrote:
>
> On Fri, Jan 4, 2019 at 7:49 PM Manivannan Sadhasivam
> wrote:
> >
> > Hi John,
> >
> > On Fri, Jan 04, 2019 at 12:56:26PM -0800, John Stultz wrote:
> > > Try to add DMA support to the uart nodes following
> > > the assignments made in the dts from the victoria vendor kernel
> > > here:
> > > https://consumer.huawei.com/en/opensource/detail/?siteCode=worldwide=p10=openSourceSoftware=10=1
> > >
> > > Cc: Tanglei Han
> > > Cc: Zhuangluan Su
> > > Cc: Ryan Grachek
> > > Cc: Manivannan Sadhasivam
> > > Cc: Wei Xu
> > > Cc: Rob Herring
> > > Cc: Mark Rutland
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: devicet...@vger.kernel.org
> > > Signed-off-by: John Stultz
> > > ---
> > > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > > b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > > index 20ae40d..aaa2b04 100644
> > > --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > > +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > > @@ -466,6 +466,8 @@
> > > compatible = "arm,pl011", "arm,primecell";
> > > reg = <0x0 0xfdf02000 0x0 0x1000>;
> > > interrupts = ;
> > > + dma-names = "rx", "tx";
> > > + dmas = < 0 1>;
> >
> > Usage of DMA channel 0 contradicts with the description provided in
> > patch, "dma: k3dma: Add support to dma_avail_chan".
>
> Hrm. Good point. I'll double check w/ Dr Su on this, I'm not sure if
> that inconsistency is due to the the vendor kernel (where these came
> from) having different reserved channels or just something overlooked
> if the uart0 is not actually being used (as we find on hikey960 as
> well).
Hrm. So it seems like uart0 is mapped to the dma0 chan0, but the
device specific files in the vendor tree overwite the dma values:
serial0: uart@fdf02000 {
pinctrl-names = "default", "idle";
pinctrl-0 = <_pmx_func
_pmx_func _cfg_func _cfg_func>;
pinctrl-1 = <_pmx_idle
_pmx_idle _cfg_idle _cfg_idle>;
dma-names = "", "";
dmas = <>;
clock-rate = <0 1920>;
status = "ok";
};
But I went ahead and pulled the dma values on uart0.
thaks
-john
Re: [PATCH 3/8 v2] dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware
On Fri, Jan 4, 2019 at 7:42 PM Manivannan Sadhasivam wrote: > On Fri, Jan 04, 2019 at 12:56:23PM -0800, John Stultz wrote: > > From: Youlin Wang > > > > There is an new "hisi-pcm-asp-dma-1.0" device added in > > "arch/arm64/boot/dts/hisilicon/hi3660.dtsi". > > So we have to add a matching id in the driver file: > > .compatible = "hisilicon,hisi-pcm-asp-dma-1.0" > > > > And also hisi-pcm-asp dma device needs no setting to the clock. > > So we skip this by adding and using soc data flags. > > > > After above this driver will support both k3 and hisi_asp dma hardware. > > > > Small description about the hardware (ASP DMAC) would be really helpful. I've taken a shot at this (along with integrating your other feedback - thanks again for the review!), though as I don't have direct documentation, my knowledge is a bit second hand. See here: https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey960-mainline-WIP=754a79facf1af0b59a7f8fd63050da12ebf5521e Let me know if you have suggestions for more specific changes! thanks -john
[PATCH] keyboard/mtk-pmic-keys.c: Remove duplicate header
Remove linux/kernel.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/input/keyboard/mtk-pmic-keys.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c index 02c67a1749fc..5027ebb7b4e8 100644 --- a/drivers/input/keyboard/mtk-pmic-keys.c +++ b/drivers/input/keyboard/mtk-pmic-keys.c @@ -19,7 +19,6 @@ #include #include #include -#include #include #include #include -- 2.17.1
Re: [PATCH 2/8 v2] Documentation: bindings: k3dma: Add binding for dma-avail-chan
On Fri, Jan 4, 2019 at 8:53 PM Manivannan Sadhasivam wrote: > > On Fri, Jan 04, 2019 at 08:39:34PM -0800, John Stultz wrote: > > On Fri, Jan 4, 2019 at 8:00 PM Manivannan Sadhasivam > > wrote: > > > > > > Hi John, > > > > > > On Fri, Jan 04, 2019 at 12:56:22PM -0800, John Stultz wrote: > > > > Some dma channels can be reserved for secure mode or other > > > > hardware on the SoC, so provide a binding for a bitmask > > > > listing the available channels for the kernel to use. > > > > > > > > Cc: Vinod Koul > > > > Cc: Rob Herring > > > > Cc: Mark Rutland > > > > Cc: Tanglei Han > > > > Cc: Zhuangluan Su > > > > Cc: Ryan Grachek > > > > Cc: Manivannan Sadhasivam > > > > Cc: dmaeng...@vger.kernel.org > > > > Cc: devicet...@vger.kernel.org > > > > Signed-off-by: John Stultz > > > > --- > > > > Documentation/devicetree/bindings/dma/k3dma.txt | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt > > > > b/Documentation/devicetree/bindings/dma/k3dma.txt > > > > index 10a2f15..1c466c1 100644 > > > > --- a/Documentation/devicetree/bindings/dma/k3dma.txt > > > > +++ b/Documentation/devicetree/bindings/dma/k3dma.txt > > > > @@ -14,6 +14,9 @@ Required properties: > > > > have specific request line > > > > - clocks: clock required > > > > > > > > +Optional properties: > > > > +- dma-avail-chan: Bitmask of available physical channels > > > > + > > > > > > This property looks too generic. Since this is specific to HiSi SoCs, > > > this could be "hisi-dma-avail-chan"? > > > > I'm fine to change it, but I'm not sure I fully understand the > > rational. Can you help me understand? > > Are device node-binding names supposed to have global scope? I assumed > > the node property names are basically scoped to the entry? > > IIUC properties documented in subsystem binding (dma.txt in this case) > will have global scope. Those which are not documented in this binding > are specific to vendor IPs and should be prefixed with the vendor > prefix (hisi in this case). Thanks I appreciate the explanation here. I hadn't really understood this point, and really haven't developed much "taste" in what makes a good or bad binding. > > Further, having some dma channels be reserved doesn't seem to be too > > unique a concept, so I'm not sure what we gain long term by prefixing > > it? > > > > Right, but this brings up the point of having this functionality in > generic DMA engine so that the DMA controller drivers need not handle. > So either we should move this available channel check to DMA Engine > and document the property in dma.txt so that other IPs can also use it > or keep the functionality in K3 driver and use HiSi prefix for the > property. > > But I'd like to hear Vinod/Rob's opinion on this! Sure. Though for now I'll prefix it as the logic is handled at the driver level. thanks -john
Re: [PATCH 2/8 v2] Documentation: bindings: k3dma: Add binding for dma-avail-chan
On Fri, Jan 04, 2019 at 08:39:34PM -0800, John Stultz wrote: > On Fri, Jan 4, 2019 at 8:00 PM Manivannan Sadhasivam > wrote: > > > > Hi John, > > > > On Fri, Jan 04, 2019 at 12:56:22PM -0800, John Stultz wrote: > > > Some dma channels can be reserved for secure mode or other > > > hardware on the SoC, so provide a binding for a bitmask > > > listing the available channels for the kernel to use. > > > > > > Cc: Vinod Koul > > > Cc: Rob Herring > > > Cc: Mark Rutland > > > Cc: Tanglei Han > > > Cc: Zhuangluan Su > > > Cc: Ryan Grachek > > > Cc: Manivannan Sadhasivam > > > Cc: dmaeng...@vger.kernel.org > > > Cc: devicet...@vger.kernel.org > > > Signed-off-by: John Stultz > > > --- > > > Documentation/devicetree/bindings/dma/k3dma.txt | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt > > > b/Documentation/devicetree/bindings/dma/k3dma.txt > > > index 10a2f15..1c466c1 100644 > > > --- a/Documentation/devicetree/bindings/dma/k3dma.txt > > > +++ b/Documentation/devicetree/bindings/dma/k3dma.txt > > > @@ -14,6 +14,9 @@ Required properties: > > > have specific request line > > > - clocks: clock required > > > > > > +Optional properties: > > > +- dma-avail-chan: Bitmask of available physical channels > > > + > > > > This property looks too generic. Since this is specific to HiSi SoCs, > > this could be "hisi-dma-avail-chan"? > > I'm fine to change it, but I'm not sure I fully understand the > rational. Can you help me understand? > Are device node-binding names supposed to have global scope? I assumed > the node property names are basically scoped to the entry? IIUC properties documented in subsystem binding (dma.txt in this case) will have global scope. Those which are not documented in this binding are specific to vendor IPs and should be prefixed with the vendor prefix (hisi in this case). > Further, having some dma channels be reserved doesn't seem to be too > unique a concept, so I'm not sure what we gain long term by prefixing > it? > Right, but this brings up the point of having this functionality in generic DMA engine so that the DMA controller drivers need not handle. So either we should move this available channel check to DMA Engine and document the property in dma.txt so that other IPs can also use it or keep the functionality in K3 driver and use HiSi prefix for the property. But I'd like to hear Vinod/Rob's opinion on this! Thanks, Mani > thanks > -john
Re: [PATCH] drivers/bus/fsl-mc/dpbp.c: Remove duplicate header
On Wed, Dec 5, 2018 at 12:10 PM Brajeswar Ghosh wrote: > > On Fri, Nov 16, 2018 at 8:47 PM Brajeswar Ghosh > wrote: > > > > On Fri, Nov 9, 2018 at 3:21 PM Brajeswar Ghosh > > wrote: > > > > > > Remove linux/fsl/mc.h which is included more than once > > > > > > Signed-off-by: Brajeswar Ghosh > > > > Any comment on this patch? > > Any comment on this patch? Any comment on this patch? > > > > > > --- > > > drivers/bus/fsl-mc/dpbp.c | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/drivers/bus/fsl-mc/dpbp.c b/drivers/bus/fsl-mc/dpbp.c > > > index 17e3c5d2f22e..9003cd3698a5 100644 > > > --- a/drivers/bus/fsl-mc/dpbp.c > > > +++ b/drivers/bus/fsl-mc/dpbp.c > > > @@ -5,7 +5,6 @@ > > > */ > > > #include > > > #include > > > -#include > > > > > > #include "fsl-mc-private.h" > > > > > > -- > > > 2.17.1 > > >
Re: [PATCH] ASoC: tlv320aic32x4: Kernel OOPS while entering DAPM standby mode
On Fri, Jan 04, 2019 at 10:10:40PM +0530, b-ak wrote: > On Fri, Jan 04, 2019 at 01:04:21AM +0530, b-ak wrote: > > On Thu, Jan 03, 2019 at 12:45:54PM +, Mark Brown wrote: > > > On Wed, Jan 02, 2019 at 10:36:33PM +0530, b-ak wrote: > > > > During the bootup of the kernel, as soon as the DAPM framework kicks in > > > > it pushes the codec into standy mode. > > > > > > > > The existing TVL320AIC32x4 codec driver doesn't prepare the clock in > > > > the probe function. > > > > This leads to an OOPS when the DAPM tries to put it into standy by > > > > calling > > > > clk_disable_unprepare() > > > > > > > > This patch fixes that problem. > > > > > > This isn't the best way of fixing this because it makes it look like > > > there's a missing disable in the removal process. What would be better > > > would be to do what other drivers do and check to see what state we're > > > transitioning from before we disable the clock in set_bias_level(). See > > > drivers like wm8903.c for examples. > > > > Hello Mark, > > > > I will test the change and update the patch. > > > > Thanks, > > Bhargav > > > > Hi Mark, > > I have updated the patch with the changes. > > Regards, > Bhargav > Hi Mark, Fixed the build error. Thanks, Bhargav >From 5854c8b48e6c2367d391cc760939538ac8f624f7 Mon Sep 17 00:00:00 2001 From: b-ak Date: Tue, 1 Jan 2019 22:52:40 +0530 Subject: [PATCH] ASoC: tlv320aic32x4: Kernel OOPS while entering DAPM standby mode During the bootup of the kernel, the DAPM bias level is in the OFF state. As soon as the DAPM framework kicks in it pushes the codec into STANDBY state. The probe function doesn't prepare the clock, and STANDBY state does a clk_disable_unprepare() without checking the previous state. This leads to an OOPS. Not transitioning from an OFF state to the STANDBY state fixes the problem. Signed-off-by: b-ak --- sound/soc/codecs/tlv320aic32x4.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index e2b5a11b16d1..f03195d2ab2e 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -822,6 +822,10 @@ static int aic32x4_set_bias_level(struct snd_soc_component *component, case SND_SOC_BIAS_PREPARE: break; case SND_SOC_BIAS_STANDBY: + /* Initial cold start */ + if (snd_soc_component_get_bias_level(component) == SND_SOC_BIAS_OFF) + break; + /* Switch off BCLK_N Divider */ snd_soc_component_update_bits(component, AIC32X4_BCLKN, AIC32X4_BCLKEN, 0); -- 2.19.1
Re: [PATCH 2/8 v2] Documentation: bindings: k3dma: Add binding for dma-avail-chan
On Fri, Jan 4, 2019 at 8:00 PM Manivannan Sadhasivam wrote: > > Hi John, > > On Fri, Jan 04, 2019 at 12:56:22PM -0800, John Stultz wrote: > > Some dma channels can be reserved for secure mode or other > > hardware on the SoC, so provide a binding for a bitmask > > listing the available channels for the kernel to use. > > > > Cc: Vinod Koul > > Cc: Rob Herring > > Cc: Mark Rutland > > Cc: Tanglei Han > > Cc: Zhuangluan Su > > Cc: Ryan Grachek > > Cc: Manivannan Sadhasivam > > Cc: dmaeng...@vger.kernel.org > > Cc: devicet...@vger.kernel.org > > Signed-off-by: John Stultz > > --- > > Documentation/devicetree/bindings/dma/k3dma.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt > > b/Documentation/devicetree/bindings/dma/k3dma.txt > > index 10a2f15..1c466c1 100644 > > --- a/Documentation/devicetree/bindings/dma/k3dma.txt > > +++ b/Documentation/devicetree/bindings/dma/k3dma.txt > > @@ -14,6 +14,9 @@ Required properties: > > have specific request line > > - clocks: clock required > > > > +Optional properties: > > +- dma-avail-chan: Bitmask of available physical channels > > + > > This property looks too generic. Since this is specific to HiSi SoCs, > this could be "hisi-dma-avail-chan"? I'm fine to change it, but I'm not sure I fully understand the rational. Can you help me understand? Are device node-binding names supposed to have global scope? I assumed the node property names are basically scoped to the entry? Further, having some dma channels be reserved doesn't seem to be too unique a concept, so I'm not sure what we gain long term by prefixing it? thanks -john
[PATCH v2] Drivers: hv: vmbus: Expose counters for interrupts and full conditions
Counter values for per-channel interrupts and ring buffer full
conditions are useful for investigating performance.
Expose counters in sysfs for 2 types of guest to host interrupts:
1) Interrupts caused by the channel's outbound ring buffer transitioning
from empty to not empty
2) Interrupts caused by the channel's inbound ring buffer transitioning
from full to not full while a packet is waiting for enough buffer space to
become available
Expose 2 counters in sysfs for the number of times that write operations
encountered a full outbound ring buffer:
1) The total number of write operations that encountered a full
condition
2) The number of write operations that were the first to encounter a
full condition
I tested this patch by confirming that the sysfs files were created and
observing the counter values. The values seemed to increase by a
reasonable amount when the Hyper-v related drivers were in use.
Signed-off-by: Kimberly Brown
---
Changes in v2:
- Added mailing lists to the cc list
- Removed the host to guest interrupt counters proposed in v1 because
they were not accurate
- Added full condition counters for the channel's outbound ring buffer
Documentation/ABI/stable/sysfs-bus-vmbus | 33
drivers/hv/ring_buffer.c | 14 +-
drivers/hv/vmbus_drv.c | 32 +++
include/linux/hyperv.h | 32 +++
4 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus
b/Documentation/ABI/stable/sysfs-bus-vmbus
index 3fed8fdb873d..31dc89989032 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -146,3 +146,36 @@ KernelVersion: 4.16
Contact: Stephen Hemminger
Description: Binary file created by uio_hv_generic for ring buffer
Users: Userspace drivers
+
+What: /sys/bus/vmbus/devices//channels//intr_in_full
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Number of guest to host interrupts caused by the inbound ring
+ buffer transitioning from full to not full while a packet is
+ waiting for buffer space to become available
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//intr_out_empty
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Number of guest to host interrupts caused by the outbound ring
+ buffer transitioning from empty to not empty
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//out_full_first
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Number of write operations that were the first to encounter an
+ outbound ring buffer full condition
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//out_full_total
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Total number of write operations that encountered an outbound
+ ring buffer full condition
+Users: Debugging tools
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 64d0c85d5161..be2cbd0bea7d 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -74,8 +74,10 @@ static void hv_signal_on_write(u32 old_write, struct
vmbus_channel *channel)
* This is the only case we need to signal when the
* ring transitions from being empty to non-empty.
*/
- if (old_write == READ_ONCE(rbi->ring_buffer->read_index))
+ if (old_write == READ_ONCE(rbi->ring_buffer->read_index)) {
+ ++channel->intr_out_empty;
vmbus_setevent(channel);
+ }
}
/* Get the next write location for the specified ring buffer. */
@@ -273,10 +275,19 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
* is empty since the read index == write index.
*/
if (bytes_avail_towrite <= totalbytes_towrite) {
+ ++channel->out_full_total;
+
+ if (!channel->out_full_flag) {
+ ++channel->out_full_first;
+ channel->out_full_flag = true;
+ }
+
spin_unlock_irqrestore(_info->ring_lock, flags);
return -EAGAIN;
}
+ channel->out_full_flag = false;
+
/* Write to the ring buffer */
next_write_location = hv_get_next_write_location(outring_info);
@@ -531,6 +542,7 @@ void hv_pkt_iter_close(struct vmbus_channel *channel)
if (curr_write_sz <= pending_sz)
return;
+ ++channel->intr_in_full;
vmbus_setevent(channel);
}
EXPORT_SYMBOL_GPL(hv_pkt_iter_close);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 283d184280af..460b7f75251c
Re: [PATCH 6/8 v2] arm64: dts: hi3660: Add dma to uart nodes
On Fri, Jan 4, 2019 at 7:49 PM Manivannan Sadhasivam wrote: > > Hi John, > > On Fri, Jan 04, 2019 at 12:56:26PM -0800, John Stultz wrote: > > Try to add DMA support to the uart nodes following > > the assignments made in the dts from the victoria vendor kernel > > here: > > https://consumer.huawei.com/en/opensource/detail/?siteCode=worldwide=p10=openSourceSoftware=10=1 > > > > Cc: Tanglei Han > > Cc: Zhuangluan Su > > Cc: Ryan Grachek > > Cc: Manivannan Sadhasivam > > Cc: Wei Xu > > Cc: Rob Herring > > Cc: Mark Rutland > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: devicet...@vger.kernel.org > > Signed-off-by: John Stultz > > --- > > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > > b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > > index 20ae40d..aaa2b04 100644 > > --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > > +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > > @@ -466,6 +466,8 @@ > > compatible = "arm,pl011", "arm,primecell"; > > reg = <0x0 0xfdf02000 0x0 0x1000>; > > interrupts = ; > > + dma-names = "rx", "tx"; > > + dmas = < 0 1>; > > Usage of DMA channel 0 contradicts with the description provided in > patch, "dma: k3dma: Add support to dma_avail_chan". Hrm. Good point. I'll double check w/ Dr Su on this, I'm not sure if that inconsistency is due to the the vendor kernel (where these came from) having different reserved channels or just something overlooked if the uart0 is not actually being used (as we find on hikey960 as well). thanks -john
Re: [PATCH 0/8 v2] k3dma patches to add support for hi3660/HiKey960
On Fri, Jan 4, 2019 at 7:37 PM Manivannan Sadhasivam wrote: > > Hi John, > > On Fri, Jan 04, 2019 at 12:56:20PM -0800, John Stultz wrote: > > This patch series is based on recent work by Tanglei Han, and > > adds support for hi3660 SoCs as found on the HiKey960 board, > > Not sure about the description/subject here! This patchset adds support > for ASP DMAC found in HI3660 SoCs, Peripheral DMAC is already supported. > So yes, it does enable ASP DMAC support, but the full set also enables the Peripheral DMAC as well in a few ways: * Avoiding setting the AXI register, which is configured differently on hi3660. * By adding support for the dma-avail-chan (so we don't try to use reserved channels) thanks -john
Re: Question: pause mode disabled for marvell 88e151x phy
On 2018/12/17 22:36, Russell King - ARM Linux wrote: > I'll try to do further diagnosis over Christmas in case I've missed > something, but I suspect it may be one of those "weird behaviour" issues > where the safest action is to disable pause mode as per my commit - > which is far saner than having mismatched pause status on either end > of a link. However, given that Marvell specs are all NDA-only, it's > very difficult to investigate beyond "this is the observed behaviour". Hi, Is there any update on the further diagnosis? >
RE: [PATCH 1/2] e1000e: Exclude device from suspend direct complete optimization
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Kai-Heng Feng > Sent: Tuesday, December 11, 2018 12:00 AM > To: Kirsher, Jeffrey T > Cc: da...@davemloft.net; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Kai-Heng Feng > > Subject: [PATCH 1/2] e1000e: Exclude device from suspend direct complete > optimization > > e1000e sets different WoL settings in system suspend callback and > runtime suspend callback. > > The suspend direct complete optimization leaves e1000e in runtime > suspneded state with wrong WoL setting during system suspend. > > To fix this, we need to disable suspend direct complete optimization to > let e1000e always use suspend callback to set correct WoL during system > suspend. > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++ > 1 file changed, 2 insertions(+) > Tested-by: Aaron Brown
Re: [PATCH 2/8 v2] Documentation: bindings: k3dma: Add binding for dma-avail-chan
Hi John, On Fri, Jan 04, 2019 at 12:56:22PM -0800, John Stultz wrote: > Some dma channels can be reserved for secure mode or other > hardware on the SoC, so provide a binding for a bitmask > listing the available channels for the kernel to use. > > Cc: Vinod Koul > Cc: Rob Herring > Cc: Mark Rutland > Cc: Tanglei Han > Cc: Zhuangluan Su > Cc: Ryan Grachek > Cc: Manivannan Sadhasivam > Cc: dmaeng...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Signed-off-by: John Stultz > --- > Documentation/devicetree/bindings/dma/k3dma.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt > b/Documentation/devicetree/bindings/dma/k3dma.txt > index 10a2f15..1c466c1 100644 > --- a/Documentation/devicetree/bindings/dma/k3dma.txt > +++ b/Documentation/devicetree/bindings/dma/k3dma.txt > @@ -14,6 +14,9 @@ Required properties: > have specific request line > - clocks: clock required > > +Optional properties: > +- dma-avail-chan: Bitmask of available physical channels > + This property looks too generic. Since this is specific to HiSi SoCs, this could be "hisi-dma-avail-chan"? Thanks, Mani > Example: > > Controller: > -- > 2.7.4 >
Re: [PATCH 7/8 v2] arm64: dts: hi3660: Add hisi asp dma device
On Fri, Jan 04, 2019 at 12:56:27PM -0800, John Stultz wrote:
> From: Youlin Wang
>
> Add asp-dma device to hi3660 dts
>
> Cc: Tanglei Han
> Cc: Zhuangluan Su
> Cc: Ryan Grachek
> Cc: Manivannan Sadhasivam
> Cc: Wei Xu
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Youlin Wang
> Signed-off-by: Tanglei Han
> Signed-off-by: John Stultz
Acked-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> v2: Removed undocumented bindings
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index aaa2b04..df4e96d 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -569,6 +569,16 @@
> dma-type = "hi3660_dma";
> };
>
> + asp_dmac: dma-controller@e804b000 {
> + compatible = "hisilicon,hisi-pcm-asp-dma-1.0";
> + reg = <0x0 0xe804b000 0x0 0x1000>;
> + #dma-cells = <1>;
> + dma-channels = <16>;
> + dma-requests = <32>;
> + interrupts = ;
> + interrupt-names = "asp_dma_irq";
> + };
> +
> rtc0: rtc@fff04000 {
> compatible = "arm,pl031", "arm,primecell";
> reg = <0x0 0Xfff04000 0x0 0x1000>;
> --
> 2.7.4
>
Re: [PATCH 6/8 v2] arm64: dts: hi3660: Add dma to uart nodes
Hi John, On Fri, Jan 04, 2019 at 12:56:26PM -0800, John Stultz wrote: > Try to add DMA support to the uart nodes following > the assignments made in the dts from the victoria vendor kernel > here: > https://consumer.huawei.com/en/opensource/detail/?siteCode=worldwide=p10=openSourceSoftware=10=1 > > Cc: Tanglei Han > Cc: Zhuangluan Su > Cc: Ryan Grachek > Cc: Manivannan Sadhasivam > Cc: Wei Xu > Cc: Rob Herring > Cc: Mark Rutland > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Signed-off-by: John Stultz > --- > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > index 20ae40d..aaa2b04 100644 > --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > @@ -466,6 +466,8 @@ > compatible = "arm,pl011", "arm,primecell"; > reg = <0x0 0xfdf02000 0x0 0x1000>; > interrupts = ; > + dma-names = "rx", "tx"; > + dmas = < 0 1>; Usage of DMA channel 0 contradicts with the description provided in patch, "dma: k3dma: Add support to dma_avail_chan". Thanks, Mani > clocks = <_ctrl HI3660_CLK_MUX_UART0>, ><_ctrl HI3660_PCLK>; > clock-names = "uartclk", "apb_pclk"; > @@ -478,6 +480,8 @@ > compatible = "arm,pl011", "arm,primecell"; > reg = <0x0 0xfdf0 0x0 0x1000>; > interrupts = ; > + dma-names = "rx", "tx"; > + dmas = < 2 3>; > clocks = <_ctrl HI3660_CLK_GATE_UART1>, ><_ctrl HI3660_CLK_GATE_UART1>; > clock-names = "uartclk", "apb_pclk"; > @@ -490,6 +494,8 @@ > compatible = "arm,pl011", "arm,primecell"; > reg = <0x0 0xfdf03000 0x0 0x1000>; > interrupts = ; > + dma-names = "rx", "tx"; > + dmas = < 4 5>; > clocks = <_ctrl HI3660_CLK_GATE_UART2>, ><_ctrl HI3660_PCLK>; > clock-names = "uartclk", "apb_pclk"; > @@ -514,6 +520,8 @@ > compatible = "arm,pl011", "arm,primecell"; > reg = <0x0 0xfdf01000 0x0 0x1000>; > interrupts = ; > + dma-names = "rx", "tx"; > + dmas = < 6 7>; > clocks = <_ctrl HI3660_CLK_GATE_UART4>, ><_ctrl HI3660_CLK_GATE_UART4>; > clock-names = "uartclk", "apb_pclk"; > @@ -526,6 +534,8 @@ > compatible = "arm,pl011", "arm,primecell"; > reg = <0x0 0xfdf05000 0x0 0x1000>; > interrupts = ; > + dma-names = "rx", "tx"; > + dmas = < 8 9>; > clocks = <_ctrl HI3660_CLK_GATE_UART5>, ><_ctrl HI3660_CLK_GATE_UART5>; > clock-names = "uartclk", "apb_pclk"; > -- > 2.7.4 >
Re: [PATCHv3 1/2] mm/memblock: extend the limit inferior of bottom-up after parsing hotplug attr
On 01/04/19 at 05:09pm, Mike Rapoport wrote:
> On Thu, Jan 03, 2019 at 10:47:06AM -0800, Tejun Heo wrote:
> > Hello,
> >
> > On Wed, Jan 02, 2019 at 07:05:38PM +0200, Mike Rapoport wrote:
> > > I agree that currently the bottom-up allocation after the kernel text has
> > > issues with KASLR. But this issues are not necessarily related to the
> > > memory hotplug. Even with a single memory node, a bottom-up allocation
> > > will
> > > fail if KASLR would put the kernel near the end of node0.
> > >
> > > What I am trying to understand is whether there is a fundamental reason to
> > > prevent allocations from [0, kernel_start)?
> > >
> > > Maybe Tejun can recall why he suggested to start bottom-up allocations
> > > from
> > > kernel_end.
> >
> > That's from 79442ed189ac ("mm/memblock.c: introduce bottom-up
> > allocation mode"). I wasn't involved in that patch, so no idea why
> > the restrictions were added, but FWIW it doesn't seem necessary to me.
>
> I should have added the reference [1] at the first place :)
> Thanks!
>
> [1] https://lore.kernel.org/lkml/20130904192215.gg26...@mtj.dyndns.org/
With my understanding, we may not be able to discard the bottom-up
method for the current kernel. It's related to hotplug feature when
'movable_node' kernel parameter is specified. With 'movable_node',
system relies on reading hotplug information from firmware, on x86 it's
acpi SRAT table. In the current system, we allocate memblock region
top-down by default. However, before that hotplug information retrieving,
there are several places of memblock allocating, top-down memblock
allocation must break hotplug feature since it will allocate kernel data
in movable zone which is usually at the end node on bare metal system.
This bottom-up way is taken on many ARCHes, it works well on system if
KASLR is not enabled. Below is the searching result in the current linux
kernel, we can see that all ARCHes have this mechanism, except of
arm/arm64. But now only arm64/mips/x86 have KASLR.
W/o KASLR, allocating memblock region above kernle end when hotplug info
is not parsed, looks very reasonable. Since kernel is usually put at
lower address, e.g on x86, it's 16M. My thought is that we need do
memblock allocation around kernel before hotplug info parsed. That is
for system w/o KASLR, we will keep the current bottom-up way; for system
with KASLR, we should allocate memblock region top-down just below
kernel start.
This issue must break hotplug, just because currently bare metal system
need add 'nokaslr' to disable KASLR since another bug fix is under
discussion as below, so this issue is covered up.
[PATCH v14 0/5] x86/boot/KASLR: Parse ACPI table and limit KASLR to choosing
immovable memory
lkml.kernel.org/r/20181214093013.13370-1-fanc.f...@cn.fujitsu.com
[~ ]$ git grep memblock_set_bottom_up
arch/alpha/kernel/setup.c: memblock_set_bottom_up(true);
arch/m68k/mm/motorola.c:memblock_set_bottom_up(true);
arch/mips/kernel/setup.c: memblock_set_bottom_up(true);
arch/mips/kernel/traps.c: memblock_set_bottom_up(false);
arch/nds32/kernel/setup.c: memblock_set_bottom_up(true);
arch/powerpc/kernel/paca.c: memblock_set_bottom_up(true);
arch/powerpc/kernel/paca.c: memblock_set_bottom_up(false);
arch/s390/kernel/setup.c: memblock_set_bottom_up(true);
arch/s390/kernel/setup.c: memblock_set_bottom_up(false);
arch/sparc/mm/init_32.c:memblock_set_bottom_up(true);
arch/x86/kernel/setup.c:memblock_set_bottom_up(true);
arch/x86/mm/numa.c: memblock_set_bottom_up(false);
include/linux/memblock.h:static inline void __init memblock_set_bottom_up(bool
enable)
Re: [PATCH 4/8 v2] dma: k3dma: Delete axi_config
On Fri, Jan 04, 2019 at 12:56:24PM -0800, John Stultz wrote: > From: Li Yu > > Axi_config controls whether DMA resources can be accessed in non-secure > mode, such as linux kernel. The register should be set by the bootloader > stage and depends on the device. > > Thus, this patch removes axi_config from k3dma driver. > > Cc: Dan Williams > Cc: Vinod Koul > Cc: Tanglei Han > Cc: Zhuangluan Su > Cc: Ryan Grachek > Cc: Manivannan Sadhasivam > Cc: dmaeng...@vger.kernel.org > Signed-off-by: Li Yu > Signed-off-by: Guodong Xu > [jstultz: Minor tweaks to commit message] > Signed-off-by: John Stultz Acked-by: Manivannan Sadhasivam Thanks, Mani > --- > drivers/dma/k3dma.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c > index df61406..b2060bf 100644 > --- a/drivers/dma/k3dma.c > +++ b/drivers/dma/k3dma.c > @@ -52,8 +52,6 @@ > #define CX_SRC 0x814 > #define CX_DST 0x818 > #define CX_CFG 0x81c > -#define AXI_CFG 0x820 > -#define AXI_CFG_DEFAULT 0x201201 > > #define CX_LLI_CHAIN_EN 0x2 > #define CX_CFG_EN0x1 > @@ -168,7 +166,6 @@ static void k3_dma_set_desc(struct k3_dma_phy *phy, > struct k3_desc_hw *hw) > writel_relaxed(hw->count, phy->base + CX_CNT0); > writel_relaxed(hw->saddr, phy->base + CX_SRC); > writel_relaxed(hw->daddr, phy->base + CX_DST); > - writel_relaxed(AXI_CFG_DEFAULT, phy->base + AXI_CFG); > writel_relaxed(hw->config, phy->base + CX_CFG); > } > > -- > 2.7.4 >
Re: [PATCH 3/8 v2] dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware
Hi John,
On Fri, Jan 04, 2019 at 12:56:23PM -0800, John Stultz wrote:
> From: Youlin Wang
>
> There is an new "hisi-pcm-asp-dma-1.0" device added in
> "arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
> So we have to add a matching id in the driver file:
> .compatible = "hisilicon,hisi-pcm-asp-dma-1.0"
>
> And also hisi-pcm-asp dma device needs no setting to the clock.
> So we skip this by adding and using soc data flags.
>
> After above this driver will support both k3 and hisi_asp dma hardware.
>
Small description about the hardware (ASP DMAC) would be really helpful.
Thanks,
Mani
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Zhuangluan Su
> Cc: Ryan Grachek
> Cc: Manivannan Sadhasivam
> Cc: dmaeng...@vger.kernel.org
> Signed-off-by: Youlin Wang
> Signed-off-by: Tanglei Han
> [jstultz: Reworked to use of_match_data]
> Signed-off-by: John Stultz
> ---
> v2:
> * Reworked to use of_match_data
> ---
> drivers/dma/k3dma.c | 37 -
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
> index fdec2b6..df61406 100644
> --- a/drivers/dma/k3dma.c
> +++ b/drivers/dma/k3dma.c
> @@ -116,6 +116,13 @@ struct k3_dma_dev {
> unsigned intirq;
> };
>
> +
> +#define K3_FLAG_NOCLK (1<<0)
> +struct k3dma_soc_data {
> + unsigned long flags;
> +};
> +
> +
> #define to_k3_dma(dmadev) container_of(dmadev, struct k3_dma_dev, slave)
>
> static int k3_dma_config_write(struct dma_chan *chan,
> @@ -790,8 +797,21 @@ static int k3_dma_transfer_resume(struct dma_chan *chan)
> return 0;
> }
>
> +static const struct k3dma_soc_data k3_v1_dma_data = {
> + .flags = 0,
> +};
> +
> +static const struct k3dma_soc_data asp_v1_dma_data = {
> + .flags = K3_FLAG_NOCLK,
> +};
> +
> static const struct of_device_id k3_pdma_dt_ids[] = {
> - { .compatible = "hisilicon,k3-dma-1.0", },
> + { .compatible = "hisilicon,k3-dma-1.0",
> + .data = _v1_dma_data
> + },
> + { .compatible = "hisilicon,hisi-pcm-asp-dma-1.0",
> + .data = _v1_dma_data
> + },
> {}
> };
> MODULE_DEVICE_TABLE(of, k3_pdma_dt_ids);
> @@ -810,6 +830,7 @@ static struct dma_chan *k3_of_dma_simple_xlate(struct
> of_phandle_args *dma_spec,
>
> static int k3_dma_probe(struct platform_device *op)
> {
> + const struct k3dma_soc_data *soc_data;
> struct k3_dma_dev *d;
> const struct of_device_id *of_id;
> struct resource *iores;
> @@ -823,6 +844,10 @@ static int k3_dma_probe(struct platform_device *op)
> if (!d)
> return -ENOMEM;
>
> + soc_data = device_get_match_data(>dev);
> + if (!soc_data)
> + return -EINVAL;
> +
> d->base = devm_ioremap_resource(>dev, iores);
> if (IS_ERR(d->base))
> return PTR_ERR(d->base);
> @@ -835,10 +860,12 @@ static int k3_dma_probe(struct platform_device *op)
> "dma-requests", >dma_requests);
> }
>
> - d->clk = devm_clk_get(>dev, NULL);
> - if (IS_ERR(d->clk)) {
> - dev_err(>dev, "no dma clk\n");
> - return PTR_ERR(d->clk);
> + if (!(soc_data->flags & K3_FLAG_NOCLK)) {
> + d->clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(d->clk)) {
> + dev_err(>dev, "no dma clk\n");
> + return PTR_ERR(d->clk);
> + }
> }
>
> irq = platform_get_irq(op, 0);
> --
> 2.7.4
>
Re: [PATCH 0/8 v2] k3dma patches to add support for hi3660/HiKey960
Hi John, On Fri, Jan 04, 2019 at 12:56:20PM -0800, John Stultz wrote: > This patch series is based on recent work by Tanglei Han, and > adds support for hi3660 SoCs as found on the HiKey960 board, Not sure about the description/subject here! This patchset adds support for ASP DMAC found in HI3660 SoCs, Peripheral DMAC is already supported. Thanks, Mani > along with a few patches I've been carrying. > > Review and feedback would be greatly appreciated! > > thanks > -john > > Cc: Tanglei Han > Cc: Zhuangluan Su > Cc: Dan Williams > Cc: Vinod Koul > Cc: Wei Xu > Cc: Mark Rutland > Cc: Rob Herring > Cc: Guodong Xu > Cc: Manivannan Sadhasivam > Cc: Ryan Grachek > CC: devicet...@vger.kernel.org > Cc: dmaeng...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > > John Stultz (3): > Documentation: bindings: k3dma: Add binding for dma-avail-chan > arm64: dts: hi3660: Add dma to uart nodes > arm64: dts: hi3660: Fixup unofficial dma-min-chan to dma-avail-chan > > Li Yu (2): > dma: k3dma: Delete axi_config > dma: k3dma: Add support to dma_avail_chan > > Youlin Wang (3): > Documentation: bindings: k3dma: Extend the k3dma driver binding to > support hisi-asp > dma: k3dma: Upgrade k3dma driver to support hisi_asp_dma hardware > arm64: dts: hi3660: Add hisi asp dma device > > Documentation/devicetree/bindings/dma/k3dma.txt | 7 ++- > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 22 - > drivers/dma/k3dma.c | 60 > + > 3 files changed, 78 insertions(+), 11 deletions(-) > > -- > 2.7.4 >
RE: [PATCH v2 1/2] virtio-balloon: tweak config_changed implementation
On Friday, January 4, 2019 11:45 PM, Michael S. Tsirkin wrote:
> > struct virtio_balloon {
> > struct virtio_device *vdev;
> > struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
> > @@ -77,6 +81,8 @@ struct virtio_balloon {
> > /* Prevent updating balloon when it is being canceled. */
> > spinlock_t stop_update_lock;
> > bool stop_update;
> > + /* Bitmap to indicate if reading the related config fields are needed
> */
> > + unsigned long config_read_bitmap;
> >
> > /* The list of allocated free pages, waiting to be given back to mm */
> > struct list_head free_page_list;
>
> It seems that you never initialize this bitmap. Probably harmless here but
> generally using uninitialized memory isn't good.
We've used kzalloc to allocate the vb struct, so it's already 0-initialized :)
> > +
> > static int send_free_pages(struct virtio_balloon *vb) {
> > int err;
> > @@ -620,6 +630,7 @@ static int send_free_pages(struct virtio_balloon *vb)
> > * stop the reporting.
> > */
> > cmd_id_active = virtio32_to_cpu(vb->vdev, vb-
> >cmd_id_active);
> > + virtio_balloon_read_cmd_id_received(vb);
[1]
> > if (cmd_id_active != vb->cmd_id_received)
> > break;
> >
> > @@ -637,11 +648,9 @@ static int send_free_pages(struct virtio_balloon
> *vb)
> > return 0;
> > }
> >
> > -static void report_free_page_func(struct work_struct *work)
> > +static void virtio_balloon_report_free_page(struct virtio_balloon
> > +*vb)
> > {
> > int err;
> > - struct virtio_balloon *vb = container_of(work, struct virtio_balloon,
> > -report_free_page_work);
> > struct device *dev = >vdev->dev;
> >
> > /* Start by sending the received cmd id to host with an outbuf. */
> > @@ -659,6 +668,22 @@ static void report_free_page_func(struct
> work_struct *work)
> > dev_err(dev, "Failed to send a stop id, err = %d\n", err); }
> >
> > +static void report_free_page_func(struct work_struct *work) {
> > + struct virtio_balloon *vb = container_of(work, struct virtio_balloon,
> > +report_free_page_work);
> > +
> > + virtio_balloon_read_cmd_id_received(vb);
>
> This will not achieve what you are trying to do, which is cancel reporting if
> it's
> in progress.
>
> You need to re-read each time you compare to cmd_id_active.
Yes, already did, please see [1] above
> An API similar to
> u32 virtio_balloon_cmd_id_received(vb)
> seems to be called for, and I would rename cmd_id_received to
> cmd_id_received_cache to make sure we caught all users.
>
I'm not sure about adding "cache" here, cmd_id_received refers to the cmd id
that the driver just received from the device. There is one called
"cmd_id_active" which
is the one that the driver is actively using.
So cmd_id_received is already a "cache" to " cmd_id_active " in some sense.
Best,
Wei
[RFT][PATCH] regulator: bcm590xx: Fix .enable_reg for BCM590XX_REG_VSR
Current implementation missed the case BCM590XX_REG_VSR, so bcm590xx_get_enable_register() returns 0 when id is BCM590XX_REG_VSR. Signed-off-by: Axel Lin --- Hi Matt, Current code looks strange becasue bcm590xx_get_enable_register() returns 0 for BCM590XX_REG_VSR but there is a BCM590XX_VSRPMCTRL1 defined in the code. I don't have the h/w, and I even cannot find the datasheet on the internet. I might be wrong, but just in case this might fix a real bug. Please help to review and test this patch. Thanks, Axel drivers/regulator/bcm590xx-regulator.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/regulator/bcm590xx-regulator.c b/drivers/regulator/bcm590xx-regulator.c index 92d6d7b10cf7..e49c0a7d5dd5 100644 --- a/drivers/regulator/bcm590xx-regulator.c +++ b/drivers/regulator/bcm590xx-regulator.c @@ -242,8 +242,12 @@ static int bcm590xx_get_enable_register(int id) case BCM590XX_REG_SDSR2: reg = BCM590XX_SDSR2PMCTRL1; break; + case BCM590XX_REG_VSR: + reg = BCM590XX_VSRPMCTRL1; + break; case BCM590XX_REG_VBUS: reg = BCM590XX_OTG_CTRL; + break; } -- 2.17.1
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Sat, Jan 05, 2019 at 10:37:17AM +0800, kbuild test robot wrote: > Hi Jason, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.20 next-20190103] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Jason-Gunthorpe/lib-scatterlist-Provide-a-DMA-page-iterator/20190105-081739 > config: x86_64-randconfig-x017-201900 (attached as .config) > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All error/warnings (new ones prefixed by >>): > >In file included from lib/scatterlist.c:9:0: > >> include/linux/export.h:81:20: error: redefinition of > >> '__kstrtab___sg_page_iter_next' > static const char __kstrtab_##sym[]\ >^ >include/linux/export.h:120:25: note: in expansion of macro > '___EXPORT_SYMBOL' > #define __EXPORT_SYMBOL ___EXPORT_SYMBOL > ^~~~ >include/linux/export.h:124:2: note: in expansion of macro '__EXPORT_SYMBOL' > __EXPORT_SYMBOL(sym, "") > ^~~ > >> lib/scatterlist.c:652:1: note: in expansion of macro 'EXPORT_SYMBOL' > EXPORT_SYMBOL(__sg_page_iter_next); > ^ Woops, should be __sg_page_dma_iter_next.. Will resend after getting some feedback. Jason
Re: [PATCH] perf stat: Poll for monitored tasks being alive in fork mode
On 1/4/2019 8:54 PM, Jiri Olsa wrote:
On Fri, Jan 04, 2019 at 10:28:17AM +0800, Jin Yao wrote:
Following test shows the stat keeps running even if no longer
task to monitor (mgen exits at ~5s).
perf stat -e cycles -p `pgrep mgen` -I1000 -- sleep 10
time counts unit events
1.000148916 1,308,365,864 cycles
2.000379171 1,297,269,875 cycles
3.000556719 1,297,187,078 cycles
4.000914241761,261,827 cycles
5.001306091cycles
6.001676881cycles
7.002046336cycles
8.002405651cycles
9.002766625cycles
10.001395827cycles
We'd better finish stat immediately if there's no longer task to
monitor.
After:
perf stat -e cycles -p `pgrep mgen` -I1000 -- sleep 10
time counts unit events
1.000180062 1,236,592,661 cycles
2.000421539 1,223,733,572 cycles
3.000609910 1,297,047,663 cycles
4.000807545 1,297,215,816 cycles
5.001001578 1,297,208,032 cycles
6.001390345582,343,659 cycles
sleep: Terminated
Now the stat exits immediately when the monitored tasks ends.
Signed-off-by: Jin Yao
---
tools/perf/builtin-stat.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 63a3afc..71f3bc8 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -553,6 +553,13 @@ static int __run_perf_stat(int argc, const char **argv,
int run_idx)
if (interval || timeout) {
while (!waitpid(child_pid, , WNOHANG)) {
+ if (!is_target_alive(,
+ evsel_list->threads) &&
+ (child_pid != -1)) {
do we need that child_pid check? we just returned from waitpid
so we should be ok.. we just make the race window smaller
could we just do:
if (!is_target_alive(,
evsel_list->threads)) {
kill(child_pid, SIGTERM);
break;
}
I think this code should be OK and I have tested yet. I have a question
about the race condition, we really don't need a lock to protect the
child_pid?
skip_signal()
{
/*
* render child_pid harmless
* won't send SIGTERM to a random
* process in case of race condition
* and fast PID recycling
*/
child_pid = -1;
}
__run_perf_stat()
{
kill(child_pid, SIGTERM);
}
If child_pid is set by -1 in a small window between checking of
child_pid and kill(), then kill(-1, SIGTERM) may happen. All processes
except the kill process itself and init would receive SIGTERM.
Is this case possible?
also I'm not sure we should do this only under new option,
as it might break people's scripts.. thoughts?
jirka
In current behavior, for non fork mode, if we terminate the monitored
task, the perf stat would return immediately. So I think this patch
should be OK.
Thanks
Jin Yao
+ kill(child_pid, SIGTERM);
+ break;
+ }
+
nanosleep(, NULL);
if (timeout)
break;
--
2.7.4
[PATCH v2 1/2] dt-bindings: hwmon: ina3221: Add ti,single-shot property
By default, ina3221, as a hardware monitor, continuously measures the inputs and generates corresponding data. However, for battery powered devices, this mode might be power consuming. This patch adds a "ti,single-shot" property to allow changing the default continuous mode to single-shot operating mode. Signed-off-by: Nicolin Chen --- Documentation/devicetree/bindings/hwmon/ina3221.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/hwmon/ina3221.txt b/Documentation/devicetree/bindings/hwmon/ina3221.txt index a7b25caa2b8e..fa63b6171407 100644 --- a/Documentation/devicetree/bindings/hwmon/ina3221.txt +++ b/Documentation/devicetree/bindings/hwmon/ina3221.txt @@ -6,6 +6,16 @@ Texas Instruments INA3221 Device Tree Bindings - reg: I2C address Optional properties: + - ti,single-shot: This chip has two power modes: single-shot (chip takes one +measurement and then shuts itself down) and continuous ( +chip takes continuous measurements). The continuous mode is +more reliable and suitable for hardware monitor type device, +but the single-shot mode is more power-friendly and useful +for battery-powered device which cares power consumptions +while still needs some measurements occasionally. +If this property is present, the single-shot mode will be +used, instead of the default continuous one for monitoring. + = The node contains optional child nodes for three channels = = Each child node describes the information of input source = -- 2.17.1
[PATCH v2 2/2] hwmon: (ina3221) Implement ti,single-shot DT property
By default, ina3221, as a hardware monitor, continuously measures
the inputs and generates corresponding data. However, for battery
powered devices, this mode might be power consuming.
The DT binding doc is updated with a new boolean type property to
allow changing the default operating mode from consuming mode to
single-shot mode, which will measure input on demand and then shut
down to save power.
So this patch implements the DT property accordingly.
Signed-off-by: Nicolin Chen
---
Changelog
v1->v2:
* Replaced the useless mode defines with a boolean variable.
drivers/hwmon/ina3221.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
index e90ccac8bebb..4258a6ebe195 100644
--- a/drivers/hwmon/ina3221.c
+++ b/drivers/hwmon/ina3221.c
@@ -111,6 +111,7 @@ struct ina3221_input {
* @inputs: Array of channel input source specific structures
* @lock: mutex lock to serialize sysfs attribute accesses
* @reg_config: Register value of INA3221_CONFIG
+ * @single_shot: running in single-shot operating mode
*/
struct ina3221_data {
struct device *pm_dev;
@@ -119,6 +120,8 @@ struct ina3221_data {
struct ina3221_input inputs[INA3221_NUM_CHANNELS];
struct mutex lock;
u32 reg_config;
+
+ bool single_shot;
};
static inline bool ina3221_is_enabled(struct ina3221_data *ina, int channel)
@@ -188,6 +191,11 @@ static int ina3221_read_in(struct device *dev, u32 attr,
int channel, long *val)
if (!ina3221_is_enabled(ina, channel))
return -ENODATA;
+ /* Write CONFIG register to trigger a single-shot measurement */
+ if (ina->single_shot)
+ regmap_write(ina->regmap, INA3221_CONFIG,
+ina->reg_config);
+
ret = ina3221_wait_for_data(ina);
if (ret)
return ret;
@@ -232,6 +240,11 @@ static int ina3221_read_curr(struct device *dev, u32 attr,
if (!ina3221_is_enabled(ina, channel))
return -ENODATA;
+ /* Write CONFIG register to trigger a single-shot measurement */
+ if (ina->single_shot)
+ regmap_write(ina->regmap, INA3221_CONFIG,
+ina->reg_config);
+
ret = ina3221_wait_for_data(ina);
if (ret)
return ret;
@@ -617,6 +630,9 @@ static int ina3221_probe_from_dt(struct device *dev, struct
ina3221_data *ina)
if (!np)
return 0;
+ if (of_property_read_bool(np, "ti,single-shot"))
+ ina->single_shot = true;
+
for_each_child_of_node(np, child) {
ret = ina3221_probe_child_from_dt(dev, child, ina);
if (ret)
@@ -666,6 +682,10 @@ static int ina3221_probe(struct i2c_client *client,
/* The driver will be reset, so use reset value */
ina->reg_config = INA3221_CONFIG_DEFAULT;
+ /* Clear continuous bit to use single-shot mode */
+ if (ina->single_shot)
+ ina->reg_config &= ~INA3221_CONFIG_MODE_CONTINUOUS;
+
/* Disable channels if their inputs are disconnected */
for (i = 0; i < INA3221_NUM_CHANNELS; i++) {
if (ina->inputs[i].disconnected)
--
2.17.1
[PATCH v2 0/2] hwmon (ina3221) Add single-shot mode support
By default, ina3221, as a hardware monitor, continuously measures the inputs and generates corresponding data. However, for battery powered devices, this mode might be power consuming. This series of patches add a feature of changing default operating mode to its single-shot mode via DT. Changelog v1->v2: * Cleaned-up PATCH-2 Nicolin Chen (2): dt-bindings: hwmon: ina3221: Add ti,single-shot property hwmon: (ina3221) Implement ti,single-shot DT property .../devicetree/bindings/hwmon/ina3221.txt | 10 ++ drivers/hwmon/ina3221.c | 20 +++ 2 files changed, 30 insertions(+) -- 2.17.1
[PATCH] kconfig: rename generated .*conf-cfg to *conf-cfg
Remove the dot-prefixing since it is just a matter of the .gitignore file. Signed-off-by: Masahiro Yamada --- scripts/kconfig/.gitignore | 1 + scripts/kconfig/Makefile | 36 ++-- 2 files changed, 19 insertions(+), 18 deletions(-) diff --git a/scripts/kconfig/.gitignore b/scripts/kconfig/.gitignore index 0aabc1d..b5bf92f 100644 --- a/scripts/kconfig/.gitignore +++ b/scripts/kconfig/.gitignore @@ -2,6 +2,7 @@ # Generated files # *.moc +*conf-cfg # # configuration programs diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 679e62e..c05ab00 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -157,53 +157,53 @@ conf-objs := conf.o $(common-objs) hostprogs-y+= nconf nconf-objs := nconf.o nconf.gui.o $(common-objs) -HOSTLDLIBS_nconf = $(shell . $(obj)/.nconf-cfg && echo $$libs) -HOSTCFLAGS_nconf.o = $(shell . $(obj)/.nconf-cfg && echo $$cflags) -HOSTCFLAGS_nconf.gui.o = $(shell . $(obj)/.nconf-cfg && echo $$cflags) +HOSTLDLIBS_nconf = $(shell . $(obj)/nconf-cfg && echo $$libs) +HOSTCFLAGS_nconf.o = $(shell . $(obj)/nconf-cfg && echo $$cflags) +HOSTCFLAGS_nconf.gui.o = $(shell . $(obj)/nconf-cfg && echo $$cflags) -$(obj)/nconf.o $(obj)/nconf.gui.o: $(obj)/.nconf-cfg +$(obj)/nconf.o $(obj)/nconf.gui.o: $(obj)/nconf-cfg # mconf: Used for the menuconfig target based on lxdialog hostprogs-y+= mconf lxdialog := checklist.o inputbox.o menubox.o textbox.o util.o yesno.o mconf-objs := mconf.o $(addprefix lxdialog/, $(lxdialog)) $(common-objs) -HOSTLDLIBS_mconf = $(shell . $(obj)/.mconf-cfg && echo $$libs) +HOSTLDLIBS_mconf = $(shell . $(obj)/mconf-cfg && echo $$libs) $(foreach f, mconf.o $(lxdialog), \ - $(eval HOSTCFLAGS_$f = $$(shell . $(obj)/.mconf-cfg && echo cflags))) + $(eval HOSTCFLAGS_$f = $$(shell . $(obj)/mconf-cfg && echo cflags))) -$(obj)/mconf.o: $(obj)/.mconf-cfg -$(addprefix $(obj)/lxdialog/, $(lxdialog)): $(obj)/.mconf-cfg +$(obj)/mconf.o: $(obj)/mconf-cfg +$(addprefix $(obj)/lxdialog/, $(lxdialog)): $(obj)/mconf-cfg # qconf: Used for the xconfig target based on Qt hostprogs-y+= qconf qconf-cxxobjs := qconf.o qconf-objs := images.o $(common-objs) -HOSTLDLIBS_qconf = $(shell . $(obj)/.qconf-cfg && echo $$libs) -HOSTCXXFLAGS_qconf.o = $(shell . $(obj)/.qconf-cfg && echo $$cflags) +HOSTLDLIBS_qconf = $(shell . $(obj)/qconf-cfg && echo $$libs) +HOSTCXXFLAGS_qconf.o = $(shell . $(obj)/qconf-cfg && echo $$cflags) -$(obj)/qconf.o: $(obj)/.qconf-cfg $(obj)/qconf.moc +$(obj)/qconf.o: $(obj)/qconf-cfg $(obj)/qconf.moc quiet_cmd_moc = MOC $@ - cmd_moc = $(shell . $(obj)/.qconf-cfg && echo $$moc) -i $< -o $@ + cmd_moc = $(shell . $(obj)/qconf-cfg && echo $$moc) -i $< -o $@ -$(obj)/%.moc: $(src)/%.h $(obj)/.qconf-cfg +$(obj)/%.moc: $(src)/%.h $(obj)/qconf-cfg $(call cmd,moc) # gconf: Used for the gconfig target based on GTK+ hostprogs-y+= gconf gconf-objs := gconf.o images.o $(common-objs) -HOSTLDLIBS_gconf= $(shell . $(obj)/.gconf-cfg && echo $$libs) -HOSTCFLAGS_gconf.o = $(shell . $(obj)/.gconf-cfg && echo $$cflags) +HOSTLDLIBS_gconf= $(shell . $(obj)/gconf-cfg && echo $$libs) +HOSTCFLAGS_gconf.o = $(shell . $(obj)/gconf-cfg && echo $$cflags) -$(obj)/gconf.o: $(obj)/.gconf-cfg +$(obj)/gconf.o: $(obj)/gconf-cfg # check if necessary packages are available, and configure build flags filechk_conf_cfg = $(CONFIG_SHELL) $< -$(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE +$(obj)/%conf-cfg: $(src)/%conf-cfg.sh FORCE $(call filechk,conf_cfg) -clean-files += .*conf-cfg +clean-files += conf-cfg -- 2.7.4
Re: [PATCH net 0/4] net: bpfilter: fix two bugs in bpfilter
On Sat, 5 Jan 2019 at 05:54, David Miller wrote: > > From: Taehee Yoo > Date: Mon, 31 Dec 2018 01:30:45 +0900 > > > This patches fix two bugs in the bpfilter_umh which are related in > > iptables command. > ... > > I am still thinking about these patches, sorry for taking so long to > give a response. > > Thank you. Thank you for letting me know!
Re: [PATCH 2/2] hwmon: (ina3221) Implement ti,single-shot DT property
On Fri, Jan 04, 2019 at 06:37:55PM -0800, Guenter Roeck wrote:
> > +enum ina3221_modes {
> > + INA3221_MODE_SINGLE_SHOT,
> > + INA3221_MODE_CONTINUOUS,
> > + INA3221_NUM_MODES,
>
> Is NUM_MODES used anywhere ? Please drop unless there is a reason to keep it.
Will clean it up in v2.
Thanks
Nicolin
Re: [PATCH 1/4] rtlwifi: rtl8723ae: Take the FW LPS mode handling out
On 1/4/19 6:48 AM, Bernd Edlinger wrote:
This appears to trigger a firmware bug and causes severe
problems with rtl8723ae PCI devices.
When the power save mode is activated for longer periods
of time the firmware stops to receive any packets.
This problem was exposed by commit 873ffe154ae0 ("rtlwifi:
Fix logic error in enter/exit power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
While the Realtek firmware group has a chance to look for a bug, I would like
you to perform a couple of tests on the original code.
The driver has three module parameters that affect power save. The 'modinfo
rtl8723ae' command lists them as
parm: ips:Set to 0 to not use link power save (default 1) (bool)
parm: swlps:Set to 1 to use SW control power save (default 0) (bool)
parm: fwlps:Set to 1 to use FW control power save (default 1) (bool)
If you were to load rtl8723ae with 'ips=0', does it still fail?
If you were to load the driver with 'swlps=1 fwlps=0', does it still fail?
Thanks for debugging this problem.
Larry
Re: [PATCH] x86: only use ERMS for user copies for larger sizes
Coming back to this old thread, because I've spent most of the day
resurrecting some of my old core x86 patches, and one of them was for
the issue David Laight complained about: horrible memcpy_toio()
performance.
Yes, I should have done this before the merge window instead of at the
end of it, but I didn't want to delay things for yet another release
just because it fell through some cracks.
Anyway, it would be lovely to hear whether memcpy_toio() now works
reasonably. I just picked our very old legacy function for this, so it
will do things in 32-bit chunks (even on x86-64), and I'm certainly
open to somebody doing something smarter, but considering that nobody
else seemed to show any interest in this at all, I just went
"whatever, good enough".
I tried to make it easy to improve on things if people want to.
The other ancient patch I resurrected was the old "use asm goto for
put_user" which I've had in a private branch for the last almost three
years.
I've tried to test this (it turns out I had completely screwed up the
32-bit case for put_user, for example), but I only have 64-bit user
space, so the i386 build ended up being just about building and
looking superficially at the code generation in a couple of places.
More testing and comments appreciated.
Now I have no ancient patches in any branches, or any known pending
issue. Except for all the pull requests that are piling up because I
didn't do them today since I was spending time on my own patches.
Oh well. There's always tomorrow.
Linus
On Mon, Nov 26, 2018 at 2:26 AM David Laight wrote:
>
> From: Linus Torvalds
> > Sent: 23 November 2018 16:36
> ...
> > End result: we *used* to do this right. For the last eight years our
> > "memcpy_{to,from}io()" has been entirely broken, and apparently even
> > the people who noticed oddities like David, never reported it as
> > breakage but instead just worked around it in drivers.
>
> I've mentioned it several times...
>
> Probably no one else noticed lots of single byte transfers while
> testing a TLP monitor he was writing for an FPGA :-)
> They are far too expensive to buy, and would never be connected
> to the right system at the right time - so we (I) wrote one.
>
> Unfortunately we don't really get to see what happens when the
> link comes up (or rather doesn't come up). We only get the
> LTSSM state transitions.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jason-Gunthorpe/lib-scatterlist-Provide-a-DMA-page-iterator/20190105-081739
config: x86_64-randconfig-x017-201900 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from lib/scatterlist.c:9:0:
>> include/linux/export.h:81:20: error: redefinition of
>> '__kstrtab___sg_page_iter_next'
static const char __kstrtab_##sym[]\
^
include/linux/export.h:120:25: note: in expansion of macro '___EXPORT_SYMBOL'
#define __EXPORT_SYMBOL ___EXPORT_SYMBOL
^~~~
include/linux/export.h:124:2: note: in expansion of macro '__EXPORT_SYMBOL'
__EXPORT_SYMBOL(sym, "")
^~~
>> lib/scatterlist.c:652:1: note: in expansion of macro 'EXPORT_SYMBOL'
EXPORT_SYMBOL(__sg_page_iter_next);
^
include/linux/export.h:81:20: note: previous definition of
'__kstrtab___sg_page_iter_next' was here
static const char __kstrtab_##sym[]\
^
include/linux/export.h:120:25: note: in expansion of macro '___EXPORT_SYMBOL'
#define __EXPORT_SYMBOL ___EXPORT_SYMBOL
^~~~
include/linux/export.h:124:2: note: in expansion of macro '__EXPORT_SYMBOL'
__EXPORT_SYMBOL(sym, "")
^~~
lib/scatterlist.c:626:1: note: in expansion of macro 'EXPORT_SYMBOL'
EXPORT_SYMBOL(__sg_page_iter_next);
^
vim +/__kstrtab___sg_page_iter_next +81 include/linux/export.h
7290d580 Ard Biesheuvel 2018-08-21 76
f5016932 Paul Gortmaker 2011-05-23 77 /* For every exported symbol, place a
struct in the __ksymtab section */
f2355416 Nicolas Pitre 2016-01-22 78 #define ___EXPORT_SYMBOL(sym, sec)
\
f5016932 Paul Gortmaker 2011-05-23 79 extern typeof(sym) sym;
\
f5016932 Paul Gortmaker 2011-05-23 80 __CRC_SYMBOL(sym, sec)
\
f5016932 Paul Gortmaker 2011-05-23 @81 static const char
__kstrtab_##sym[] \
7290d580 Ard Biesheuvel 2018-08-21 82
__attribute__((section("__ksymtab_strings"), used, aligned(1))) \
94e58e0a Masahiro Yamada 2018-05-09 83 = #sym;
\
7290d580 Ard Biesheuvel 2018-08-21 84 __KSYMTAB_ENTRY(sym, sec)
f5016932 Paul Gortmaker 2011-05-23 85
:: The code at line 81 was first introduced by commit
:: f50169324df4ad942e544386d136216c8617636a module.h: split out the
EXPORT_SYMBOL into export.h
:: TO: Paul Gortmaker
:: CC: Paul Gortmaker
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 2/2] hwmon: (ina3221) Implement ti,single-shot DT property
On 1/4/19 4:49 PM, Nicolin Chen wrote:
By default, ina3221, as a hardware monitor, continuously measures
the inputs and generates corresponding data. However, for battery
powered devices, this mode might be power consuming.
The DT binding doc is updated with a new boolean type property to
allow changing the default operating mode from consuming mode to
single-shot mode, which will measure input on demand and then shut
down to save power.
So this patch implements the DT property accordingly.
Signed-off-by: Nicolin Chen
---
drivers/hwmon/ina3221.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
index e90ccac8bebb..152735659e19 100644
--- a/drivers/hwmon/ina3221.c
+++ b/drivers/hwmon/ina3221.c
@@ -91,6 +91,12 @@ enum ina3221_channels {
INA3221_NUM_CHANNELS
};
+enum ina3221_modes {
+ INA3221_MODE_SINGLE_SHOT,
+ INA3221_MODE_CONTINUOUS,
+ INA3221_NUM_MODES,
Is NUM_MODES used anywhere ? Please drop unless there is a reason to keep it.
Guenter
+};
+
/**
* struct ina3221_input - channel input source specific information
* @label: label of channel input source
@@ -111,6 +117,7 @@ struct ina3221_input {
* @inputs: Array of channel input source specific structures
* @lock: mutex lock to serialize sysfs attribute accesses
* @reg_config: Register value of INA3221_CONFIG
+ * @mode: Operating mode -- continuous or single-shot
*/
struct ina3221_data {
struct device *pm_dev;
@@ -119,6 +126,7 @@ struct ina3221_data {
struct ina3221_input inputs[INA3221_NUM_CHANNELS];
struct mutex lock;
u32 reg_config;
+ enum ina3221_modes mode;
};
static inline bool ina3221_is_enabled(struct ina3221_data *ina, int channel)
@@ -188,6 +196,11 @@ static int ina3221_read_in(struct device *dev, u32 attr,
int channel, long *val)
if (!ina3221_is_enabled(ina, channel))
return -ENODATA;
+ /* Write CONFIG register to trigger a single-shot measurement */
+ if (ina->mode == INA3221_MODE_SINGLE_SHOT)
+ regmap_write(ina->regmap, INA3221_CONFIG,
+ina->reg_config);
+
ret = ina3221_wait_for_data(ina);
if (ret)
return ret;
@@ -232,6 +245,11 @@ static int ina3221_read_curr(struct device *dev, u32 attr,
if (!ina3221_is_enabled(ina, channel))
return -ENODATA;
+ /* Write CONFIG register to trigger a single-shot measurement */
+ if (ina->mode == INA3221_MODE_SINGLE_SHOT)
+ regmap_write(ina->regmap, INA3221_CONFIG,
+ina->reg_config);
+
ret = ina3221_wait_for_data(ina);
if (ret)
return ret;
@@ -617,6 +635,9 @@ static int ina3221_probe_from_dt(struct device *dev, struct
ina3221_data *ina)
if (!np)
return 0;
+ if (of_property_read_bool(np, "ti,single-shot"))
+ ina->mode = INA3221_MODE_SINGLE_SHOT;
+
for_each_child_of_node(np, child) {
ret = ina3221_probe_child_from_dt(dev, child, ina);
if (ret)
@@ -654,6 +675,9 @@ static int ina3221_probe(struct i2c_client *client,
}
}
+ /* Hardware default uses the continuous mode */
+ ina->mode = INA3221_MODE_CONTINUOUS;
+
for (i = 0; i < INA3221_NUM_CHANNELS; i++)
ina->inputs[i].shunt_resistor = INA3221_RSHUNT_DEFAULT;
@@ -666,6 +690,10 @@ static int ina3221_probe(struct i2c_client *client,
/* The driver will be reset, so use reset value */
ina->reg_config = INA3221_CONFIG_DEFAULT;
+ /* Clear continuous bit to use single-shot mode */
+ if (ina->mode == INA3221_MODE_SINGLE_SHOT)
+ ina->reg_config &= ~INA3221_CONFIG_MODE_CONTINUOUS;
+
/* Disable channels if their inputs are disconnected */
for (i = 0; i < INA3221_NUM_CHANNELS; i++) {
if (ina->inputs[i].disconnected)
Re: [GIT PULL] sound updates for 4.21
On 1/4/19 6:34 PM, Azat Khuzhin wrote: This is unfortunately a known issue with this driver, Takashi and I had a couple of email threads on this. Even without errors removing the module doesn't seem to release all resources. I don't like this at all, and for the Sound Open Firmware (SOF) driver I mandated module load-unload as a functional requirement along with zero warnings w/ Sparse, Coccinelle and friends, but on this legacy code I am afraid there is no simple fix - at least not in a merge window or a single kernel cycle. And the fact that kernel crashes after? Just want extra confirmation The kernel crash is related to an HDMI issue that we haven't been able to reproduce on our development and validation devices so far but that's not an excuse and we do need to figure it out. Things work e.g. fine with the KBL Dell XPS13 but not on Linus' SKL Dell XPS13 device, so I'll get one and will also work on additional devices remotely.
[PATCH 10/21] ASoC: rt274: fix boolean tests
Reported by Coccinelle:
sound/soc/codecs/rt274.c:958:6-8: WARNING: Comparison to bool
sound/soc/codecs/rt274.c:961:6-9: WARNING: Comparison to bool
sound/soc/codecs/rt274.c:384:5-7: WARNING: Comparison to bool
sound/soc/codecs/rt274.c:387:5-8: WARNING: Comparison to bool
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/rt274.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/rt274.c b/sound/soc/codecs/rt274.c
index e2855ab9a2c6..9e88f7b25d38 100644
--- a/sound/soc/codecs/rt274.c
+++ b/sound/soc/codecs/rt274.c
@@ -381,10 +381,10 @@ static void rt274_jack_detect_work(struct work_struct
*work)
if (rt274_jack_detect(rt274, , ) < 0)
return;
- if (hp == true)
+ if (hp)
status |= SND_JACK_HEADPHONE;
- if (mic == true)
+ if (mic)
status |= SND_JACK_MICROPHONE;
snd_soc_jack_report(rt274->jack, status,
@@ -955,10 +955,10 @@ static irqreturn_t rt274_irq(int irq, void *data)
ret = rt274_jack_detect(rt274, , );
if (ret == 0) {
- if (hp == true)
+ if (hp)
status |= SND_JACK_HEADPHONE;
- if (mic == true)
+ if (mic)
status |= SND_JACK_MICROPHONE;
snd_soc_jack_report(rt274->jack, status,
--
2.17.1
[PATCH 19/21] ASoC: da7219: use logical AND
Reported by Sparse: da7219.c:841:57: warning: dubious: x & !y Cc: Adam Thomson Signed-off-by: Pierre-Louis Bossart --- sound/soc/codecs/da7219.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c index ce165047b9f9..513ec0368653 100644 --- a/sound/soc/codecs/da7219.c +++ b/sound/soc/codecs/da7219.c @@ -838,7 +838,7 @@ static int da7219_dai_event(struct snd_soc_dapm_widget *w, ++i; msleep(50); } - } while ((i < DA7219_SRM_CHECK_RETRIES) & (!srm_lock)); + } while ((i < DA7219_SRM_CHECK_RETRIES) && (!srm_lock)); if (!srm_lock) dev_warn(component->dev, "SRM failed to lock\n"); -- 2.17.1
[PATCH 16/21] ASoC: tscs42xx.c: fix boolean test
Reported by Coccinelle:
sound/soc/codecs/tscs42xx.c:392:5-31: WARNING: Comparison to bool
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/tscs42xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
index 7396a6e5277e..27b8c6ba72fa 100644
--- a/sound/soc/codecs/tscs42xx.c
+++ b/sound/soc/codecs/tscs42xx.c
@@ -389,7 +389,7 @@ static int dac_event(struct snd_soc_dapm_widget *w,
mutex_lock(>coeff_ram_lock);
- if (tscs42xx->coeff_ram_synced == false) {
+ if (!tscs42xx->coeff_ram_synced) {
ret = write_coeff_ram(component, tscs42xx->coeff_ram, 0x00,
COEFF_RAM_COEFF_COUNT);
if (ret < 0)
--
2.17.1
[PATCH 15/21] ASoC: nau8824: fix boolean assignment
Reported by Coccinelle:
nau8824.c:810:6-12: ERROR: Assignment of bool to non-0/1 constant
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/nau8824.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/nau8824.c b/sound/soc/codecs/nau8824.c
index 468d5143e2c4..87ed3dc496dc 100644
--- a/sound/soc/codecs/nau8824.c
+++ b/sound/soc/codecs/nau8824.c
@@ -807,7 +807,7 @@ static const struct snd_soc_dapm_route
nau8824_dapm_routes[] = {
static bool nau8824_is_jack_inserted(struct nau8824 *nau8824)
{
struct snd_soc_jack *jack = nau8824->jack;
- bool insert = FALSE;
+ bool insert = false;
if (nau8824->irq && jack)
insert = jack->status & SND_JACK_HEADPHONE;
--
2.17.1
[PATCH 13/21] ASoC: max98927: fix boolean assignments
Reported by Coccinelle:
sound/soc/codecs/max98927.c:508:2-20: WARNING: Assignment of bool to 0/1
sound/soc/codecs/max98927.c:889:3-28: WARNING: Assignment of bool to 0/1
sound/soc/codecs/max98927.c:891:3-28: WARNING: Assignment of bool to 0/1
sound/soc/codecs/max98927.c:893:2-27: WARNING: Assignment of bool to 0/1
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/max98927.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
index 065303a46535..e53d2007f3be 100644
--- a/sound/soc/codecs/max98927.c
+++ b/sound/soc/codecs/max98927.c
@@ -505,7 +505,7 @@ static int max98927_dac_event(struct snd_soc_dapm_widget *w,
switch (event) {
case SND_SOC_DAPM_PRE_PMU:
- max98927->tdm_mode = 0;
+ max98927->tdm_mode = false;
break;
case SND_SOC_DAPM_POST_PMU:
regmap_update_bits(max98927->regmap,
@@ -886,11 +886,11 @@ static int max98927_i2c_probe(struct i2c_client *i2c,
if (!of_property_read_u32(i2c->dev.of_node,
"interleave_mode", )) {
if (value > 0)
- max98927->interleave_mode = 1;
+ max98927->interleave_mode = true;
else
- max98927->interleave_mode = 0;
+ max98927->interleave_mode = false;
} else
- max98927->interleave_mode = 0;
+ max98927->interleave_mode = false;
/* regmap initialization */
max98927->regmap
--
2.17.1
[PATCH 20/21] ASoC: rt5645: store eq kcontrol byte in __be
From: Bard liao
The eq parameters binary is stored in __be. However, it is unsigned short
in rt5645_eq_param_s{} which will cause incorrect type assignment. So add
struct rt5645_eq_param_s_be16{} to store the eq binary and convert it to
unsigned short in rt5645->eq_param.
Cc: Oder Chiou
Signed-off-by: Bard liao
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/rt5645.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 52ce380c8f3a..9a0751978090 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -401,6 +401,11 @@ struct rt5645_eq_param_s {
unsigned short val;
};
+struct rt5645_eq_param_s_be16 {
+ __be16 reg;
+ __be16 val;
+};
+
static const char *const rt5645_supply_names[] = {
"avdd",
"cpvdd",
@@ -672,8 +677,8 @@ static int rt5645_hweq_get(struct snd_kcontrol *kcontrol,
{
struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
struct rt5645_priv *rt5645 = snd_soc_component_get_drvdata(component);
- struct rt5645_eq_param_s *eq_param =
- (struct rt5645_eq_param_s *)ucontrol->value.bytes.data;
+ struct rt5645_eq_param_s_be16 *eq_param =
+ (struct rt5645_eq_param_s_be16 *)ucontrol->value.bytes.data;
int i;
for (i = 0; i < RT5645_HWEQ_NUM; i++) {
@@ -698,36 +703,33 @@ static int rt5645_hweq_put(struct snd_kcontrol *kcontrol,
{
struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
struct rt5645_priv *rt5645 = snd_soc_component_get_drvdata(component);
- struct rt5645_eq_param_s *eq_param =
- (struct rt5645_eq_param_s *)ucontrol->value.bytes.data;
+ struct rt5645_eq_param_s_be16 *eq_param =
+ (struct rt5645_eq_param_s_be16 *)ucontrol->value.bytes.data;
int i;
for (i = 0; i < RT5645_HWEQ_NUM; i++) {
- eq_param[i].reg = be16_to_cpu(eq_param[i].reg);
- eq_param[i].val = be16_to_cpu(eq_param[i].val);
+ rt5645->eq_param[i].reg = be16_to_cpu(eq_param[i].reg);
+ rt5645->eq_param[i].val = be16_to_cpu(eq_param[i].val);
}
/* The final setting of the table should be RT5645_EQ_CTRL2 */
for (i = RT5645_HWEQ_NUM - 1; i >= 0; i--) {
- if (eq_param[i].reg == 0)
+ if (rt5645->eq_param[i].reg == 0)
continue;
- else if (eq_param[i].reg != RT5645_EQ_CTRL2)
+ else if (rt5645->eq_param[i].reg != RT5645_EQ_CTRL2)
return 0;
else
break;
}
for (i = 0; i < RT5645_HWEQ_NUM; i++) {
- if (!rt5645_validate_hweq(eq_param[i].reg) &&
- eq_param[i].reg != 0)
+ if (!rt5645_validate_hweq(rt5645->eq_param[i].reg) &&
+ rt5645->eq_param[i].reg != 0)
return 0;
- else if (eq_param[i].reg == 0)
+ else if (rt5645->eq_param[i].reg == 0)
break;
}
- memcpy(rt5645->eq_param, eq_param,
- RT5645_HWEQ_NUM * sizeof(struct rt5645_eq_param_s));
-
return 0;
}
--
2.17.1
[PATCH 17/21] ASoC: mt6351: remove unneeded variable
Reported by Coccinelle:
mt6351.c:1418:5-8: Unneeded variable: "ret". Return "0" on line 1437
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/mt6351.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/codecs/mt6351.c b/sound/soc/codecs/mt6351.c
index f73dcd753584..4b3ce01c5a93 100644
--- a/sound/soc/codecs/mt6351.c
+++ b/sound/soc/codecs/mt6351.c
@@ -1415,8 +1415,6 @@ static const struct snd_soc_dapm_route
mt6351_dapm_routes[] = {
static int mt6351_codec_init_reg(struct snd_soc_component *cmpnt)
{
- int ret = 0;
-
/* Disable CLKSQ 26MHz */
regmap_update_bits(cmpnt->regmap, MT6351_TOP_CLKSQ, 0x0001, 0x0);
/* disable AUDGLB */
@@ -1434,7 +1432,7 @@ static int mt6351_codec_init_reg(struct snd_soc_component
*cmpnt)
/* Reverse the PMIC clock*/
regmap_update_bits(cmpnt->regmap, MT6351_AFE_PMIC_NEWIF_CFG2,
0x8000, 0x8000);
- return ret;
+ return 0;
}
static int mt6351_codec_probe(struct snd_soc_component *cmpnt)
--
2.17.1
[PATCH 21/21] ASoC: rl6437a: use __be32 for a __be32 buf
From: Bard liao
The buf in rl6347a_hw_read is __be32.
Cc: Oder Chiou
Signed-off-by: Bard liao
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/rl6347a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rl6347a.c b/sound/soc/codecs/rl6347a.c
index 8f571cf8edd4..c0d729b45277 100644
--- a/sound/soc/codecs/rl6347a.c
+++ b/sound/soc/codecs/rl6347a.c
@@ -64,8 +64,8 @@ int rl6347a_hw_read(void *context, unsigned int reg, unsigned
int *value)
struct i2c_client *client = context;
struct i2c_msg xfer[2];
int ret;
- __be32 be_reg;
- unsigned int index, vid, buf = 0x0;
+ __be32 be_reg, buf = 0x0;
+ unsigned int index, vid;
/* handle index registers */
if (reg <= 0xff) {
--
2.17.1
[PATCH 18/21] ASoC: da7219: fix endianness issues
Reported by Sparse. da7219.c:440:44: warning: cast to restricted __le16 da7219.c:461:13: warning: incorrect type in assignment (different base types) da7219.c:461:13:expected unsigned short [unsigned] [usertype] val da7219.c:461:13:got restricted __le16 [usertype] da7219.c:1451:16: warning: incorrect type in assignment (different base types) da7219.c:1451:16:expected unsigned short [unsigned] [usertype] offset da7219.c:1451:16:got restricted __le16 [usertype] da7219-aad.c:150:37: warning: incorrect type in assignment (different base types) da7219-aad.c:150:37:expected unsigned short [unsigned] [usertype] tonegen_freq_hptest da7219-aad.c:150:37:got restricted __le16 [usertype] da7219-aad.c:157:37: warning: incorrect type in assignment (different base types) da7219-aad.c:157:37:expected unsigned short [unsigned] [usertype] tonegen_freq_hptest da7219-aad.c:157:37:got restricted __le16 [usertype] Cc: Adam Thomson Signed-off-by: Pierre-Louis Bossart --- sound/soc/codecs/da7219-aad.c | 2 +- sound/soc/codecs/da7219.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/da7219-aad.c b/sound/soc/codecs/da7219-aad.c index 2c7d5088e6f2..e0964b20a389 100644 --- a/sound/soc/codecs/da7219-aad.c +++ b/sound/soc/codecs/da7219-aad.c @@ -117,7 +117,7 @@ static void da7219_aad_hptest_work(struct work_struct *work) struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(component); struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component); - u16 tonegen_freq_hptest; + __le16 tonegen_freq_hptest; u8 pll_srm_sts, pll_ctrl, gain_ramp_ctrl, accdet_cfg8; int report = 0, ret = 0; diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c index e46e9f4bc994..ce165047b9f9 100644 --- a/sound/soc/codecs/da7219.c +++ b/sound/soc/codecs/da7219.c @@ -423,7 +423,7 @@ static int da7219_tonegen_freq_get(struct snd_kcontrol *kcontrol, struct soc_mixer_control *mixer_ctrl = (struct soc_mixer_control *) kcontrol->private_value; unsigned int reg = mixer_ctrl->reg; - u16 val; + __le16 val; int ret; mutex_lock(>ctrl_lock); @@ -450,7 +450,7 @@ static int da7219_tonegen_freq_put(struct snd_kcontrol *kcontrol, struct soc_mixer_control *mixer_ctrl = (struct soc_mixer_control *) kcontrol->private_value; unsigned int reg = mixer_ctrl->reg; - u16 val; + __le16 val; int ret; /* @@ -1396,7 +1396,7 @@ static int da7219_set_dai_tdm_slot(struct snd_soc_dai *dai, struct snd_soc_component *component = dai->component; struct da7219_priv *da7219 = snd_soc_component_get_drvdata(component); u8 dai_bclks_per_wclk; - u16 offset; + __le16 offset; u32 frame_size; /* No channels enabled so disable TDM, revert to 64-bit frames */ -- 2.17.1
[PATCH 11/21] ASoc: rt286: fix boolean tests
Reported by Coccinelle: sound/soc/codecs/rt286.c:927:5-7: WARNING: Comparison to bool sound/soc/codecs/rt286.c:930:5-8: WARNING: Comparison to bool sound/soc/codecs/rt286.c:299:5-7: WARNING: Comparison to bool sound/soc/codecs/rt286.c:302:5-8: WARNING: Comparison to bool Signed-off-by: Pierre-Louis Bossart --- sound/soc/codecs/rt286.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/rt286.c b/sound/soc/codecs/rt286.c index 0b0f748bffbe..c9457c247a03 100644 --- a/sound/soc/codecs/rt286.c +++ b/sound/soc/codecs/rt286.c @@ -296,10 +296,10 @@ static void rt286_jack_detect_work(struct work_struct *work) rt286_jack_detect(rt286, , ); - if (hp == true) + if (hp) status |= SND_JACK_HEADPHONE; - if (mic == true) + if (mic) status |= SND_JACK_MICROPHONE; snd_soc_jack_report(rt286->jack, status, @@ -924,10 +924,10 @@ static irqreturn_t rt286_irq(int irq, void *data) /* Clear IRQ */ regmap_update_bits(rt286->regmap, RT286_IRQ_CTRL, 0x1, 0x1); - if (hp == true) + if (hp) status |= SND_JACK_HEADPHONE; - if (mic == true) + if (mic) status |= SND_JACK_MICROPHONE; snd_soc_jack_report(rt286->jack, status, -- 2.17.1
[PATCH 04/21] ASoC: codecs: fix kernel doc descriptions
Missing or spurious parameter descriptions. Fix warnings with W=1 Signed-off-by: Pierre-Louis Bossart --- sound/soc/codecs/nau8825.c | 1 + sound/soc/codecs/rt5514.c | 1 + sound/soc/codecs/rt5677.c | 8 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/nau8825.c b/sound/soc/codecs/nau8825.c index 7bbcbf5f05c8..47e65cf99879 100644 --- a/sound/soc/codecs/nau8825.c +++ b/sound/soc/codecs/nau8825.c @@ -351,6 +351,7 @@ static void nau8825_hpvol_ramp(struct nau8825 *nau8825, * Computes log10 of a value; the result is round off to 3 decimal. This func- * tion takes reference to dvb-math. The source code locates as the following. * Linux/drivers/media/dvb-core/dvb_math.c + * @value: input for log10 * * return log10(value) * 1000 */ diff --git a/sound/soc/codecs/rt5514.c b/sound/soc/codecs/rt5514.c index a67de68b6da6..f9ad6e36ab16 100644 --- a/sound/soc/codecs/rt5514.c +++ b/sound/soc/codecs/rt5514.c @@ -489,6 +489,7 @@ static const struct snd_kcontrol_new rt5514_sto2_dmic_mux = /** * rt5514_calc_dmic_clk - Calculate the frequency divider parameter of dmic. * + * @component: only used for dev_warn * @rate: base clock rate. * * Choose divider parameter that gives the highest possible DMIC frequency in diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 9b7a1833d331..6fc70e441458 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -547,7 +547,7 @@ static bool rt5677_readable_register(struct device *dev, unsigned int reg) * @rt5677: Private Data. * @addr: Address index. * @value: Address data. - * + * @opcode: opcode value * * Returns 0 for success or negative error code. */ @@ -602,7 +602,7 @@ static int rt5677_dsp_mode_i2c_write_addr(struct rt5677_priv *rt5677, /** * rt5677_dsp_mode_i2c_read_addr - Read value from address on DSP mode. - * rt5677: Private Data. + * @rt5677: Private Data. * @addr: Address index. * @value: Address data. * @@ -651,7 +651,7 @@ static int rt5677_dsp_mode_i2c_read_addr( /** * rt5677_dsp_mode_i2c_write - Write register on DSP mode. - * rt5677: Private Data. + * @rt5677: Private Data. * @reg: Register index. * @value: Register data. * @@ -667,7 +667,7 @@ static int rt5677_dsp_mode_i2c_write(struct rt5677_priv *rt5677, /** * rt5677_dsp_mode_i2c_read - Read register on DSP mode. - * @codec: SoC audio codec device. + * @rt5677: Private Data * @reg: Register index. * @value: Register data. * -- 2.17.1
[PATCH 08/21] ASoC: rt298: fix boolean tests
Reported by Coccinelle:
sound/soc/codecs/rt298.c:992:6-8: WARNING: Comparison to bool
sound/soc/codecs/rt298.c:995:6-9: WARNING: Comparison to bool
sound/soc/codecs/rt298.c:317:5-7: WARNING: Comparison to bool
sound/soc/codecs/rt298.c:320:5-8: WARNING: Comparison to bool
sound/soc/codecs/rt298.c:348:5-7: WARNING: Comparison to bool
sound/soc/codecs/rt298.c:351:5-8: WARNING: Comparison to bool
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/rt298.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/rt298.c b/sound/soc/codecs/rt298.c
index 06cdba4edfe2..bcf5bab31969 100644
--- a/sound/soc/codecs/rt298.c
+++ b/sound/soc/codecs/rt298.c
@@ -314,10 +314,10 @@ static void rt298_jack_detect_work(struct work_struct
*work)
if (rt298_jack_detect(rt298, , ) < 0)
return;
- if (hp == true)
+ if (hp)
status |= SND_JACK_HEADPHONE;
- if (mic == true)
+ if (mic)
status |= SND_JACK_MICROPHONE;
snd_soc_jack_report(rt298->jack, status,
@@ -345,10 +345,10 @@ int rt298_mic_detect(struct snd_soc_component *component,
struct snd_soc_jack *j
regmap_update_bits(rt298->regmap, RT298_IRQ_CTRL, 0x2, 0x2);
rt298_jack_detect(rt298, , );
- if (hp == true)
+ if (hp)
status |= SND_JACK_HEADPHONE;
- if (mic == true)
+ if (mic)
status |= SND_JACK_MICROPHONE;
snd_soc_jack_report(rt298->jack, status,
@@ -989,10 +989,10 @@ static irqreturn_t rt298_irq(int irq, void *data)
regmap_update_bits(rt298->regmap, RT298_IRQ_CTRL, 0x1, 0x1);
if (ret == 0) {
- if (hp == true)
+ if (hp)
status |= SND_JACK_HEADPHONE;
- if (mic == true)
+ if (mic)
status |= SND_JACK_MICROPHONE;
snd_soc_jack_report(rt298->jack, status,
--
2.17.1
[PATCH 12/21] ASoC: rt5640: fix boolean assignments
Reported by Coccinelle:
sound/soc/codecs/rt5640.c:980:2-17: WARNING: Assignment of bool to 0/1
sound/soc/codecs/rt5640.c:984:2-17: WARNING: Assignment of bool to 0/1
sound/soc/codecs/rt5640.c:2825:1-16: WARNING: Assignment of bool to 0/1
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/rt5640.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c
index fc530481a6e4..b3580ecadecf 100644
--- a/sound/soc/codecs/rt5640.c
+++ b/sound/soc/codecs/rt5640.c
@@ -977,11 +977,11 @@ static int rt5640_hp_event(struct snd_soc_dapm_widget *w,
switch (event) {
case SND_SOC_DAPM_POST_PMU:
rt5640_pmu_depop(component);
- rt5640->hp_mute = 0;
+ rt5640->hp_mute = false;
break;
case SND_SOC_DAPM_PRE_PMD:
- rt5640->hp_mute = 1;
+ rt5640->hp_mute = true;
msleep(70);
break;
@@ -2822,7 +2822,7 @@ static int rt5640_i2c_probe(struct i2c_client *i2c,
regmap_update_bits(rt5640->regmap, RT5640_DUMMY1,
RT5640_MCLK_DET, RT5640_MCLK_DET);
- rt5640->hp_mute = 1;
+ rt5640->hp_mute = true;
rt5640->irq = i2c->irq;
INIT_DELAYED_WORK(>bp_work, rt5640_button_press_work);
INIT_WORK(>jack_work, rt5640_jack_work);
--
2.17.1
[PATCH 02/21] ASoC: max98090: remove unused constant variables
Fix warnings with W=1
If these variables are useful then this driver should be modified to
expose them.
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/max98090.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index c97f21836c66..30c242c38d99 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -314,9 +314,6 @@ static const DECLARE_TLV_DB_SCALE(max98090_av_tlv, -1200,
100, 0);
static const DECLARE_TLV_DB_SCALE(max98090_dvg_tlv, 0, 600, 0);
static const DECLARE_TLV_DB_SCALE(max98090_dv_tlv, -1500, 100, 0);
-static const DECLARE_TLV_DB_SCALE(max98090_sidetone_tlv, -6050, 200, 0);
-
-static const DECLARE_TLV_DB_SCALE(max98090_alc_tlv, -1500, 100, 0);
static const DECLARE_TLV_DB_SCALE(max98090_alcmakeup_tlv, 0, 100, 0);
static const DECLARE_TLV_DB_SCALE(max98090_alccomp_tlv, -3100, 100, 0);
static const DECLARE_TLV_DB_SCALE(max98090_drcexp_tlv, -6600, 100, 0);
@@ -817,18 +814,6 @@ static SOC_ENUM_SINGLE_VIRT_DECL(dmic_mux_enum,
dmic_mux_text);
static const struct snd_kcontrol_new max98090_dmic_mux =
SOC_DAPM_ENUM("DMIC Mux", dmic_mux_enum);
-static const char *max98090_micpre_text[] = { "Off", "On" };
-
-static SOC_ENUM_SINGLE_DECL(max98090_pa1en_enum,
- M98090_REG_MIC1_INPUT_LEVEL,
- M98090_MIC_PA1EN_SHIFT,
- max98090_micpre_text);
-
-static SOC_ENUM_SINGLE_DECL(max98090_pa2en_enum,
- M98090_REG_MIC2_INPUT_LEVEL,
- M98090_MIC_PA2EN_SHIFT,
- max98090_micpre_text);
-
/* LINEA mixer switch */
static const struct snd_kcontrol_new max98090_linea_mixer_controls[] = {
SOC_DAPM_SINGLE("IN1 Switch", M98090_REG_LINE_INPUT_CONFIG,
--
2.17.1
[PATCH 14/21] ASoC: rt5651: fix boolean assignments
Reported by Coccinelle: sound/soc/codecs/rt5651.c:750:2-17: WARNING: Assignment of bool to 0/1 sound/soc/codecs/rt5651.c:754:2-17: WARNING: Assignment of bool to 0/1 sound/soc/codecs/rt5651.c:2192:1-16: WARNING: Assignment of bool to 0/1 Signed-off-by: Pierre-Louis Bossart --- sound/soc/codecs/rt5651.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c index b7ba64350a07..3882e238ff99 100644 --- a/sound/soc/codecs/rt5651.c +++ b/sound/soc/codecs/rt5651.c @@ -747,11 +747,11 @@ static int rt5651_hp_event(struct snd_soc_dapm_widget *w, RT5651_HP_CP_PD | RT5651_HP_SG_EN); regmap_update_bits(rt5651->regmap, RT5651_PR_BASE + RT5651_CHPUMP_INT_REG1, 0x0700, 0x0400); - rt5651->hp_mute = 0; + rt5651->hp_mute = false; break; case SND_SOC_DAPM_PRE_PMD: - rt5651->hp_mute = 1; + rt5651->hp_mute = true; usleep_range(7, 75000); break; @@ -2189,7 +2189,7 @@ static int rt5651_i2c_probe(struct i2c_client *i2c, dev_warn(>dev, "Failed to apply regmap patch: %d\n", ret); rt5651->irq = i2c->irq; - rt5651->hp_mute = 1; + rt5651->hp_mute = true; INIT_DELAYED_WORK(>bp_work, rt5651_button_press_work); INIT_WORK(>jack_detect_work, rt5651_jack_detect_work); -- 2.17.1
[PATCH 09/21] ASoC: cs4271: fix boolean assignments
Reported by Coccinelle:
sound/soc/codecs/cs4271.c:226:2-16: WARNING: Assignment of bool to 0/1
sound/soc/codecs/cs4271.c:229:2-16: WARNING: Assignment of bool to 0/1
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/cs4271.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c
index 849fdb2cb260..1104830edaf8 100644
--- a/sound/soc/codecs/cs4271.c
+++ b/sound/soc/codecs/cs4271.c
@@ -223,10 +223,10 @@ static int cs4271_set_dai_fmt(struct snd_soc_dai
*codec_dai,
switch (format & SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
- cs4271->master = 0;
+ cs4271->master = false;
break;
case SND_SOC_DAIFMT_CBM_CFM:
- cs4271->master = 1;
+ cs4271->master = true;
val |= CS4271_MODE1_MASTER;
break;
default:
--
2.17.1
[PATCH 01/21] ASoC: dmic: declare trigger function as static
No reason why this is global, fix warnings with W=1
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/dmic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index da921da50ef0..de041369e5a7 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -44,8 +44,8 @@ struct dmic {
int modeswitch_delay;
};
-int dmic_daiops_trigger(struct snd_pcm_substream *substream,
- int cmd, struct snd_soc_dai *dai)
+static int dmic_daiops_trigger(struct snd_pcm_substream *substream,
+ int cmd, struct snd_soc_dai *dai)
{
struct snd_soc_component *component = dai->component;
struct dmic *dmic = snd_soc_component_get_drvdata(component);
--
2.17.1
[PATCH 03/21] ASoC: es8316: remove unused constant variables
Fix warnings with W=1
If these variables are useful this driver should be modified to expose
them.
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/es8316.c | 4
1 file changed, 4 deletions(-)
diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c
index e97d12d578b0..b10c4d812958 100644
--- a/sound/soc/codecs/es8316.c
+++ b/sound/soc/codecs/es8316.c
@@ -159,8 +159,6 @@ static const char * const es8316_hpmux_texts[] = {
"lin-rin with Boost and PGA"
};
-static const unsigned int es8316_hpmux_values[] = { 0, 1, 2, 3 };
-
static SOC_ENUM_SINGLE_DECL(es8316_left_hpmux_enum, ES8316_HPMIX_SEL,
4, es8316_hpmux_texts);
@@ -191,8 +189,6 @@ static const char * const es8316_dacsrc_texts[] = {
"RDATA TO LDAC, LDATA TO RDAC",
};
-static const unsigned int es8316_dacsrc_values[] = { 0, 1, 2, 3 };
-
static SOC_ENUM_SINGLE_DECL(es8316_dacsrc_mux_enum, ES8316_DAC_SET1,
6, es8316_dacsrc_texts);
--
2.17.1
[PATCH 07/21] ASoC: max98383: fix boolean assignments to true/false
Reported by Coccinelle: sound/soc/codecs/max98373.c:411:2-20: WARNING: Assignment of bool to 0/1 sound/soc/codecs/max98373.c:922:2-27: WARNING: Assignment of bool to 0/1 sound/soc/codecs/max98373.c:924:2-27: WARNING: Assignment of bool to 0/1 Signed-off-by: Pierre-Louis Bossart --- sound/soc/codecs/max98373.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c index 9c8616a7b61c..528695cd6a1c 100644 --- a/sound/soc/codecs/max98373.c +++ b/sound/soc/codecs/max98373.c @@ -408,7 +408,7 @@ static int max98373_dac_event(struct snd_soc_dapm_widget *w, regmap_update_bits(max98373->regmap, MAX98373_R20FF_GLOBAL_SHDN, MAX98373_GLOBAL_EN_MASK, 0); - max98373->tdm_mode = 0; + max98373->tdm_mode = false; break; default: return 0; @@ -919,9 +919,9 @@ static int max98373_i2c_probe(struct i2c_client *i2c, /* update interleave mode info */ if (device_property_read_bool(>dev, "maxim,interleave_mode")) - max98373->interleave_mode = 1; + max98373->interleave_mode = true; else - max98373->interleave_mode = 0; + max98373->interleave_mode = false; /* regmap initialization */ -- 2.17.1
[PATCH 05/21] ASoC: rt5645: remove unused mux define
From: Bard liao
rt5645_if3_adc_in_mux, rt5645_inr_mux, and rt5645_inl_mux are not used.
Remove them from the driver.
Signed-off-by: Bard liao
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/rt5645.c | 36
1 file changed, 36 deletions(-)
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index be674688dc40..52ce380c8f3a 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -1288,30 +1288,6 @@ static SOC_ENUM_SINGLE_DECL(
static const struct snd_kcontrol_new rt5645_dac_r2_mux =
SOC_DAPM_ENUM("DAC2 R source", rt5645_dac2r_enum);
-
-/* INL/R source */
-static const char * const rt5645_inl_src[] = {
- "IN2P", "MonoP"
-};
-
-static SOC_ENUM_SINGLE_DECL(
- rt5645_inl_enum, RT5645_INL1_INR1_VOL,
- RT5645_INL_SEL_SFT, rt5645_inl_src);
-
-static const struct snd_kcontrol_new rt5645_inl_mux =
- SOC_DAPM_ENUM("INL source", rt5645_inl_enum);
-
-static const char * const rt5645_inr_src[] = {
- "IN2N", "MonoN"
-};
-
-static SOC_ENUM_SINGLE_DECL(
- rt5645_inr_enum, RT5645_INL1_INR1_VOL,
- RT5645_INR_SEL_SFT, rt5645_inr_src);
-
-static const struct snd_kcontrol_new rt5645_inr_mux =
- SOC_DAPM_ENUM("INR source", rt5645_inr_enum);
-
/* Stereo1 ADC source */
/* MX-27 [12] */
static const char * const rt5645_stereo_adc1_src[] = {
@@ -1611,18 +1587,6 @@ static SOC_ENUM_SINGLE_DECL(
static const struct snd_kcontrol_new rt5645_if2_adc_in_mux =
SOC_DAPM_ENUM("IF2 ADC IN source", rt5645_if2_adc_in_enum);
-/* MX-2F [1:0] */
-static const char * const rt5645_if3_adc_in_src[] = {
- "IF_ADC1", "IF_ADC2", "VAD_ADC"
-};
-
-static SOC_ENUM_SINGLE_DECL(
- rt5645_if3_adc_in_enum, RT5645_DIG_INF1_DATA,
- RT5645_IF3_ADC_IN_SFT, rt5645_if3_adc_in_src);
-
-static const struct snd_kcontrol_new rt5645_if3_adc_in_mux =
- SOC_DAPM_ENUM("IF3 ADC IN source", rt5645_if3_adc_in_enum);
-
/* MX-31 [15] [13] [11] [9] */
static const char * const rt5645_pdm_src[] = {
"Mono DAC", "Stereo DAC"
--
2.17.1
[PATCH 06/21] ASoC: rt5670: remove unused mux/mixer define
From: Bard liao
Some mux/mixer are not used. Remove them from the driver.
Signed-off-by: Bard liao
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/codecs/rt5670.c | 54 ---
1 file changed, 54 deletions(-)
diff --git a/sound/soc/codecs/rt5670.c b/sound/soc/codecs/rt5670.c
index 453328c988c0..9a037108b1ae 100644
--- a/sound/soc/codecs/rt5670.c
+++ b/sound/soc/codecs/rt5670.c
@@ -1057,20 +1057,6 @@ static const struct snd_kcontrol_new rt5670_lout_mix[] =
{
RT5670_M_OV_R_LM_SFT, 1, 1),
};
-static const struct snd_kcontrol_new rt5670_hpl_mix[] = {
- SOC_DAPM_SINGLE("DAC L1 Switch", RT5670_HPO_MIXER,
- RT5670_M_DACL1_HML_SFT, 1, 1),
- SOC_DAPM_SINGLE("INL1 Switch", RT5670_HPO_MIXER,
- RT5670_M_INL1_HML_SFT, 1, 1),
-};
-
-static const struct snd_kcontrol_new rt5670_hpr_mix[] = {
- SOC_DAPM_SINGLE("DAC R1 Switch", RT5670_HPO_MIXER,
- RT5670_M_DACR1_HMR_SFT, 1, 1),
- SOC_DAPM_SINGLE("INR1 Switch", RT5670_HPO_MIXER,
- RT5670_M_INR1_HMR_SFT, 1, 1),
-};
-
static const struct snd_kcontrol_new lout_l_enable_control =
SOC_DAPM_SINGLE_AUTODISABLE("Switch", RT5670_LOUT1,
RT5670_L_MUTE_SFT, 1, 1);
@@ -1196,24 +1182,6 @@ static SOC_ENUM_SINGLE_DECL(rt5670_stereo2_adc2_enum,
RT5670_STO2_ADC_MIXER,
static const struct snd_kcontrol_new rt5670_sto2_adc_2_mux =
SOC_DAPM_ENUM("Stereo2 ADC 2 Mux", rt5670_stereo2_adc2_enum);
-
-/* MX-27 MX26 [10] */
-static const char * const rt5670_stereo_adc_src[] = {
- "ADC1L ADC2R", "ADC3"
-};
-
-static SOC_ENUM_SINGLE_DECL(rt5670_stereo1_adc_enum, RT5670_STO1_ADC_MIXER,
- RT5670_ADC_SRC_SFT, rt5670_stereo_adc_src);
-
-static const struct snd_kcontrol_new rt5670_sto_adc_mux =
- SOC_DAPM_ENUM("Stereo1 ADC source", rt5670_stereo1_adc_enum);
-
-static SOC_ENUM_SINGLE_DECL(rt5670_stereo2_adc_enum, RT5670_STO2_ADC_MIXER,
- RT5670_ADC_SRC_SFT, rt5670_stereo_adc_src);
-
-static const struct snd_kcontrol_new rt5670_sto2_adc_mux =
- SOC_DAPM_ENUM("Stereo2 ADC source", rt5670_stereo2_adc_enum);
-
/* MX-27 MX-26 [9:8] */
static const char * const rt5670_stereo_dmic_src[] = {
"DMIC1", "DMIC2", "DMIC3"
@@ -1231,17 +1199,6 @@ static SOC_ENUM_SINGLE_DECL(rt5670_stereo2_dmic_enum,
RT5670_STO2_ADC_MIXER,
static const struct snd_kcontrol_new rt5670_sto2_dmic_mux =
SOC_DAPM_ENUM("Stereo2 DMIC source", rt5670_stereo2_dmic_enum);
-/* MX-27 [0] */
-static const char * const rt5670_stereo_dmic3_src[] = {
- "DMIC3", "PDM ADC"
-};
-
-static SOC_ENUM_SINGLE_DECL(rt5670_stereo_dmic3_enum, RT5670_STO1_ADC_MIXER,
- RT5670_DMIC3_SRC_SFT, rt5670_stereo_dmic3_src);
-
-static const struct snd_kcontrol_new rt5670_sto_dmic3_mux =
- SOC_DAPM_ENUM("Stereo DMIC3 source", rt5670_stereo_dmic3_enum);
-
/* Mono ADC source */
/* MX-28 [12] */
static const char * const rt5670_mono_adc_l1_src[] = {
@@ -1334,17 +1291,6 @@ static SOC_ENUM_SINGLE_DECL(rt5670_if2_adc_in_enum,
RT5670_DIG_INF1_DATA,
static const struct snd_kcontrol_new rt5670_if2_adc_in_mux =
SOC_DAPM_ENUM("IF2 ADC IN source", rt5670_if2_adc_in_enum);
-/* MX-30 [5:4] */
-static const char * const rt5670_if4_adc_in_src[] = {
- "IF_ADC1", "IF_ADC2", "IF_ADC3"
-};
-
-static SOC_ENUM_SINGLE_DECL(rt5670_if4_adc_in_enum, RT5670_DIG_INF2_DATA,
- RT5670_IF4_ADC_IN_SFT, rt5670_if4_adc_in_src);
-
-static const struct snd_kcontrol_new rt5670_if4_adc_in_mux =
- SOC_DAPM_ENUM("IF4 ADC IN source", rt5670_if4_adc_in_enum);
-
/* MX-31 [15] [13] [11] [9] */
static const char * const rt5670_pdm_src[] = {
"Mono DAC", "Stereo DAC"
--
2.17.1
Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5
Hi again,
On Thu, Jan 03, 2019 at 04:11:58PM -0800, Brian Norris wrote:
> On Thu, Jan 03, 2019 at 04:01:45PM -0800, Bjorn Andersson wrote:
> > I share your concern about this, but I came to suggest this as the
> > driver cares about platforms but the firmware is (often?)
> > device/product-specific.
> >
> > E.g. we will serve the MTP and Pixel 3 with the qcom,sdm845-adsp-pas
> > compatible, but they are unlikely to run the same adsp firmware. This
> > allows the individual dtb to specify which firmware the driver should
> > use.
>
> I understand this, but that still doesn't mean we should be suggesting
> each DTB to clutter the top-level firmware search path, especially since
> lazy people will probably just use "modem.mdt" and similar. That means
> you no longer can ship the same rootfs that supports both QCOM and
> modems, if modem also uses the same lazy format.
>
> It seems like a much better practice to at least enforce a particular
> prefix to things. e.g., the driver could assume:
>
> qcom/sdm845-adsp-pas/ (or if you must, just qcom/)
>
> and your DTB only gets to add .../ to that path.
>
> In case it isn't clear: I think it's also severely misguided that the
> existing driver gets away with lines like
>
> request_firmware(, "modem.mdt", ...);
>
> today ;)
To add to my thoughts, since I think maybe Sibi was a little unclear of
my thoughts:
One of my primary concerns with the existing approach is that it's
basically a complete free-for-all. We should have some minimal standards
(enforced in code) such that our DTB can never point us at something
like /lib/firmware//foo.bin (or /lib/firmware/modem.mdt;
or lots of other bad examples). This could probably be done simply by
always prefixing 'qcom/' (I don't remember -- does request_firmware()
follow '..'? e.g., 'firmware-name = "../bar/foo.bin"'.)
As a bonus: it would be very nice if we can provide a little more
structure by default, and avoid arbitrary hierarchy in the DTS. That's
where I brought up ath10k's "variant" as an example; if we can use
'compatible' to capture most of this particular Hexagon core's
properties, then we only leave a single level of variability to the DTS.
But I might be off-base with the "bonus" paragraph. So I'd also be
somewhat happy with something much less ambitious, like just a built-in
prefix ('qcom/').
And you can also just ignore my thoughts entirely (and I'll be even less
happy), since Rob did already provide his Reviewed-by ;) I mostly wanted
to give food for thought, in the hopes that something in here would help
improve this a bit.
Regards,
Brian
Re: [PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver
Am 04.01.19 um 12:21 schrieb Andreas Färber: > Currently there's still some bugs to be investigated, with communication > stalling on one device and another reading the radio versions wrong > (07 / 1f instead of 21, also observed on spi once). Reproducable 100% on SPI by setting REGCACHE_RBTREE in sx130x.c. Since this serdev driver was using REGCACHE_NONE still and I don't spot a register missing as volatile either, I guess it may be a timing issue? My earlier locking patch is applied, to rule out any non-determinism in the register access order due to radio vs. concentrator interactions. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 1/3] spmi: pmic-arb: convert to v2 irq interfaces to support hierarchical IRQ chips
On Fri, Jan 04, 2019 at 04:25:23PM -0800, Stephen Boyd wrote: > > + /* > > +* Check to see if the hwirq is already associated with another > > virq on > > +* this IRQ domain. If so, then disassociate it before associating > > the > > +* hwirq with the new virq. IRQs are all initially setup without an > > IRQ > > +* hierarchy when this driver is probed and when > > mfd/qcom-spmi-pmic.c is > > +* probed. Later in the boot process, an IRQ hierarchy is requested > > by > > +* pinctrl-spmi-gpio.c, and the same hwirq is now associated with a > > new > > +* virq. > > Is that because we count the irqs in the pmic gpio driver? Yes. The call to devm_of_platform_populate() in drivers/mfd/qcom-spmi-pmic.c also triggers this condition. I'll experiment with this some more this weekend. > Otherwise patch looks good to me. Thanks for working on this. Are you > going to convert the ssbi master and gpio chip too? Yes, I will do that work as well once this patch series is accepted. I currently don't have the hardware to test it, but I'm willing to pick up a cheap device on ebay. Any suggestions for something that boots a mainline kernel with the ssbi? It looks like the Sony Xperia Z phone is one of the supported devices. Thanks for your review on the other patches. It all makes sense. Brian
Re: [PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver
Am 04.01.19 um 12:21 schrieb Andreas Färber: > diff --git a/drivers/net/lora/sx130x_picogw.c > b/drivers/net/lora/sx130x_picogw.c > new file mode 100644 > index ..577f9fb71d46 > --- /dev/null > +++ b/drivers/net/lora/sx130x_picogw.c [...] > + serdev_device_set_baudrate(sdev, 115200); > + serdev_device_set_parity(sdev, SERDEV_PARITY_NONE); > + serdev_device_set_flow_control(sdev, true); This should probably be false? https://github.com/Lora-net/picoGW_hal/blob/master/libloragw/src/loragw_com_linux.c#L65 tty.c_iflag &= ~(IXON | IXOFF | IXANY | ICRNL); ... tty.c_oflag &= ~(IXON | IXOFF | IXANY | ICRNL); Nothing that looks like RTS/CTS anywhere, which appears to be what the serdev implementation is switching with the above function. However, both true and false appeared to work equally so far. With one particular USB device I get the following warning/error, seemingly independent of whether I enable flow control above or not: [68640.481454] lora-picogw-usb 4-1:1.0: failed to set dtr/rts (imagine s/lora-picogw-usb/cdc_acm/ - cf. cdc-acm.c:acm_port_dtr_rts()) Looks like a firmware/hardware issue to me, since it appeared with the original cdc_acm driver on reboot, plus across reset, ports and hosts. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: KMSAN: uninit-value in mpol_rebind_mm
On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka wrote: > > Yes, it doesn't and it's not trivial to do. The tool reports uses of > > unint _values_. Values don't necessary reside in memory. It can be a > > register, that come from another register that was calculated as a sum > > of two other values, which may come from a function argument, etc. > > I see. BTW, the patch I sent will be picked up for testing, or does it > have to be in mmotm/linux-next first? I grabbed it. To go further we'd need a changelog, a signoff, description of testing status, reviews, a Fixes: and perhaps a cc:stable ;)
Re: [RFC][PATCH] hwmon: (ina2xx) Improve current and power reading precision
Hi Stefan, Sorry for a super late reply. I took a long vacation. On Wed, Nov 21, 2018 at 10:16:09PM +, Brüns, Stefan wrote: > > > Another concern may be voltage drop over the shunt, but for this case you > > > have a nominal voltage of 1.8V, so 30uV are 0.001%. > > > > > > > When measuring a 1.8v voltage running a small current (e.g. 33 mA), > > > > the power value (that's supposed to be 59.4 mW) becomes inaccurate > > > > due to the larger scale (25mA for method A; 62.5 mA for method B). > > > > Just found out that I have typos here: 25mW and 62.5mW. > > > > > Another look into the datasheet reveals, even at full gain (PGA=1), the > > > LSB is 40mV / 2^12 = 40mV / 4096 ~ 10uV. So when the current ADC reads > > > out as 3*LSB, this anything between 25mA and 35mA. This is the best case > > > figure. > > Current read doesn't get affected a lot actually, since hwmon ABI > > also reports current value in unit mA. However, the power read is > > the matter here. With a 62.5mW power_lsb, power results are kinda > > useless on my system. > > The reported current does not matter here, actually. Internally, the ADC > value > will have an uncertainty of 10mA (at PGA=1). At 1.8V, your uncertainty is > 18mW. And thats *only* the quantization noise. It wont get better than that. The fact is that I do get better power results after setting the calibration value to 0x7ff. That's the necessity of this change. > Also note, you are apparently using the ina2xx hwmon driver - I strongly > advise against it, you should either use the ina2xx driver from the IIO > subsystem directly, or use the IIO driver via iio-hwmon. The IIO version is also using the minimum calibration value. It will not solve my problem here. > There is also always the possibility to read the bus and shunt voltage > registers and calculate the power manually. Won't that be a waste since the hardware could have provided a better accuracy? It would need more I2C bus reads and cpu cycles for calculation. I don't get why you're against a setting for calibration value. This is how the hardware got designed to cover different cases. Since we do have such a case that needs some accuracy, it'd be fair to add it into the driver. Plus, the feature won't change the minimum calibration value at all -- everyone would be happy. Thanks Nicolin
Re: [PATCH] Display CHECK files like CC files
Hi Matthew, On Thu, Jan 3, 2019 at 12:41 AM Matthew Wilcox wrote: > > When building with O= and C=1, this output looks weird: > > CC fs/file_table.o > CHECK ../fs/file_table.c > CC fs/open.o > CHECK ../fs/open.c > CC fs/super.o > CHECK ../fs/super.c > CC fs/read_write.o > CHECK ../fs/read_write.c > > Use $@ like CC instead of $< to produce the same output for both CHECK and CC. > > Signed-off-by: Matthew Wilcox > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index fd03d60f6c5a..f36b03396d9a 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -74,10 +74,10 @@ __build: $(if $(KBUILD_BUILTIN),$(builtin-target) > $(lib-target) $(extra-y)) \ > > # Linus' kernel sanity checking tool > ifeq ($(KBUILD_CHECKSRC),1) > - quiet_cmd_checksrc = CHECK $< > + quiet_cmd_checksrc = CHECK $@ > cmd_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< > else ifeq ($(KBUILD_CHECKSRC),2) > - quiet_cmd_force_checksrc = CHECK $< > + quiet_cmd_force_checksrc = CHECK $@ > cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< > endif IMHO, $@ is also a bit weird since Sparse does not produce objects at all. What I can suggest is like follows: quiet_cmd_checksrc = CHECK $(patsubst $(srctree)/%,%,$<) -- Best Regards Masahiro Yamada
Re: ZDNet article on GPL is wrong and misleading. PJ (paralegal) does not fully understand the law she's spoke about.
Please CC trim the freebsd lists. This is not our jam. BTW, cross posting was never socially acceptable so please don't. Suddenly, I feel sorry for Mr. Moglen and Mr. Raymond. I can image 20 years of this sort of nonsense in your mailboxes. Cheers for all the good stuff you've done for FOSS. Regards, Jason
Re: [PATCH 3/7] dt-bindings: riscv: cpus: add E51 cores to the list of documented CPUs
On Fri, Jan 4, 2019 at 4:46 PM Palmer Dabbelt wrote: > > On Thu, 20 Dec 2018 13:01:41 PST (-0800), r...@kernel.org wrote: > > On Fri, Dec 14, 2018 at 09:21:50PM -0800, Paul Walmsley wrote: > >> Add compatible strings for the SiFive E51 family of CPU cores to the > >> RISC-V CPU compatible string documentation. The E51 CPU core is > >> described in: > >> > >> https://static.dev.sifive.com/FU540-C000-v1.0.pdf > >> > >> Cc: Rob Herring > >> Cc: Mark Rutland > >> Cc: Palmer Dabbelt > >> Cc: Albert Ou > >> Cc: devicet...@vger.kernel.org > >> Cc: linux-ri...@lists.infradead.org > >> Cc: linux-kernel@vger.kernel.org > >> Signed-off-by: Paul Walmsley > >> Signed-off-by: Paul Walmsley > >> --- > >> Documentation/devicetree/bindings/riscv/cpus.txt | 5 +++-- > >> 1 file changed, 3 insertions(+), 2 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt > >> b/Documentation/devicetree/bindings/riscv/cpus.txt > >> index adf7b7af5dc3..fb9d4f86f41f 100644 > >> --- a/Documentation/devicetree/bindings/riscv/cpus.txt > >> +++ b/Documentation/devicetree/bindings/riscv/cpus.txt > >> @@ -68,8 +68,9 @@ described below. > >> - compatible: > >> Usage: required > >> Value type: > >> -Definition: must contain "riscv", may contain one of > >> -"sifive,rocket0" > >> +Definition: must contain "riscv", may contain one or > >> +more of "sifive,rocket0", "sifive,e51", > >> +"sifive,e5" > > > > I can't really tell what are valid combinations from this. It reads that > > I could list every string here and that would be valid. It is basically > > 'riscv' plus any other combinations of strings. > > I think that's actually the correct interpretation: if it's a RISC-V CPU then > it must have "riscv" listed in compatible, but it can also be anything else. But is '"sifive,rocket0", "sifive,e51", "sifive,e5", "riscv"' valid? What about '"sifive,rocket0", "sifive,e5", "riscv"'? If they are, is there really any value in specifying all of them or different variations? I'd suggest keeping things simple because writing a json-schema gets messy when there's arbitrary combinations of compatible values. > There's some concrete examples here (a "sifive,e51" is a type of "riscv"), but > I don't think it's realistic to count on us being able to enumerate all RISC-V > implementations here. I think you'll find that "riscv" will become pointless as it is not specific enough to mean anything. It would be like having "arm" as a compatible on Arm based systems. OTOH, you only really need to enumerate what you can't discover. For example, how are optional features (SIMD inst a common example) discovered? On Arm, we generally just have the CPU model in the compatible, but it's generally not even used because that, cpu revision, instruction set features, etc. are all discoverable. Rob
Re: [PATCH v2 2/2] mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)
On Wed, Jan 2, 2019 at 9:58 PM Faiz Abbas wrote:
>
> Hi Olof, Eduardo,
>
> On 03/01/19 1:26 AM, Eduardo Valentin wrote:
> > On Wed, Jan 02, 2019 at 10:29:31AM -0800, Olof Johansson wrote:
> >> Hi,
> >>
> >>
> >> On Wed, Dec 12, 2018 at 1:20 AM Ulf Hansson wrote:
> >>>
> >>> + Thermal maintainers
> >>>
> >>> On Tue, 11 Dec 2018 at 15:20, Faiz Abbas wrote:
>
> Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
> (SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
> unexpected tuning pattern errors. A small failure band may be present
> in the tuning range which may be missed by the current algorithm.
> Furthermore, the failure bands vary with temperature leading to
> different optimum tuning values for different temperatures.
>
> As suggested in the related Application Report (SPRACA9B - October 2017
> - Revised July 2018 [2]), tuning should be done in two stages.
> In stage 1, assign the optimum ratio in the maximum pass window for the
> current temperature. In stage 2, if the chosen value is close to the
> small failure band, move away from it in the appropriate direction.
>
> References:
> [1] http://www.ti.com/lit/pdf/sprz426
> [2] http://www.ti.com/lit/pdf/SPRACA9
>
> Signed-off-by: Faiz Abbas
> Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/Kconfig | 2 +
> drivers/mmc/host/sdhci-omap.c | 90 ++-
> 2 files changed, 91 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 5fa580cec831..d8f984483ab0 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -977,6 +977,8 @@ config MMC_SDHCI_XENON
> config MMC_SDHCI_OMAP
> tristate "TI SDHCI Controller Support"
> depends on MMC_SDHCI_PLTFM && OF
> + select THERMAL
> + select TI_SOC_THERMAL
> help
> This selects the Secure Digital Host Controller Interface
> (SDHCI)
> support present in TI's DRA7 SOCs. The controller supports
> diff --git a/drivers/mmc/host/sdhci-omap.c
> b/drivers/mmc/host/sdhci-omap.c
> index f588ab679cb0..b75c55011fcb 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> #include "sdhci-pltfm.h"
>
> @@ -286,15 +287,19 @@ static int sdhci_omap_execute_tuning(struct
> mmc_host *mmc, u32 opcode)
> struct sdhci_host *host = mmc_priv(mmc);
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
> + struct thermal_zone_device *thermal_dev;
> struct device *dev = omap_host->dev;
> struct mmc_ios *ios = >ios;
> u32 start_window = 0, max_window = 0;
> + bool single_point_failure = false;
> bool dcrc_was_enabled = false;
> u8 cur_match, prev_match = 0;
> u32 length = 0, max_len = 0;
> u32 phase_delay = 0;
> + int temperature;
> int ret = 0;
> u32 reg;
> + int i;
>
> /* clock tuning is not needed for upto 52MHz */
> if (ios->clock <= 5200)
> @@ -304,6 +309,16 @@ static int sdhci_omap_execute_tuning(struct
> mmc_host *mmc, u32 opcode)
> if (ios->timing == MMC_TIMING_UHS_SDR50 && !(reg & CAPA2_TSDR50))
> return 0;
>
> + thermal_dev = thermal_zone_get_zone_by_name("cpu_thermal");
> >>>
> >>> I couldn't find a corresponding call to a put function, like
> >>> "thermal_zone_put()" or whatever, which made me realize that the
> >>> thermal zone API is incomplete. Or depending on how you put it, it
> >>> lacks object reference counting, unless I am missing something.
> >>>
> >>> For example, what happens if the thermal zone becomes unregistered
> >>> between this point and when you call thermal_zone_get_temp() a couple
> >>> of line below. I assume it's a known problem, but just wanted to point
> >>> it out.
> >>>
> >
> > Yes, there is no ref counting. Specially because the get zones usages
> > were too specific, and mostly used in application cases that module
> > would not really be removed. Though not a good excuse, still, not very
> > problematic. Now, if the API is getting other usages, then refcounting
> > may be necessary.
> >
> + if (IS_ERR(thermal_dev)) {
> + dev_err(dev, "Unable to get thermal zone for tuning\n");
> + return PTR_ERR(thermal_dev);
> + }
> +
> + ret = thermal_zone_get_temp(thermal_dev, );
> + if (ret)
> +
[PATCH] drivers: platform: goldfish_sync: add a driver
From: Roman Kiryanov
The Goldfish sync driver is designed to provide a interface
between the underlying host's sync device and the kernel's
fence sync framework.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/Kconfig | 7 +
drivers/platform/goldfish/Makefile | 1 +
drivers/platform/goldfish/goldfish_sync.c | 833
include/uapi/linux/goldfish/goldfish_sync.h | 28 +
4 files changed, 869 insertions(+)
create mode 100644 drivers/platform/goldfish/goldfish_sync.c
create mode 100644 include/uapi/linux/goldfish/goldfish_sync.h
diff --git a/drivers/platform/goldfish/Kconfig
b/drivers/platform/goldfish/Kconfig
index 479031aa4f88..fbc0c53e8f35 100644
--- a/drivers/platform/goldfish/Kconfig
+++ b/drivers/platform/goldfish/Kconfig
@@ -16,4 +16,11 @@ config GOLDFISH_PIPE
This is a virtual device to drive the QEMU pipe interface used by
the Goldfish Android Virtual Device.
+config GOLDFISH_SYNC
+ tristate "Goldfish AVD Sync Driver"
+ depends on SW_SYNC
+ depends on SYNC_FILE
+ help
+ Emulated sync fences for the Goldfish Android Virtual Device.
+
endif # GOLDFISH
diff --git a/drivers/platform/goldfish/Makefile
b/drivers/platform/goldfish/Makefile
index e0c202df9674..78c8736ba55d 100644
--- a/drivers/platform/goldfish/Makefile
+++ b/drivers/platform/goldfish/Makefile
@@ -2,3 +2,4 @@
# Makefile for Goldfish platform specific drivers
#
obj-$(CONFIG_GOLDFISH_PIPE)+= goldfish_pipe.o
+obj-$(CONFIG_GOLDFISH_SYNC)+= goldfish_sync.o
diff --git a/drivers/platform/goldfish/goldfish_sync.c
b/drivers/platform/goldfish/goldfish_sync.c
new file mode 100644
index ..e8b7903487cd
--- /dev/null
+++ b/drivers/platform/goldfish/goldfish_sync.c
@@ -0,0 +1,833 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* The Goldfish sync driver is designed to provide a interface
+ * between the underlying host's sync device and the kernel's
+ * fence sync framework.
+ *
+ * The purpose of the device/driver is to enable lightweight creation and
+ * signaling of timelines and fences in order to synchronize the guest with
+ * host-side graphics events.
+ *
+ * Each time the interrupt trips, the driver may perform a sync operation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct sync_pt {
+ struct dma_fence base; /* must be the first field in this struct */
+ struct list_head active_list; /* see active_list_head below */
+};
+
+struct goldfish_sync_state;
+
+struct goldfish_sync_timeline {
+ struct goldfish_sync_state *sync_state;
+
+ /* This object is owned by userspace from open() calls and also each
+* sync_pt refers to it.
+*/
+ struct kref kref;
+ charname[32]; /* for debugging */
+
+ u64 context;
+ unsigned intseqno;
+ /* list of active (unsignaled/errored) sync_pts */
+ struct list_headactive_list_head;
+ spinlock_t lock; /* protects the fields above */
+};
+
+/* The above definitions (command codes, register layout, ioctl definitions)
+ * need to be in sync with the following files:
+ *
+ * Host-side (emulator):
+ * external/qemu/android/emulation/goldfish_sync.h
+ * external/qemu-android/hw/misc/goldfish_sync.c
+ *
+ * Guest-side (system image):
+ * device/generic/goldfish-opengl/system/egl/goldfish_sync.h
+ * device/generic/goldfish/ueventd.ranchu.rc
+ * platform/build/target/board/generic/sepolicy/file_contexts
+ */
+struct goldfish_sync_hostcmd {
+ /* sorted for alignment */
+ u64 handle;
+ u64 hostcmd_handle;
+ u32 cmd;
+ u32 time_arg;
+};
+
+struct goldfish_sync_guestcmd {
+ u64 host_command; /* u64 for alignment */
+ u64 glsync_handle;
+ u64 thread_handle;
+ u64 guest_timeline_handle;
+};
+
+/* The host operations are: */
+enum cmd_id {
+ /* Ready signal - used to mark when irq should lower */
+ CMD_SYNC_READY = 0,
+
+ /* Create a new timeline. writes timeline handle */
+ CMD_CREATE_SYNC_TIMELINE= 1,
+
+ /* Create a fence object. reads timeline handle and time argument.
+* Writes fence fd to the SYNC_REG_HANDLE register.
+*/
+ CMD_CREATE_SYNC_FENCE = 2,
+
+ /* Increments timeline. reads timeline handle and time argument */
+ CMD_SYNC_TIMELINE_INC = 3,
+
+ /* Destroys a timeline. reads timeline handle */
+ CMD_DESTROY_SYNC_TIMELINE = 4,
+
+ /* Starts a wait on the host with the given glsync object and
+* sync thread handle.
+*/
+ CMD_TRIGGER_HOST_WAIT = 5,
+};
+
+/* The host register layout
[PATCH 2/2] hwmon: (ina3221) Implement ti,single-shot DT property
By default, ina3221, as a hardware monitor, continuously measures
the inputs and generates corresponding data. However, for battery
powered devices, this mode might be power consuming.
The DT binding doc is updated with a new boolean type property to
allow changing the default operating mode from consuming mode to
single-shot mode, which will measure input on demand and then shut
down to save power.
So this patch implements the DT property accordingly.
Signed-off-by: Nicolin Chen
---
drivers/hwmon/ina3221.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
index e90ccac8bebb..152735659e19 100644
--- a/drivers/hwmon/ina3221.c
+++ b/drivers/hwmon/ina3221.c
@@ -91,6 +91,12 @@ enum ina3221_channels {
INA3221_NUM_CHANNELS
};
+enum ina3221_modes {
+ INA3221_MODE_SINGLE_SHOT,
+ INA3221_MODE_CONTINUOUS,
+ INA3221_NUM_MODES,
+};
+
/**
* struct ina3221_input - channel input source specific information
* @label: label of channel input source
@@ -111,6 +117,7 @@ struct ina3221_input {
* @inputs: Array of channel input source specific structures
* @lock: mutex lock to serialize sysfs attribute accesses
* @reg_config: Register value of INA3221_CONFIG
+ * @mode: Operating mode -- continuous or single-shot
*/
struct ina3221_data {
struct device *pm_dev;
@@ -119,6 +126,7 @@ struct ina3221_data {
struct ina3221_input inputs[INA3221_NUM_CHANNELS];
struct mutex lock;
u32 reg_config;
+ enum ina3221_modes mode;
};
static inline bool ina3221_is_enabled(struct ina3221_data *ina, int channel)
@@ -188,6 +196,11 @@ static int ina3221_read_in(struct device *dev, u32 attr,
int channel, long *val)
if (!ina3221_is_enabled(ina, channel))
return -ENODATA;
+ /* Write CONFIG register to trigger a single-shot measurement */
+ if (ina->mode == INA3221_MODE_SINGLE_SHOT)
+ regmap_write(ina->regmap, INA3221_CONFIG,
+ina->reg_config);
+
ret = ina3221_wait_for_data(ina);
if (ret)
return ret;
@@ -232,6 +245,11 @@ static int ina3221_read_curr(struct device *dev, u32 attr,
if (!ina3221_is_enabled(ina, channel))
return -ENODATA;
+ /* Write CONFIG register to trigger a single-shot measurement */
+ if (ina->mode == INA3221_MODE_SINGLE_SHOT)
+ regmap_write(ina->regmap, INA3221_CONFIG,
+ina->reg_config);
+
ret = ina3221_wait_for_data(ina);
if (ret)
return ret;
@@ -617,6 +635,9 @@ static int ina3221_probe_from_dt(struct device *dev, struct
ina3221_data *ina)
if (!np)
return 0;
+ if (of_property_read_bool(np, "ti,single-shot"))
+ ina->mode = INA3221_MODE_SINGLE_SHOT;
+
for_each_child_of_node(np, child) {
ret = ina3221_probe_child_from_dt(dev, child, ina);
if (ret)
@@ -654,6 +675,9 @@ static int ina3221_probe(struct i2c_client *client,
}
}
+ /* Hardware default uses the continuous mode */
+ ina->mode = INA3221_MODE_CONTINUOUS;
+
for (i = 0; i < INA3221_NUM_CHANNELS; i++)
ina->inputs[i].shunt_resistor = INA3221_RSHUNT_DEFAULT;
@@ -666,6 +690,10 @@ static int ina3221_probe(struct i2c_client *client,
/* The driver will be reset, so use reset value */
ina->reg_config = INA3221_CONFIG_DEFAULT;
+ /* Clear continuous bit to use single-shot mode */
+ if (ina->mode == INA3221_MODE_SINGLE_SHOT)
+ ina->reg_config &= ~INA3221_CONFIG_MODE_CONTINUOUS;
+
/* Disable channels if their inputs are disconnected */
for (i = 0; i < INA3221_NUM_CHANNELS; i++) {
if (ina->inputs[i].disconnected)
--
2.17.1
[PATCH 1/2] dt-bindings: hwmon: ina3221: Add ti,single-shot property
By default, ina3221, as a hardware monitor, continuously measures the inputs and generates corresponding data. However, for battery powered devices, this mode might be power consuming. This patch adds a "ti,single-shot" property to allow changing the default continuous mode to single-shot operating mode. Signed-off-by: Nicolin Chen --- Documentation/devicetree/bindings/hwmon/ina3221.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/hwmon/ina3221.txt b/Documentation/devicetree/bindings/hwmon/ina3221.txt index a7b25caa2b8e..fa63b6171407 100644 --- a/Documentation/devicetree/bindings/hwmon/ina3221.txt +++ b/Documentation/devicetree/bindings/hwmon/ina3221.txt @@ -6,6 +6,16 @@ Texas Instruments INA3221 Device Tree Bindings - reg: I2C address Optional properties: + - ti,single-shot: This chip has two power modes: single-shot (chip takes one +measurement and then shuts itself down) and continuous ( +chip takes continuous measurements). The continuous mode is +more reliable and suitable for hardware monitor type device, +but the single-shot mode is more power-friendly and useful +for battery-powered device which cares power consumptions +while still needs some measurements occasionally. +If this property is present, the single-shot mode will be +used, instead of the default continuous one for monitoring. + = The node contains optional child nodes for three channels = = Each child node describes the information of input source = -- 2.17.1
[PATCH 0/2] hwmon (ina3221) Add single-shot mode support
By default, ina3221, as a hardware monitor, continuously measures the inputs and generates corresponding data. However, for battery powered devices, this mode might be power consuming. This series of patches add a feature of changing default operating mode to its single-shot mode via DT. Nicolin Chen (2): dt-bindings: hwmon: ina3221: Add ti,single-shot property hwmon: (ina3221) Implement ti,single-shot DT property .../devicetree/bindings/hwmon/ina3221.txt | 10 +++ drivers/hwmon/ina3221.c | 28 +++ 2 files changed, 38 insertions(+) -- 2.17.1
Re: [RFC PATCH] media: rcar-vin: Allow independent VIN link enablement
Hi Niklas,
How about a patch that simply replaces the entity use_count check with a
stream_count check?
As in:
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index f0719ce24b97..aef8d8dab6ab 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -131,9 +131,13 @@ static int rvin_group_link_notify(struct media_link
*link, u32 flags,
!is_media_entity_v4l2_video_device(link->sink->entity))
return 0;
- /* If any entity is in use don't allow link changes. */
+ /*
+ * Don't allow link changes if any entity in the graph is
+ * streaming, modifying the CHSEL register fields can disrupt
+ * running streams.
+ */
media_device_for_each_entity(entity, >mdev)
- if (entity->use_count)
+ if (entity->stream_count)
return -EBUSY;
mutex_lock(>lock);
And that might be overkilll, maybe only the stream_count's of the VIN
entities need to be checked.
Steve
On 12/29/18 3:37 PM, Steve Longerbeam wrote:
Hi Niklas,
On 12/26/18 4:51 PM, Niklas Söderlund wrote:
Hi Steve,
Thanks for your patch.
On 2018-12-25 15:27:25 -0800, Steve Longerbeam wrote:
There is a block of code in rvin_group_link_notify() that prevents
enabling a link to a VIN node if any entity in the media graph is
in use. This prevents enabling a VIN link even if there is an in-use
entity somewhere in the graph that is independent of the link's
pipeline.
For example, the code block will prevent enabling a link from
the first rcar-csi2 receiver to a VIN node even if there is an
enabled link somewhere far upstream on the second independent
rcar-csi2 receiver pipeline.
Unfortunately this is by design and needed due to the hardware design.
The different VIN endpoints shares a configuration register which
controls the routing from the CSI-2 receivers to the VIN (register name
CHSEL). Modifying the CHSEL register which is what happens when a link
is enabled/disabled can have side effects on running streams even if
they are not shown to be dependent in the media graph.
Ok, understood, modifying CHSEL register can adversely affect running
streams.
There is a CHSEL register in VIN0 which controls the routing from all
CSI-2 receivers to VIN0-3 and a CHSEL register in VIN4 which controls
the same for VIN4-7.
If this code block is meant to prevent modifying a link if the
link is actively involved in streaming, there is already such a
check in __media_entity_setup_link() that verifies the stream_count
of the link's source and sink entities are both zero.
For the reason above the check in __media_entity_setup_link() is not
enough :-( This register sharing is my least favorite thing about the
VIN on Gen3 and forces the driver to become more complex as all VIN
instances needs to know about each other and interact.
Given above I understand why the stream count checks in
__media_entity_setup_link() are insufficient, because only the
requested link's source stream count is checked, and not the other
CSI-2 receiver for example.
But why check the use counts of every entity upstream from the VIN
sources? Why not check only the VIN source entities stream counts
(both CSI-2 receivers and/or parallel devices), and ignore entities
upstream from those?
And why are the use counts checked, it seems it should be the stream
counts that should be checked.
Remove the code block so that VIN node links can be enabled even if
there are other independent in-use entities.
There is room for some improvement in this area disregarding the odd
hardware design. It *could* be allowed to change a link terminating in
VIN4-7 even if there is a stream running for one or more in VIN0-3.
I would be interested to test such a patch but to allow any link change
which is allowed by __media_entity_setup_link() is unfortunately not
possible, as I understand it. Maybe someone more clever then me can find
ways to unlock even more then just the split between VIN0-3 and VIn4-7.
In essence the CHSEL register can not be changed if it's involved in a
running pipeline even if the end result would be that the running
pipeline would look the same. This is possible as there are multiple
CHSEL settings where the same source is connected to a specific VIN
while other members of the "subgroup of VINs" (e.g. VIN0-3) is routed to
something else for the two CHSEL settings.
Right, so rvin_group_link_notify() determines whether the requested
VIN link enable will result in a valid set of CSI2->VIN links for the
given hardware, using the CHSEL bitmask tables. Which is why it seems
it is the stream counts that should be checked as mentioned above,
rather than the use counts, because the CHSEL bitmask checks are
validating the set of enabled links, and the only remaining checks are
to verify no streams are running on either CSI-2 receiver.
Steve
Fixes: c0cc5aef31 ("media: rcar-vin: add link notify for
Re: [v2 PATCH 3/5] mm: memcontrol: introduce wipe_on_offline interface
On Fri, Jan 4, 2019 at 4:21 PM Yang Shi wrote:
>
> We have some usecases which create and remove memcgs very frequently,
> and the tasks in the memcg may just access the files which are unlikely
> accessed by anyone else. So, we prefer force_empty the memcg before
> rmdir'ing it to reclaim the page cache so that they don't get
> accumulated to incur unnecessary memory pressure. Since the memory
> pressure may incur direct reclaim to harm some latency sensitive
> applications.
>
> Force empty would help out such usecase, however force empty reclaims
> memory synchronously when writing to memory.force_empty. It may take
> some time to return and the afterwards operations are blocked by it.
> Although this can be done in background, some usecases may need create
> new memcg with the same name right after the old one is deleted. So,
> the creation might get blocked by the before reclaim/remove operation.
>
> Delaying memory reclaim in cgroup offline for such usecase sounds
> reasonable. Introduced a new interface, called wipe_on_offline for both
> default and legacy hierarchy, which does memory reclaim in css offline
> kworker.
>
> Writing to 1 would enable it, writing 0 would disable it.
>
> Suggested-by: Michal Hocko
> Cc: Johannes Weiner
> Signed-off-by: Yang Shi
> ---
> include/linux/memcontrol.h | 3 +++
> mm/memcontrol.c| 49
> ++
> 2 files changed, 52 insertions(+)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 83ae11c..2f1258a 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -311,6 +311,9 @@ struct mem_cgroup {
> struct list_head event_list;
> spinlock_t event_list_lock;
>
> + /* Reclaim as much as possible memory in offline kworker */
> + bool wipe_on_offline;
> +
> struct mem_cgroup_per_node *nodeinfo[0];
> /* WARNING: nodeinfo must be the last member here */
> };
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 75208a2..5a13c6b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2918,6 +2918,35 @@ static ssize_t mem_cgroup_force_empty_write(struct
> kernfs_open_file *of,
> return mem_cgroup_force_empty(memcg) ?: nbytes;
> }
>
> +static int wipe_on_offline_show(struct seq_file *m, void *v)
> +{
> + struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> +
> + seq_printf(m, "%lu\n", (unsigned long)memcg->wipe_on_offline);
> +
> + return 0;
> +}
> +
> +static int wipe_on_offline_write(struct cgroup_subsys_state *css,
> +struct cftype *cft, u64 val)
> +{
> + int ret = 0;
> +
> + struct mem_cgroup *memcg = mem_cgroup_from_css(css);
> +
> + if (mem_cgroup_is_root(memcg))
> + return -EINVAL;
> +
> + if (val == 0)
> + memcg->wipe_on_offline = false;
> + else if (val == 1)
> + memcg->wipe_on_offline = true;
> + else
> + ret = -EINVAL;
> +
> + return ret;
> +}
> +
> static u64 mem_cgroup_hierarchy_read(struct cgroup_subsys_state *css,
> struct cftype *cft)
> {
> @@ -4283,6 +4312,11 @@ static ssize_t memcg_write_event_control(struct
> kernfs_open_file *of,
> .write = mem_cgroup_reset,
> .read_u64 = mem_cgroup_read_u64,
> },
> + {
> + .name = "wipe_on_offline",
What about "force_empty_on_offline"?
> + .seq_show = wipe_on_offline_show,
> + .write_u64 = wipe_on_offline_write,
> + },
> { },/* terminate */
> };
>
> @@ -4569,6 +4603,15 @@ static void mem_cgroup_css_offline(struct
> cgroup_subsys_state *css)
> page_counter_set_min(>memory, 0);
> page_counter_set_low(>memory, 0);
>
> + /*
> +* Reclaim as much as possible memory when offlining.
> +*
> +* Do it after min/low is reset otherwise some memory might
> +* be protected by min/low.
> +*/
> + if (memcg->wipe_on_offline)
> + mem_cgroup_force_empty(memcg);
> +
mem_cgroup_force_empty() also does drain_all_stock(), so, move
drain_all_stock() in mem_cgroup_css_offline() to the else of 'if
(memcg->wipe_on_offline)'.
> memcg_offline_kmem(memcg);
> wb_memcg_offline(memcg);
>
> @@ -5694,6 +5737,12 @@ static ssize_t memory_oom_group_write(struct
> kernfs_open_file *of,
> .seq_show = memory_oom_group_show,
> .write = memory_oom_group_write,
> },
> + {
> + .name = "wipe_on_offline",
> + .flags = CFTYPE_NOT_ON_ROOT,
> + .seq_show = wipe_on_offline_show,
> + .write_u64 = wipe_on_offline_write,
> + },
> { } /* terminate */
> };
>
> --
> 1.8.3.1
>
Re: [v2 PATCH 2/5] mm: memcontrol: do not try to do swap when force empty
On Fri, Jan 4, 2019 at 4:21 PM Yang Shi wrote:
>
> The typical usecase of force empty is to try to reclaim as much as
> possible memory before offlining a memcg. Since there should be no
> attached tasks to offlining memcg, the tasks anonymous pages would have
> already been freed or uncharged. Even though anonymous pages get
> swapped out, but they still get charged to swap space. So, it sounds
> pointless to do swap for force empty.
>
> I tried to dig into the history of this, it was introduced by
> commit 8c7c6e34a125 ("memcg: mem+swap controller core"), but there is
> not any clue about why it was done so at the first place.
>
> The below simple test script shows slight file cache reclaim improvement
> when swap is on.
>
> echo 3 > /proc/sys/vm/drop_caches
> mkdir /sys/fs/cgroup/memory/test
> echo 30 > /sys/fs/cgroup/memory/test/memory.swappiness
> echo $$ >/sys/fs/cgroup/memory/test/cgroup.procs
> cat /proc/meminfo | grep ^Cached|awk -F" " '{print $2}'
> dd if=/dev/zero of=/mnt/test bs=1M count=1024
> ping localhost > /dev/null &
> echo 1 > /sys/fs/cgroup/memory/test/memory.force_empty
> killall ping
> echo $$ >/sys/fs/cgroup/memory/cgroup.procs
> cat /proc/meminfo | grep ^Cached|awk -F" " '{print $2}'
> rmdir /sys/fs/cgroup/memory/test
> cat /proc/meminfo | grep ^Cached|awk -F" " '{print $2}'
>
> The number of page cache is:
> w/o w/
> before force empty10887921088784
> after force empty 41492 39428
> reclaimed 10473001049356
>
> Without doing swap, force empty can reclaim 2MB more memory in 1GB page
> cache.
>
> Cc: Michal Hocko
> Cc: Johannes Weiner
> Signed-off-by: Yang Shi
> ---
> mm/memcontrol.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index af7f18b..75208a2 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2895,7 +2895,7 @@ static int mem_cgroup_force_empty(struct mem_cgroup
> *memcg)
> return -EINTR;
>
> progress = try_to_free_mem_cgroup_pages(memcg, 1,
> - GFP_KERNEL, true);
> + GFP_KERNEL, false);
I think we agreed not to change the behavior of force_empty. You can
customize 'force_empty on wipe_on_offline' to not swapout.
> if (!progress) {
> nr_retries--;
> /* maybe some writeback is necessary */
> --
> 1.8.3.1
>
Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Hi Jacek,
On 04/01/2019 23.37, Jacek Anaszewski wrote:
But, aside from that hypothetic issue, we need a solution for
LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity
via a single register write. How would you propose to address that?
You could model it to something like this in device tree:
led-module @ {
compatible = "lp5024";
// There is in hardware setup to use either linear or
// logarithmic scaling:
//enable-logarithmic-brightness;
led0 {
// this will create led instance for LED0 in lp5024
label = "lp-led0";
// This specifies LED number within lp5024
led-index = <0>; // set output-base as 0*3 == 0
element-red {
// refers to OUT0
output-offset = <0>;
};
element-green {
// refers to OUT1
output-offset = <1>;
};
element-blue {
// refers to OUT2
output-offset = <2>;
};
};
led1 {
// this will create led instance for LED1 in lp5024
label = "lp-led1";
// This specifies LED number within lp5024
led-index = <1>; // set output-base as 1*3 == 3
element-red {
// refers to OUT3
output-offset = <0>;
};
element-green {
// refers to OUT4
output-offset = <1>;
};
element-blue {
// refers to OUT5
output-offset = <2>;
};
};
bank-led {
// this will create led instance for bank leds in lp5024
label = "lp-bank-led";
// configured bank led configuration
led-index = <2 3 4 5 6 7>;
// As here is list of led-indices this entry is
// assumed to be bank configuration. Bank mode is enable
// for the indices.
// set output-base as BANK A
element-red {
// refers to BANK A
output-offset = <0>;
};
element-green {
// refers to BANK B
output-offset = <1>;
};
element-blue {
// refers to BANK C
output-offset = <2>;
};
};
};
This would then create three led instances and each led instance has
brightness setting and that goes straight to hardware.
If one would want to override hardware control for brightness then I
suppose you would define in led node something like:
brightness-model = "hsl"
This would then pick red, green and blue elements for hsl calculations
and others color elements for linear. LED specific hardware brightness
would then be either 0 or 0xFF depending if all of LED color elements
are zero or not.
Would that kind of model work?
Thanks,
Vesa Jääskeläinen
Re: [GIT PULL] sound updates for 4.21
> This is unfortunately a known issue with this driver, Takashi and I had > a couple of email threads on this. Even without errors removing the > module doesn't seem to release all resources. I don't like this at all, > and for the Sound Open Firmware (SOF) driver I mandated module > load-unload as a functional requirement along with zero warnings w/ > Sparse, Coccinelle and friends, but on this legacy code I am afraid > there is no simple fix - at least not in a merge window or a single > kernel cycle. And the fact that kernel crashes after? Just want extra confirmation Thanks, Azat.
Re: [RFC PATCH V3 1/5] vhost: generalize adding used elem
On Fri, Jan 04, 2019 at 04:29:34PM -0500, Michael S. Tsirkin wrote:
> On Sat, Dec 29, 2018 at 08:46:52PM +0800, Jason Wang wrote:
> > Use one generic vhost_copy_to_user() instead of two dedicated
> > accessor. This will simplify the conversion to fine grain
> > accessors. About 2% improvement of PPS were seen during vitio-user
> > txonly test.
> >
> > Signed-off-by: Jason Wang
>
> I don't hve a problem with this patch but do you have
> any idea how come removing what's supposed to be
> an optimization speeds things up?
With SMAP, the 2x vhost_put_user() will also mean an extra STAC/CLAC pair,
which is probably slower than the overhead of CALL+RET to whatever flavor
of copy_user_generic() gets used. CALL+RET is really the only overhead
since all variants of copy_user_generic() unroll accesses smaller than
64 bytes, e.g. on a 64-bit system, __copy_to_user() will write all 8
bytes in a single MOV.
Removing the special casing also eliminates a few hundred bytes of code
as well as the need for hardware to predict count==1 vs. count>1.
>
> > ---
> > drivers/vhost/vhost.c | 11 +--
> > 1 file changed, 1 insertion(+), 10 deletions(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 55e5aa662ad5..f179b5ee14c4 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2174,16 +2174,7 @@ static int __vhost_add_used_n(struct vhost_virtqueue
> > *vq,
> >
> > start = vq->last_used_idx & (vq->num - 1);
> > used = vq->used->ring + start;
> > - if (count == 1) {
> > - if (vhost_put_user(vq, heads[0].id, >id)) {
> > - vq_err(vq, "Failed to write used id");
> > - return -EFAULT;
> > - }
> > - if (vhost_put_user(vq, heads[0].len, >len)) {
> > - vq_err(vq, "Failed to write used len");
> > - return -EFAULT;
> > - }
> > - } else if (vhost_copy_to_user(vq, used, heads, count * sizeof *used)) {
> > + if (vhost_copy_to_user(vq, used, heads, count * sizeof *used)) {
> > vq_err(vq, "Failed to write used");
> > return -EFAULT;
> > }
> > --
> > 2.17.1
Re: [REGRESSION, BISECTED] pci: nvme device with HMB fails on arm64
On Fri, Jan 04, 2019 at 06:34:47PM +0100, Christoph Hellwig wrote:
> Hi Liviu,
Hi Christoph,
>
> please try the patch below. Note that this is in top of mainline,
> as the commit you found already needed another fixup, which has
> made it to Linus already.
This patch does fix the issue with NVMe HMBs. You can add my:
Tested-by: Liviu Dudau
Now I need to go and try to figure out why the rk_gmac-dwmac driver gives this
warning:
[ 11.277363] [ cut here ]
[ 11.277800] DMA-API: rk_gmac-dwmac fe30.ethernet: device driver frees
DMA memory with wrong function [device address=0xe7c21c02] [size=342
bytes] [mapped as page] [unmapped as single]
[ 11.279348] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:1085
check_unmap+0x720/0x840
[ 11.280037] Modules linked in: pcie_rockchip_host phy_rockchip_pcie rockchip
realtek dwmac_rk stmmac_platform stmmac
[ 11.280989] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.20.0-10990-gda3599602d2f-dirty #1
[ 11.281708] Hardware name: FriendlyARM NanoPC-T4 (DT)
[ 11.282162] pstate: 8085 (Nzcv daIf -PAN -UAO)
[ 11.282592] pc : check_unmap+0x720/0x840
[ 11.282947] lr : check_unmap+0x720/0x840
[ 11.283299] sp : 10003b90
[ 11.283597] x29: 10003b90 x28: 8000e7d74800
[ 11.284075] x27: 8000f66fe410 x26: 10f33370
[ 11.284551] x25: x24: 63d0
[ 11.285027] x23: 10f33000 x22: 10f0d818
[ 11.285504] x21: 10003c48 x20: 1110dd80
[ 11.285981] x19: 8000f6657090 x18: 0010
[ 11.286457] x17: 0001 x16: 0007
[ 11.286933] x15: x14: 5d32306331326337
[ 11.287409] x13: 6530303030303030 x12: 3078303d73736572
[ 11.287886] x11: 6464612065636976 x10: 65645b206e6f6974
[ 11.288363] x9 : 636e756620676e6f x8 : 2073612064657070
[ 11.288840] x7 : 616d6e755b205d65 x6 : 01d4
[ 11.289316] x5 : 0001 x4 : 8000e685f000
[ 11.289793] x3 : 8000f774deb8 x2 : 0007
[ 11.290269] x1 : d5f5206026126100 x0 :
[ 11.290746] Call trace:
[ 11.290974] check_unmap+0x720/0x840
[ 11.291301] debug_dma_unmap_page+0xc4/0xd0
[ 11.291719] stmmac_napi_poll+0x214/0x1088 [stmmac]
[ 11.292160] net_rx_action+0x12c/0x3d0
[ 11.292502] __do_softirq+0x1a0/0x438
[ 11.292835] irq_exit+0xcc/0xe0
[ 11.293124] __handle_domain_irq+0x9c/0x108
[ 11.293500] gic_handle_irq+0xb8/0x15c
[ 11.293839] el1_irq+0xb4/0x130
[ 11.294127] cpuidle_enter_state+0xbc/0x508
[ 11.294504] cpuidle_enter+0x34/0x48
[ 11.294830] call_cpuidle+0x44/0x68
[ 11.295148] do_idle+0x264/0x2a0
[ 11.295445] cpu_startup_entry+0x28/0x30
[ 11.295802] rest_init+0xd4/0xe0
[ 11.296101] arch_call_rest_init+0x14/0x1c
[ 11.296471] start_kernel+0x48c/0x4b4
[ 11.296800] ---[ end trace c63a0054785f45a3 ]---
[ 11.297213] DMA-API: Mapped at:
[ 11.297531] stmmac_xmit+0x4b8/0x1168 [stmmac]
[ 11.297934] dev_hard_start_xmit+0xac/0x290
[ 11.298313] sch_direct_xmit+0x120/0x330
[ 11.298667] __qdisc_run+0x140/0x6e8
[ 11.298994] __dev_queue_xmit+0x48c/0x718
I've seen you have provided some other net driver reporter with a patch to make
dma_map_single_attrs use
dma_map_page_attrs, which I have applied, but that doesn't remove the WARN()
for me.
Many thanks,
Liviu
>
> --
> From a959cc1a8ee00dcb274922f9d74f6ed632709047 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Fri, 4 Jan 2019 18:31:48 +0100
> Subject: dma-direct: fix DMA_ATTR_NO_KERNEL_MAPPING for remapped allocations
>
> We need to return a dma_addr_t even if we don't have a kernel mapping.
> Do so by consolidating the phys_to_dma call in a single place and jump
> to it from all the branches that return successfully.
>
> Fixes: bfd56cd60521 ("dma-mapping: support highmem in the generic remap
> allocator")
> Reported-by: Liviu Dudau Signed-off-by: Christoph Hellwig
> ---
> kernel/dma/remap.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/dma/remap.c b/kernel/dma/remap.c
> index 18cc09fc27b9..7a723194ecbe 100644
> --- a/kernel/dma/remap.c
> +++ b/kernel/dma/remap.c
> @@ -204,8 +204,7 @@ void *arch_dma_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle,
> ret = dma_alloc_from_pool(size, , flags);
> if (!ret)
> return NULL;
> - *dma_handle = phys_to_dma(dev, page_to_phys(page));
> - return ret;
> + goto done;
> }
>
> page = __dma_direct_alloc_pages(dev, size, dma_handle, flags, attrs);
> @@ -215,8 +214,10 @@ void *arch_dma_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle,
> /* remove any dirty cache lines on the kernel alias */
> arch_dma_prep_coherent(page, size);
>
> - if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> - return page; /* opaque cookie */
> + if (attrs &
Re: [PATCH 1/3] spmi: pmic-arb: convert to v2 irq interfaces to support hierarchical IRQ chips
Quoting Brian Masney (2018-12-29 03:47:53)
> Convert the spmi-pmic-arb IRQ code to use the version 2 IRQ interface
> in order to support hierarchical IRQ chips. Code was tested on a LG
> Nexus 5 (hammerhead) phone.
Can you add the motivation for this change here? Why should we care?
>
> Signed-off-by: Brian Masney
> ---
> drivers/spmi/spmi-pmic-arb.c | 91 +---
> 1 file changed, 64 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
> index 360b8218f322..c651d19f0623 100644
> --- a/drivers/spmi/spmi-pmic-arb.c
> +++ b/drivers/spmi/spmi-pmic-arb.c
> @@ -666,7 +666,8 @@ static int qpnpint_get_irqchip_state(struct irq_data *d,
> return 0;
> }
>
> -static int qpnpint_irq_request_resources(struct irq_data *d)
> +static int qpnpint_irq_domain_activate(struct irq_domain *domain,
> + struct irq_data *d, bool reserve)
> {
> struct spmi_pmic_arb *pmic_arb = irq_data_get_irq_chip_data(d);
> u16 periph = hwirq_to_per(d->hwirq);
> @@ -692,36 +693,37 @@ static struct irq_chip pmic_arb_irqchip = {
> .irq_set_type = qpnpint_irq_set_type,
> .irq_set_wake = qpnpint_irq_set_wake,
> .irq_get_irqchip_state = qpnpint_get_irqchip_state,
> - .irq_request_resources = qpnpint_irq_request_resources,
> .flags = IRQCHIP_MASK_ON_SUSPEND,
> };
>
> -static int qpnpint_irq_domain_dt_translate(struct irq_domain *d,
> - struct device_node *controller,
> - const u32 *intspec,
> - unsigned int intsize,
> - unsigned long *out_hwirq,
> - unsigned int *out_type)
> +static int qpnpint_irq_domain_translate(struct irq_domain *d,
> + struct irq_fwspec *fwspec,
> + unsigned long *out_hwirq,
> + unsigned int *out_type)
> {
> struct spmi_pmic_arb *pmic_arb = d->host_data;
> u16 apid, ppid;
> int rc;
>
> - dev_dbg(_arb->spmic->dev, "intspec[0] 0x%1x intspec[1] 0x%02x
> intspec[2] 0x%02x\n",
> - intspec[0], intspec[1], intspec[2]);
> + dev_dbg(_arb->spmic->dev,
> + "param[0] 0x%1x param[1] 0x%02x param[2] 0x%02x\n",
> + fwspec->param[0], fwspec->param[1], fwspec->param[2]);
>
> - if (irq_domain_get_of_node(d) != controller)
> + if (irq_domain_get_of_node(d) != pmic_arb->spmic->dev.of_node)
> return -EINVAL;
> - if (intsize != 4)
> + if (fwspec->param_count != 4)
> return -EINVAL;
> - if (intspec[0] > 0xF || intspec[1] > 0xFF || intspec[2] > 0x7)
> + if (fwspec->param[0] > 0xF || fwspec->param[1] > 0xFF ||
> + fwspec->param[2] > 0x7)
> return -EINVAL;
>
> - ppid = intspec[0] << 8 | intspec[1];
> + ppid = fwspec->param[0] << 8 | fwspec->param[1];
> rc = pmic_arb->ver_ops->ppid_to_apid(pmic_arb, ppid);
> if (rc < 0) {
> - dev_err(_arb->spmic->dev, "failed to xlate sid = %#x,
> periph = %#x, irq = %u rc = %d\n",
> - intspec[0], intspec[1], intspec[2], rc);
> + dev_err(_arb->spmic->dev,
> + "failed to xlate sid = %#x, periph = %#x, irq = %u rc
> = %d\n",
> + fwspec->param[0], fwspec->param[1], fwspec->param[2],
Why not assign a u32 *intspec to fwspec->param and then not change many
lines in this function? Reducing the diff is useful to avoid glossing
over some mistake in variable renames.
> + rc);
> return rc;
> }
>
> @@ -732,25 +734,58 @@ static int qpnpint_irq_domain_dt_translate(struct
> irq_domain *d,
> if (apid < pmic_arb->min_apid)
> pmic_arb->min_apid = apid;
>
> - *out_hwirq = spec_to_hwirq(intspec[0], intspec[1], intspec[2], apid);
> - *out_type = intspec[3] & IRQ_TYPE_SENSE_MASK;
> + *out_hwirq = spec_to_hwirq(fwspec->param[0], fwspec->param[1],
> + fwspec->param[2], apid);
> + *out_type = fwspec->param[3] & IRQ_TYPE_SENSE_MASK;
>
> dev_dbg(_arb->spmic->dev, "out_hwirq = %lu\n", *out_hwirq);
>
> return 0;
> }
>
> -static int qpnpint_irq_domain_map(struct irq_domain *d,
> - unsigned int virq,
> - irq_hw_number_t hwirq)
> +
> +static void qpnpint_irq_domain_map(struct spmi_pmic_arb *pmic_arb,
> + struct irq_domain *domain, unsigned int
> virq,
> + irq_hw_number_t hwirq)
> {
> - struct spmi_pmic_arb *pmic_arb = d->host_data;
> + unsigned int
[v2 PATCH 1/5] doc: memcontrol: fix the obsolete content about force empty
We don't do page cache reparent anymore when offlining memcg, so update force empty related content accordingly. Reviewed-by: Shakeel Butt Acked-by: Michal Hocko Cc: Johannes Weiner Signed-off-by: Yang Shi --- Documentation/cgroup-v1/memory.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/cgroup-v1/memory.txt b/Documentation/cgroup-v1/memory.txt index 3682e99..8e2cb1d 100644 --- a/Documentation/cgroup-v1/memory.txt +++ b/Documentation/cgroup-v1/memory.txt @@ -70,7 +70,7 @@ Brief summary of control files. memory.soft_limit_in_bytes # set/show soft limit of memory usage memory.stat# show various statistics memory.use_hierarchy # set/show hierarchical account enabled - memory.force_empty # trigger forced move charge to parent + memory.force_empty # trigger forced page reclaim memory.pressure_level # set memory pressure notifications memory.swappiness # set/show swappiness parameter of vmscan (See sysctl's vm.swappiness) @@ -459,8 +459,9 @@ About use_hierarchy, see Section 6. the cgroup will be reclaimed and as many pages reclaimed as possible. The typical use case for this interface is before calling rmdir(). - Because rmdir() moves all pages to parent, some out-of-use page caches can be - moved to the parent. If you want to avoid that, force_empty will be useful. + Though rmdir() offlines memcg, but the memcg may still stay there due to + charged file caches. Some out-of-use page caches may keep charged until + memory pressure happens. If you want to avoid that, force_empty will be useful. Also, note that when memory.kmem.limit_in_bytes is set the charges due to kernel pages will still be seen. This is not considered a failure and the -- 1.8.3.1
[v2 PATCH 2/5] mm: memcontrol: do not try to do swap when force empty
The typical usecase of force empty is to try to reclaim as much as
possible memory before offlining a memcg. Since there should be no
attached tasks to offlining memcg, the tasks anonymous pages would have
already been freed or uncharged. Even though anonymous pages get
swapped out, but they still get charged to swap space. So, it sounds
pointless to do swap for force empty.
I tried to dig into the history of this, it was introduced by
commit 8c7c6e34a125 ("memcg: mem+swap controller core"), but there is
not any clue about why it was done so at the first place.
The below simple test script shows slight file cache reclaim improvement
when swap is on.
echo 3 > /proc/sys/vm/drop_caches
mkdir /sys/fs/cgroup/memory/test
echo 30 > /sys/fs/cgroup/memory/test/memory.swappiness
echo $$ >/sys/fs/cgroup/memory/test/cgroup.procs
cat /proc/meminfo | grep ^Cached|awk -F" " '{print $2}'
dd if=/dev/zero of=/mnt/test bs=1M count=1024
ping localhost > /dev/null &
echo 1 > /sys/fs/cgroup/memory/test/memory.force_empty
killall ping
echo $$ >/sys/fs/cgroup/memory/cgroup.procs
cat /proc/meminfo | grep ^Cached|awk -F" " '{print $2}'
rmdir /sys/fs/cgroup/memory/test
cat /proc/meminfo | grep ^Cached|awk -F" " '{print $2}'
The number of page cache is:
w/o w/
before force empty10887921088784
after force empty 41492 39428
reclaimed 10473001049356
Without doing swap, force empty can reclaim 2MB more memory in 1GB page
cache.
Cc: Michal Hocko
Cc: Johannes Weiner
Signed-off-by: Yang Shi
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index af7f18b..75208a2 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2895,7 +2895,7 @@ static int mem_cgroup_force_empty(struct mem_cgroup
*memcg)
return -EINTR;
progress = try_to_free_mem_cgroup_pages(memcg, 1,
- GFP_KERNEL, true);
+ GFP_KERNEL, false);
if (!progress) {
nr_retries--;
/* maybe some writeback is necessary */
--
1.8.3.1
[v2 PATCH 3/5] mm: memcontrol: introduce wipe_on_offline interface
We have some usecases which create and remove memcgs very frequently,
and the tasks in the memcg may just access the files which are unlikely
accessed by anyone else. So, we prefer force_empty the memcg before
rmdir'ing it to reclaim the page cache so that they don't get
accumulated to incur unnecessary memory pressure. Since the memory
pressure may incur direct reclaim to harm some latency sensitive
applications.
Force empty would help out such usecase, however force empty reclaims
memory synchronously when writing to memory.force_empty. It may take
some time to return and the afterwards operations are blocked by it.
Although this can be done in background, some usecases may need create
new memcg with the same name right after the old one is deleted. So,
the creation might get blocked by the before reclaim/remove operation.
Delaying memory reclaim in cgroup offline for such usecase sounds
reasonable. Introduced a new interface, called wipe_on_offline for both
default and legacy hierarchy, which does memory reclaim in css offline
kworker.
Writing to 1 would enable it, writing 0 would disable it.
Suggested-by: Michal Hocko
Cc: Johannes Weiner
Signed-off-by: Yang Shi
---
include/linux/memcontrol.h | 3 +++
mm/memcontrol.c| 49 ++
2 files changed, 52 insertions(+)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 83ae11c..2f1258a 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -311,6 +311,9 @@ struct mem_cgroup {
struct list_head event_list;
spinlock_t event_list_lock;
+ /* Reclaim as much as possible memory in offline kworker */
+ bool wipe_on_offline;
+
struct mem_cgroup_per_node *nodeinfo[0];
/* WARNING: nodeinfo must be the last member here */
};
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 75208a2..5a13c6b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2918,6 +2918,35 @@ static ssize_t mem_cgroup_force_empty_write(struct
kernfs_open_file *of,
return mem_cgroup_force_empty(memcg) ?: nbytes;
}
+static int wipe_on_offline_show(struct seq_file *m, void *v)
+{
+ struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
+
+ seq_printf(m, "%lu\n", (unsigned long)memcg->wipe_on_offline);
+
+ return 0;
+}
+
+static int wipe_on_offline_write(struct cgroup_subsys_state *css,
+struct cftype *cft, u64 val)
+{
+ int ret = 0;
+
+ struct mem_cgroup *memcg = mem_cgroup_from_css(css);
+
+ if (mem_cgroup_is_root(memcg))
+ return -EINVAL;
+
+ if (val == 0)
+ memcg->wipe_on_offline = false;
+ else if (val == 1)
+ memcg->wipe_on_offline = true;
+ else
+ ret = -EINVAL;
+
+ return ret;
+}
+
static u64 mem_cgroup_hierarchy_read(struct cgroup_subsys_state *css,
struct cftype *cft)
{
@@ -4283,6 +4312,11 @@ static ssize_t memcg_write_event_control(struct
kernfs_open_file *of,
.write = mem_cgroup_reset,
.read_u64 = mem_cgroup_read_u64,
},
+ {
+ .name = "wipe_on_offline",
+ .seq_show = wipe_on_offline_show,
+ .write_u64 = wipe_on_offline_write,
+ },
{ },/* terminate */
};
@@ -4569,6 +4603,15 @@ static void mem_cgroup_css_offline(struct
cgroup_subsys_state *css)
page_counter_set_min(>memory, 0);
page_counter_set_low(>memory, 0);
+ /*
+* Reclaim as much as possible memory when offlining.
+*
+* Do it after min/low is reset otherwise some memory might
+* be protected by min/low.
+*/
+ if (memcg->wipe_on_offline)
+ mem_cgroup_force_empty(memcg);
+
memcg_offline_kmem(memcg);
wb_memcg_offline(memcg);
@@ -5694,6 +5737,12 @@ static ssize_t memory_oom_group_write(struct
kernfs_open_file *of,
.seq_show = memory_oom_group_show,
.write = memory_oom_group_write,
},
+ {
+ .name = "wipe_on_offline",
+ .flags = CFTYPE_NOT_ON_ROOT,
+ .seq_show = wipe_on_offline_show,
+ .write_u64 = wipe_on_offline_write,
+ },
{ } /* terminate */
};
--
1.8.3.1
[v2 PATCH 4/5] mm: memcontrol: bring force_empty into default hierarchy
The default hierarchy doesn't support force_empty, but there are some
usecases which create and remove memcgs very frequently, and the
tasks in the memcg may just access the files which are unlikely
accessed by anyone else. So, we prefer force_empty the memcg before
rmdir'ing it to reclaim the page cache so that they don't get
accumulated to incur unnecessary memory pressure. Since the memory
pressure may incur direct reclaim to harm some latency sensitive
applications.
There is another patch which introduces asynchronous memory reclaim when
offlining, but the behavior of force_empty is still needed by some
usecases which want to get the memory reclaimed immediately. So, bring
force_empty interface in default hierarchy too.
Cc: Michal Hocko
Cc: Johannes Weiner
Signed-off-by: Yang Shi
---
Documentation/admin-guide/cgroup-v2.rst | 14 ++
mm/memcontrol.c | 4
2 files changed, 18 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 7bf3f12..0290c65 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1289,6 +1289,20 @@ PAGE_SIZE multiple when read back.
Shows pressure stall information for memory. See
Documentation/accounting/psi.txt for details.
+ memory.force_empty
+This interface is provided to make cgroup's memory usage empty.
+When writing anything to this
+
+# echo 0 > memory.force_empty
+
+the cgroup will be reclaimed and as many pages reclaimed as possible.
+
+The typical use case for this interface is before calling rmdir().
+Though rmdir() offlines memcg, but the memcg may still stay there due
to
+charged file caches. Some out-of-use page caches may keep charged until
+memory pressure happens. If you want to avoid that, force_empty will be
+useful.
+
Usage Guidelines
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 5a13c6b..c4a7dc7 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5743,6 +5743,10 @@ static ssize_t memory_oom_group_write(struct
kernfs_open_file *of,
.seq_show = wipe_on_offline_show,
.write_u64 = wipe_on_offline_write,
},
+ {
+ .name = "force_empty",
+ .write = mem_cgroup_force_empty_write,
+ },
{ } /* terminate */
};
--
1.8.3.1
[v2 PATCH 5/5] doc: memcontrol: add description for wipe_on_offline
Add desprition of wipe_on_offline interface in cgroup documents. Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Yang Shi --- Documentation/admin-guide/cgroup-v2.rst | 9 + Documentation/cgroup-v1/memory.txt | 10 ++ 2 files changed, 19 insertions(+) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 0290c65..e4ef08c 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1303,6 +1303,15 @@ PAGE_SIZE multiple when read back. memory pressure happens. If you want to avoid that, force_empty will be useful. + memory.wipe_on_offline + +This is similar to force_empty, but it just does memory reclaim +asynchronously in css offline kworker. + +Writing into 1 will enable it, disable it by writing into 0. + +It would reclaim as much as possible memory just as what force_empty does. + Usage Guidelines diff --git a/Documentation/cgroup-v1/memory.txt b/Documentation/cgroup-v1/memory.txt index 8e2cb1d..1c6e1ca 100644 --- a/Documentation/cgroup-v1/memory.txt +++ b/Documentation/cgroup-v1/memory.txt @@ -71,6 +71,7 @@ Brief summary of control files. memory.stat# show various statistics memory.use_hierarchy # set/show hierarchical account enabled memory.force_empty # trigger forced page reclaim + memory.wipe_on_offline # trigger forced page reclaim when offlining memory.pressure_level # set memory pressure notifications memory.swappiness # set/show swappiness parameter of vmscan (See sysctl's vm.swappiness) @@ -581,6 +582,15 @@ hierarchical_= N0= N1= ... The "total" count is sum of file + anon + unevictable. +5.7 wipe_on_offline + +This is similar to force_empty, but it just does memory reclaim asynchronously +in css offline kworker. + +Writing into 1 will enable it, disable it by writing into 0. + +It would reclaim as much as possible memory just as what force_empty does. + 6. Hierarchy support The memory controller supports a deep hierarchy and hierarchical accounting. -- 1.8.3.1
[RFC v2 PATCH 0/5] mm: memcontrol: do memory reclaim when offlining
We have some usecases which create and remove memcgs very frequently, and the tasks in the memcg may just access the files which are unlikely accessed by anyone else. So, we prefer force_empty the memcg before rmdir'ing it to reclaim the page cache so that they don't get accumulated to incur unnecessary memory pressure. Since the memory pressure may incur direct reclaim to harm some latency sensitive applications. Force empty would help out such usecase, however force empty reclaims memory synchronously when writing to memory.force_empty. It may take some time to return and the afterwards operations are blocked by it. Although this can be done in background, some usecases may need create new memcg with the same name right after the old one is deleted. So, the creation might get blocked by the before reclaim/remove operation. Delaying memory reclaim in cgroup offline for such usecase sounds reasonable. Introduced a new interface, called wipe_on_offline for both default and legacy hierarchy, which does memory reclaim in css offline kworker. v1 -> v2: * Introduced wipe_on_offline interface suggested by Michal * Bring force_empty into default hierarchy Patch #1: Fix some obsolete information about force_empty in the document Patch #2: A minor improvement to skip swap for force_empty Patch #3: Introduces wipe_on_offline interface Patch #4: Being force_empty into default hierarchy Patch #5: Document update Yang Shi (5): doc: memcontrol: fix the obsolete content about force empty mm: memcontrol: do not try to do swap when force empty mm: memcontrol: introduce wipe_on_offline interface mm: memcontrol: bring force_empty into default hierarchy doc: memcontrol: add description for wipe_on_offline Documentation/admin-guide/cgroup-v2.rst | 23 +++ Documentation/cgroup-v1/memory.txt | 17 ++--- include/linux/memcontrol.h | 3 +++ mm/memcontrol.c | 55 ++- 4 files changed, 94 insertions(+), 4 deletions(-)
Re: "flip_done timed out" messages causing huge increase in boot time
I should really get to bed ... of course, I meant 516a49cc19467e298d08a404f73a6e311f4548d1 ;-) On Sat, 5 Jan 2019 at 01:16, Daniel Kamil Kozar wrote: > > Small omission on my part : I meant 4.19.12, not 4.19.2 as the last > working version. > Also, I can confirm that reverting > 13947d150bae871bd880565ada318b0bcd0e690e from the current HEAD of > linux-stable fixes the issue. > > On Sat, 5 Jan 2019 at 00:47, Daniel Kamil Kozar wrote: > > > > Hello. > > After upgrading the kernel to 4.20, I noticed that the boot time > > increased from about 5 seconds to 25 seconds. My machine is an Asus > > K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external > > display connected to it via HDMI. If the display is unplugged when > > booting the machine, the boot time stays at its old value. > > The kernel log shows two messages like this : > > > > [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done > > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > > [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies > > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > > > > Which are the only ones that don't appear in 4.19.2, where the boot > > time was smaller. Bisecting the commits between these two versions > > leads to commit 516a49cc19467e298d08a404f73a6e311f4548d1. > > > > Let me know if you need more information. > > > > Kind regards, > > Daniel
Re: "flip_done timed out" messages causing huge increase in boot time
Small omission on my part : I meant 4.19.12, not 4.19.2 as the last working version. Also, I can confirm that reverting 13947d150bae871bd880565ada318b0bcd0e690e from the current HEAD of linux-stable fixes the issue. On Sat, 5 Jan 2019 at 00:47, Daniel Kamil Kozar wrote: > > Hello. > After upgrading the kernel to 4.20, I noticed that the boot time > increased from about 5 seconds to 25 seconds. My machine is an Asus > K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external > display connected to it via HDMI. If the display is unplugged when > booting the machine, the boot time stays at its old value. > The kernel log shows two messages like this : > > [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies > [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out > > Which are the only ones that don't appear in 4.19.2, where the boot > time was smaller. Bisecting the commits between these two versions > leads to commit 516a49cc19467e298d08a404f73a6e311f4548d1. > > Let me know if you need more information. > > Kind regards, > Daniel
