Re: [PATCH 6/6] mmc: host: sdhci-sprd: added Spreadtrum's host controller R11
Hi Ulf,
On 11 June 2018 at 15:15, Ulf Hansson wrote:
> On 8 June 2018 at 10:18, Chunyan Zhang wrote:
>> From: Chunyan Zhang
>>
>> This patch adds the initial support of Secure Digital Host Controller
>> Interface compliant controller - R11 found in some latest Spreadtrum
>> chipsets.
>>
>> R11 is a variant based on SD v4.0 specification.
>>
>> With this driver, mmc can be initialized, can be mounted, read and
>> written.
>>
>> Original-by: Billows Wu
>> Signed-off-by: Chunyan Zhang
>> ---
>> drivers/mmc/host/Kconfig | 13 ++
>> drivers/mmc/host/Makefile | 1 +
>> drivers/mmc/host/sdhci-sprd-r11.c | 472
>> ++
>> 3 files changed, 486 insertions(+)
>> create mode 100644 drivers/mmc/host/sdhci-sprd-r11.c
>
> This is a DT based driver. Please add a separate patch describing the
> corresponding bindings and compatibles.
Ok.
>
> [...]
>
>> +static int sdhci_sprd_get_dt_resource(struct platform_device *pdev,
>> + struct sdhci_sprd_host *sprd_host)
>> +{
>> + int ret = 0;
>> + struct clk *clk;
>> +
>> + clk = devm_clk_get(>dev, "sdio");
>> + if (IS_ERR(clk)) {
>> + ret = PTR_ERR(clk);
>> + dev_warn(>dev, "Failed to get sdio clock (%d)\n", ret);
>> + goto out;
>> + }
>> + sprd_host->clk_sdio = clk;
>> +
>> + clk = devm_clk_get(>dev, "source");
>> + if (IS_ERR(clk)) {
>> + ret = PTR_ERR(clk);
>> + dev_warn(>dev, "Failed to get source clock (%d)\n",
>> ret);
>> + goto out;
>> + }
>> + sprd_host->clk_source = clk;
>> +
>> + clk_set_parent(sprd_host->clk_sdio, sprd_host->clk_source);
>> + sprd_host->base_rate = clk_get_rate(sprd_host->clk_source);
>> + if (!sprd_host->base_rate) {
>> + sprd_host->base_rate = 2600;
>> + dev_warn(>dev, "The source clock rate is 0\n");
>> + }
>> +
>
> The above can be managed by the assigned-clock* DT bindings. Please
> have a look at:
>
Ah, didn't notice these bindings, managing in this way is indeed better.
> Documentation/devicetree/bindings/clock/clock-bindings.txt
> drivers/clk/clk-conf.c
>
>> + clk = devm_clk_get(>dev, "enable");
>> + if (IS_ERR(clk)) {
>> + ret = PTR_ERR(clk);
>> + dev_warn(>dev, "Failed to get gate clock (%d)\n", ret);
>
> The printed name of the clock doesn't match the name used in
> devm_clk_get() call.
>
> BTW, I think devm_clk_get() already prints some information when it
> fails to lookup a clock. Isn't that sufficient?
Right, will remove this print.
>
>> + goto out;
>> + }
>> + sprd_host->clk_enable = clk;
>> +
>> +out:
>> + return ret;
>> +}
>> +
>> +static void sdhci_sprd_set_mmc_struct(struct platform_device *pdev,
>> + struct mmc_host *mmc)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> + struct sdhci_host *host = mmc_priv(mmc);
>> +
>> + mmc->caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED |
>> + MMC_CAP_ERASE | MMC_CAP_CMD23;
>> +
>> + mmc_of_parse(mmc);
>> + mmc_of_parse_voltage(np, >ocr_mask);
>
> mmc_of_parse_voltage() is intended to be used for controllers that
> internally manages the powered to the card. Is that really the case?
I guess it is not, will remove this,
>
> I assume you have external regulator(s) to manage that, no?
>
>> +
>> + mmc->ocr_avail = 0x4;
>> + mmc->ocr_avail_sdio = mmc->ocr_avail;
>> + mmc->ocr_avail_sd = mmc->ocr_avail;
>> + mmc->ocr_avail_mmc = mmc->ocr_avail;
>
and this,
> If there is external regulators used, all the above can go away. In
> either case, at least the *_sdio, *_sd, *_mmc can go away.
>
>> +
>> + mmc->max_current_330 = SDHCI_SPRD_MAX_CUR;
>> + mmc->max_current_300 = SDHCI_SPRD_MAX_CUR;
>> + mmc->max_current_180 = SDHCI_SPRD_MAX_CUR;
>
also this :)
> This should probably also be fetched used an external regulator and
> sdhci already manages that.
>
>> +
>> + host->dma_mask = DMA_BIT_MASK(64);
>> + mmc_dev(host->mmc)->dma_mask = >dma_mask;
>> +}
>
> [...]
>
>> +
>> +static unsigned int sdhci_sprd_get_min_clock(struct sdhci_host *host)
>> +{
>> + return 40;
>> +}
>
> Isn't there a more straightforward way to assign the minimum clock
> rate? Do you really need to use a callback?
>
Do you mean setting mmc->f_min directly after sdhci_add_host()?
We would get a different f_min without this callback, since
SDHCI_CLOCK_MUL_MASK in caps1 register is reserved.
>> +
>> +static void sdhci_sprd_reset(struct sdhci_host *host, u8 mask)
>> +{
>> + sdhci_reset(host, mask);
>> +}
>
> Looks like an unnecessary wrapper function.
Ok, will take out of this wrapper.
>
> [...]
>
>> +static int sdhci_sprd_probe(struct platform_device *pdev)
>> +{
>> + struct sdhci_host *host;
>> + struct
Re: [PATCH 6/6] mmc: host: sdhci-sprd: added Spreadtrum's host controller R11
Hi Ulf,
On 11 June 2018 at 15:15, Ulf Hansson wrote:
> On 8 June 2018 at 10:18, Chunyan Zhang wrote:
>> From: Chunyan Zhang
>>
>> This patch adds the initial support of Secure Digital Host Controller
>> Interface compliant controller - R11 found in some latest Spreadtrum
>> chipsets.
>>
>> R11 is a variant based on SD v4.0 specification.
>>
>> With this driver, mmc can be initialized, can be mounted, read and
>> written.
>>
>> Original-by: Billows Wu
>> Signed-off-by: Chunyan Zhang
>> ---
>> drivers/mmc/host/Kconfig | 13 ++
>> drivers/mmc/host/Makefile | 1 +
>> drivers/mmc/host/sdhci-sprd-r11.c | 472
>> ++
>> 3 files changed, 486 insertions(+)
>> create mode 100644 drivers/mmc/host/sdhci-sprd-r11.c
>
> This is a DT based driver. Please add a separate patch describing the
> corresponding bindings and compatibles.
Ok.
>
> [...]
>
>> +static int sdhci_sprd_get_dt_resource(struct platform_device *pdev,
>> + struct sdhci_sprd_host *sprd_host)
>> +{
>> + int ret = 0;
>> + struct clk *clk;
>> +
>> + clk = devm_clk_get(>dev, "sdio");
>> + if (IS_ERR(clk)) {
>> + ret = PTR_ERR(clk);
>> + dev_warn(>dev, "Failed to get sdio clock (%d)\n", ret);
>> + goto out;
>> + }
>> + sprd_host->clk_sdio = clk;
>> +
>> + clk = devm_clk_get(>dev, "source");
>> + if (IS_ERR(clk)) {
>> + ret = PTR_ERR(clk);
>> + dev_warn(>dev, "Failed to get source clock (%d)\n",
>> ret);
>> + goto out;
>> + }
>> + sprd_host->clk_source = clk;
>> +
>> + clk_set_parent(sprd_host->clk_sdio, sprd_host->clk_source);
>> + sprd_host->base_rate = clk_get_rate(sprd_host->clk_source);
>> + if (!sprd_host->base_rate) {
>> + sprd_host->base_rate = 2600;
>> + dev_warn(>dev, "The source clock rate is 0\n");
>> + }
>> +
>
> The above can be managed by the assigned-clock* DT bindings. Please
> have a look at:
>
Ah, didn't notice these bindings, managing in this way is indeed better.
> Documentation/devicetree/bindings/clock/clock-bindings.txt
> drivers/clk/clk-conf.c
>
>> + clk = devm_clk_get(>dev, "enable");
>> + if (IS_ERR(clk)) {
>> + ret = PTR_ERR(clk);
>> + dev_warn(>dev, "Failed to get gate clock (%d)\n", ret);
>
> The printed name of the clock doesn't match the name used in
> devm_clk_get() call.
>
> BTW, I think devm_clk_get() already prints some information when it
> fails to lookup a clock. Isn't that sufficient?
Right, will remove this print.
>
>> + goto out;
>> + }
>> + sprd_host->clk_enable = clk;
>> +
>> +out:
>> + return ret;
>> +}
>> +
>> +static void sdhci_sprd_set_mmc_struct(struct platform_device *pdev,
>> + struct mmc_host *mmc)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> + struct sdhci_host *host = mmc_priv(mmc);
>> +
>> + mmc->caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED |
>> + MMC_CAP_ERASE | MMC_CAP_CMD23;
>> +
>> + mmc_of_parse(mmc);
>> + mmc_of_parse_voltage(np, >ocr_mask);
>
> mmc_of_parse_voltage() is intended to be used for controllers that
> internally manages the powered to the card. Is that really the case?
I guess it is not, will remove this,
>
> I assume you have external regulator(s) to manage that, no?
>
>> +
>> + mmc->ocr_avail = 0x4;
>> + mmc->ocr_avail_sdio = mmc->ocr_avail;
>> + mmc->ocr_avail_sd = mmc->ocr_avail;
>> + mmc->ocr_avail_mmc = mmc->ocr_avail;
>
and this,
> If there is external regulators used, all the above can go away. In
> either case, at least the *_sdio, *_sd, *_mmc can go away.
>
>> +
>> + mmc->max_current_330 = SDHCI_SPRD_MAX_CUR;
>> + mmc->max_current_300 = SDHCI_SPRD_MAX_CUR;
>> + mmc->max_current_180 = SDHCI_SPRD_MAX_CUR;
>
also this :)
> This should probably also be fetched used an external regulator and
> sdhci already manages that.
>
>> +
>> + host->dma_mask = DMA_BIT_MASK(64);
>> + mmc_dev(host->mmc)->dma_mask = >dma_mask;
>> +}
>
> [...]
>
>> +
>> +static unsigned int sdhci_sprd_get_min_clock(struct sdhci_host *host)
>> +{
>> + return 40;
>> +}
>
> Isn't there a more straightforward way to assign the minimum clock
> rate? Do you really need to use a callback?
>
Do you mean setting mmc->f_min directly after sdhci_add_host()?
We would get a different f_min without this callback, since
SDHCI_CLOCK_MUL_MASK in caps1 register is reserved.
>> +
>> +static void sdhci_sprd_reset(struct sdhci_host *host, u8 mask)
>> +{
>> + sdhci_reset(host, mask);
>> +}
>
> Looks like an unnecessary wrapper function.
Ok, will take out of this wrapper.
>
> [...]
>
>> +static int sdhci_sprd_probe(struct platform_device *pdev)
>> +{
>> + struct sdhci_host *host;
>> + struct
[PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
Current ISH driver only registers suspend/resume PM callbacks which don't
support hibernation (suspend to disk). Basically after hiberation, the ISH
can't resume properly and user may not see sensor events
(for example: screen rotation may not work).
User will not see a crash or panic or anything except the following message
in log:
hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from ISHTP
device
So this patch adds support for S4/hiberbation to ISH by using the
SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly. The suspend
and resume functions will now be used for both suspend to RAM and hibernation.
If power management is disabled, SIMPLE_DEV_PM_OPS will do nothing, the suspend
and resume related functions won't be used, so mark them as __maybe_unused to
clarify that this is the intended behavior, and remove #ifdefs for power
management.
Cc: sta...@vger.kernel.org
Signed-off-by: Even Xu
Acked-by: Srinivas Pandruvada
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 582e449..a2c53ea 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -205,8 +205,7 @@ static void ish_remove(struct pci_dev *pdev)
kfree(ishtp_dev);
}
-#ifdef CONFIG_PM
-static struct device *ish_resume_device;
+static struct device __maybe_unused *ish_resume_device;
/* 50ms to get resume response */
#define WAIT_FOR_RESUME_ACK_MS 50
@@ -220,7 +219,7 @@ static struct device *ish_resume_device;
* in that case a simple resume message is enough, others we need
* a reset sequence.
*/
-static void ish_resume_handler(struct work_struct *work)
+static void __maybe_unused ish_resume_handler(struct work_struct *work)
{
struct pci_dev *pdev = to_pci_dev(ish_resume_device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -262,7 +261,7 @@ static void ish_resume_handler(struct work_struct *work)
*
* Return: 0 to the pm core
*/
-static int ish_suspend(struct device *device)
+static int __maybe_unused ish_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -288,7 +287,7 @@ static int ish_suspend(struct device *device)
return 0;
}
-static DECLARE_WORK(resume_work, ish_resume_handler);
+static __maybe_unused DECLARE_WORK(resume_work, ish_resume_handler);
/**
* ish_resume() - ISH resume callback
* @device:device pointer
@@ -297,7 +296,7 @@ static DECLARE_WORK(resume_work, ish_resume_handler);
*
* Return: 0 to the pm core
*/
-static int ish_resume(struct device *device)
+static int __maybe_unused ish_resume(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -311,21 +310,14 @@ static int ish_resume(struct device *device)
return 0;
}
-static const struct dev_pm_ops ish_pm_ops = {
- .suspend = ish_suspend,
- .resume = ish_resume,
-};
-#define ISHTP_ISH_PM_OPS (_pm_ops)
-#else
-#define ISHTP_ISH_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(ish_pm_ops, ish_suspend, ish_resume);
static struct pci_driver ish_driver = {
.name = KBUILD_MODNAME,
.id_table = ish_pci_tbl,
.probe = ish_probe,
.remove = ish_remove,
- .driver.pm = ISHTP_ISH_PM_OPS,
+ .driver.pm = _pm_ops,
};
module_pci_driver(ish_driver);
--
2.7.4
[PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
Current ISH driver only registers suspend/resume PM callbacks which don't
support hibernation (suspend to disk). Basically after hiberation, the ISH
can't resume properly and user may not see sensor events
(for example: screen rotation may not work).
User will not see a crash or panic or anything except the following message
in log:
hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from ISHTP
device
So this patch adds support for S4/hiberbation to ISH by using the
SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly. The suspend
and resume functions will now be used for both suspend to RAM and hibernation.
If power management is disabled, SIMPLE_DEV_PM_OPS will do nothing, the suspend
and resume related functions won't be used, so mark them as __maybe_unused to
clarify that this is the intended behavior, and remove #ifdefs for power
management.
Cc: sta...@vger.kernel.org
Signed-off-by: Even Xu
Acked-by: Srinivas Pandruvada
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 582e449..a2c53ea 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -205,8 +205,7 @@ static void ish_remove(struct pci_dev *pdev)
kfree(ishtp_dev);
}
-#ifdef CONFIG_PM
-static struct device *ish_resume_device;
+static struct device __maybe_unused *ish_resume_device;
/* 50ms to get resume response */
#define WAIT_FOR_RESUME_ACK_MS 50
@@ -220,7 +219,7 @@ static struct device *ish_resume_device;
* in that case a simple resume message is enough, others we need
* a reset sequence.
*/
-static void ish_resume_handler(struct work_struct *work)
+static void __maybe_unused ish_resume_handler(struct work_struct *work)
{
struct pci_dev *pdev = to_pci_dev(ish_resume_device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -262,7 +261,7 @@ static void ish_resume_handler(struct work_struct *work)
*
* Return: 0 to the pm core
*/
-static int ish_suspend(struct device *device)
+static int __maybe_unused ish_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -288,7 +287,7 @@ static int ish_suspend(struct device *device)
return 0;
}
-static DECLARE_WORK(resume_work, ish_resume_handler);
+static __maybe_unused DECLARE_WORK(resume_work, ish_resume_handler);
/**
* ish_resume() - ISH resume callback
* @device:device pointer
@@ -297,7 +296,7 @@ static DECLARE_WORK(resume_work, ish_resume_handler);
*
* Return: 0 to the pm core
*/
-static int ish_resume(struct device *device)
+static int __maybe_unused ish_resume(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -311,21 +310,14 @@ static int ish_resume(struct device *device)
return 0;
}
-static const struct dev_pm_ops ish_pm_ops = {
- .suspend = ish_suspend,
- .resume = ish_resume,
-};
-#define ISHTP_ISH_PM_OPS (_pm_ops)
-#else
-#define ISHTP_ISH_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(ish_pm_ops, ish_suspend, ish_resume);
static struct pci_driver ish_driver = {
.name = KBUILD_MODNAME,
.id_table = ish_pci_tbl,
.probe = ish_probe,
.remove = ish_remove,
- .driver.pm = ISHTP_ISH_PM_OPS,
+ .driver.pm = _pm_ops,
};
module_pci_driver(ish_driver);
--
2.7.4
Re: [PATCH] mfd: cros_ec: remove unused __remove function
On Tue, 12 Jun 2018, Gwendal Grignou wrote:
> On Sun, Jun 10, 2018 at 11:08 PM Lee Jones wrote:
> >
> > On Fri, 08 Jun 2018, Benson Leung wrote:
> >
> > >
> > > On Fri, Jun 08, 2018 at 04:48:06PM +0200, Arnd Bergmann wrote:
> > > > This function is no longer called, so we get a harmless
> > > > warning until it is removed as well:
> > > >
> > > > drivers/mfd/cros_ec_dev.c:265:13: error: '__remove' defined but not
> > > > used [-Werror=unused-function]
> > > >
> > > > Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data")
> > >
> > > Gwendal, in PATCH v2 of https://patchwork.kernel.org/patch/10439449/
> > > you mentioned that you readded the __remove to avoid a warning when built
> > > as a module. Can you explain what's going on?
> >
> > Yes please, and quickly. I'm going to sent the patch-set today. If I
> > don't hear from you promptly, I'll probably pull the patch!
> I readded it because when cros_ec_dev is loaded as module, I get a
> warning on dmesg when unloading:
>
> """Device 'cros_pd' [or 'cros_ec'] does not have a release() function,
> it is broken and must be fixed."""
>
> The warning comes from device_release(). Given I get a warning when I
> remove the release function or when I leave it empty. Let's pull the
> patch.
I already did. It's in Mainline. :)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: cros_ec: remove unused __remove function
On Tue, 12 Jun 2018, Gwendal Grignou wrote:
> On Sun, Jun 10, 2018 at 11:08 PM Lee Jones wrote:
> >
> > On Fri, 08 Jun 2018, Benson Leung wrote:
> >
> > >
> > > On Fri, Jun 08, 2018 at 04:48:06PM +0200, Arnd Bergmann wrote:
> > > > This function is no longer called, so we get a harmless
> > > > warning until it is removed as well:
> > > >
> > > > drivers/mfd/cros_ec_dev.c:265:13: error: '__remove' defined but not
> > > > used [-Werror=unused-function]
> > > >
> > > > Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data")
> > >
> > > Gwendal, in PATCH v2 of https://patchwork.kernel.org/patch/10439449/
> > > you mentioned that you readded the __remove to avoid a warning when built
> > > as a module. Can you explain what's going on?
> >
> > Yes please, and quickly. I'm going to sent the patch-set today. If I
> > don't hear from you promptly, I'll probably pull the patch!
> I readded it because when cros_ec_dev is loaded as module, I get a
> warning on dmesg when unloading:
>
> """Device 'cros_pd' [or 'cros_ec'] does not have a release() function,
> it is broken and must be fixed."""
>
> The warning comes from device_release(). Given I get a warning when I
> remove the release function or when I leave it empty. Let's pull the
> patch.
I already did. It's in Mainline. :)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
Hi everyone,
I wrote a patch for this issue.
There was a discussion about prechecking approach, but I finally found
out it's hard to make change on memblock after numa_init, so I take
another apporach (see patch description).
I'm glad if you check that it works for you.
Thanks,
Naoya Horiguchi
---
From: Naoya Horiguchi
Date: Wed, 13 Jun 2018 12:43:27 +0900
Subject: [PATCH] mm: zero remaining unavailable struct pages
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: [#1] SMP PTI
CPU: 2 PID: 1728 Comm: page-types Not tainted
4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
04/01/2014
RIP: 0010:stable_page_flags+0x27/0x3c0
Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53
48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84
10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
RSP: 0018:bbd44111fde0 EFLAGS: 00010202
RAX: fffe RBX: 7fffeff9 RCX:
RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
RBP: R08: 0001 R09: 0001
R10: bbd44111fed8 R11: R12: ed1182fff5c0
R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
FS: 7efc4335a500() GS:93a5bfc0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: fffe CR3: b2a58000 CR4: 001406e0
Call Trace:
kpageflags_read+0xc7/0x120
proc_reg_read+0x3c/0x60
__vfs_read+0x36/0x170
vfs_read+0x89/0x130
ksys_pread64+0x71/0x90
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7efc42e75e23
Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83
3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34
c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
According to kernel bisection, this problem became visible due to commit
f7f99100d8d9 which changes how struct pages are initialized.
Memblock layout affects the pfn ranges covered by node/zone. Consider
that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
the default (no memmap= given) memblock layout is like below:
MEMBLOCK configuration:
memory size = 0x0001fff75c00 reserved size = 0x0300c000
memory.cnt = 0x4
memory[0x0] [0x1000-0x0009efff], 0x0009e000
bytes on node 0 flags: 0x0
memory[0x1] [0x0010-0xbffd6fff], 0xbfed7000
bytes on node 0 flags: 0x0
memory[0x2] [0x0001-0x00013fff], 0x4000
bytes on node 0 flags: 0x0
memory[0x3] [0x00014000-0x00023fff], 0x0001
bytes on node 1 flags: 0x0
...
If you give memmap=1G!4G (so it just covers memory[0x2]),
the range [0x1-0x13fff] is gone:
MEMBLOCK configuration:
memory size = 0x0001bff75c00 reserved size = 0x0300c000
memory.cnt = 0x3
memory[0x0] [0x1000-0x0009efff], 0x0009e000
bytes on node 0 flags: 0x0
memory[0x1] [0x0010-0xbffd6fff], 0xbfed7000
bytes on node 0 flags: 0x0
memory[0x2] [0x00014000-0x00023fff], 0x0001
bytes on node 1 flags: 0x0
...
This causes shrinking node 0's pfn range because it is calculated by
the address range of memblock.memory. So some of struct pages in the
gap range are left uninitialized.
We have a function zero_resv_unavail() which does zeroing the struct
pages outside memblock.memory, but currently it covers only the reserved
unavailable range (i.e. memblock.memory && !memblock.reserved).
This patch extends it to cover all unavailable range, which fixes
the reported issue.
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Naoya Horiguchi
---
include/linux/memblock.h | 16
mm/page_alloc.c | 33 -
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index ca59883c8364..f191e51c5d2a 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -236,22 +236,6 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long
*out_start_pfn,
for_each_mem_range_rev(i, , , \
nid, flags, p_start, p_end, p_nid)
-/**
- * for_each_resv_unavail_range - iterate through reserved and unavailable
memory
- * @i: u64 used as loop variable
- * @flags: pick from blocks based on memory attributes
- * @p_start: ptr to phys_addr_t for start address of the range, can be
[PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
Hi everyone,
I wrote a patch for this issue.
There was a discussion about prechecking approach, but I finally found
out it's hard to make change on memblock after numa_init, so I take
another apporach (see patch description).
I'm glad if you check that it works for you.
Thanks,
Naoya Horiguchi
---
From: Naoya Horiguchi
Date: Wed, 13 Jun 2018 12:43:27 +0900
Subject: [PATCH] mm: zero remaining unavailable struct pages
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: [#1] SMP PTI
CPU: 2 PID: 1728 Comm: page-types Not tainted
4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
04/01/2014
RIP: 0010:stable_page_flags+0x27/0x3c0
Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53
48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84
10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
RSP: 0018:bbd44111fde0 EFLAGS: 00010202
RAX: fffe RBX: 7fffeff9 RCX:
RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
RBP: R08: 0001 R09: 0001
R10: bbd44111fed8 R11: R12: ed1182fff5c0
R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
FS: 7efc4335a500() GS:93a5bfc0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: fffe CR3: b2a58000 CR4: 001406e0
Call Trace:
kpageflags_read+0xc7/0x120
proc_reg_read+0x3c/0x60
__vfs_read+0x36/0x170
vfs_read+0x89/0x130
ksys_pread64+0x71/0x90
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7efc42e75e23
Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83
3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34
c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
According to kernel bisection, this problem became visible due to commit
f7f99100d8d9 which changes how struct pages are initialized.
Memblock layout affects the pfn ranges covered by node/zone. Consider
that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
the default (no memmap= given) memblock layout is like below:
MEMBLOCK configuration:
memory size = 0x0001fff75c00 reserved size = 0x0300c000
memory.cnt = 0x4
memory[0x0] [0x1000-0x0009efff], 0x0009e000
bytes on node 0 flags: 0x0
memory[0x1] [0x0010-0xbffd6fff], 0xbfed7000
bytes on node 0 flags: 0x0
memory[0x2] [0x0001-0x00013fff], 0x4000
bytes on node 0 flags: 0x0
memory[0x3] [0x00014000-0x00023fff], 0x0001
bytes on node 1 flags: 0x0
...
If you give memmap=1G!4G (so it just covers memory[0x2]),
the range [0x1-0x13fff] is gone:
MEMBLOCK configuration:
memory size = 0x0001bff75c00 reserved size = 0x0300c000
memory.cnt = 0x3
memory[0x0] [0x1000-0x0009efff], 0x0009e000
bytes on node 0 flags: 0x0
memory[0x1] [0x0010-0xbffd6fff], 0xbfed7000
bytes on node 0 flags: 0x0
memory[0x2] [0x00014000-0x00023fff], 0x0001
bytes on node 1 flags: 0x0
...
This causes shrinking node 0's pfn range because it is calculated by
the address range of memblock.memory. So some of struct pages in the
gap range are left uninitialized.
We have a function zero_resv_unavail() which does zeroing the struct
pages outside memblock.memory, but currently it covers only the reserved
unavailable range (i.e. memblock.memory && !memblock.reserved).
This patch extends it to cover all unavailable range, which fixes
the reported issue.
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Naoya Horiguchi
---
include/linux/memblock.h | 16
mm/page_alloc.c | 33 -
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index ca59883c8364..f191e51c5d2a 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -236,22 +236,6 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long
*out_start_pfn,
for_each_mem_range_rev(i, , , \
nid, flags, p_start, p_end, p_nid)
-/**
- * for_each_resv_unavail_range - iterate through reserved and unavailable
memory
- * @i: u64 used as loop variable
- * @flags: pick from blocks based on memory attributes
- * @p_start: ptr to phys_addr_t for start address of the range, can be
[PATCH] mfd: kempld-core: constify variables that point to const structure
Add const to the declaration of various local variables of type
kempld_platform_data for which the referenced value is always only
dereferenced or passed to a const parameter, to record the fact that
kempld_platform_data_generic is declared as const.
The semantic match that finds this issue is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
identifier i,j;
@@
const struct i j = { ... };
@ok@
identifier r.i;
position p;
@@
const struct i@p *
@@
identifier r.i;
position p != ok.p;
@@
* struct i@p *
//
Signed-off-by: Julia Lawall
---
drivers/mfd/kempld-core.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c
index 390b27c..fb5a10b 100644
--- a/drivers/mfd/kempld-core.c
+++ b/drivers/mfd/kempld-core.c
@@ -143,7 +143,7 @@ static int kempld_register_cells_generic(struct
kempld_device_data *pld)
static int kempld_create_platform_device(const struct dmi_system_id *id)
{
- struct kempld_platform_data *pdata = id->driver_data;
+ const struct kempld_platform_data *pdata = id->driver_data;
int ret;
kempld_pdev = platform_device_alloc("kempld", -1);
@@ -259,7 +259,7 @@ void kempld_write32(struct kempld_device_data *pld, u8
index, u32 data)
*/
void kempld_get_mutex(struct kempld_device_data *pld)
{
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
mutex_lock(>lock);
pdata->get_hardware_mutex(pld);
@@ -272,7 +272,7 @@ void kempld_get_mutex(struct kempld_device_data *pld)
*/
void kempld_release_mutex(struct kempld_device_data *pld)
{
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
pdata->release_hardware_mutex(pld);
mutex_unlock(>lock);
@@ -290,7 +290,7 @@ void kempld_release_mutex(struct kempld_device_data *pld)
static int kempld_get_info(struct kempld_device_data *pld)
{
int ret;
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
char major, minor;
ret = pdata->get_info(pld);
@@ -332,7 +332,7 @@ static int kempld_get_info(struct kempld_device_data *pld)
*/
static int kempld_register_cells(struct kempld_device_data *pld)
{
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
return pdata->register_cells(pld);
}
@@ -444,7 +444,8 @@ static int kempld_detect_device(struct kempld_device_data
*pld)
static int kempld_probe(struct platform_device *pdev)
{
- struct kempld_platform_data *pdata = dev_get_platdata(>dev);
+ const struct kempld_platform_data *pdata =
+ dev_get_platdata(>dev);
struct device *dev = >dev;
struct kempld_device_data *pld;
struct resource *ioport;
@@ -476,7 +477,7 @@ static int kempld_probe(struct platform_device *pdev)
static int kempld_remove(struct platform_device *pdev)
{
struct kempld_device_data *pld = platform_get_drvdata(pdev);
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
sysfs_remove_group(>dev->kobj, _attr_group);
[PATCH] mfd: kempld-core: constify variables that point to const structure
Add const to the declaration of various local variables of type
kempld_platform_data for which the referenced value is always only
dereferenced or passed to a const parameter, to record the fact that
kempld_platform_data_generic is declared as const.
The semantic match that finds this issue is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
identifier i,j;
@@
const struct i j = { ... };
@ok@
identifier r.i;
position p;
@@
const struct i@p *
@@
identifier r.i;
position p != ok.p;
@@
* struct i@p *
//
Signed-off-by: Julia Lawall
---
drivers/mfd/kempld-core.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c
index 390b27c..fb5a10b 100644
--- a/drivers/mfd/kempld-core.c
+++ b/drivers/mfd/kempld-core.c
@@ -143,7 +143,7 @@ static int kempld_register_cells_generic(struct
kempld_device_data *pld)
static int kempld_create_platform_device(const struct dmi_system_id *id)
{
- struct kempld_platform_data *pdata = id->driver_data;
+ const struct kempld_platform_data *pdata = id->driver_data;
int ret;
kempld_pdev = platform_device_alloc("kempld", -1);
@@ -259,7 +259,7 @@ void kempld_write32(struct kempld_device_data *pld, u8
index, u32 data)
*/
void kempld_get_mutex(struct kempld_device_data *pld)
{
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
mutex_lock(>lock);
pdata->get_hardware_mutex(pld);
@@ -272,7 +272,7 @@ void kempld_get_mutex(struct kempld_device_data *pld)
*/
void kempld_release_mutex(struct kempld_device_data *pld)
{
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
pdata->release_hardware_mutex(pld);
mutex_unlock(>lock);
@@ -290,7 +290,7 @@ void kempld_release_mutex(struct kempld_device_data *pld)
static int kempld_get_info(struct kempld_device_data *pld)
{
int ret;
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
char major, minor;
ret = pdata->get_info(pld);
@@ -332,7 +332,7 @@ static int kempld_get_info(struct kempld_device_data *pld)
*/
static int kempld_register_cells(struct kempld_device_data *pld)
{
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
return pdata->register_cells(pld);
}
@@ -444,7 +444,8 @@ static int kempld_detect_device(struct kempld_device_data
*pld)
static int kempld_probe(struct platform_device *pdev)
{
- struct kempld_platform_data *pdata = dev_get_platdata(>dev);
+ const struct kempld_platform_data *pdata =
+ dev_get_platdata(>dev);
struct device *dev = >dev;
struct kempld_device_data *pld;
struct resource *ioport;
@@ -476,7 +477,7 @@ static int kempld_probe(struct platform_device *pdev)
static int kempld_remove(struct platform_device *pdev)
{
struct kempld_device_data *pld = platform_get_drvdata(pdev);
- struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
+ const struct kempld_platform_data *pdata = dev_get_platdata(pld->dev);
sysfs_remove_group(>dev->kobj, _attr_group);
[lkp-robot] [watchdog/softlockup] 4808e7a5dc: BUG:KASAN:null-ptr-deref_in_h
FYI, we noticed the following commit (built with gcc-5):
commit: 4808e7a5dc055fd8776e6b59e02775730ea716f6 ("watchdog/softlockup: Replace
"watchdog/%u" threads with cpu_stop_work")
url:
https://github.com/0day-ci/linux/commits/Peter-Zijlstra/kthread-smpboot-More-fixes/20180613-003329
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
||
1e88b12632 | 4808e7a5dc |
++++
| boot_successes | 0
| 0 |
| boot_failures | 10
| 11 |
| WARNING:at_lib/debugobjects.c:#__debug_object_init | 10
||
| RIP:__debug_object_init| 10
||
| WARNING:suspicious_RCU_usage | 10
||
| lib/test_rhashtable.c:#suspicious_rcu_dereference_protected()usage | 10
||
| WARNING:possible_circular_locking_dependency_detected | 9
||
| BUG:workqueue_lockup-pool | 1
||
| BUG:KASAN:null-ptr-deref_in_h | 0
| 11 |
| BUG:unable_to_handle_kernel| 0
| 11 |
| Oops:#[##] | 0
| 11 |
| RIP:hrtimer_active | 0
| 11 |
| Kernel_panic-not_syncing:Fatal_exception | 0
| 11 |
++++
[0.037000] BUG: KASAN: null-ptr-deref in hrtimer_active+0x70/0xa0
[0.037000] Read of size 4 at addr 0010 by task swapper/1
[0.037000]
[0.037000] CPU: 0 PID: 1 Comm: swapper Tainted: GT
4.17.0-11348-g4808e7a #1
[0.037000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[0.037000] Call Trace:
[0.037000] ? kasan_report+0xe3/0x360
[0.037000] ? hrtimer_active+0x70/0xa0
[0.037000] ? hrtimer_try_to_cancel+0x17/0x210
[0.037000] ? hrtimer_cancel+0x15/0x20
[0.037000] ? softlockup_stop_fn+0x11/0x20
[0.037000] ? lockup_detector_reconfigure+0x25/0xa0
[0.037000] ? lockup_detector_init+0x51/0x5d
[0.037000] ? kernel_init_freeable+0xa9/0x243
[0.037000] ? rest_init+0xd0/0xd0
[0.037000] ? kernel_init+0xf/0x120
[0.037000] ? rest_init+0xd0/0xd0
[0.037000] ? ret_from_fork+0x24/0x30
[0.037000]
==
[0.037000] Disabling lock debugging due to kernel taint
[0.037032] BUG: unable to handle kernel NULL pointer dereference at
0010
[0.038000] PGD 0 P4D 0
[0.038000] Oops: [#1] PREEMPT KASAN PTI
[0.038000] CPU: 0 PID: 1 Comm: swapper Tainted: GB T
4.17.0-11348-g4808e7a #1
[0.038000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[0.038000] RIP: 0010:hrtimer_active+0x70/0xa0
[0.038000] Code: 11 4c 89 f7 e8 a1 05 19 00 48 8b 45 30 48 39 c3 74 36 4c
89 f7 e8 90 05 19 00 48 8b 5d 30 4c 8d 6b 10 4c 89 ef e8 80 04 19 00 <44> 8b 63
10 41 f6 c4 01 74 a2 f3 90 eb ea 5b b8 01 00 00 00 5d 41
[0.038000] RSP: :8815fe68 EFLAGS: 00010282
[0.038000] RAX: 88154900 RBX: RCX:
[0.038000] RDX: 0001 RSI: RDI: 8242a236
[0.038000] RBP: 8351ef20 R08: R09:
[0.038000] R10: 0001 R11: fbfff09346c7 R12:
[0.038000] R13: 0010 R14: 8351ef50 R15: 8351ef58
[0.038000] FS: () GS:83482000()
knlGS:
[0.038000] CS: 0010 DS: ES: CR0: 80050033
[0.038000] CR2: 0010 CR3: 03424000 CR4: 06b0
[0.038000] Call Trace:
[0.038000] ? hrtimer_try_to_cancel+0x17/0x210
[0.038000] ? hrtimer_cancel+0x15/0x20
[0.038000] ? softlockup_stop_fn+0x11/0x20
[0.038000] ? lockup_detector_reconfigure+0x25/0xa0
[0.038000] ? lockup_detector_init+0x51/0x5d
[0.038000] ? kernel_init_freeable+0xa9/0x243
[0.038000] ? rest_init+0xd0/0xd0
[0.038000] ? kernel_init+0xf/0x120
[0.038000] ? rest_init+0xd0/0xd0
[0.038000] ?
[lkp-robot] [watchdog/softlockup] 4808e7a5dc: BUG:KASAN:null-ptr-deref_in_h
FYI, we noticed the following commit (built with gcc-5):
commit: 4808e7a5dc055fd8776e6b59e02775730ea716f6 ("watchdog/softlockup: Replace
"watchdog/%u" threads with cpu_stop_work")
url:
https://github.com/0day-ci/linux/commits/Peter-Zijlstra/kthread-smpboot-More-fixes/20180613-003329
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
||
1e88b12632 | 4808e7a5dc |
++++
| boot_successes | 0
| 0 |
| boot_failures | 10
| 11 |
| WARNING:at_lib/debugobjects.c:#__debug_object_init | 10
||
| RIP:__debug_object_init| 10
||
| WARNING:suspicious_RCU_usage | 10
||
| lib/test_rhashtable.c:#suspicious_rcu_dereference_protected()usage | 10
||
| WARNING:possible_circular_locking_dependency_detected | 9
||
| BUG:workqueue_lockup-pool | 1
||
| BUG:KASAN:null-ptr-deref_in_h | 0
| 11 |
| BUG:unable_to_handle_kernel| 0
| 11 |
| Oops:#[##] | 0
| 11 |
| RIP:hrtimer_active | 0
| 11 |
| Kernel_panic-not_syncing:Fatal_exception | 0
| 11 |
++++
[0.037000] BUG: KASAN: null-ptr-deref in hrtimer_active+0x70/0xa0
[0.037000] Read of size 4 at addr 0010 by task swapper/1
[0.037000]
[0.037000] CPU: 0 PID: 1 Comm: swapper Tainted: GT
4.17.0-11348-g4808e7a #1
[0.037000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[0.037000] Call Trace:
[0.037000] ? kasan_report+0xe3/0x360
[0.037000] ? hrtimer_active+0x70/0xa0
[0.037000] ? hrtimer_try_to_cancel+0x17/0x210
[0.037000] ? hrtimer_cancel+0x15/0x20
[0.037000] ? softlockup_stop_fn+0x11/0x20
[0.037000] ? lockup_detector_reconfigure+0x25/0xa0
[0.037000] ? lockup_detector_init+0x51/0x5d
[0.037000] ? kernel_init_freeable+0xa9/0x243
[0.037000] ? rest_init+0xd0/0xd0
[0.037000] ? kernel_init+0xf/0x120
[0.037000] ? rest_init+0xd0/0xd0
[0.037000] ? ret_from_fork+0x24/0x30
[0.037000]
==
[0.037000] Disabling lock debugging due to kernel taint
[0.037032] BUG: unable to handle kernel NULL pointer dereference at
0010
[0.038000] PGD 0 P4D 0
[0.038000] Oops: [#1] PREEMPT KASAN PTI
[0.038000] CPU: 0 PID: 1 Comm: swapper Tainted: GB T
4.17.0-11348-g4808e7a #1
[0.038000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[0.038000] RIP: 0010:hrtimer_active+0x70/0xa0
[0.038000] Code: 11 4c 89 f7 e8 a1 05 19 00 48 8b 45 30 48 39 c3 74 36 4c
89 f7 e8 90 05 19 00 48 8b 5d 30 4c 8d 6b 10 4c 89 ef e8 80 04 19 00 <44> 8b 63
10 41 f6 c4 01 74 a2 f3 90 eb ea 5b b8 01 00 00 00 5d 41
[0.038000] RSP: :8815fe68 EFLAGS: 00010282
[0.038000] RAX: 88154900 RBX: RCX:
[0.038000] RDX: 0001 RSI: RDI: 8242a236
[0.038000] RBP: 8351ef20 R08: R09:
[0.038000] R10: 0001 R11: fbfff09346c7 R12:
[0.038000] R13: 0010 R14: 8351ef50 R15: 8351ef58
[0.038000] FS: () GS:83482000()
knlGS:
[0.038000] CS: 0010 DS: ES: CR0: 80050033
[0.038000] CR2: 0010 CR3: 03424000 CR4: 06b0
[0.038000] Call Trace:
[0.038000] ? hrtimer_try_to_cancel+0x17/0x210
[0.038000] ? hrtimer_cancel+0x15/0x20
[0.038000] ? softlockup_stop_fn+0x11/0x20
[0.038000] ? lockup_detector_reconfigure+0x25/0xa0
[0.038000] ? lockup_detector_init+0x51/0x5d
[0.038000] ? kernel_init_freeable+0xa9/0x243
[0.038000] ? rest_init+0xd0/0xd0
[0.038000] ? kernel_init+0xf/0x120
[0.038000] ? rest_init+0xd0/0xd0
[0.038000] ?
Re: REGRESSION?: debugfs: inode: debugfs_create_dir uses mode permission from parent
On Tue, Jun 12, 2018 at 03:40:41PM -0700, John Stultz wrote:
> Hey all,
> I noticed recently that linus/master (plus patches) stopped booting
> to UI on HiKey960, and I bisected the issue down to:
> 92170b62f1c1 ("debugfs: inode: debugfs_create_dir uses mode permission
> from parent")
>
> On the HiKey960 board, we mount debugfs via:
>mount debugfs /sys/kernel/debug /sys/kernel/debug mode=755
>
> But since the change, it seems most of the nodes in /sys/kernel/debug
> are: drwx--
>
> Which ends up breaking the egl library, keeping it from loading.
While the debugfs change is now reverted in Linus's tree, I find it
"odd" that a debugfs change would cause egl from loading entirely. No
userspace code should depend on debugfs files being there or not. If it
does, that's a bug as debugfs is for _debugging_ stuff, it should not be
an interface between user/kernel that userspace requires for basic
functionality like booting.
And yes, I know all about the crazy qualcom batter api, where they
shoved it into debugfs and ignored the built-in kernel api, that should
be fixed now. If this is a new one-of-those types of problem, I need to
know so it can get resolved.
thanks,
greg k-h
Re: REGRESSION?: debugfs: inode: debugfs_create_dir uses mode permission from parent
On Tue, Jun 12, 2018 at 03:40:41PM -0700, John Stultz wrote:
> Hey all,
> I noticed recently that linus/master (plus patches) stopped booting
> to UI on HiKey960, and I bisected the issue down to:
> 92170b62f1c1 ("debugfs: inode: debugfs_create_dir uses mode permission
> from parent")
>
> On the HiKey960 board, we mount debugfs via:
>mount debugfs /sys/kernel/debug /sys/kernel/debug mode=755
>
> But since the change, it seems most of the nodes in /sys/kernel/debug
> are: drwx--
>
> Which ends up breaking the egl library, keeping it from loading.
While the debugfs change is now reverted in Linus's tree, I find it
"odd" that a debugfs change would cause egl from loading entirely. No
userspace code should depend on debugfs files being there or not. If it
does, that's a bug as debugfs is for _debugging_ stuff, it should not be
an interface between user/kernel that userspace requires for basic
functionality like booting.
And yes, I know all about the crazy qualcom batter api, where they
shoved it into debugfs and ignored the built-in kernel api, that should
be fixed now. If this is a new one-of-those types of problem, I need to
know so it can get resolved.
thanks,
greg k-h
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 9:49 PM Greg Kroah-Hartman wrote: > > The revert is fine, I'll work on the kvm debugfs file stuff for 4.19. Yeah, I did two fairly brute-force fixes for two different issues (the only common thread was kvm - testing the first fix was what then got me to the debugfs revert). I'm going to be start traveling towards Japan and China tomorrow morning, so I wanted to just get the problems I noticed out of my tree. Both of the two top commits in my tree probably have better more targeted fixes eventually. Linus
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 9:49 PM Greg Kroah-Hartman wrote: > > The revert is fine, I'll work on the kvm debugfs file stuff for 4.19. Yeah, I did two fairly brute-force fixes for two different issues (the only common thread was kvm - testing the first fix was what then got me to the debugfs revert). I'm going to be start traveling towards Japan and China tomorrow morning, so I wanted to just get the problems I noticed out of my tree. Both of the two top commits in my tree probably have better more targeted fixes eventually. Linus
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 08:52:08PM -0700, Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 8:26 PM Linus Torvalds
> wrote:
> >
> > Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
> > mode permission from parent") breaks lkvm, and I think qemu-kvm too.
> >
> > The commit looks like the RightThing(tm) to do, but we do not break
> > existing work-flows, no matter how much we'd like to. So it gets
> > reverted.
>
> I suspect it's the special kvm debugfs entries - see kvm_create_vm_debugfs()
>
> Anyway, I've verified that both qemu-kvm and kvm-tool work fine with
> the revert in place.
I should have read the whole thread :)
The revert is fine, I'll work on the kvm debugfs file stuff for 4.19.
thanks,
greg k-h
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 08:52:08PM -0700, Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 8:26 PM Linus Torvalds
> wrote:
> >
> > Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
> > mode permission from parent") breaks lkvm, and I think qemu-kvm too.
> >
> > The commit looks like the RightThing(tm) to do, but we do not break
> > existing work-flows, no matter how much we'd like to. So it gets
> > reverted.
>
> I suspect it's the special kvm debugfs entries - see kvm_create_vm_debugfs()
>
> Anyway, I've verified that both qemu-kvm and kvm-tool work fine with
> the revert in place.
I should have read the whole thread :)
The revert is fine, I'll work on the kvm debugfs file stuff for 4.19.
thanks,
greg k-h
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 08:26:46PM -0700, Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 8:00 PM Linus Torvalds
> wrote:
> >
> > Yeah, the biusection seems to actually be diving into Greg's device pulls.
> >
> > Odd. I'm not seeing why that would break kvm, but maybe there's
> > something in the device core layer that really messed it up.
> >
> > I'll continue to bisect to see.
>
> Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
> mode permission from parent") breaks lkvm, and I think qemu-kvm too.
>
> The commit looks like the RightThing(tm) to do, but we do not break
> existing work-flows, no matter how much we'd like to. So it gets
> reverted.
>
> Greg, Thomas, perhaps some alternative model? I'm not sure exactly
> what kvm needs from debugfs.
I don't know either, I have a revert of that patch sitting in my queue
waiting to send to you for 4.18-rc1. I didn't realize it was causing
breakage for others, or I would have sent it to you now. You can revert
it yourself now if you want, so we can fix this problem now and work on
figuring out what is so "odd" about kvm's debugfs files.
thanks,
greg k-h
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 08:26:46PM -0700, Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 8:00 PM Linus Torvalds
> wrote:
> >
> > Yeah, the biusection seems to actually be diving into Greg's device pulls.
> >
> > Odd. I'm not seeing why that would break kvm, but maybe there's
> > something in the device core layer that really messed it up.
> >
> > I'll continue to bisect to see.
>
> Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
> mode permission from parent") breaks lkvm, and I think qemu-kvm too.
>
> The commit looks like the RightThing(tm) to do, but we do not break
> existing work-flows, no matter how much we'd like to. So it gets
> reverted.
>
> Greg, Thomas, perhaps some alternative model? I'm not sure exactly
> what kvm needs from debugfs.
I don't know either, I have a revert of that patch sitting in my queue
waiting to send to you for 4.18-rc1. I didn't realize it was causing
breakage for others, or I would have sent it to you now. You can revert
it yourself now if you want, so we can fix this problem now and work on
figuring out what is so "odd" about kvm's debugfs files.
thanks,
greg k-h
Re: [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
* Janusz Krzysztofik [180613 01:18]:
> On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> > Hi Janusz,
> >
> > On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > > GPIO lookup table for ams-delta-serio device was introduced by commit
> > > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > > lookup table" was not accepted by subystem maintainer who requested
> > > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > > with a regulator and removal of remaining GPIO pins from the driver as
> > > not handled by it.
> > >
> > > Let's start with removal of no the longer needed GPIO lookup table from
> > > the board init file.
> > >
> > > Series created and tested on top of next-20180608 tag from linux-next
> > > tree.
> >
> > This all is really nice (modulo a couple of questions), thank you for
> > implementing this. How do you want to merge this? Through OMAP tree or
> > input?
>
> Hi Dmitry,
>
> If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
> have a few board patches built on top of it in my queue.
Works for me once Dmitry is happy with the patches.
Regards,
Tony
Re: [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
* Janusz Krzysztofik [180613 01:18]:
> On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> > Hi Janusz,
> >
> > On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > > GPIO lookup table for ams-delta-serio device was introduced by commit
> > > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > > lookup table" was not accepted by subystem maintainer who requested
> > > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > > with a regulator and removal of remaining GPIO pins from the driver as
> > > not handled by it.
> > >
> > > Let's start with removal of no the longer needed GPIO lookup table from
> > > the board init file.
> > >
> > > Series created and tested on top of next-20180608 tag from linux-next
> > > tree.
> >
> > This all is really nice (modulo a couple of questions), thank you for
> > implementing this. How do you want to merge this? Through OMAP tree or
> > input?
>
> Hi Dmitry,
>
> If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
> have a few board patches built on top of it in my queue.
Works for me once Dmitry is happy with the patches.
Regards,
Tony
Re: [PATCH 3.18 00/21] 3.18.113-stable review
On Tue, Jun 12, 2018 at 03:08:12PM -0700, kernelci.org bot wrote: > stable-rc/linux-3.18.y boot: 52 boots: 28 failed, 18 passed with 1 offline, 5 > conflicts (v3.18.112-22-gb0582263e3c9) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-22-gb0582263e3c9/ > Full Build Summary: > https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-22-gb0582263e3c9/ > > Tree: stable-rc > Branch: linux-3.18.y > Git Describe: v3.18.112-22-gb0582263e3c9 > Git Commit: b0582263e3c9810fd887ca92d19cb9ff30a4d9f6 > Git URL: > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 24 unique boards, 12 SoC families, 13 builds out of 183 > > Boot Regressions Detected: > > arm: > > bcm2835_defconfig: > bcm2835-rpi-b: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > davinci_all_defconfig: > dm365evm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > exynos_defconfig: > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > imx_v6_v7_defconfig: > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > multi_v7_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > zynq-zc702: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > mvebu_v7_defconfig: > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > omap2plus_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sama5_defconfig: > at91-sama5d4ek: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sunxi_defconfig: > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > tegra_defconfig: > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) That is a lot of new failures, did the whole lab fail, or is this really a problem in v3.18.112 here? thanks, greg k-h
Re: [PATCH 4.9 00/31] 4.9.108-stable review
On Tue, Jun 12, 2018 at 02:58:16PM -0600, Shuah Khan wrote: > On 06/12/2018 10:46 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.108 release. > > There are 31 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jun 14 16:46:09 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.108-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.9.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.9 00/31] 4.9.108-stable review
On Tue, Jun 12, 2018 at 02:58:16PM -0600, Shuah Khan wrote: > On 06/12/2018 10:46 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.108 release. > > There are 31 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jun 14 16:46:09 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.108-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.9.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 3.18 00/21] 3.18.113-stable review
On Tue, Jun 12, 2018 at 03:08:12PM -0700, kernelci.org bot wrote: > stable-rc/linux-3.18.y boot: 52 boots: 28 failed, 18 passed with 1 offline, 5 > conflicts (v3.18.112-22-gb0582263e3c9) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-22-gb0582263e3c9/ > Full Build Summary: > https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-22-gb0582263e3c9/ > > Tree: stable-rc > Branch: linux-3.18.y > Git Describe: v3.18.112-22-gb0582263e3c9 > Git Commit: b0582263e3c9810fd887ca92d19cb9ff30a4d9f6 > Git URL: > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 24 unique boards, 12 SoC families, 13 builds out of 183 > > Boot Regressions Detected: > > arm: > > bcm2835_defconfig: > bcm2835-rpi-b: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > davinci_all_defconfig: > dm365evm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > exynos_defconfig: > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > imx_v6_v7_defconfig: > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > multi_v7_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > zynq-zc702: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > mvebu_v7_defconfig: > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > omap2plus_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sama5_defconfig: > at91-sama5d4ek: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sunxi_defconfig: > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > tegra_defconfig: > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) That is a lot of new failures, did the whole lab fail, or is this really a problem in v3.18.112 here? thanks, greg k-h
Re: [PATCH v2] IB/umem: ib_ucontext already have tgid, remove pid from ib_umem structure
On Tue, May 08, 2018 at 04:50:16PM +0800, Lidong Chen wrote:
> The userspace may invoke ibv_reg_mr and ibv_dereg_mr by different threads.
> If when ibv_dereg_mr invoke and the thread which invoked ibv_reg_mr has
> exited, get_pid_task will return NULL, ib_umem_release does not decrease
> mm->pinned_vm. This patch fixes it by use tgid in ib_ucontext struct.
>
> Signed-off-by: Lidong Chen
> ---
> [v2]
> - use ib_ucontext tgid instread of tgid in ib_umem structure
I'm looking at this again, and it doesn't seem quite right..
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 9a4e899..2b6c9b5 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -119,7 +119,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
> unsigned long addr,
> umem->length = size;
> umem->address= addr;
> umem->page_shift = PAGE_SHIFT;
> - umem->pid= get_task_pid(current, PIDTYPE_PID);
> /*
>* We ask for writable memory if any of the following
>* access flags are set. "Local write" and "remote write"
> @@ -132,7 +131,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
> unsigned long addr,
>IB_ACCESS_REMOTE_ATOMIC | IB_ACCESS_MW_BIND));
>
> if (access & IB_ACCESS_ON_DEMAND) {
> - put_pid(umem->pid);
> ret = ib_umem_odp_get(context, umem, access);
> if (ret) {
> kfree(umem);
> @@ -148,7 +146,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
> unsigned long addr,
>
> page_list = (struct page **) __get_free_page(GFP_KERNEL);
> if (!page_list) {
> - put_pid(umem->pid);
> kfree(umem);
> return ERR_PTR(-ENOMEM);
> }
in ib_umem_get we are doing this:
down_write(>mm->mmap_sem);
locked = npages + current->mm->pinned_vm;
And then in release we now do:
task = get_pid_task(umem->context->tgid, PIDTYPE_PID);
if (!task)
goto out;
mm = get_task_mm(task);
mm->pinned_vm -= diff;
But there is no guarantee that context->tgid and 'current' are the
same thing during ib_umem_get..
So in the dysfunctional case where someone forks and keeps the context
FD open on both sides of the fork they can cause the pinned_vm
counter to become wrong in the processes. Sounds bad..
Thus, I think we need to go back to storing the tgid in the ib_umem
and just fix it to store the group leader not the thread PID?
And then even more we need the ib_get_mr_mm() helper to make sense of
this, because all the drivers are doing the wrong thing by using the
context->tgid too.
Is that all right?
Jason
Re: [PATCH v2] IB/umem: ib_ucontext already have tgid, remove pid from ib_umem structure
On Tue, May 08, 2018 at 04:50:16PM +0800, Lidong Chen wrote:
> The userspace may invoke ibv_reg_mr and ibv_dereg_mr by different threads.
> If when ibv_dereg_mr invoke and the thread which invoked ibv_reg_mr has
> exited, get_pid_task will return NULL, ib_umem_release does not decrease
> mm->pinned_vm. This patch fixes it by use tgid in ib_ucontext struct.
>
> Signed-off-by: Lidong Chen
> ---
> [v2]
> - use ib_ucontext tgid instread of tgid in ib_umem structure
I'm looking at this again, and it doesn't seem quite right..
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 9a4e899..2b6c9b5 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -119,7 +119,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
> unsigned long addr,
> umem->length = size;
> umem->address= addr;
> umem->page_shift = PAGE_SHIFT;
> - umem->pid= get_task_pid(current, PIDTYPE_PID);
> /*
>* We ask for writable memory if any of the following
>* access flags are set. "Local write" and "remote write"
> @@ -132,7 +131,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
> unsigned long addr,
>IB_ACCESS_REMOTE_ATOMIC | IB_ACCESS_MW_BIND));
>
> if (access & IB_ACCESS_ON_DEMAND) {
> - put_pid(umem->pid);
> ret = ib_umem_odp_get(context, umem, access);
> if (ret) {
> kfree(umem);
> @@ -148,7 +146,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
> unsigned long addr,
>
> page_list = (struct page **) __get_free_page(GFP_KERNEL);
> if (!page_list) {
> - put_pid(umem->pid);
> kfree(umem);
> return ERR_PTR(-ENOMEM);
> }
in ib_umem_get we are doing this:
down_write(>mm->mmap_sem);
locked = npages + current->mm->pinned_vm;
And then in release we now do:
task = get_pid_task(umem->context->tgid, PIDTYPE_PID);
if (!task)
goto out;
mm = get_task_mm(task);
mm->pinned_vm -= diff;
But there is no guarantee that context->tgid and 'current' are the
same thing during ib_umem_get..
So in the dysfunctional case where someone forks and keeps the context
FD open on both sides of the fork they can cause the pinned_vm
counter to become wrong in the processes. Sounds bad..
Thus, I think we need to go back to storing the tgid in the ib_umem
and just fix it to store the group leader not the thread PID?
And then even more we need the ib_get_mr_mm() helper to make sense of
this, because all the drivers are doing the wrong thing by using the
context->tgid too.
Is that all right?
Jason
Re: OOPSes in mem_cgroup_protected
On Tue, Jun 12, 2018 at 09:08:27PM -0700, John Stultz wrote:
> On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
> > Hey Tejun,
> > With the current linus/master, I'm able to fairly regularly trip
> > OOPSes (two examples below) in mem_cgroup_protected(), which seems to
> > be new. I haven't managed to trigger this sort of thing with v4.17.
> >
> > I've not had much time to dig in or bisect it - I only know that
> > enabling most of the memory debuging config options didn't seem to
> > trip anything prior to the issue. So I wanted to send you a heads up
> > to see if there was already known, or if there was anything you might
> > suggest to help chase this down.
>
>
> So the line where we're crashing seems to be in mem_cgroup_protected():
> parent_emin = READ_ONCE(parent->memory.emin);
>
> where I'm guessing the parent->memory value is null, and emin is at
> the 0x120 offset in the strucutre.
>
> Reverting the following commits seems to avoid the issue.
> bf8d5d52ffe8 ("memcg: introduce memory.min")
> 5f93ad67436b ("mm: treat memory.low value inclusive")
> 230671533d64 ("mm: memory.low hierarchical behavior")
>
> I'm guessing I'm tripping over some path where the memory value never
> gets initialized?
>
> Any ideas or suggestions?
Hi, John!
The patch below should fix the problem.
It's in the mm tree right now, and hopefully will be merged upstream asap.
Sorry for the inconvenience.
Thanks!
--
>From 276e916d62887b85c35a9d053543bb52b00a81bf Mon Sep 17 00:00:00 2001
From: Roman Gushchin
Date: Wed, 13 Jun 2018 01:01:43 +
Subject: [PATCH] mm: fix null pointer dereference in mem_cgroup_protected
Shakeel reported a crash in mem_cgroup_protected(), which can be triggered
by memcg reclaim if the legacy cgroup v1 use_hierarchy=0 mode is used:
[ 226.060572] BUG: unable to handle kernel NULL pointer dereference
at 0120
[ 226.068310] PGD 801ff55da067 P4D 801ff55da067 PUD 1fdc7df067 PMD 0
[ 226.075191] Oops: [#4] SMP PTI
[ 226.078637] CPU: 0 PID: 15581 Comm: bash Tainted: G D
4.17.0-smp-clean #5
[ 226.086635] Hardware name: ...
[ 226.094546] RIP: 0010:mem_cgroup_protected+0x54/0x130
[ 226.099533] Code: 4c 8b 8e 00 01 00 00 4c 8b 86 08 01 00 00 48 8d
8a 08 ff ff ff 48 85 d2 ba 00 00 00 00 48 0f 44 ca 48 39 c8 0f 84 cf
00 00 00 <48> 8b 81 20 01 00 00 4d 89 ca 4c 39 c8 4c 0f 46 d0 4d 85 d2
74 05
[ 226.118194] RSP: :abe64dfafa58 EFLAGS: 00010286
[ 226.123358] RAX: 9fb6ff03d000 RBX: 9fb6f5b1b000 RCX:
[ 226.130406] RDX: RSI: 9fb6f5b1b000 RDI: 9fb6f5b1b000
[ 226.137454] RBP: abe64dfafb08 R08: R09:
[ 226.144503] R10: R11: c800 R12: abe64dfafb88
[ 226.151551] R13: 9fb6f5b1b000 R14: abe64dfafb88 R15: 9fb77fffe000
[ 226.158602] FS: 7fed1f8ac700() GS:9fb6ff40()
knlGS:
[ 226.166594] CS: 0010 DS: ES: CR0: 80050033
[ 226.172270] CR2: 0120 CR3: 001fdcf86003 CR4: 001606f0
[ 226.179317] Call Trace:
[ 226.181732] ? shrink_node+0x194/0x510
[ 226.185435] do_try_to_free_pages+0xfd/0x390
[ 226.189653] try_to_free_mem_cgroup_pages+0x123/0x210
[ 226.194643] try_charge+0x19e/0x700
[ 226.198088] mem_cgroup_try_charge+0x10b/0x1a0
[ 226.202478] wp_page_copy+0x134/0x5b0
[ 226.206094] do_wp_page+0x90/0x460
[ 226.209453] __handle_mm_fault+0x8e3/0xf30
[ 226.213498] handle_mm_fault+0xfe/0x220
[ 226.217285] __do_page_fault+0x262/0x500
[ 226.221158] do_page_fault+0x28/0xd0
[ 226.224689] ? page_fault+0x8/0x30
[ 226.228048] page_fault+0x1e/0x30
[ 226.231323] RIP: 0033:0x485b72
The problem happens because parent_mem_cgroup() returns a NULL pointer,
which is dereferenced later without a check.
As cgroup v1 has no memory guarantee support, let's make
mem_cgroup_protected() immediately return MEMCG_PROT_NONE, if the given
cgroup has no parent (non-hierarchical mode is used).
Link: http://lkml.kernel.org/r/20180611175418.7007-2-g...@fb.com
Fixes: bf8d5d52ffe8 ("memcg: introduce memory.min")
Signed-off-by: Roman Gushchin
Reported-by: Shakeel Butt
Tested-by: Shakeel Butt
Acked-by: Johannes Weiner
Acked-by: Michal Hocko
Signed-off-by: Andrew Morton
---
mm/memcontrol.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c1e64d60ed02..5a3873e9d657 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5480,6 +5480,10 @@ enum mem_cgroup_protection mem_cgroup_protected(struct
mem_cgroup *root,
elow = memcg->memory.low;
parent = parent_mem_cgroup(memcg);
+ /* No parent means a non-hierarchical mode on v1 memcg */
+ if (!parent)
+ return MEMCG_PROT_NONE;
+
if (parent == root)
goto exit;
--
2.14.4
Re: OOPSes in mem_cgroup_protected
On Tue, Jun 12, 2018 at 09:08:27PM -0700, John Stultz wrote:
> On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
> > Hey Tejun,
> > With the current linus/master, I'm able to fairly regularly trip
> > OOPSes (two examples below) in mem_cgroup_protected(), which seems to
> > be new. I haven't managed to trigger this sort of thing with v4.17.
> >
> > I've not had much time to dig in or bisect it - I only know that
> > enabling most of the memory debuging config options didn't seem to
> > trip anything prior to the issue. So I wanted to send you a heads up
> > to see if there was already known, or if there was anything you might
> > suggest to help chase this down.
>
>
> So the line where we're crashing seems to be in mem_cgroup_protected():
> parent_emin = READ_ONCE(parent->memory.emin);
>
> where I'm guessing the parent->memory value is null, and emin is at
> the 0x120 offset in the strucutre.
>
> Reverting the following commits seems to avoid the issue.
> bf8d5d52ffe8 ("memcg: introduce memory.min")
> 5f93ad67436b ("mm: treat memory.low value inclusive")
> 230671533d64 ("mm: memory.low hierarchical behavior")
>
> I'm guessing I'm tripping over some path where the memory value never
> gets initialized?
>
> Any ideas or suggestions?
Hi, John!
The patch below should fix the problem.
It's in the mm tree right now, and hopefully will be merged upstream asap.
Sorry for the inconvenience.
Thanks!
--
>From 276e916d62887b85c35a9d053543bb52b00a81bf Mon Sep 17 00:00:00 2001
From: Roman Gushchin
Date: Wed, 13 Jun 2018 01:01:43 +
Subject: [PATCH] mm: fix null pointer dereference in mem_cgroup_protected
Shakeel reported a crash in mem_cgroup_protected(), which can be triggered
by memcg reclaim if the legacy cgroup v1 use_hierarchy=0 mode is used:
[ 226.060572] BUG: unable to handle kernel NULL pointer dereference
at 0120
[ 226.068310] PGD 801ff55da067 P4D 801ff55da067 PUD 1fdc7df067 PMD 0
[ 226.075191] Oops: [#4] SMP PTI
[ 226.078637] CPU: 0 PID: 15581 Comm: bash Tainted: G D
4.17.0-smp-clean #5
[ 226.086635] Hardware name: ...
[ 226.094546] RIP: 0010:mem_cgroup_protected+0x54/0x130
[ 226.099533] Code: 4c 8b 8e 00 01 00 00 4c 8b 86 08 01 00 00 48 8d
8a 08 ff ff ff 48 85 d2 ba 00 00 00 00 48 0f 44 ca 48 39 c8 0f 84 cf
00 00 00 <48> 8b 81 20 01 00 00 4d 89 ca 4c 39 c8 4c 0f 46 d0 4d 85 d2
74 05
[ 226.118194] RSP: :abe64dfafa58 EFLAGS: 00010286
[ 226.123358] RAX: 9fb6ff03d000 RBX: 9fb6f5b1b000 RCX:
[ 226.130406] RDX: RSI: 9fb6f5b1b000 RDI: 9fb6f5b1b000
[ 226.137454] RBP: abe64dfafb08 R08: R09:
[ 226.144503] R10: R11: c800 R12: abe64dfafb88
[ 226.151551] R13: 9fb6f5b1b000 R14: abe64dfafb88 R15: 9fb77fffe000
[ 226.158602] FS: 7fed1f8ac700() GS:9fb6ff40()
knlGS:
[ 226.166594] CS: 0010 DS: ES: CR0: 80050033
[ 226.172270] CR2: 0120 CR3: 001fdcf86003 CR4: 001606f0
[ 226.179317] Call Trace:
[ 226.181732] ? shrink_node+0x194/0x510
[ 226.185435] do_try_to_free_pages+0xfd/0x390
[ 226.189653] try_to_free_mem_cgroup_pages+0x123/0x210
[ 226.194643] try_charge+0x19e/0x700
[ 226.198088] mem_cgroup_try_charge+0x10b/0x1a0
[ 226.202478] wp_page_copy+0x134/0x5b0
[ 226.206094] do_wp_page+0x90/0x460
[ 226.209453] __handle_mm_fault+0x8e3/0xf30
[ 226.213498] handle_mm_fault+0xfe/0x220
[ 226.217285] __do_page_fault+0x262/0x500
[ 226.221158] do_page_fault+0x28/0xd0
[ 226.224689] ? page_fault+0x8/0x30
[ 226.228048] page_fault+0x1e/0x30
[ 226.231323] RIP: 0033:0x485b72
The problem happens because parent_mem_cgroup() returns a NULL pointer,
which is dereferenced later without a check.
As cgroup v1 has no memory guarantee support, let's make
mem_cgroup_protected() immediately return MEMCG_PROT_NONE, if the given
cgroup has no parent (non-hierarchical mode is used).
Link: http://lkml.kernel.org/r/20180611175418.7007-2-g...@fb.com
Fixes: bf8d5d52ffe8 ("memcg: introduce memory.min")
Signed-off-by: Roman Gushchin
Reported-by: Shakeel Butt
Tested-by: Shakeel Butt
Acked-by: Johannes Weiner
Acked-by: Michal Hocko
Signed-off-by: Andrew Morton
---
mm/memcontrol.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c1e64d60ed02..5a3873e9d657 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5480,6 +5480,10 @@ enum mem_cgroup_protection mem_cgroup_protected(struct
mem_cgroup *root,
elow = memcg->memory.low;
parent = parent_mem_cgroup(memcg);
+ /* No parent means a non-hierarchical mode on v1 memcg */
+ if (!parent)
+ return MEMCG_PROT_NONE;
+
if (parent == root)
goto exit;
--
2.14.4
ACPI support in common clock framework
Hi Michael, Stephen, We are adding ACPI support in our Linux based platform. At present our clock hierarchy using common clock framework through DTS. Now we required ACPI support in common clock framework to upgrade our platform. For example, clk_get API called in many drivers to get clock device is tightly coupled with DT framework. Please let us know, if anybody in Open Source community have plans to add ACPI support for common clock framework. If not please suggest us alternative method to use common clock framework in ACPI use case. Thanks in advance. Regards, Srinath.
ACPI support in common clock framework
Hi Michael, Stephen, We are adding ACPI support in our Linux based platform. At present our clock hierarchy using common clock framework through DTS. Now we required ACPI support in common clock framework to upgrade our platform. For example, clk_get API called in many drivers to get clock device is tightly coupled with DT framework. Please let us know, if anybody in Open Source community have plans to add ACPI support for common clock framework. If not please suggest us alternative method to use common clock framework in ACPI use case. Thanks in advance. Regards, Srinath.
Re: REGRESSION: "wlcore: sdio: allow pm to handle sdio power" breaks wifi on HiKey960
* John Stultz [180612 22:15]:
> Hey Folks,
> I noticed with linus/master wifi wasn't coming up on HiKey960. I
> bisected it down and it seems to be due to:
>
> 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
> 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
>
> When wifi fails to load, the only useful error message I see is:
> [8.466097] wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed
> to get_sync(-13)
Sorry to hear about that.
> Reverting those two changes gets wifi working again for me:
> [8.754953] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
> [8.761778] random: crng init done
> [8.765185] random: 7 urandom warning(s) missed due to ratelimiting
> [8.779149] wlcore: loaded
> ...
> [ 12.945903] wlcore: PHY firmware version: Rev 8.2.0.0.237
> [ 13.058077] wlcore: firmware booted (Rev 8.9.0.0.70)
>
>
> Any suggestions how to resolve this w/o a revert?
Sounds like we need to ignore also -EACCES if runtime PM is
disabled for MMC. Care to try and see if the patch below
helps?
Regards,
Tony
8<
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -155,7 +155,7 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue
*glue)
struct mmc_card *card = func->card;
ret = pm_runtime_get_sync(>dev);
- if (ret < 0) {
+ if (ret < 0 && ret != -EACCES) {
pm_runtime_put_noidle(>dev);
dev_err(glue->dev, "%s: failed to get_sync(%d)\n",
__func__, ret);
@@ -182,7 +182,7 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue
*glue)
/* Let runtime PM know the card is powered off */
error = pm_runtime_put(>dev);
- if (error < 0 && error != -EBUSY) {
+ if (error < 0 && error != -EBUSY && error != -EACCES) {
dev_err(>dev, "%s failed: %i\n", __func__, error);
return error;
Re: REGRESSION: "wlcore: sdio: allow pm to handle sdio power" breaks wifi on HiKey960
* John Stultz [180612 22:15]:
> Hey Folks,
> I noticed with linus/master wifi wasn't coming up on HiKey960. I
> bisected it down and it seems to be due to:
>
> 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
> 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
>
> When wifi fails to load, the only useful error message I see is:
> [8.466097] wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed
> to get_sync(-13)
Sorry to hear about that.
> Reverting those two changes gets wifi working again for me:
> [8.754953] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
> [8.761778] random: crng init done
> [8.765185] random: 7 urandom warning(s) missed due to ratelimiting
> [8.779149] wlcore: loaded
> ...
> [ 12.945903] wlcore: PHY firmware version: Rev 8.2.0.0.237
> [ 13.058077] wlcore: firmware booted (Rev 8.9.0.0.70)
>
>
> Any suggestions how to resolve this w/o a revert?
Sounds like we need to ignore also -EACCES if runtime PM is
disabled for MMC. Care to try and see if the patch below
helps?
Regards,
Tony
8<
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -155,7 +155,7 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue
*glue)
struct mmc_card *card = func->card;
ret = pm_runtime_get_sync(>dev);
- if (ret < 0) {
+ if (ret < 0 && ret != -EACCES) {
pm_runtime_put_noidle(>dev);
dev_err(glue->dev, "%s: failed to get_sync(%d)\n",
__func__, ret);
@@ -182,7 +182,7 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue
*glue)
/* Let runtime PM know the card is powered off */
error = pm_runtime_put(>dev);
- if (error < 0 && error != -EBUSY) {
+ if (error < 0 && error != -EBUSY && error != -EACCES) {
dev_err(>dev, "%s failed: %i\n", __func__, error);
return error;
Re: OOPSes in mem_cgroup_protected
On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
> Hey Tejun,
> With the current linus/master, I'm able to fairly regularly trip
> OOPSes (two examples below) in mem_cgroup_protected(), which seems to
> be new. I haven't managed to trigger this sort of thing with v4.17.
>
> I've not had much time to dig in or bisect it - I only know that
> enabling most of the memory debuging config options didn't seem to
> trip anything prior to the issue. So I wanted to send you a heads up
> to see if there was already known, or if there was anything you might
> suggest to help chase this down.
So the line where we're crashing seems to be in mem_cgroup_protected():
parent_emin = READ_ONCE(parent->memory.emin);
where I'm guessing the parent->memory value is null, and emin is at
the 0x120 offset in the strucutre.
Reverting the following commits seems to avoid the issue.
bf8d5d52ffe8 ("memcg: introduce memory.min")
5f93ad67436b ("mm: treat memory.low value inclusive")
230671533d64 ("mm: memory.low hierarchical behavior")
I'm guessing I'm tripping over some path where the memory value never
gets initialized?
Any ideas or suggestions?
thanks
-john
(usually I'd trim the backtraces below, but keeping them as I added
Roman to the CC list)
> console:/ $ [ 170.530896] Unable to handle kernel read from
> unreadable memory at virtual address 0120
> [ 170.540158] Mem abort info:
> [ 170.543092] ESR = 0x9605
> [ 170.546193] Exception class = DABT (current EL), IL = 32 bits
> [ 170.552251] SET = 0, FnV = 0
> [ 170.555444] EA = 0, S1PTW = 0
> [ 170.558698] Data abort info:
> [ 170.561624] ISV = 0, ISS = 0x0005
> [ 170.565572] CM = 0, WnR = 0
> [ 170.568650] user pgtable: 4k pages, 39-bit VAs, pgdp = 190bb04e
> [ 170.575374] [0120] pgd=, pud=
> [ 170.582297] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [ 170.587929] CPU: 7 PID: 663 Comm: kswapd0 Not tainted
> 4.17.0-11699-gb4f23f3 #411
> [ 170.595358] Hardware name: HiKey Development Board (DT)
> [ 170.600623] pstate: a045 (NzCv daif +PAN -UAO)
> [ 170.605478] pc : mem_cgroup_protected+0x34/0x120
> [ 170.610142] lr : shrink_node+0x120/0x478
> [ 170.614093] sp : ff8009d23c50
> [ 170.617438] x29: ff8009d23c50 x28: ff8009d23d48
> [ 170.622808] x27: ffc074ca1000 x26: ff8009d23e28
> [ 170.628160] x25: ff8009d23d88 x24:
> [ 170.633481] x23: x22: ff8009071f80
> [ 170.638802] x21: 0012 x20: 0012
> [ 170.644124] x19: x18: 0400
> [ 170.649444] x17: x16: ffc074ca2000
> [ 170.654765] x15: x14: 0400
> [ 170.660087] x13: 00b1 x12: 0003
> [ 170.665408] x11: 0020 x10:
> [ 170.670729] x9 : 0001 x8 : 0004
> [ 170.676050] x7 : ffc074d43c00 x6 :
> [ 170.681370] x5 : x4 :
> [ 170.686690] x3 : dafa x2 :
> [ 170.692010] x1 : ffc074ca1000 x0 : ffc0386e8000
> [ 170.697335] Process kswapd0 (pid: 663, stack limit = 0xe0f0ae51)
> [ 170.704039] Call trace:
> [ 170.706497] mem_cgroup_protected+0x34/0x120
> [ 170.710775] balance_pgdat+0x1cc/0x418
> [ 170.714529] kswapd+0x180/0x3b8
> [ 170.717674] kthread+0xf8/0x128
> [ 170.720824] ret_from_fork+0x10/0x18
> [ 170.724411] Code: b40007a2 d103e042 eb02001f 540006c0 (f9409046)
> [ 170.730542] ---[ end trace 7c961b6d409886f1 ]---
> [ 170.839299] Kernel panic - not syncing: Fatal exception
> [ 170.844549] SMP: stopping secondary CPUs
> [ 170.848488] Kernel Offset: disabled
> [ 170.851982] CPU features: 0x24802004
> [ 170.86] Memory Limit: none
> [ 170.888494] Rebooting in 5 seconds..
>
>
>
>
> console:/ # [ 348.612152] Unable to handle kernel read from
> unreadable memory at virtual address 0120
> [ 348.617384] Unable to handle kernel access to user memory outside
> uaccess routines at virtual address 0120
> [ 348.621360] Mem abort info:
> [ 348.632086] Mem abort info:
> [ 348.634870] ESR = 0x9605
> [ 348.634885] Exception class = DABT (current EL), IL = 32 bits
> [ 348.637686] ESR = 0x9605
> [ 348.640785] SET = 0, FnV = 0
> [ 348.646740] Exception class = DABT (current EL), IL = 32 bits
> [ 348.649799] EA = 0, S1PTW = 0
> [ 348.652892] SET = 0, FnV = 0
> [ 348.652901] EA = 0, S1PTW = 0
> [ 348.652913] Data abort info:
> [ 348.658905] Data abort info:
> [ 348.662041] ISV = 0, ISS = 0x0005
> [ 348.662050] CM = 0, WnR = 0
> [ 348.662071] user pgtable: 4k pages, 39-bit VAs, pgdp = 697cecc4
> [ 348.665129] ISV = 0, ISS = 0x0005
> [ 348.668298] [0120] pgd=3a915003, pud=3a915003
> [ 348.671224] CM = 0, WnR = 0
> [ 348.671242] user pgtable: 4k pages, 39-bit VAs,
Re: OOPSes in mem_cgroup_protected
On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
> Hey Tejun,
> With the current linus/master, I'm able to fairly regularly trip
> OOPSes (two examples below) in mem_cgroup_protected(), which seems to
> be new. I haven't managed to trigger this sort of thing with v4.17.
>
> I've not had much time to dig in or bisect it - I only know that
> enabling most of the memory debuging config options didn't seem to
> trip anything prior to the issue. So I wanted to send you a heads up
> to see if there was already known, or if there was anything you might
> suggest to help chase this down.
So the line where we're crashing seems to be in mem_cgroup_protected():
parent_emin = READ_ONCE(parent->memory.emin);
where I'm guessing the parent->memory value is null, and emin is at
the 0x120 offset in the strucutre.
Reverting the following commits seems to avoid the issue.
bf8d5d52ffe8 ("memcg: introduce memory.min")
5f93ad67436b ("mm: treat memory.low value inclusive")
230671533d64 ("mm: memory.low hierarchical behavior")
I'm guessing I'm tripping over some path where the memory value never
gets initialized?
Any ideas or suggestions?
thanks
-john
(usually I'd trim the backtraces below, but keeping them as I added
Roman to the CC list)
> console:/ $ [ 170.530896] Unable to handle kernel read from
> unreadable memory at virtual address 0120
> [ 170.540158] Mem abort info:
> [ 170.543092] ESR = 0x9605
> [ 170.546193] Exception class = DABT (current EL), IL = 32 bits
> [ 170.552251] SET = 0, FnV = 0
> [ 170.555444] EA = 0, S1PTW = 0
> [ 170.558698] Data abort info:
> [ 170.561624] ISV = 0, ISS = 0x0005
> [ 170.565572] CM = 0, WnR = 0
> [ 170.568650] user pgtable: 4k pages, 39-bit VAs, pgdp = 190bb04e
> [ 170.575374] [0120] pgd=, pud=
> [ 170.582297] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [ 170.587929] CPU: 7 PID: 663 Comm: kswapd0 Not tainted
> 4.17.0-11699-gb4f23f3 #411
> [ 170.595358] Hardware name: HiKey Development Board (DT)
> [ 170.600623] pstate: a045 (NzCv daif +PAN -UAO)
> [ 170.605478] pc : mem_cgroup_protected+0x34/0x120
> [ 170.610142] lr : shrink_node+0x120/0x478
> [ 170.614093] sp : ff8009d23c50
> [ 170.617438] x29: ff8009d23c50 x28: ff8009d23d48
> [ 170.622808] x27: ffc074ca1000 x26: ff8009d23e28
> [ 170.628160] x25: ff8009d23d88 x24:
> [ 170.633481] x23: x22: ff8009071f80
> [ 170.638802] x21: 0012 x20: 0012
> [ 170.644124] x19: x18: 0400
> [ 170.649444] x17: x16: ffc074ca2000
> [ 170.654765] x15: x14: 0400
> [ 170.660087] x13: 00b1 x12: 0003
> [ 170.665408] x11: 0020 x10:
> [ 170.670729] x9 : 0001 x8 : 0004
> [ 170.676050] x7 : ffc074d43c00 x6 :
> [ 170.681370] x5 : x4 :
> [ 170.686690] x3 : dafa x2 :
> [ 170.692010] x1 : ffc074ca1000 x0 : ffc0386e8000
> [ 170.697335] Process kswapd0 (pid: 663, stack limit = 0xe0f0ae51)
> [ 170.704039] Call trace:
> [ 170.706497] mem_cgroup_protected+0x34/0x120
> [ 170.710775] balance_pgdat+0x1cc/0x418
> [ 170.714529] kswapd+0x180/0x3b8
> [ 170.717674] kthread+0xf8/0x128
> [ 170.720824] ret_from_fork+0x10/0x18
> [ 170.724411] Code: b40007a2 d103e042 eb02001f 540006c0 (f9409046)
> [ 170.730542] ---[ end trace 7c961b6d409886f1 ]---
> [ 170.839299] Kernel panic - not syncing: Fatal exception
> [ 170.844549] SMP: stopping secondary CPUs
> [ 170.848488] Kernel Offset: disabled
> [ 170.851982] CPU features: 0x24802004
> [ 170.86] Memory Limit: none
> [ 170.888494] Rebooting in 5 seconds..
>
>
>
>
> console:/ # [ 348.612152] Unable to handle kernel read from
> unreadable memory at virtual address 0120
> [ 348.617384] Unable to handle kernel access to user memory outside
> uaccess routines at virtual address 0120
> [ 348.621360] Mem abort info:
> [ 348.632086] Mem abort info:
> [ 348.634870] ESR = 0x9605
> [ 348.634885] Exception class = DABT (current EL), IL = 32 bits
> [ 348.637686] ESR = 0x9605
> [ 348.640785] SET = 0, FnV = 0
> [ 348.646740] Exception class = DABT (current EL), IL = 32 bits
> [ 348.649799] EA = 0, S1PTW = 0
> [ 348.652892] SET = 0, FnV = 0
> [ 348.652901] EA = 0, S1PTW = 0
> [ 348.652913] Data abort info:
> [ 348.658905] Data abort info:
> [ 348.662041] ISV = 0, ISS = 0x0005
> [ 348.662050] CM = 0, WnR = 0
> [ 348.662071] user pgtable: 4k pages, 39-bit VAs, pgdp = 697cecc4
> [ 348.665129] ISV = 0, ISS = 0x0005
> [ 348.668298] [0120] pgd=3a915003, pud=3a915003
> [ 348.671224] CM = 0, WnR = 0
> [ 348.671242] user pgtable: 4k pages, 39-bit VAs,
[PATCH 2/2] fs/exofs: only use true/false for asignment of bool type variable
Signed-off-by: Chengguang Xu --- fs/exofs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exofs/super.c b/fs/exofs/super.c index f3e17a9..75b5db0 100644 --- a/fs/exofs/super.c +++ b/fs/exofs/super.c @@ -118,7 +118,7 @@ static int parse_options(char *options, struct exofs_mountopt *opts) EXOFS_MIN_PID); return -EINVAL; } - s_pid = 1; + s_pid = true; break; case Opt_to: if (match_int([0], )) -- 1.8.3.1
[PATCH 2/2] fs/exofs: only use true/false for asignment of bool type variable
Signed-off-by: Chengguang Xu --- fs/exofs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exofs/super.c b/fs/exofs/super.c index f3e17a9..75b5db0 100644 --- a/fs/exofs/super.c +++ b/fs/exofs/super.c @@ -118,7 +118,7 @@ static int parse_options(char *options, struct exofs_mountopt *opts) EXOFS_MIN_PID); return -EINVAL; } - s_pid = 1; + s_pid = true; break; case Opt_to: if (match_int([0], )) -- 1.8.3.1
[PATCH 1/2] fs/exofs: fix potential memory leak in mount option parsing
There are some cases can cause memory leak when parsing
option 'osdname'.
Signed-off-by: Chengguang Xu
---
fs/exofs/super.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/exofs/super.c b/fs/exofs/super.c
index 719a315..f3e17a9 100644
--- a/fs/exofs/super.c
+++ b/fs/exofs/super.c
@@ -101,6 +101,7 @@ static int parse_options(char *options, struct
exofs_mountopt *opts)
token = match_token(p, tokens, args);
switch (token) {
case Opt_name:
+ kfree(opts->dev_name);
opts->dev_name = match_strdup([0]);
if (unlikely(!opts->dev_name)) {
EXOFS_ERR("Error allocating dev_name");
@@ -867,8 +868,10 @@ static struct dentry *exofs_mount(struct file_system_type
*type,
int ret;
ret = parse_options(data, );
- if (ret)
+ if (ret) {
+ kfree(opts.dev_name);
return ERR_PTR(ret);
+ }
if (!opts.dev_name)
opts.dev_name = dev_name;
--
1.8.3.1
[PATCH 1/2] fs/exofs: fix potential memory leak in mount option parsing
There are some cases can cause memory leak when parsing
option 'osdname'.
Signed-off-by: Chengguang Xu
---
fs/exofs/super.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/exofs/super.c b/fs/exofs/super.c
index 719a315..f3e17a9 100644
--- a/fs/exofs/super.c
+++ b/fs/exofs/super.c
@@ -101,6 +101,7 @@ static int parse_options(char *options, struct
exofs_mountopt *opts)
token = match_token(p, tokens, args);
switch (token) {
case Opt_name:
+ kfree(opts->dev_name);
opts->dev_name = match_strdup([0]);
if (unlikely(!opts->dev_name)) {
EXOFS_ERR("Error allocating dev_name");
@@ -867,8 +868,10 @@ static struct dentry *exofs_mount(struct file_system_type
*type,
int ret;
ret = parse_options(data, );
- if (ret)
+ if (ret) {
+ kfree(opts.dev_name);
return ERR_PTR(ret);
+ }
if (!opts.dev_name)
opts.dev_name = dev_name;
--
1.8.3.1
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 8:26 PM Linus Torvalds
wrote:
>
> Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
> mode permission from parent") breaks lkvm, and I think qemu-kvm too.
>
> The commit looks like the RightThing(tm) to do, but we do not break
> existing work-flows, no matter how much we'd like to. So it gets
> reverted.
I suspect it's the special kvm debugfs entries - see kvm_create_vm_debugfs()
Anyway, I've verified that both qemu-kvm and kvm-tool work fine with
the revert in place.
Linus
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 8:26 PM Linus Torvalds
wrote:
>
> Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
> mode permission from parent") breaks lkvm, and I think qemu-kvm too.
>
> The commit looks like the RightThing(tm) to do, but we do not break
> existing work-flows, no matter how much we'd like to. So it gets
> reverted.
I suspect it's the special kvm debugfs entries - see kvm_create_vm_debugfs()
Anyway, I've verified that both qemu-kvm and kvm-tool work fine with
the revert in place.
Linus
Re: [PATCH 1/2] gpio: davinci: Move fetching IRQ to beginning of probe
On Tuesday 12 June 2018 08:05 PM, J, KEERTHY wrote: > > > On 6/12/2018 6:39 PM, Linus Walleij wrote: >> On Wed, Jun 6, 2018 at 11:18 AM, Keerthy wrote: >> >>> Currently IRQ resource fetching is done at the very end of probe. >>> In case the of IRQ resource not being ready, we defer probe >>> and need to revert prior changes. Hence move it to the beginning of >>> the probe so as to avoid reverting. >>> >>> Signed-off-by: Keerthy >> >> Patch applied for v4.19. > > Linus, > > There is a minor fix in v3. > > https://patchwork.kernel.org/patch/10459591/ > > Also v3 of Patch 2 Here: > > https://lkml.org/lkml/2018/6/12/146 Posted a v4: Patch 1: https://patchwork.ozlabs.org/patch/928638/ Patch 2: https://patchwork.ozlabs.org/patch/928639/ > > Regards, > Keerthy >> >> Yours, >> Linus Walleij >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >>
Re: [PATCH 1/2] gpio: davinci: Move fetching IRQ to beginning of probe
On Tuesday 12 June 2018 08:05 PM, J, KEERTHY wrote: > > > On 6/12/2018 6:39 PM, Linus Walleij wrote: >> On Wed, Jun 6, 2018 at 11:18 AM, Keerthy wrote: >> >>> Currently IRQ resource fetching is done at the very end of probe. >>> In case the of IRQ resource not being ready, we defer probe >>> and need to revert prior changes. Hence move it to the beginning of >>> the probe so as to avoid reverting. >>> >>> Signed-off-by: Keerthy >> >> Patch applied for v4.19. > > Linus, > > There is a minor fix in v3. > > https://patchwork.kernel.org/patch/10459591/ > > Also v3 of Patch 2 Here: > > https://lkml.org/lkml/2018/6/12/146 Posted a v4: Patch 1: https://patchwork.ozlabs.org/patch/928638/ Patch 2: https://patchwork.ozlabs.org/patch/928639/ > > Regards, > Keerthy >> >> Yours, >> Linus Walleij >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >>
[PATCH v4 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe
This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk board.
Changes in v3:
Changed type of bank_irq to int from unsigned
drivers/gpio/gpio-davinci.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 987126c..0ff2c0d 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem
*irq2regs(struct irq_data *d)
return g;
}
-static int davinci_gpio_irq_setup(struct platform_device *pdev);
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
/*--*/
@@ -167,7 +167,7 @@ static int davinci_gpio_get(struct gpio_chip *chip,
unsigned offset)
static int davinci_gpio_probe(struct platform_device *pdev)
{
static int ctrl_num, bank_base;
- int gpio, bank, ret = 0;
+ int gpio, bank, bank_irq, ret = 0;
unsigned ngpio, nbank;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
@@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
+ bank_irq = platform_get_irq(pdev, 0);
+ if (bank_irq < 0) {
+ dev_dbg(dev, "IRQ not populated\n");
+ return bank_irq;
+ }
+
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
if (!chips->chip.label)
@@ -243,7 +249,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
platform_set_drvdata(pdev, chips);
- ret = davinci_gpio_irq_setup(pdev);
+ ret = davinci_gpio_irq_setup(pdev, bank_irq);
if (ret)
goto err;
@@ -452,16 +458,15 @@ static struct irq_chip
*keystone_gpio_get_irq_chip(unsigned int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev)
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
{
unsignedgpio, bank;
int irq;
int ret;
struct clk *clk;
u32 binten = 0;
- unsignedngpio, bank_irq;
+ unsignedngpio;
struct device *dev = >dev;
- struct resource *res;
struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;
@@ -481,18 +486,6 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
ngpio = pdata->ngpio;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -EBUSY;
- }
-
- bank_irq = res->start;
-
- if (!bank_irq) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -ENODEV;
- }
clk = devm_clk_get(dev, "gpio");
if (IS_ERR(clk)) {
--
1.9.1
[PATCH v4 2/2] gpio: davinci: Do not assume continuous IRQ numbering
Currently the driver assumes that the interrupts are continuous
and does platform_get_irq only once and assumes the rest are continuous,
instead call platform_get_irq for all the interrupts and store them
in an array for later use.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk board.
Changes in v4:
* Corrected the gpio offset calculation from irq number
using the lookup.
Changes in v3:
* Changed irqs type from unsigned to int
Changes in v2:
* Extended the logic of using saved IRQs to unbanked IRQs
as per Grygorii's suggestion.
drivers/gpio/gpio-davinci.c| 63 --
include/linux/platform_data/gpio-davinci.h | 3 +-
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 0ff2c0d..b483d84 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem
*irq2regs(struct irq_data *d)
return g;
}
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
+static int davinci_gpio_irq_setup(struct platform_device *pdev);
/*--*/
@@ -167,8 +167,8 @@ static int davinci_gpio_get(struct gpio_chip *chip,
unsigned offset)
static int davinci_gpio_probe(struct platform_device *pdev)
{
static int ctrl_num, bank_base;
- int gpio, bank, bank_irq, ret = 0;
- unsigned ngpio, nbank;
+ int gpio, bank, i, ret = 0;
+ unsigned int ngpio, nbank, nirq;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
struct device *dev = >dev;
@@ -197,6 +197,16 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (WARN_ON(ARCH_NR_GPIOS < ngpio))
ngpio = ARCH_NR_GPIOS;
+ /*
+* If there are unbanked interrupts then the number of
+* interrupts is equal to number of gpios else all are banked so
+* number of interrupts is equal to number of banks(each with 16 gpios)
+*/
+ if (pdata->gpio_unbanked)
+ nirq = pdata->gpio_unbanked;
+ else
+ nirq = DIV_ROUND_UP(ngpio, 16);
+
nbank = DIV_ROUND_UP(ngpio, 32);
chips = devm_kzalloc(dev,
nbank * sizeof(struct davinci_gpio_controller),
@@ -209,10 +219,13 @@ static int davinci_gpio_probe(struct platform_device
*pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
- bank_irq = platform_get_irq(pdev, 0);
- if (bank_irq < 0) {
- dev_dbg(dev, "IRQ not populated\n");
- return bank_irq;
+ for (i = 0; i < nirq; i++) {
+ chips->irqs[i] = platform_get_irq(pdev, i);
+ if (chips->irqs[i] < 0) {
+ dev_info(dev, "IRQ not populated, err = %d\n",
+chips->irqs[i]);
+ return chips->irqs[i];
+ }
}
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
@@ -249,7 +262,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
platform_set_drvdata(pdev, chips);
- ret = davinci_gpio_irq_setup(pdev, bank_irq);
+ ret = davinci_gpio_irq_setup(pdev);
if (ret)
goto err;
@@ -383,7 +396,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip,
unsigned offset)
* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
*/
if (offset < d->gpio_unbanked)
- return d->base_irq + offset;
+ return d->irqs[offset];
else
return -ENODEV;
}
@@ -392,11 +405,18 @@ static int gpio_irq_type_unbanked(struct irq_data *data,
unsigned trigger)
{
struct davinci_gpio_controller *d;
struct davinci_gpio_regs __iomem *g;
- u32 mask;
+ u32 mask, i;
d = (struct davinci_gpio_controller
*)irq_data_get_irq_handler_data(data);
g = (struct davinci_gpio_regs __iomem *)d->regs[0];
- mask = __gpio_mask(data->irq - d->base_irq);
+ for (i = 0; i < MAX_INT_PER_BANK; i++)
+ if (data->irq == d->irqs[i])
+ break;
+
+ if (i == MAX_INT_PER_BANK)
+ return -EINVAL;
+
+ mask = __gpio_mask(i);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -458,7 +478,7 @@ static struct irq_chip *keystone_gpio_get_irq_chip(unsigned
int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
+static int davinci_gpio_irq_setup(struct platform_device *pdev)
{
unsignedgpio, bank;
int irq;
@@ -492,6 +512,7 @@ static int
[PATCH v4 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe
This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk board.
Changes in v3:
Changed type of bank_irq to int from unsigned
drivers/gpio/gpio-davinci.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 987126c..0ff2c0d 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem
*irq2regs(struct irq_data *d)
return g;
}
-static int davinci_gpio_irq_setup(struct platform_device *pdev);
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
/*--*/
@@ -167,7 +167,7 @@ static int davinci_gpio_get(struct gpio_chip *chip,
unsigned offset)
static int davinci_gpio_probe(struct platform_device *pdev)
{
static int ctrl_num, bank_base;
- int gpio, bank, ret = 0;
+ int gpio, bank, bank_irq, ret = 0;
unsigned ngpio, nbank;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
@@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
+ bank_irq = platform_get_irq(pdev, 0);
+ if (bank_irq < 0) {
+ dev_dbg(dev, "IRQ not populated\n");
+ return bank_irq;
+ }
+
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
if (!chips->chip.label)
@@ -243,7 +249,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
platform_set_drvdata(pdev, chips);
- ret = davinci_gpio_irq_setup(pdev);
+ ret = davinci_gpio_irq_setup(pdev, bank_irq);
if (ret)
goto err;
@@ -452,16 +458,15 @@ static struct irq_chip
*keystone_gpio_get_irq_chip(unsigned int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev)
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
{
unsignedgpio, bank;
int irq;
int ret;
struct clk *clk;
u32 binten = 0;
- unsignedngpio, bank_irq;
+ unsignedngpio;
struct device *dev = >dev;
- struct resource *res;
struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;
@@ -481,18 +486,6 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
ngpio = pdata->ngpio;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -EBUSY;
- }
-
- bank_irq = res->start;
-
- if (!bank_irq) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -ENODEV;
- }
clk = devm_clk_get(dev, "gpio");
if (IS_ERR(clk)) {
--
1.9.1
[PATCH v4 2/2] gpio: davinci: Do not assume continuous IRQ numbering
Currently the driver assumes that the interrupts are continuous
and does platform_get_irq only once and assumes the rest are continuous,
instead call platform_get_irq for all the interrupts and store them
in an array for later use.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk board.
Changes in v4:
* Corrected the gpio offset calculation from irq number
using the lookup.
Changes in v3:
* Changed irqs type from unsigned to int
Changes in v2:
* Extended the logic of using saved IRQs to unbanked IRQs
as per Grygorii's suggestion.
drivers/gpio/gpio-davinci.c| 63 --
include/linux/platform_data/gpio-davinci.h | 3 +-
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 0ff2c0d..b483d84 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem
*irq2regs(struct irq_data *d)
return g;
}
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
+static int davinci_gpio_irq_setup(struct platform_device *pdev);
/*--*/
@@ -167,8 +167,8 @@ static int davinci_gpio_get(struct gpio_chip *chip,
unsigned offset)
static int davinci_gpio_probe(struct platform_device *pdev)
{
static int ctrl_num, bank_base;
- int gpio, bank, bank_irq, ret = 0;
- unsigned ngpio, nbank;
+ int gpio, bank, i, ret = 0;
+ unsigned int ngpio, nbank, nirq;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
struct device *dev = >dev;
@@ -197,6 +197,16 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (WARN_ON(ARCH_NR_GPIOS < ngpio))
ngpio = ARCH_NR_GPIOS;
+ /*
+* If there are unbanked interrupts then the number of
+* interrupts is equal to number of gpios else all are banked so
+* number of interrupts is equal to number of banks(each with 16 gpios)
+*/
+ if (pdata->gpio_unbanked)
+ nirq = pdata->gpio_unbanked;
+ else
+ nirq = DIV_ROUND_UP(ngpio, 16);
+
nbank = DIV_ROUND_UP(ngpio, 32);
chips = devm_kzalloc(dev,
nbank * sizeof(struct davinci_gpio_controller),
@@ -209,10 +219,13 @@ static int davinci_gpio_probe(struct platform_device
*pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
- bank_irq = platform_get_irq(pdev, 0);
- if (bank_irq < 0) {
- dev_dbg(dev, "IRQ not populated\n");
- return bank_irq;
+ for (i = 0; i < nirq; i++) {
+ chips->irqs[i] = platform_get_irq(pdev, i);
+ if (chips->irqs[i] < 0) {
+ dev_info(dev, "IRQ not populated, err = %d\n",
+chips->irqs[i]);
+ return chips->irqs[i];
+ }
}
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
@@ -249,7 +262,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
platform_set_drvdata(pdev, chips);
- ret = davinci_gpio_irq_setup(pdev, bank_irq);
+ ret = davinci_gpio_irq_setup(pdev);
if (ret)
goto err;
@@ -383,7 +396,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip,
unsigned offset)
* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
*/
if (offset < d->gpio_unbanked)
- return d->base_irq + offset;
+ return d->irqs[offset];
else
return -ENODEV;
}
@@ -392,11 +405,18 @@ static int gpio_irq_type_unbanked(struct irq_data *data,
unsigned trigger)
{
struct davinci_gpio_controller *d;
struct davinci_gpio_regs __iomem *g;
- u32 mask;
+ u32 mask, i;
d = (struct davinci_gpio_controller
*)irq_data_get_irq_handler_data(data);
g = (struct davinci_gpio_regs __iomem *)d->regs[0];
- mask = __gpio_mask(data->irq - d->base_irq);
+ for (i = 0; i < MAX_INT_PER_BANK; i++)
+ if (data->irq == d->irqs[i])
+ break;
+
+ if (i == MAX_INT_PER_BANK)
+ return -EINVAL;
+
+ mask = __gpio_mask(i);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -458,7 +478,7 @@ static struct irq_chip *keystone_gpio_get_irq_chip(unsigned
int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
+static int davinci_gpio_irq_setup(struct platform_device *pdev)
{
unsignedgpio, bank;
int irq;
@@ -492,6 +512,7 @@ static int
Re: REGRESSION: "wlcore: sdio: allow pm to handle sdio power" breaks wifi on HiKey960
On Tue, Jun 12, 2018 at 3:12 PM, John Stultz wrote:
> Hey Folks,
> I noticed with linus/master wifi wasn't coming up on HiKey960. I
> bisected it down and it seems to be due to:
>
> 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
> 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
>
>
> When wifi fails to load, the only useful error message I see is:
> [8.466097] wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed
> to get_sync(-13)
>
> Reverting those two changes gets wifi working again for me:
> [8.754953] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
> [8.761778] random: crng init done
> [8.765185] random: 7 urandom warning(s) missed due to ratelimiting
> [8.779149] wlcore: loaded
> ...
> [ 12.945903] wlcore: PHY firmware version: Rev 8.2.0.0.237
> [ 13.058077] wlcore: firmware booted (Rev 8.9.0.0.70)
>
>
> Any suggestions how to resolve this w/o a revert?
This also effects the older HiKey board as well.
thanks
-john
Re: REGRESSION: "wlcore: sdio: allow pm to handle sdio power" breaks wifi on HiKey960
On Tue, Jun 12, 2018 at 3:12 PM, John Stultz wrote:
> Hey Folks,
> I noticed with linus/master wifi wasn't coming up on HiKey960. I
> bisected it down and it seems to be due to:
>
> 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
> 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
>
>
> When wifi fails to load, the only useful error message I see is:
> [8.466097] wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed
> to get_sync(-13)
>
> Reverting those two changes gets wifi working again for me:
> [8.754953] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
> [8.761778] random: crng init done
> [8.765185] random: 7 urandom warning(s) missed due to ratelimiting
> [8.779149] wlcore: loaded
> ...
> [ 12.945903] wlcore: PHY firmware version: Rev 8.2.0.0.237
> [ 13.058077] wlcore: firmware booted (Rev 8.9.0.0.70)
>
>
> Any suggestions how to resolve this w/o a revert?
This also effects the older HiKey board as well.
thanks
-john
Re: [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver
On 06/13/2018 01:12 AM, Matthias Kaehlcke wrote:
> Hi,
>
> On Tue, Jun 12, 2018 at 10:10:51AM +0530, Rajendra Nayak wrote:
>> The RPMh Power domain driver aggregates the corner votes from various
>> consumers for the ARC resources and communicates it to RPMh.
>>
>> We also add data for all power domains on sdm845 SoC as part of the patch.
>> The driver can be extended to support other SoCs which support RPMh
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> drivers/soc/qcom/Kconfig| 9 +
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/rpmhpd.c | 427
>> include/dt-bindings/power/qcom-rpmhpd.h | 31 ++
>> 4 files changed, 468 insertions(+)
>> create mode 100644 drivers/soc/qcom/rpmhpd.c
>> create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 5c54931a7b99..7cb7eba2b997 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
>>
>>Say y here if you intend to boot the modem remoteproc.
>>
>> +config QCOM_RPMHPD
>> +tristate "Qualcomm RPMh Power domain driver"
>> +depends on QCOM_RPMH && QCOM_COMMAND_DB
>> +help
>> + QCOM RPMh Power domain driver to support power-domains with
>> + performance states. The driver communicates a performance state
>> + value to RPMh which then translates it into corresponding voltage
>> + for the voltage rail.
>> +
>> config QCOM_RPMPD
>> tristate "Qualcomm RPM Power domain driver"
>> depends on MFD_QCOM_RPM && QCOM_SMD_RPM
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index 9550c170de93..499513f63bef 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM)+= smsm.o
>> obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
>> obj-$(CONFIG_QCOM_APR) += apr.o
>> obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
>> +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
>> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
>> new file mode 100644
>> index ..7083ec1590ff
>> --- /dev/null
>> +++ b/drivers/soc/qcom/rpmhpd.c
>> @@ -0,0 +1,427 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
>> +
>> +#define DEFINE_RPMHPD_AO(_platform, _name, _active) \
>> +static struct rpmhpd _platform##_##_active; \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.peer = &_platform##_##_active, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}; \
>> +static struct rpmhpd _platform##_##_active = { \
>> +.pd = { .name = #_active, },\
>> +.peer = &_platform##_##_name, \
>> +.active_only = true,\
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}
>> +
>> +#define DEFINE_RPMHPD(_platform, _name)
>> \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
>> +}
>
> Perhaps describe briefly the concept of an AO (active-only) and a peer
> domain. It is not necessarily evident why an AO domain would have
> WAKE_ONLY and SLEEP_ONLY as valid states, while the non-AO domain has
> ACTIVE_ONLY as it's only state.
Sure, I'll add in more comments to describe this.
>
>> +/*
>> + * This function is used to aggregate the votes across the active only
>> + * resources and its peers. The aggregated votes are send to RPMh as
>
> s/send/sent/
>
>> + * ACTIVE_ONLY votes (which take effect immediately), as WAKE_ONLY votes
>> + * (applied
Re: [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver
On 06/13/2018 01:12 AM, Matthias Kaehlcke wrote:
> Hi,
>
> On Tue, Jun 12, 2018 at 10:10:51AM +0530, Rajendra Nayak wrote:
>> The RPMh Power domain driver aggregates the corner votes from various
>> consumers for the ARC resources and communicates it to RPMh.
>>
>> We also add data for all power domains on sdm845 SoC as part of the patch.
>> The driver can be extended to support other SoCs which support RPMh
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> drivers/soc/qcom/Kconfig| 9 +
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/rpmhpd.c | 427
>> include/dt-bindings/power/qcom-rpmhpd.h | 31 ++
>> 4 files changed, 468 insertions(+)
>> create mode 100644 drivers/soc/qcom/rpmhpd.c
>> create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 5c54931a7b99..7cb7eba2b997 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
>>
>>Say y here if you intend to boot the modem remoteproc.
>>
>> +config QCOM_RPMHPD
>> +tristate "Qualcomm RPMh Power domain driver"
>> +depends on QCOM_RPMH && QCOM_COMMAND_DB
>> +help
>> + QCOM RPMh Power domain driver to support power-domains with
>> + performance states. The driver communicates a performance state
>> + value to RPMh which then translates it into corresponding voltage
>> + for the voltage rail.
>> +
>> config QCOM_RPMPD
>> tristate "Qualcomm RPM Power domain driver"
>> depends on MFD_QCOM_RPM && QCOM_SMD_RPM
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index 9550c170de93..499513f63bef 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM)+= smsm.o
>> obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
>> obj-$(CONFIG_QCOM_APR) += apr.o
>> obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
>> +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
>> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
>> new file mode 100644
>> index ..7083ec1590ff
>> --- /dev/null
>> +++ b/drivers/soc/qcom/rpmhpd.c
>> @@ -0,0 +1,427 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
>> +
>> +#define DEFINE_RPMHPD_AO(_platform, _name, _active) \
>> +static struct rpmhpd _platform##_##_active; \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.peer = &_platform##_##_active, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}; \
>> +static struct rpmhpd _platform##_##_active = { \
>> +.pd = { .name = #_active, },\
>> +.peer = &_platform##_##_name, \
>> +.active_only = true,\
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}
>> +
>> +#define DEFINE_RPMHPD(_platform, _name)
>> \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
>> +}
>
> Perhaps describe briefly the concept of an AO (active-only) and a peer
> domain. It is not necessarily evident why an AO domain would have
> WAKE_ONLY and SLEEP_ONLY as valid states, while the non-AO domain has
> ACTIVE_ONLY as it's only state.
Sure, I'll add in more comments to describe this.
>
>> +/*
>> + * This function is used to aggregate the votes across the active only
>> + * resources and its peers. The aggregated votes are send to RPMh as
>
> s/send/sent/
>
>> + * ACTIVE_ONLY votes (which take effect immediately), as WAKE_ONLY votes
>> + * (applied
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 8:00 PM Linus Torvalds
wrote:
>
> Yeah, the biusection seems to actually be diving into Greg's device pulls.
>
> Odd. I'm not seeing why that would break kvm, but maybe there's
> something in the device core layer that really messed it up.
>
> I'll continue to bisect to see.
Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
mode permission from parent") breaks lkvm, and I think qemu-kvm too.
The commit looks like the RightThing(tm) to do, but we do not break
existing work-flows, no matter how much we'd like to. So it gets
reverted.
Greg, Thomas, perhaps some alternative model? I'm not sure exactly
what kvm needs from debugfs.
Linus
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 8:00 PM Linus Torvalds
wrote:
>
> Yeah, the biusection seems to actually be diving into Greg's device pulls.
>
> Odd. I'm not seeing why that would break kvm, but maybe there's
> something in the device core layer that really messed it up.
>
> I'll continue to bisect to see.
Ok, so commit 95cde3c59966 ("debugfs: inode: debugfs_create_dir uses
mode permission from parent") breaks lkvm, and I think qemu-kvm too.
The commit looks like the RightThing(tm) to do, but we do not break
existing work-flows, no matter how much we'd like to. So it gets
reverted.
Greg, Thomas, perhaps some alternative model? I'm not sure exactly
what kvm needs from debugfs.
Linus
Re: [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver
On 06/13/2018 12:36 AM, Rob Herring wrote:
> On Tue, Jun 12, 2018 at 10:10:51AM +0530, Rajendra Nayak wrote:
>> The RPMh Power domain driver aggregates the corner votes from various
>> consumers for the ARC resources and communicates it to RPMh.
>>
>> We also add data for all power domains on sdm845 SoC as part of the patch.
>> The driver can be extended to support other SoCs which support RPMh
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> drivers/soc/qcom/Kconfig| 9 +
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/rpmhpd.c | 427
>> include/dt-bindings/power/qcom-rpmhpd.h | 31 ++
>
> These includes should go with the binding.
will move them to the bindings patch when I resend, thanks.
>
>> 4 files changed, 468 insertions(+)
>> create mode 100644 drivers/soc/qcom/rpmhpd.c
>> create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 5c54931a7b99..7cb7eba2b997 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
>>
>>Say y here if you intend to boot the modem remoteproc.
>>
>> +config QCOM_RPMHPD
>> +tristate "Qualcomm RPMh Power domain driver"
>> +depends on QCOM_RPMH && QCOM_COMMAND_DB
>> +help
>> + QCOM RPMh Power domain driver to support power-domains with
>> + performance states. The driver communicates a performance state
>> + value to RPMh which then translates it into corresponding voltage
>> + for the voltage rail.
>> +
>> config QCOM_RPMPD
>> tristate "Qualcomm RPM Power domain driver"
>> depends on MFD_QCOM_RPM && QCOM_SMD_RPM
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index 9550c170de93..499513f63bef 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM)+= smsm.o
>> obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
>> obj-$(CONFIG_QCOM_APR) += apr.o
>> obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
>> +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
>> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
>> new file mode 100644
>> index ..7083ec1590ff
>> --- /dev/null
>> +++ b/drivers/soc/qcom/rpmhpd.c
>> @@ -0,0 +1,427 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
>> +
>> +#define DEFINE_RPMHPD_AO(_platform, _name, _active) \
>> +static struct rpmhpd _platform##_##_active; \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.peer = &_platform##_##_active, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}; \
>> +static struct rpmhpd _platform##_##_active = { \
>> +.pd = { .name = #_active, },\
>> +.peer = &_platform##_##_name, \
>> +.active_only = true,\
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}
>> +
>> +#define DEFINE_RPMHPD(_platform, _name)
>> \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
>> +}
>> +
>> +/*
>> + * This is the number of bytes used for each command DB aux data entry of an
>> + * ARC resource.
>> + */
>> +#define RPMH_ARC_LEVEL_SIZE 2
>> +#define RPMH_ARC_MAX_LEVELS 16
>> +
>> +struct rpmhpd {
>> +struct device *dev;
>> +struct generic_pm_domain pd;
>> +struct rpmhpd *peer;
>> +const bool active_only;
>> +unsigned intcorner;
>> +unsigned intactive_corner;
>> +u32 level[RPMH_ARC_MAX_LEVELS];
Re: [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver
On 06/13/2018 12:36 AM, Rob Herring wrote:
> On Tue, Jun 12, 2018 at 10:10:51AM +0530, Rajendra Nayak wrote:
>> The RPMh Power domain driver aggregates the corner votes from various
>> consumers for the ARC resources and communicates it to RPMh.
>>
>> We also add data for all power domains on sdm845 SoC as part of the patch.
>> The driver can be extended to support other SoCs which support RPMh
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> drivers/soc/qcom/Kconfig| 9 +
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/rpmhpd.c | 427
>> include/dt-bindings/power/qcom-rpmhpd.h | 31 ++
>
> These includes should go with the binding.
will move them to the bindings patch when I resend, thanks.
>
>> 4 files changed, 468 insertions(+)
>> create mode 100644 drivers/soc/qcom/rpmhpd.c
>> create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 5c54931a7b99..7cb7eba2b997 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
>>
>>Say y here if you intend to boot the modem remoteproc.
>>
>> +config QCOM_RPMHPD
>> +tristate "Qualcomm RPMh Power domain driver"
>> +depends on QCOM_RPMH && QCOM_COMMAND_DB
>> +help
>> + QCOM RPMh Power domain driver to support power-domains with
>> + performance states. The driver communicates a performance state
>> + value to RPMh which then translates it into corresponding voltage
>> + for the voltage rail.
>> +
>> config QCOM_RPMPD
>> tristate "Qualcomm RPM Power domain driver"
>> depends on MFD_QCOM_RPM && QCOM_SMD_RPM
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index 9550c170de93..499513f63bef 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM)+= smsm.o
>> obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
>> obj-$(CONFIG_QCOM_APR) += apr.o
>> obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
>> +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
>> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
>> new file mode 100644
>> index ..7083ec1590ff
>> --- /dev/null
>> +++ b/drivers/soc/qcom/rpmhpd.c
>> @@ -0,0 +1,427 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
>> +
>> +#define DEFINE_RPMHPD_AO(_platform, _name, _active) \
>> +static struct rpmhpd _platform##_##_active; \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.peer = &_platform##_##_active, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}; \
>> +static struct rpmhpd _platform##_##_active = { \
>> +.pd = { .name = #_active, },\
>> +.peer = &_platform##_##_name, \
>> +.active_only = true,\
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}
>> +
>> +#define DEFINE_RPMHPD(_platform, _name)
>> \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
>> +}
>> +
>> +/*
>> + * This is the number of bytes used for each command DB aux data entry of an
>> + * ARC resource.
>> + */
>> +#define RPMH_ARC_LEVEL_SIZE 2
>> +#define RPMH_ARC_MAX_LEVELS 16
>> +
>> +struct rpmhpd {
>> +struct device *dev;
>> +struct generic_pm_domain pd;
>> +struct rpmhpd *peer;
>> +const bool active_only;
>> +unsigned intcorner;
>> +unsigned intactive_corner;
>> +u32 level[RPMH_ARC_MAX_LEVELS];
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 7:51 PM Wanpeng Li wrote: > > > > Bisecting. But that's unrelated to the recent kvm build breakage. > > Yeah, it happens before the KVM GIT PULL on Linus's tree, you will see > the warning above unless you lauch the guest w/ root user, maybe other > subsystems' modifications break something. Yeah, the biusection seems to actually be diving into Greg's device pulls. Odd. I'm not seeing why that would break kvm, but maybe there's something in the device core layer that really messed it up. I'll continue to bisect to see. Linus
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 7:51 PM Wanpeng Li wrote: > > > > Bisecting. But that's unrelated to the recent kvm build breakage. > > Yeah, it happens before the KVM GIT PULL on Linus's tree, you will see > the warning above unless you lauch the guest w/ root user, maybe other > subsystems' modifications break something. Yeah, the biusection seems to actually be diving into Greg's device pulls. Odd. I'm not seeing why that would break kvm, but maybe there's something in the device core layer that really messed it up. I'll continue to bisect to see. Linus
Re: [GIT PULL] KVM changes for 4.18 merge window
On Wed, 13 Jun 2018 at 10:42, Linus Torvalds wrote: > > On Tue, Jun 12, 2018 at 7:18 PM Linus Torvalds > wrote: > > > > The attached patch _may_ be the right thing to do. It's not pretty. > > .. and when I decided to actually do some minimal kvm testing with > that patch, I notice that we've apparently broken kvm entirely during > this merge window, and I just get > > Error: KVM_CREATE_VM ioctl > Warning: Failed init: kvm__init > > when doing lkvm run. > > Bisecting. But that's unrelated to the recent kvm build breakage. Yeah, it happens before the KVM GIT PULL on Linus's tree, you will see the warning above unless you lauch the guest w/ root user, maybe other subsystems' modifications break something. Regards, Wanpeng Li
Re: [GIT PULL] KVM changes for 4.18 merge window
On Wed, 13 Jun 2018 at 10:42, Linus Torvalds wrote: > > On Tue, Jun 12, 2018 at 7:18 PM Linus Torvalds > wrote: > > > > The attached patch _may_ be the right thing to do. It's not pretty. > > .. and when I decided to actually do some minimal kvm testing with > that patch, I notice that we've apparently broken kvm entirely during > this merge window, and I just get > > Error: KVM_CREATE_VM ioctl > Warning: Failed init: kvm__init > > when doing lkvm run. > > Bisecting. But that's unrelated to the recent kvm build breakage. Yeah, it happens before the KVM GIT PULL on Linus's tree, you will see the warning above unless you lauch the guest w/ root user, maybe other subsystems' modifications break something. Regards, Wanpeng Li
Re: Possible regression caused by commit a192aa923b66a
Hi Rafael,
On Jun 12, 2018, at 5:17 PM, Rafael J. Wysocki wrote:
On Monday, June 11, 2018 11:52:34 PM CEST Rafael J. Wysocki wrote:
--703623056e64c488
Content-Type: text/plain; charset="UTF-8"
On Mon, Jun 11, 2018 at 10:09 AM, Rafael J. Wysocki
wrote:
On Mon, Jun 11, 2018 at 8:26 AM, Kai-Heng Feng
wrote:
Hi Rafael,
There's a regression report [1] that says commit a192aa923b66a ("ACPI /
LPSS: Consolidate runtime PM and system sleep handling") is the first
bad
commit.
From the looks of it, it didn't introduce any behavioral change. So your
help is appreciated.
[1] https://bugs.launchpad.net/bugs/1774950
Well, the only difference is the iosf quirk AFAICS, but that should be
easy enough to check. I'll try to cut a patch for that later today.
If the iosf quirk is the source of the problem, the attached patch
should help.
The one below should be slightly better, please test this one.
Affected users reported that this patch solves the issue for them.
Kai-Heng
---
drivers/acpi/acpi_lpss.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -940,9 +941,10 @@ static void lpss_iosf_exit_d3_state(void
mutex_unlock(_iosf_mutex);
}
-static int acpi_lpss_suspend(struct device *dev, bool wakeup)
+static int acpi_lpss_suspend(struct device *dev, bool runtime)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+ bool wakeup = runtime || device_may_wakeup(dev);
int ret;
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
@@ -955,13 +957,14 @@ static int acpi_lpss_suspend(struct devi
* wrong status for devices being about to be powered off. See
* lpss_iosf_enter_d3_state() for further information.
*/
- if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+ if ((runtime || !pm_suspend_via_firmware()) &&
+ lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_enter_d3_state();
return ret;
}
-static int acpi_lpss_resume(struct device *dev)
+static int acpi_lpss_resume(struct device *dev, bool runtime)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
@@ -970,7 +973,8 @@ static int acpi_lpss_resume(struct devic
* This call is kept first to be in symmetry with
* acpi_lpss_runtime_suspend() one.
*/
- if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+ if ((runtime || !pm_resume_via_firmware()) &&
+ lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_exit_d3_state();
ret = acpi_dev_resume(dev);
@@ -994,12 +998,12 @@ static int acpi_lpss_suspend_late(struct
return 0;
ret = pm_generic_suspend_late(dev);
- return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
+ return ret ? ret : acpi_lpss_suspend(dev, false);
}
static int acpi_lpss_resume_early(struct device *dev)
{
- int ret = acpi_lpss_resume(dev);
+ int ret = acpi_lpss_resume(dev, false);
return ret ? ret : pm_generic_resume_early(dev);
}
@@ -1014,7 +1018,7 @@ static int acpi_lpss_runtime_suspend(str
static int acpi_lpss_runtime_resume(struct device *dev)
{
- int ret = acpi_lpss_resume(dev);
+ int ret = acpi_lpss_resume(dev, true);
return ret ? ret : pm_generic_runtime_resume(dev);
}
Re: Possible regression caused by commit a192aa923b66a
Hi Rafael,
On Jun 12, 2018, at 5:17 PM, Rafael J. Wysocki wrote:
On Monday, June 11, 2018 11:52:34 PM CEST Rafael J. Wysocki wrote:
--703623056e64c488
Content-Type: text/plain; charset="UTF-8"
On Mon, Jun 11, 2018 at 10:09 AM, Rafael J. Wysocki
wrote:
On Mon, Jun 11, 2018 at 8:26 AM, Kai-Heng Feng
wrote:
Hi Rafael,
There's a regression report [1] that says commit a192aa923b66a ("ACPI /
LPSS: Consolidate runtime PM and system sleep handling") is the first
bad
commit.
From the looks of it, it didn't introduce any behavioral change. So your
help is appreciated.
[1] https://bugs.launchpad.net/bugs/1774950
Well, the only difference is the iosf quirk AFAICS, but that should be
easy enough to check. I'll try to cut a patch for that later today.
If the iosf quirk is the source of the problem, the attached patch
should help.
The one below should be slightly better, please test this one.
Affected users reported that this patch solves the issue for them.
Kai-Heng
---
drivers/acpi/acpi_lpss.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -940,9 +941,10 @@ static void lpss_iosf_exit_d3_state(void
mutex_unlock(_iosf_mutex);
}
-static int acpi_lpss_suspend(struct device *dev, bool wakeup)
+static int acpi_lpss_suspend(struct device *dev, bool runtime)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+ bool wakeup = runtime || device_may_wakeup(dev);
int ret;
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
@@ -955,13 +957,14 @@ static int acpi_lpss_suspend(struct devi
* wrong status for devices being about to be powered off. See
* lpss_iosf_enter_d3_state() for further information.
*/
- if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+ if ((runtime || !pm_suspend_via_firmware()) &&
+ lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_enter_d3_state();
return ret;
}
-static int acpi_lpss_resume(struct device *dev)
+static int acpi_lpss_resume(struct device *dev, bool runtime)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
@@ -970,7 +973,8 @@ static int acpi_lpss_resume(struct devic
* This call is kept first to be in symmetry with
* acpi_lpss_runtime_suspend() one.
*/
- if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+ if ((runtime || !pm_resume_via_firmware()) &&
+ lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_exit_d3_state();
ret = acpi_dev_resume(dev);
@@ -994,12 +998,12 @@ static int acpi_lpss_suspend_late(struct
return 0;
ret = pm_generic_suspend_late(dev);
- return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
+ return ret ? ret : acpi_lpss_suspend(dev, false);
}
static int acpi_lpss_resume_early(struct device *dev)
{
- int ret = acpi_lpss_resume(dev);
+ int ret = acpi_lpss_resume(dev, false);
return ret ? ret : pm_generic_resume_early(dev);
}
@@ -1014,7 +1018,7 @@ static int acpi_lpss_runtime_suspend(str
static int acpi_lpss_runtime_resume(struct device *dev)
{
- int ret = acpi_lpss_resume(dev);
+ int ret = acpi_lpss_resume(dev, true);
return ret ? ret : pm_generic_runtime_resume(dev);
}
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 7:18 PM Linus Torvalds wrote: > > The attached patch _may_ be the right thing to do. It's not pretty. .. and when I decided to actually do some minimal kvm testing with that patch, I notice that we've apparently broken kvm entirely during this merge window, and I just get Error: KVM_CREATE_VM ioctl Warning: Failed init: kvm__init when doing lkvm run. Bisecting. But that's unrelated to the recent kvm build breakage. Linus
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 7:18 PM Linus Torvalds wrote: > > The attached patch _may_ be the right thing to do. It's not pretty. .. and when I decided to actually do some minimal kvm testing with that patch, I notice that we've apparently broken kvm entirely during this merge window, and I just get Error: KVM_CREATE_VM ioctl Warning: Failed init: kvm__init when doing lkvm run. Bisecting. But that's unrelated to the recent kvm build breakage. Linus
linux-next: Tree for Jun 13
Hi all, Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180612: The drivers-x86 tree lost its build failure. Non-merge commits (relative to Linus' tree): 928 1119 files changed, 21702 insertions(+), 16141 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 278 trees (counting Linus' and 64 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (19785cf93b6c Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (c90fca951e90 Merge tag 'powerpc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (cdb8744d8035 Revert "net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets") Merging bpf/master (5d902372ba5f xsk: re-add queue id check for XDP_SKB path) Merging ipsec/master (d6990976af7c vti6: fix PMTU caching and reporting on xmit) Merging netfilter/master (21ba8847f857 netfilter: nf_conncount: Fix garbage collection with zones) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (3dc7c7badb75 IB/mlx4: Fix an error handling path in 'mlx4_ib_rereg_user_mr()') Merging sound-current/for-linus (5ebf6b1e4596 ALSA: usb-audio: Disable the quirk for Nura headset) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging tty.current/tty-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb.current/usb-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb-gadget-fixes/fixes (6d08b06e67cd Linux 4.17-rc2) Merging usb-serial-fixes/usb-linus (75bc37fefc44 Linux 4.17-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: fix ulpi-node lookup) Merging phy/fix
linux-next: Tree for Jun 13
Hi all, Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180612: The drivers-x86 tree lost its build failure. Non-merge commits (relative to Linus' tree): 928 1119 files changed, 21702 insertions(+), 16141 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 278 trees (counting Linus' and 64 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (19785cf93b6c Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (c90fca951e90 Merge tag 'powerpc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (cdb8744d8035 Revert "net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets") Merging bpf/master (5d902372ba5f xsk: re-add queue id check for XDP_SKB path) Merging ipsec/master (d6990976af7c vti6: fix PMTU caching and reporting on xmit) Merging netfilter/master (21ba8847f857 netfilter: nf_conncount: Fix garbage collection with zones) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (3dc7c7badb75 IB/mlx4: Fix an error handling path in 'mlx4_ib_rereg_user_mr()') Merging sound-current/for-linus (5ebf6b1e4596 ALSA: usb-audio: Disable the quirk for Nura headset) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging tty.current/tty-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb.current/usb-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb-gadget-fixes/fixes (6d08b06e67cd Linux 4.17-rc2) Merging usb-serial-fixes/usb-linus (75bc37fefc44 Linux 4.17-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: fix ulpi-node lookup) Merging phy/fix
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 7:03 AM Paolo Bonzini wrote:
>
> * x86: many bugfixes, implement more Hyper-V super powers,
Uhhuh, I didn't notice this initially, because my basic sanity tests
are with everything enabled, but this breaks the build:
ERROR: "ms_hyperv" [arch/x86/kvm/kvm-intel.ko] undefined!
The attached patch _may_ be the right thing to do. It's not pretty.
Hmm? And why was this not found before it hit my tree?
Linus
arch/x86/kvm/vmx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index fc61e25966e4..d0dd35d582da 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4429,6 +4429,7 @@ static int alloc_loaded_vmcs(struct loaded_vmcs *loaded_vmcs)
goto out_vmcs;
memset(loaded_vmcs->msr_bitmap, 0xff, PAGE_SIZE);
+#if IS_ENABLED(CONFIG_HYPERV)
if (static_branch_unlikely(_evmcs) &&
(ms_hyperv.nested_features & HV_X64_NESTED_MSR_BITMAP)) {
struct hv_enlightened_vmcs *evmcs =
@@ -4436,6 +4437,8 @@ static int alloc_loaded_vmcs(struct loaded_vmcs *loaded_vmcs)
evmcs->hv_enlightenments_control.msr_bitmap = 1;
}
+#endif
+
}
return 0;
Re: [GIT PULL] KVM changes for 4.18 merge window
On Tue, Jun 12, 2018 at 7:03 AM Paolo Bonzini wrote:
>
> * x86: many bugfixes, implement more Hyper-V super powers,
Uhhuh, I didn't notice this initially, because my basic sanity tests
are with everything enabled, but this breaks the build:
ERROR: "ms_hyperv" [arch/x86/kvm/kvm-intel.ko] undefined!
The attached patch _may_ be the right thing to do. It's not pretty.
Hmm? And why was this not found before it hit my tree?
Linus
arch/x86/kvm/vmx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index fc61e25966e4..d0dd35d582da 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4429,6 +4429,7 @@ static int alloc_loaded_vmcs(struct loaded_vmcs *loaded_vmcs)
goto out_vmcs;
memset(loaded_vmcs->msr_bitmap, 0xff, PAGE_SIZE);
+#if IS_ENABLED(CONFIG_HYPERV)
if (static_branch_unlikely(_evmcs) &&
(ms_hyperv.nested_features & HV_X64_NESTED_MSR_BITMAP)) {
struct hv_enlightened_vmcs *evmcs =
@@ -4436,6 +4437,8 @@ static int alloc_loaded_vmcs(struct loaded_vmcs *loaded_vmcs)
evmcs->hv_enlightenments_control.msr_bitmap = 1;
}
+#endif
+
}
return 0;
Re: [PATCHv4 1/3] scripts: Preprocess module-common.lds
2018-06-12 9:32 GMT+09:00 Laura Abbott :
>
> In preparation for some upcoming work, allow module-common.lds
> to be run through the preprocessor.
>
> Signed-off-by: Laura Abbott
> ---
> scripts/.gitignore | 1 +
> scripts/Makefile | 2 +-
> scripts/{module-common.lds => module-common.lds.S} | 0
> 3 files changed, 2 insertions(+), 1 deletion(-)
> rename scripts/{module-common.lds => module-common.lds.S} (100%)
>
> diff --git a/scripts/.gitignore b/scripts/.gitignore
> index 0442c06eefcb..afd1de57d9c6 100644
> --- a/scripts/.gitignore
> +++ b/scripts/.gitignore
> @@ -13,3 +13,4 @@ asn1_compiler
> extract-cert
> sign-file
> insert-sys-cert
> +module-common.lds
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 25ab143cbe14..631d9d1a71e4 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -25,7 +25,7 @@ HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
> HOSTLOADLIBES_sign-file = -lcrypto
> HOSTLOADLIBES_extract-cert = -lcrypto
>
> -always := $(hostprogs-y) $(hostprogs-m)
> +always := $(hostprogs-y) $(hostprogs-m) module-common.lds
You do not need to generate module-common.lds all the time.
It is necessary only when the module feature is enabled.
You can do like this:
extra-$(CONFIG_MODULES) += module-common.lds
--
Best Regards
Masahiro Yamada
Re: [PATCHv4 1/3] scripts: Preprocess module-common.lds
2018-06-12 9:32 GMT+09:00 Laura Abbott :
>
> In preparation for some upcoming work, allow module-common.lds
> to be run through the preprocessor.
>
> Signed-off-by: Laura Abbott
> ---
> scripts/.gitignore | 1 +
> scripts/Makefile | 2 +-
> scripts/{module-common.lds => module-common.lds.S} | 0
> 3 files changed, 2 insertions(+), 1 deletion(-)
> rename scripts/{module-common.lds => module-common.lds.S} (100%)
>
> diff --git a/scripts/.gitignore b/scripts/.gitignore
> index 0442c06eefcb..afd1de57d9c6 100644
> --- a/scripts/.gitignore
> +++ b/scripts/.gitignore
> @@ -13,3 +13,4 @@ asn1_compiler
> extract-cert
> sign-file
> insert-sys-cert
> +module-common.lds
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 25ab143cbe14..631d9d1a71e4 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -25,7 +25,7 @@ HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
> HOSTLOADLIBES_sign-file = -lcrypto
> HOSTLOADLIBES_extract-cert = -lcrypto
>
> -always := $(hostprogs-y) $(hostprogs-m)
> +always := $(hostprogs-y) $(hostprogs-m) module-common.lds
You do not need to generate module-common.lds all the time.
It is necessary only when the module feature is enabled.
You can do like this:
extra-$(CONFIG_MODULES) += module-common.lds
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 10/11] dt-bindings: misc: add bindings for cros_ec_throttler
On Tue, Jun 12, 2018 at 01:40:22PM -0700, Brian Norris wrote: > Hi Rob, > > On Tue, Jun 12, 2018 at 01:10:11PM -0600, Rob Herring wrote: > > On Thu, Jun 07, 2018 at 11:12:13AM -0700, Matthias Kaehlcke wrote: > > > The cros_ec_throttler monitors events from the Chrome OS Embedded > > > Controller to throttle the system if needed, using the mechanisms > > > provided by the throttler core. > > > > > > Signed-off-by: Matthias Kaehlcke > > > --- > > > Changes in v2: > > > - patch added to series > > > > > > Documentation/devicetree/bindings/misc/cros_ec_throttler.txt | 4 > > > 1 file changed, 4 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > > > > diff --git a/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > b/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > new file mode 100644 > > > index ..7316dcc0ef75 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > @@ -0,0 +1,4 @@ > > > +* cros_ec_throttler driver > > > > Bindings are for h/w, not drivers. > > (OK, sure, don't call this "driver". And maybe this could use some more > description about what kind of events are emitted by this sort of > device.) > > > I continue to fail to see why this needs to be in DT. There are other > > ways to instantiate drivers. > > This is mostly relevant to: > [PATCH v2 08/11] dt-bindings: PM / OPP: add opp-throttlers property > > so it's probably good to take a look at that one too. > > The primary purpose is to have a target to point at when determining who > is the source of throttling. This is similar to other CrOS EC subdevices > (e.g., PWM) where we technically don't require a subnode (the EC > firmware can its own PWM hardware without DT), but it is important that, > e.g., a backlight device has something to point at when it's using a PWM > attached to the EC. So we have a PWM subnode. > > In this case, we're a little vague about what exactly the hardware is > here, but there *is* hardware that's emitting "throttle" events (hint: > here, it's related to sensing too high of system current). This is all > abstracted by firmware, which simply tells us we need to scale back our > power usage. > > So, what do you think of patch 8? Should OPPs have phandles to such a > throttler? If so, should the phandle just point at the main EC device > (see mfd/cros-ec.txt), or is it reasonable to have a subnode to > represent something more specific? > > Or maybe this is entirely on the wrong track. But this is the resulting > proposal after your comments on v1, so it's probably best we have a > clearer overall review of what makes sense here, so we don't just go in > cycles on new proposals that get rejected. I also think we need to clarify if this is the right direction. Since Rob proposed the OPP hints and didn't object when I replied with the opp-throttlers example I assumed he was ok with it.
Re: [PATCH v2 10/11] dt-bindings: misc: add bindings for cros_ec_throttler
On Tue, Jun 12, 2018 at 01:40:22PM -0700, Brian Norris wrote: > Hi Rob, > > On Tue, Jun 12, 2018 at 01:10:11PM -0600, Rob Herring wrote: > > On Thu, Jun 07, 2018 at 11:12:13AM -0700, Matthias Kaehlcke wrote: > > > The cros_ec_throttler monitors events from the Chrome OS Embedded > > > Controller to throttle the system if needed, using the mechanisms > > > provided by the throttler core. > > > > > > Signed-off-by: Matthias Kaehlcke > > > --- > > > Changes in v2: > > > - patch added to series > > > > > > Documentation/devicetree/bindings/misc/cros_ec_throttler.txt | 4 > > > 1 file changed, 4 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > > > > diff --git a/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > b/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > new file mode 100644 > > > index ..7316dcc0ef75 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt > > > @@ -0,0 +1,4 @@ > > > +* cros_ec_throttler driver > > > > Bindings are for h/w, not drivers. > > (OK, sure, don't call this "driver". And maybe this could use some more > description about what kind of events are emitted by this sort of > device.) > > > I continue to fail to see why this needs to be in DT. There are other > > ways to instantiate drivers. > > This is mostly relevant to: > [PATCH v2 08/11] dt-bindings: PM / OPP: add opp-throttlers property > > so it's probably good to take a look at that one too. > > The primary purpose is to have a target to point at when determining who > is the source of throttling. This is similar to other CrOS EC subdevices > (e.g., PWM) where we technically don't require a subnode (the EC > firmware can its own PWM hardware without DT), but it is important that, > e.g., a backlight device has something to point at when it's using a PWM > attached to the EC. So we have a PWM subnode. > > In this case, we're a little vague about what exactly the hardware is > here, but there *is* hardware that's emitting "throttle" events (hint: > here, it's related to sensing too high of system current). This is all > abstracted by firmware, which simply tells us we need to scale back our > power usage. > > So, what do you think of patch 8? Should OPPs have phandles to such a > throttler? If so, should the phandle just point at the main EC device > (see mfd/cros-ec.txt), or is it reasonable to have a subnode to > represent something more specific? > > Or maybe this is entirely on the wrong track. But this is the resulting > proposal after your comments on v1, so it's probably best we have a > clearer overall review of what makes sense here, so we don't just go in > cycles on new proposals that get rejected. I also think we need to clarify if this is the right direction. Since Rob proposed the OPP hints and didn't object when I replied with the opp-throttlers example I assumed he was ok with it.
Re: [PATCH 1/2] ndings: mediatek: Add bindings for mediatek MT6765 Platform
On Tue, 2018-06-12 at 18:51 -0600, Rob Herring wrote: > On Tue, Jun 12, 2018 at 4:40 PM, Mars Cheng wrote: > > This adds dt-binding documentation for Mediatek MT6765. Only > > include very basic items, gic, uart timer and cpu. > > Check your subject... Hi Rob oops, my bad... will correct this in v2 > > > > > Signed-off-by: Mars Cheng > > --- > > Documentation/devicetree/bindings/arm/mediatek.txt |4 > > .../interrupt-controller/mediatek,sysirq.txt |1 + > > .../devicetree/bindings/serial/mtk-uart.txt|1 + > > 3 files changed, 6 insertions(+)
Re: [PATCH 1/2] ndings: mediatek: Add bindings for mediatek MT6765 Platform
On Tue, 2018-06-12 at 18:51 -0600, Rob Herring wrote: > On Tue, Jun 12, 2018 at 4:40 PM, Mars Cheng wrote: > > This adds dt-binding documentation for Mediatek MT6765. Only > > include very basic items, gic, uart timer and cpu. > > Check your subject... Hi Rob oops, my bad... will correct this in v2 > > > > > Signed-off-by: Mars Cheng > > --- > > Documentation/devicetree/bindings/arm/mediatek.txt |4 > > .../interrupt-controller/mediatek,sysirq.txt |1 + > > .../devicetree/bindings/serial/mtk-uart.txt|1 + > > 3 files changed, 6 insertions(+)
Re: [PATCH 2/2] arm64: dts: mediatek: add mt6765 support
Hi Rob
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6765-evb.dts
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Mars.C
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
>
> With the SPDX tag, you can drop the license text.
Got it, will fix it.
>
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt6765.dtsi"
> > +
> > +/ {
> > + model = "MediaTek MT6765 EVB";
> > + compatible = "mediatek,mt6765-evb", "mediatek,mt6765";
> > +
> > + aliases {
> > + serial0 =
> > + };
> > +
> > + memory@4000 {
> > + device_type = "memory";
> > + reg = <0 0x4000 0 0x1e80>;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:921600n8";
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6765.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt6765.dtsi
> > new file mode 100644
> > index 000..7222a5e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6765.dtsi
> > @@ -0,0 +1,148 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Mars.C
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
>
> ditto
Got it.
>
> > + */
> > +
> > +#include
> > +#include
> > +
> > +/ {
> > + compatible = "mediatek,mt6765";
> > + interrupt-parent = <>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x000>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x001>;
> > + };
> > +
> > + cpu2: cpu@2 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x002>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x003>;
> > + };
> > +
> > + cpu4: cpu@100 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x100>;
> > + };
> > +
> > + cpu5: cpu@101 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x101>;
> > + };
> > +
> > + cpu6: cpu@102 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x102>;
> > + };
> > +
> > + cpu7: cpu@103 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x103>;
> > + };
> > + };
> > +
> > + uart_clk: dummy26m {
> > + compatible = "fixed-clock";
> > + clock-frequency = <2600>;
> > + #clock-cells = <0>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
>
Re: [PATCH 2/2] arm64: dts: mediatek: add mt6765 support
Hi Rob
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6765-evb.dts
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Mars.C
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
>
> With the SPDX tag, you can drop the license text.
Got it, will fix it.
>
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt6765.dtsi"
> > +
> > +/ {
> > + model = "MediaTek MT6765 EVB";
> > + compatible = "mediatek,mt6765-evb", "mediatek,mt6765";
> > +
> > + aliases {
> > + serial0 =
> > + };
> > +
> > + memory@4000 {
> > + device_type = "memory";
> > + reg = <0 0x4000 0 0x1e80>;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:921600n8";
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6765.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt6765.dtsi
> > new file mode 100644
> > index 000..7222a5e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6765.dtsi
> > @@ -0,0 +1,148 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Mars.C
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
>
> ditto
Got it.
>
> > + */
> > +
> > +#include
> > +#include
> > +
> > +/ {
> > + compatible = "mediatek,mt6765";
> > + interrupt-parent = <>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x000>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x001>;
> > + };
> > +
> > + cpu2: cpu@2 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x002>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x003>;
> > + };
> > +
> > + cpu4: cpu@100 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x100>;
> > + };
> > +
> > + cpu5: cpu@101 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x101>;
> > + };
> > +
> > + cpu6: cpu@102 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x102>;
> > + };
> > +
> > + cpu7: cpu@103 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + enable-method = "psci";
> > + reg = <0x103>;
> > + };
> > + };
> > +
> > + uart_clk: dummy26m {
> > + compatible = "fixed-clock";
> > + clock-frequency = <2600>;
> > + #clock-cells = <0>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
>
Re: [PATCH v2 09/11] misc: throttler: Add core support for non-thermal throttling
On Tue, Jun 12, 2018 at 01:00:14PM -0700, Brian Norris wrote:
> Hi,
>
> On Tue, Jun 12, 2018 at 10:11:40AM -0700, Matthias Kaehlcke wrote:
> > On Mon, Jun 11, 2018 at 06:49:13PM -0700, Brian Norris wrote:
> > > On Thu, Jun 07, 2018 at 11:12:12AM -0700, Matthias Kaehlcke wrote:
> > > > The purpose of the throttler is to provide support for non-thermal
> > > > throttling. Throttling is triggered by external event, e.g. the
> > > > detection of a high battery discharge current, close to the OCP limit
> > > > of the battery. The throttler is only in charge of the throttling, not
> > > > the monitoring, which is done by another (possibly platform specific)
> > > > driver.
> > > >
> > > > Signed-off-by: Matthias Kaehlcke
> > > > ---
> > > > Changes in v2:
> > > > - completely reworked the driver to support configuration through OPPs,
> > > > which
> > > > requires a more dynamic handling
> > > > - added sysfs attribute to set the level for debugging and testing
> > > > - Makefile: depend on Kconfig option to traverse throttler directory
> > > > - Kconfig: removed 'default n'
> > > > - added SPDX line instead of license boiler-plate
> > > > - added entry to MAINTAINERS file
> > > >
> > > >
> > > > MAINTAINERS | 7 +
> > > > drivers/misc/Kconfig| 1 +
> > > > drivers/misc/Makefile | 1 +
> > > > drivers/misc/throttler/Kconfig | 14 +
> > > > drivers/misc/throttler/Makefile | 1 +
> > > > drivers/misc/throttler/core.c | 642
> > > > include/linux/throttler.h | 11 +
> > > > 7 files changed, 677 insertions(+)
> > > > create mode 100644 drivers/misc/throttler/Kconfig
> > > > create mode 100644 drivers/misc/throttler/Makefile
> > > > create mode 100644 drivers/misc/throttler/core.c
> > > > create mode 100644 include/linux/throttler.h
> > > >
>
> ...
>
> > > > diff --git a/drivers/misc/throttler/Kconfig
> > > > b/drivers/misc/throttler/Kconfig
> > > > new file mode 100644
> > > > index ..e561f1df5085
> > > > --- /dev/null
> > > > +++ b/drivers/misc/throttler/Kconfig
> > > > @@ -0,0 +1,14 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +
> > > > +menuconfig THROTTLER
> > > > + bool "Throttler support"
> > > > + depends on OF
> > > > + select CPU_FREQ
> > > > + select PM_DEVFREQ
> > >
> > > I'm curious whether we're actually truly compile-time dependent on
> > > {CPU,DEV}FREQ? It seems like those subsystems mostly stub out stuff so
> > > they fall back to no-ops if not built in.
> > >
> > > I know that's not very useful for your existing throttler, since it
> > > wouldn't be very effective if one or both were disabled.
> >
> > The idea is not to depend on both options being enabled, since
> > throttling of one type might be all that is needed.
>
> OK, then if you fix the build errors...don't do these 'select's here?
Ok, I'll remove them
> > As the build bot pointed out cpufreq doesn't stub out all functions.
> > Probably the cleanest way to work around this is to define a stub for
> > cpufreq_update_policy() in the throttler when CONFIG_CPU_FREQ is not
> > defined.
>
> Might make sense.
>
> Also, how is it that CONFIG_CPU_FREQ managed to not be defined, even
> though you 'select'ed it? Was the kbuild error on some oddball
> architecture that doesn't support CPU_FREQ?
The build error occured with 'openrisc', from a quick grep in
drivers/cpufreq it seems indeed that there is no driver for this
architecture.
> > > > diff --git a/drivers/misc/throttler/core.c
> > > > b/drivers/misc/throttler/core.c
> > > > new file mode 100644
> > > > index ..15b50c111032
> > > > --- /dev/null
> > > > +++ b/drivers/misc/throttler/core.c
> > > > ...
> > > > +// #define DEBUG_THROTTLER
> > >
> > > Did you mean to leave your debug code in? Seems like you have some
> > > related dead code under #ifdefs.
> >
> > Yes, I left it in intentionally.
> >
> > > (If you do want this, maybe it'd be better under debugfs, until somebody
> > > really wants to formalize and document it.)
> >
> > Since it is code that is never enabled in an official kernel build I
> > found it simpler to use sysfs with a direct association with the
> > device, instead of having /throttler//level.
> >
> > If folks have strong opinions about using debugfs or not having the
> > debug code at all I'm fine with changing/dropping it.
>
> If you ever expect this to actually get merged, I'd think we should go
> with one way or the other. Dead code is not appreciated in mainline, so
> either make it something people can actually have a chance of using
> (e.g., a CONFIG_* option or debugfs), or else drop it.
Ok, will change to debugfs with CONFIG_* option.
> > > > +static int thr_init_freq_table(struct throttler *thr, struct device
> > > > *opp_dev,
> > > > + struct thr_freq_table *ft)
> > > > +{
> > > > + struct device_node *np_opp_desc, *np_opp;
> > > > + int
Re: [PATCH v2 09/11] misc: throttler: Add core support for non-thermal throttling
On Tue, Jun 12, 2018 at 01:00:14PM -0700, Brian Norris wrote:
> Hi,
>
> On Tue, Jun 12, 2018 at 10:11:40AM -0700, Matthias Kaehlcke wrote:
> > On Mon, Jun 11, 2018 at 06:49:13PM -0700, Brian Norris wrote:
> > > On Thu, Jun 07, 2018 at 11:12:12AM -0700, Matthias Kaehlcke wrote:
> > > > The purpose of the throttler is to provide support for non-thermal
> > > > throttling. Throttling is triggered by external event, e.g. the
> > > > detection of a high battery discharge current, close to the OCP limit
> > > > of the battery. The throttler is only in charge of the throttling, not
> > > > the monitoring, which is done by another (possibly platform specific)
> > > > driver.
> > > >
> > > > Signed-off-by: Matthias Kaehlcke
> > > > ---
> > > > Changes in v2:
> > > > - completely reworked the driver to support configuration through OPPs,
> > > > which
> > > > requires a more dynamic handling
> > > > - added sysfs attribute to set the level for debugging and testing
> > > > - Makefile: depend on Kconfig option to traverse throttler directory
> > > > - Kconfig: removed 'default n'
> > > > - added SPDX line instead of license boiler-plate
> > > > - added entry to MAINTAINERS file
> > > >
> > > >
> > > > MAINTAINERS | 7 +
> > > > drivers/misc/Kconfig| 1 +
> > > > drivers/misc/Makefile | 1 +
> > > > drivers/misc/throttler/Kconfig | 14 +
> > > > drivers/misc/throttler/Makefile | 1 +
> > > > drivers/misc/throttler/core.c | 642
> > > > include/linux/throttler.h | 11 +
> > > > 7 files changed, 677 insertions(+)
> > > > create mode 100644 drivers/misc/throttler/Kconfig
> > > > create mode 100644 drivers/misc/throttler/Makefile
> > > > create mode 100644 drivers/misc/throttler/core.c
> > > > create mode 100644 include/linux/throttler.h
> > > >
>
> ...
>
> > > > diff --git a/drivers/misc/throttler/Kconfig
> > > > b/drivers/misc/throttler/Kconfig
> > > > new file mode 100644
> > > > index ..e561f1df5085
> > > > --- /dev/null
> > > > +++ b/drivers/misc/throttler/Kconfig
> > > > @@ -0,0 +1,14 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +
> > > > +menuconfig THROTTLER
> > > > + bool "Throttler support"
> > > > + depends on OF
> > > > + select CPU_FREQ
> > > > + select PM_DEVFREQ
> > >
> > > I'm curious whether we're actually truly compile-time dependent on
> > > {CPU,DEV}FREQ? It seems like those subsystems mostly stub out stuff so
> > > they fall back to no-ops if not built in.
> > >
> > > I know that's not very useful for your existing throttler, since it
> > > wouldn't be very effective if one or both were disabled.
> >
> > The idea is not to depend on both options being enabled, since
> > throttling of one type might be all that is needed.
>
> OK, then if you fix the build errors...don't do these 'select's here?
Ok, I'll remove them
> > As the build bot pointed out cpufreq doesn't stub out all functions.
> > Probably the cleanest way to work around this is to define a stub for
> > cpufreq_update_policy() in the throttler when CONFIG_CPU_FREQ is not
> > defined.
>
> Might make sense.
>
> Also, how is it that CONFIG_CPU_FREQ managed to not be defined, even
> though you 'select'ed it? Was the kbuild error on some oddball
> architecture that doesn't support CPU_FREQ?
The build error occured with 'openrisc', from a quick grep in
drivers/cpufreq it seems indeed that there is no driver for this
architecture.
> > > > diff --git a/drivers/misc/throttler/core.c
> > > > b/drivers/misc/throttler/core.c
> > > > new file mode 100644
> > > > index ..15b50c111032
> > > > --- /dev/null
> > > > +++ b/drivers/misc/throttler/core.c
> > > > ...
> > > > +// #define DEBUG_THROTTLER
> > >
> > > Did you mean to leave your debug code in? Seems like you have some
> > > related dead code under #ifdefs.
> >
> > Yes, I left it in intentionally.
> >
> > > (If you do want this, maybe it'd be better under debugfs, until somebody
> > > really wants to formalize and document it.)
> >
> > Since it is code that is never enabled in an official kernel build I
> > found it simpler to use sysfs with a direct association with the
> > device, instead of having /throttler//level.
> >
> > If folks have strong opinions about using debugfs or not having the
> > debug code at all I'm fine with changing/dropping it.
>
> If you ever expect this to actually get merged, I'd think we should go
> with one way or the other. Dead code is not appreciated in mainline, so
> either make it something people can actually have a chance of using
> (e.g., a CONFIG_* option or debugfs), or else drop it.
Ok, will change to debugfs with CONFIG_* option.
> > > > +static int thr_init_freq_table(struct throttler *thr, struct device
> > > > *opp_dev,
> > > > + struct thr_freq_table *ft)
> > > > +{
> > > > + struct device_node *np_opp_desc, *np_opp;
> > > > + int
Re: [GIT PULL] overflow updates (part 2) for v4.18-rc1
On Tue, Jun 12, 2018 at 4:36 PM Kees Cook wrote: > > - Treewide conversions of allocators to use either 2-factor argument > variant when available, or array_size() and array3_size() as needed (Kees) Ok, some of this smells just a tad too much of automation, but I've done the pull and it's going through my build tests. Example nonsensical conversion: - res = kzalloc(sizeof(struct resource) * 2, GFP_KERNEL); + res = kcalloc(2, sizeof(struct resource), GFP_KERNEL); which isn't _wrong_, but... In some of the cases it turns a compile-time constant into a function call, ie this just makes for bigger and slower code for no reason what-so-ever. - ch->tx_array = vzalloc(MIC_DMA_DESC_RX_SIZE * sizeof(*ch->tx_array)); + ch->tx_array = vzalloc(array_size(MIC_DMA_DESC_RX_SIZE, + sizeof(*ch->tx_array))); At least in the kzalloc/kcalloc conversion it results in more legible code. The array_size() conversions, in contrast, actually result in *LESS* legible code, in worse code generation, and absolutely no upside for cases like the above. To make up for it, there's some conversions *away* from nonsensical expressions: - hc_name = kzalloc(sizeof(char) * (HSMMC_NAME_LEN + 1), GFP_KERNEL); + hc_name = kzalloc(HSMMC_NAME_LEN + 1, GFP_KERNEL); but I _really_ think you were way too eager to move to array_size() even when it made no sense what-so-ever. But at least with the kcalloc()/kmalloc_array() conversions now preferred, those crazy cases are now a minority rather than "most of the patch makes code worse". I am *not* looking forward to the conflicts this causes, but maybe it won't be too bad. Fingers crossed. Linus
Re: [GIT PULL] overflow updates (part 2) for v4.18-rc1
On Tue, Jun 12, 2018 at 4:36 PM Kees Cook wrote: > > - Treewide conversions of allocators to use either 2-factor argument > variant when available, or array_size() and array3_size() as needed (Kees) Ok, some of this smells just a tad too much of automation, but I've done the pull and it's going through my build tests. Example nonsensical conversion: - res = kzalloc(sizeof(struct resource) * 2, GFP_KERNEL); + res = kcalloc(2, sizeof(struct resource), GFP_KERNEL); which isn't _wrong_, but... In some of the cases it turns a compile-time constant into a function call, ie this just makes for bigger and slower code for no reason what-so-ever. - ch->tx_array = vzalloc(MIC_DMA_DESC_RX_SIZE * sizeof(*ch->tx_array)); + ch->tx_array = vzalloc(array_size(MIC_DMA_DESC_RX_SIZE, + sizeof(*ch->tx_array))); At least in the kzalloc/kcalloc conversion it results in more legible code. The array_size() conversions, in contrast, actually result in *LESS* legible code, in worse code generation, and absolutely no upside for cases like the above. To make up for it, there's some conversions *away* from nonsensical expressions: - hc_name = kzalloc(sizeof(char) * (HSMMC_NAME_LEN + 1), GFP_KERNEL); + hc_name = kzalloc(HSMMC_NAME_LEN + 1, GFP_KERNEL); but I _really_ think you were way too eager to move to array_size() even when it made no sense what-so-ever. But at least with the kcalloc()/kmalloc_array() conversions now preferred, those crazy cases are now a minority rather than "most of the patch makes code worse". I am *not* looking forward to the conflicts this causes, but maybe it won't be too bad. Fingers crossed. Linus
Re: [GIT PULL] Please pull NFS client changes for 4.18
On Tue, Jun 12 2018, Paul E. McKenney wrote: > On Tue, Jun 12, 2018 at 06:11:50PM -0700, Linus Torvalds wrote: >> On Tue, Jun 12, 2018 at 6:02 PM Paul E. McKenney >> wrote: >> > >> > We did review this one, and Neil did make requested changes to the comment >> > header and documentation. >> >> Oh, I checked the commit for "acked-by" from you and didn't see any, >> so I was assuming this was just Neil and Trond on their own.. > > Hmmm... I gave them a Reviewed-by, but perhaps it got lost. > > http://lkml.kernel.org/r/20180501141404.gd26...@linux.vnet.ibm.com > > Thanx, Paul Sorry about that. I think I planned to add it after I heard back from Trond what he thought of the patch, but I didn't hear anything until it landed. I'll try to be more proactive next time. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [GIT PULL] Please pull NFS client changes for 4.18
On Tue, Jun 12 2018, Paul E. McKenney wrote: > On Tue, Jun 12, 2018 at 06:11:50PM -0700, Linus Torvalds wrote: >> On Tue, Jun 12, 2018 at 6:02 PM Paul E. McKenney >> wrote: >> > >> > We did review this one, and Neil did make requested changes to the comment >> > header and documentation. >> >> Oh, I checked the commit for "acked-by" from you and didn't see any, >> so I was assuming this was just Neil and Trond on their own.. > > Hmmm... I gave them a Reviewed-by, but perhaps it got lost. > > http://lkml.kernel.org/r/20180501141404.gd26...@linux.vnet.ibm.com > > Thanx, Paul Sorry about that. I think I planned to add it after I heard back from Trond what he thought of the patch, but I didn't hear anything until it landed. I'll try to be more proactive next time. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [GIT PULL] Please pull NFS client changes for 4.18
On Tue, Jun 12, 2018 at 06:11:50PM -0700, Linus Torvalds wrote: > On Tue, Jun 12, 2018 at 6:02 PM Paul E. McKenney > wrote: > > > > We did review this one, and Neil did make requested changes to the comment > > header and documentation. > > Oh, I checked the commit for "acked-by" from you and didn't see any, > so I was assuming this was just Neil and Trond on their own.. Hmmm... I gave them a Reviewed-by, but perhaps it got lost. http://lkml.kernel.org/r/20180501141404.gd26...@linux.vnet.ibm.com Thanx, Paul
Re: [GIT PULL] Please pull NFS client changes for 4.18
On Tue, Jun 12, 2018 at 06:11:50PM -0700, Linus Torvalds wrote: > On Tue, Jun 12, 2018 at 6:02 PM Paul E. McKenney > wrote: > > > > We did review this one, and Neil did make requested changes to the comment > > header and documentation. > > Oh, I checked the commit for "acked-by" from you and didn't see any, > so I was assuming this was just Neil and Trond on their own.. Hmmm... I gave them a Reviewed-by, but perhaps it got lost. http://lkml.kernel.org/r/20180501141404.gd26...@linux.vnet.ibm.com Thanx, Paul
Re: [PATCH -mm -V3 03/21] mm, THP, swap: Support PMD swap mapping in swap_duplicate()
Daniel Jordan writes: > On Tue, Jun 12, 2018 at 09:23:19AM +0800, Huang, Ying wrote: >> Daniel Jordan writes: >> >> +#else >> >> +static inline int __swap_duplicate_cluster(swp_entry_t *entry, >> > >> > This doesn't need inline. >> >> Why not? This is just a one line stub. > > Forgot to respond to this. The compiler will likely choose to optimize out > calls to an empty function like this. Checking, this is indeed what it does > in > this case on my machine, with or without inline. Yes. I believe a decent compiler will inline the function in any way. And it does no harm to keep "inline" too, Yes? > By the way, when building without CONFIG_THP_SWAP, we get > > linux/mm/swapfile.c:933:13: warning: ‘__swap_free_cluster’ defined but not > used [-Wunused-function] >static void __swap_free_cluster(struct swap_info_struct *si, unsigned long > idx) >^~~ Thanks! I will fix this. Don't know why 0-Day didn't catch this. Best Regards, Huang, Ying
Re: [PATCH -mm -V3 03/21] mm, THP, swap: Support PMD swap mapping in swap_duplicate()
Daniel Jordan writes: > On Tue, Jun 12, 2018 at 09:23:19AM +0800, Huang, Ying wrote: >> Daniel Jordan writes: >> >> +#else >> >> +static inline int __swap_duplicate_cluster(swp_entry_t *entry, >> > >> > This doesn't need inline. >> >> Why not? This is just a one line stub. > > Forgot to respond to this. The compiler will likely choose to optimize out > calls to an empty function like this. Checking, this is indeed what it does > in > this case on my machine, with or without inline. Yes. I believe a decent compiler will inline the function in any way. And it does no harm to keep "inline" too, Yes? > By the way, when building without CONFIG_THP_SWAP, we get > > linux/mm/swapfile.c:933:13: warning: ‘__swap_free_cluster’ defined but not > used [-Wunused-function] >static void __swap_free_cluster(struct swap_info_struct *si, unsigned long > idx) >^~~ Thanks! I will fix this. Don't know why 0-Day didn't catch this. Best Regards, Huang, Ying
[PATCH v3] dcdbas: Add support for WSMT ACPI table
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version to 5.6.0-3.3
v3 Removed dependency on ACPI in Kconfig
Moved the added #include to be in alphabetical order
Added comments in smi_request_store()
Simplified checksum code
Changed loop searching 0xf to be more readable
Reworked calculation of remap_size & smi_data_buf_size
drivers/firmware/dcdbas.c | 118 +++---
drivers/firmware/dcdbas.h | 10
2 files changed, 122 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 0bdea60c65dd..e95dc9aee2fa 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -21,6 +21,7 @@
*/
#include
+#include
#include
#include
#include
@@ -41,7 +42,7 @@
#include "dcdbas.h"
#define DRIVER_NAME"dcdbas"
-#define DRIVER_VERSION "5.6.0-3.2"
+#define DRIVER_VERSION "5.6.0-3.3"
#define DRIVER_DESCRIPTION "Dell Systems Management Base Driver"
static struct platform_device *dcdbas_pdev;
@@ -49,19 +50,23 @@ static struct platform_device *dcdbas_pdev;
static u8 *smi_data_buf;
static dma_addr_t smi_data_buf_handle;
static unsigned long smi_data_buf_size;
+static unsigned long max_smi_data_buf_size = MAX_SMI_DATA_BUF_SIZE;
static u32 smi_data_buf_phys_addr;
static DEFINE_MUTEX(smi_data_lock);
+static u8 *eps_buffer;
static unsigned int host_control_action;
static unsigned int host_control_smi_type;
static unsigned int host_control_on_shutdown;
+static bool wsmt_enabled;
+
/**
* smi_data_buf_free: free SMI data buffer
*/
static void smi_data_buf_free(void)
{
- if (!smi_data_buf)
+ if (!smi_data_buf || wsmt_enabled)
return;
dev_dbg(_pdev->dev, "%s: phys: %x size: %lu\n",
@@ -86,7 +91,7 @@ static int smi_data_buf_realloc(unsigned long size)
if (smi_data_buf_size >= size)
return 0;
- if (size > MAX_SMI_DATA_BUF_SIZE)
+ if (size > max_smi_data_buf_size)
return -EINVAL;
/* new buffer is needed */
@@ -169,7 +174,7 @@ static ssize_t smi_data_write(struct file *filp, struct
kobject *kobj,
{
ssize_t ret;
- if ((pos + count) > MAX_SMI_DATA_BUF_SIZE)
+ if ((pos + count) > max_smi_data_buf_size)
return -EINVAL;
mutex_lock(_data_lock);
@@ -322,8 +327,14 @@ static ssize_t smi_request_store(struct device *dev,
ret = count;
break;
case 1:
- /* Calling Interface SMI */
- smi_cmd->ebx = (u32) virt_to_phys(smi_cmd->command_buffer);
+ /* Calling Interface SMI
+*
+* Provide physical address of command buffer field within
+* the struct smi_cmd... can't use virt_to_phys on smi_cmd
+* because address may be from memremap.
+*/
+ smi_cmd->ebx = smi_data_buf_phys_addr +
+ offsetof(struct smi_cmd, command_buffer);
ret = dcdbas_smi_request(smi_cmd);
if (!ret)
ret = count;
@@ -482,6 +493,94 @@ static void dcdbas_host_control(void)
}
}
+/* WSMT */
+
+static u8 checksum(u8 *buffer, u8 length)
+{
+ u8 sum = 0;
+ u8 *end = buffer + length;
+
+ while (buffer < end)
+ sum += *buffer++;
+ return sum;
+}
+
+static inline struct smm_eps_table *check_eps_table(u8 *addr)
+{
+ struct smm_eps_table *eps = (struct smm_eps_table *)addr;
+
+ if (strncmp(eps->smm_comm_buff_anchor, SMM_EPS_SIG, 4) != 0)
+ return NULL;
+
+ if (checksum(addr, eps->length) != 0)
+ return NULL;
+
+ return eps;
+}
+
+static int dcdbas_check_wsmt(void)
+{
+ struct acpi_table_wsmt *wsmt = NULL;
+ struct smm_eps_table *eps = NULL;
+ u64 remap_size;
+ u8 *addr;
+
+ acpi_get_table(ACPI_SIG_WSMT, 0, (struct acpi_table_header **));
+ if (!wsmt)
+ return 0;
+
+ /* Check if WSMT ACPI table shows that protection is enabled */
+ if (!(wsmt->protection_flags & ACPI_WSMT_FIXED_COMM_BUFFERS)
+ || !(wsmt->protection_flags
+& ACPI_WSMT_COMM_BUFFER_NESTED_PTR_PROTECTION))
+ return 0;
+
+ /* Scan for EPS (entry point structure) */
+ for (addr = (u8 *)__va(0xf);
+addr < (u8 *)__va(0x10 - sizeof(struct smm_eps_table));
+addr += 1) {
+ eps = check_eps_table(addr);
+ if (eps)
+ break;
+ }
+
+ if (!eps) {
+ dev_dbg(_pdev->dev, "found WSMT, but no EPS found\n");
+
[PATCH v3] dcdbas: Add support for WSMT ACPI table
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version to 5.6.0-3.3
v3 Removed dependency on ACPI in Kconfig
Moved the added #include to be in alphabetical order
Added comments in smi_request_store()
Simplified checksum code
Changed loop searching 0xf to be more readable
Reworked calculation of remap_size & smi_data_buf_size
drivers/firmware/dcdbas.c | 118 +++---
drivers/firmware/dcdbas.h | 10
2 files changed, 122 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 0bdea60c65dd..e95dc9aee2fa 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -21,6 +21,7 @@
*/
#include
+#include
#include
#include
#include
@@ -41,7 +42,7 @@
#include "dcdbas.h"
#define DRIVER_NAME"dcdbas"
-#define DRIVER_VERSION "5.6.0-3.2"
+#define DRIVER_VERSION "5.6.0-3.3"
#define DRIVER_DESCRIPTION "Dell Systems Management Base Driver"
static struct platform_device *dcdbas_pdev;
@@ -49,19 +50,23 @@ static struct platform_device *dcdbas_pdev;
static u8 *smi_data_buf;
static dma_addr_t smi_data_buf_handle;
static unsigned long smi_data_buf_size;
+static unsigned long max_smi_data_buf_size = MAX_SMI_DATA_BUF_SIZE;
static u32 smi_data_buf_phys_addr;
static DEFINE_MUTEX(smi_data_lock);
+static u8 *eps_buffer;
static unsigned int host_control_action;
static unsigned int host_control_smi_type;
static unsigned int host_control_on_shutdown;
+static bool wsmt_enabled;
+
/**
* smi_data_buf_free: free SMI data buffer
*/
static void smi_data_buf_free(void)
{
- if (!smi_data_buf)
+ if (!smi_data_buf || wsmt_enabled)
return;
dev_dbg(_pdev->dev, "%s: phys: %x size: %lu\n",
@@ -86,7 +91,7 @@ static int smi_data_buf_realloc(unsigned long size)
if (smi_data_buf_size >= size)
return 0;
- if (size > MAX_SMI_DATA_BUF_SIZE)
+ if (size > max_smi_data_buf_size)
return -EINVAL;
/* new buffer is needed */
@@ -169,7 +174,7 @@ static ssize_t smi_data_write(struct file *filp, struct
kobject *kobj,
{
ssize_t ret;
- if ((pos + count) > MAX_SMI_DATA_BUF_SIZE)
+ if ((pos + count) > max_smi_data_buf_size)
return -EINVAL;
mutex_lock(_data_lock);
@@ -322,8 +327,14 @@ static ssize_t smi_request_store(struct device *dev,
ret = count;
break;
case 1:
- /* Calling Interface SMI */
- smi_cmd->ebx = (u32) virt_to_phys(smi_cmd->command_buffer);
+ /* Calling Interface SMI
+*
+* Provide physical address of command buffer field within
+* the struct smi_cmd... can't use virt_to_phys on smi_cmd
+* because address may be from memremap.
+*/
+ smi_cmd->ebx = smi_data_buf_phys_addr +
+ offsetof(struct smi_cmd, command_buffer);
ret = dcdbas_smi_request(smi_cmd);
if (!ret)
ret = count;
@@ -482,6 +493,94 @@ static void dcdbas_host_control(void)
}
}
+/* WSMT */
+
+static u8 checksum(u8 *buffer, u8 length)
+{
+ u8 sum = 0;
+ u8 *end = buffer + length;
+
+ while (buffer < end)
+ sum += *buffer++;
+ return sum;
+}
+
+static inline struct smm_eps_table *check_eps_table(u8 *addr)
+{
+ struct smm_eps_table *eps = (struct smm_eps_table *)addr;
+
+ if (strncmp(eps->smm_comm_buff_anchor, SMM_EPS_SIG, 4) != 0)
+ return NULL;
+
+ if (checksum(addr, eps->length) != 0)
+ return NULL;
+
+ return eps;
+}
+
+static int dcdbas_check_wsmt(void)
+{
+ struct acpi_table_wsmt *wsmt = NULL;
+ struct smm_eps_table *eps = NULL;
+ u64 remap_size;
+ u8 *addr;
+
+ acpi_get_table(ACPI_SIG_WSMT, 0, (struct acpi_table_header **));
+ if (!wsmt)
+ return 0;
+
+ /* Check if WSMT ACPI table shows that protection is enabled */
+ if (!(wsmt->protection_flags & ACPI_WSMT_FIXED_COMM_BUFFERS)
+ || !(wsmt->protection_flags
+& ACPI_WSMT_COMM_BUFFER_NESTED_PTR_PROTECTION))
+ return 0;
+
+ /* Scan for EPS (entry point structure) */
+ for (addr = (u8 *)__va(0xf);
+addr < (u8 *)__va(0x10 - sizeof(struct smm_eps_table));
+addr += 1) {
+ eps = check_eps_table(addr);
+ if (eps)
+ break;
+ }
+
+ if (!eps) {
+ dev_dbg(_pdev->dev, "found WSMT, but no EPS found\n");
+
Re: [PATCH v2 18/24] serdev: ttydev: Serdev driver that creates an standard TTY port
On Mon, Jun 11, 2018 at 5:52 AM, Ricardo Ribalda Delgado wrote: > Standard TTY port that can be loaded/unloaded via serdev sysfs. This > serdev driver can only be used by serdev controllers that are compatible > with ttyport. I'm hesitant to expose a tty device on top of serdev to userspace that we then have to support forever unless that's the only way tty devices (for serial ports) are created. I did a similar patch which just registered both serdev and a tty allowing them to coexist. It suffered from warnings about open counts though and felt hacky. Rob
Re: [PATCH v2 18/24] serdev: ttydev: Serdev driver that creates an standard TTY port
On Mon, Jun 11, 2018 at 5:52 AM, Ricardo Ribalda Delgado wrote: > Standard TTY port that can be loaded/unloaded via serdev sysfs. This > serdev driver can only be used by serdev controllers that are compatible > with ttyport. I'm hesitant to expose a tty device on top of serdev to userspace that we then have to support forever unless that's the only way tty devices (for serial ports) are created. I did a similar patch which just registered both serdev and a tty allowing them to coexist. It suffered from warnings about open counts though and felt hacky. Rob
Re: [PATCH v3 2/2] gpio: davinci: Do not assume continuous IRQ numbering
On 6/13/2018 6:36 AM, J, KEERTHY wrote:
On 6/13/2018 1:36 AM, Grygorii Strashko wrote:
On 06/12/2018 02:59 AM, Keerthy wrote:
Currently the driver assumes that the interrupts are continuous
and does platform_get_irq only once and assumes the rest are continuous,
instead call platform_get_irq for all the interrupts and store them
in an array for later use.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk board.
Changes in v3:
* Changed irqs type from unsigned to int
Changes in v2:
* Extended the logic of using saved IRQs to unbanked IRQs
as per Grygorii's suggestion.
drivers/gpio/gpio-davinci.c | 54
+++---
include/linux/platform_data/gpio-davinci.h | 3 +-
2 files changed, 36 insertions(+), 21 deletions(-)
[...]
@@ -383,7 +396,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip
*chip, unsigned offset)
* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
*/
if (offset < d->gpio_unbanked)
- return d->base_irq + offset;
+ return d->irqs[offset];
this one seems right
else
return -ENODEV;
}
@@ -396,7 +409,7 @@ static int gpio_irq_type_unbanked(struct irq_data
*data, unsigned trigger)
d = (struct davinci_gpio_controller
*)irq_data_get_irq_handler_data(data);
g = (struct davinci_gpio_regs __iomem *)d->regs[0];
- mask = __gpio_mask(data->irq - d->base_irq);
+ mask = __gpio_mask(data->irq - d->irqs[0]);
but this one is not. You can't do "base + offset" or "irq - base" ops
if Irqs range is not sequential. So, in my opinion, here you need to
convert irq to gpio bank offset (hwirq value in irq_data is not offset
- gic specific value) which means - walk through d->irqs[x] and find
item with d->irqs[x] == irq which will give gpio bank offset.
Than offset can be used to build mask.
Agreed.
- mask = __gpio_mask(data->irq - d->base_irq);
+ for (i = 0; i < MAX_INT_PER_BANK; i++)
+ if (data->irq == d->irqs[i])
+ break;
+
+ if (i == MAX_INT_PER_BANK)
+ return -EINVAL;
+
+ mask = __gpio_mask(i);
I believe the above snippet works for non-sequential IRQs.
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -458,7 +471,7 @@ static struct irq_chip
*keystone_gpio_get_irq_chip(unsigned int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int
bank_irq)
[...]
#include
#define MAX_REGS_BANKS 5
+#define MAX_INT_PER_BANK 32
struct davinci_gpio_platform_data {
u32 ngpio;
@@ -41,7 +42,7 @@ struct davinci_gpio_controller {
spinlock_t lock;
void __iomem *regs[MAX_REGS_BANKS];
int gpio_unbanked;
- unsigned int base_irq;
+ int irqs[MAX_INT_PER_BANK];
unsigned int base;
};
Re: [PATCH v3 2/2] gpio: davinci: Do not assume continuous IRQ numbering
On 6/13/2018 6:36 AM, J, KEERTHY wrote:
On 6/13/2018 1:36 AM, Grygorii Strashko wrote:
On 06/12/2018 02:59 AM, Keerthy wrote:
Currently the driver assumes that the interrupts are continuous
and does platform_get_irq only once and assumes the rest are continuous,
instead call platform_get_irq for all the interrupts and store them
in an array for later use.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk board.
Changes in v3:
* Changed irqs type from unsigned to int
Changes in v2:
* Extended the logic of using saved IRQs to unbanked IRQs
as per Grygorii's suggestion.
drivers/gpio/gpio-davinci.c | 54
+++---
include/linux/platform_data/gpio-davinci.h | 3 +-
2 files changed, 36 insertions(+), 21 deletions(-)
[...]
@@ -383,7 +396,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip
*chip, unsigned offset)
* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
*/
if (offset < d->gpio_unbanked)
- return d->base_irq + offset;
+ return d->irqs[offset];
this one seems right
else
return -ENODEV;
}
@@ -396,7 +409,7 @@ static int gpio_irq_type_unbanked(struct irq_data
*data, unsigned trigger)
d = (struct davinci_gpio_controller
*)irq_data_get_irq_handler_data(data);
g = (struct davinci_gpio_regs __iomem *)d->regs[0];
- mask = __gpio_mask(data->irq - d->base_irq);
+ mask = __gpio_mask(data->irq - d->irqs[0]);
but this one is not. You can't do "base + offset" or "irq - base" ops
if Irqs range is not sequential. So, in my opinion, here you need to
convert irq to gpio bank offset (hwirq value in irq_data is not offset
- gic specific value) which means - walk through d->irqs[x] and find
item with d->irqs[x] == irq which will give gpio bank offset.
Than offset can be used to build mask.
Agreed.
- mask = __gpio_mask(data->irq - d->base_irq);
+ for (i = 0; i < MAX_INT_PER_BANK; i++)
+ if (data->irq == d->irqs[i])
+ break;
+
+ if (i == MAX_INT_PER_BANK)
+ return -EINVAL;
+
+ mask = __gpio_mask(i);
I believe the above snippet works for non-sequential IRQs.
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -458,7 +471,7 @@ static struct irq_chip
*keystone_gpio_get_irq_chip(unsigned int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int
bank_irq)
[...]
#include
#define MAX_REGS_BANKS 5
+#define MAX_INT_PER_BANK 32
struct davinci_gpio_platform_data {
u32 ngpio;
@@ -41,7 +42,7 @@ struct davinci_gpio_controller {
spinlock_t lock;
void __iomem *regs[MAX_REGS_BANKS];
int gpio_unbanked;
- unsigned int base_irq;
+ int irqs[MAX_INT_PER_BANK];
unsigned int base;
};
Re: [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> Hi Janusz,
>
> On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > GPIO lookup table for ams-delta-serio device was introduced by commit
> > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > lookup table" was not accepted by subystem maintainer who requested
> > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > with a regulator and removal of remaining GPIO pins from the driver as
> > not handled by it.
> >
> > Let's start with removal of no the longer needed GPIO lookup table from
> > the board init file.
> >
> > Series created and tested on top of next-20180608 tag from linux-next
> > tree.
>
> This all is really nice (modulo a couple of questions), thank you for
> implementing this. How do you want to merge this? Through OMAP tree or
> input?
Hi Dmitry,
If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
have a few board patches built on top of it in my queue.
Thanks,
Janusz
[PATCH 0/2] Re-use DEFINE_SHOW_ATTRIBUTE() macro
...instead of open coding file operations followed by custom ->open() callbacks per each attribute. Peng Donglin (2): ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro arch/arm/mm/ptdump_debugfs.c | 13 + arch/arm64/mm/ptdump_debugfs.c | 13 + 2 files changed, 2 insertions(+), 24 deletions(-) -- 2.7.4
[PATCH 2/2] ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin
---
arch/arm64/mm/ptdump_debugfs.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
index 02b18f8..24d786f 100644
--- a/arch/arm64/mm/ptdump_debugfs.c
+++ b/arch/arm64/mm/ptdump_debugfs.c
@@ -10,18 +10,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
Re: [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> Hi Janusz,
>
> On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > GPIO lookup table for ams-delta-serio device was introduced by commit
> > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > lookup table" was not accepted by subystem maintainer who requested
> > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > with a regulator and removal of remaining GPIO pins from the driver as
> > not handled by it.
> >
> > Let's start with removal of no the longer needed GPIO lookup table from
> > the board init file.
> >
> > Series created and tested on top of next-20180608 tag from linux-next
> > tree.
>
> This all is really nice (modulo a couple of questions), thank you for
> implementing this. How do you want to merge this? Through OMAP tree or
> input?
Hi Dmitry,
If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
have a few board patches built on top of it in my queue.
Thanks,
Janusz
[PATCH 0/2] Re-use DEFINE_SHOW_ATTRIBUTE() macro
...instead of open coding file operations followed by custom ->open() callbacks per each attribute. Peng Donglin (2): ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro arch/arm/mm/ptdump_debugfs.c | 13 + arch/arm64/mm/ptdump_debugfs.c | 13 + 2 files changed, 2 insertions(+), 24 deletions(-) -- 2.7.4
[PATCH 2/2] ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin
---
arch/arm64/mm/ptdump_debugfs.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
index 02b18f8..24d786f 100644
--- a/arch/arm64/mm/ptdump_debugfs.c
+++ b/arch/arm64/mm/ptdump_debugfs.c
@@ -10,18 +10,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
[PATCH 1/2] ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin
---
arch/arm/mm/ptdump_debugfs.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
index be8d87b..79002fe 100644
--- a/arch/arm/mm/ptdump_debugfs.c
+++ b/arch/arm/mm/ptdump_debugfs.c
@@ -11,18 +11,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
[PATCH 1/2] ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin
---
arch/arm/mm/ptdump_debugfs.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
index be8d87b..79002fe 100644
--- a/arch/arm/mm/ptdump_debugfs.c
+++ b/arch/arm/mm/ptdump_debugfs.c
@@ -11,18 +11,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
