[PATCH net-next] qed: Mark expected switch fall-through
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
drivers/net/ethernet/qlogic/qed/qed_cxt.c:2126:4: warning: this statement may
fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index c2ad405b2f50..35c9f484eb9f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -2129,6 +2129,7 @@ int qed_cxt_set_pf_params(struct qed_hwfn *p_hwfn, u32
rdma_tasks)
rdma_tasks);
/* no need for break since RoCE coexist with Ethernet */
}
+ /* fall through */
case QED_PCI_ETH:
{
struct qed_eth_pf_params *p_params =
--
2.20.1
Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain
Hi Suravee, On Tue, Jan 22, 2019 at 03:53:18PM +, Suthikulpanit, Suravee wrote: > Thanks for the detail. Alright then, let's just go with the version you > sent on 1/16/19. Do you want me to resend V3 with that changes, or > would you be taking care of that? Please send me a v3 based on the diff I sent last week. Also add a separate patch which adds the missing dte flush for the alias entry. Thanks, Joerg
[PATCH 2/2] mtd: spi-nor: Add support for MX25V8035F
From: Frieder Schrempf
This adds support for the Macronix MX25V8035F, a 8Mb SPI NOR chip.
Signed-off-by: Frieder Schrempf
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index aa8a04293a25..f08ea9cf86b6 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1849,6 +1849,8 @@ static const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
.fixups = &mx25l25635_fixups },
{ "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_4B_OPCODES) },
+ { "mx25v8035f", INFO(0xc22314, 0, 64 * 1024, 16,
+SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
{ "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_DUAL_READ |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ "mx66u51235f", INFO(0xc2253a, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
--
2.17.1
[PATCH 1/2] mtd: spi-nor: Add support for EN25Q80A
From: Frieder Schrempf
This adds support for the EON EN25Q80A, a 8Mb SPI NOR chip.
Signed-off-by: Frieder Schrempf
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6e13bbd1aaa5..aa8a04293a25 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1737,6 +1737,8 @@ static const struct flash_info spi_nor_ids[] = {
/* EON -- en25xxx */
{ "en25f32",INFO(0x1c3116, 0, 64 * 1024, 64, SECT_4K) },
{ "en25p32",INFO(0x1c2016, 0, 64 * 1024, 64, 0) },
+ { "en25q80a", INFO(0x1c3014, 0, 64 * 1024, 16,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "en25q32b", INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
{ "en25p64",INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
{ "en25q64",INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
--
2.17.1
[PATCH net-next] bna: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/ethernet/brocade/bna/bfa_ioc.c:790:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/brocade/bna/bfa_ioc.c:860:3: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough Signed-off-by: Gustavo A. R. Silva --- drivers/net/ethernet/brocade/bna/bfa_ioc.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c b/drivers/net/ethernet/brocade/bna/bfa_ioc.c index a36e38676640..cbc9175d74c5 100644 --- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c +++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c @@ -788,9 +788,8 @@ bfa_iocpf_sm_enabling(struct bfa_iocpf *iocpf, enum iocpf_event event) case IOCPF_E_INITFAIL: del_timer(&ioc->iocpf_timer); - /* -* !!! fall through !!! -*/ + /* fall through */ + case IOCPF_E_TIMEOUT: bfa_nw_ioc_hw_sem_release(ioc); if (event == IOCPF_E_TIMEOUT) @@ -858,9 +857,7 @@ bfa_iocpf_sm_disabling(struct bfa_iocpf *iocpf, enum iocpf_event event) case IOCPF_E_FAIL: del_timer(&ioc->iocpf_timer); - /* -* !!! fall through !!! -*/ + /* fall through*/ case IOCPF_E_TIMEOUT: bfa_ioc_set_cur_ioc_fwstate(ioc, BFI_IOC_FAIL); -- 2.20.1
[PATCH] iommu/mediatek: Use correct fwspec in mtk_iommu_add_device()
From: Joerg Roedel
The mtk_iommu_add_device() function keeps the fwspec in an
on-stack pointer and calls mtk_iommu_create_mapping(), which
might change its source, dev->iommu_fwspec. This causes the
on-stack pointer to be obsoleted and the device
initialization to fail. Update the on-stack fwspec pointer
after mtk_iommu_create_mapping() has been called.
Reported-by: Frank Wunderlich
Fixes: a9bf2eec5a6f ('iommu/mediatek: Use helper functions to access
dev->iommu_fwspec')
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu_v1.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 6ede4286b835..f60bdb85c4c0 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -442,6 +442,10 @@ static int mtk_iommu_add_device(struct device *dev)
iommu_spec.args_count = count;
mtk_iommu_create_mapping(dev, &iommu_spec);
+
+ /* dev->iommu_fwspec might have changed */
+ fwspec = dev_iommu_fwspec_get(dev);
+
of_node_put(iommu_spec.np);
}
--
2.13.7
[PATCH V3 2/6] misc/pvpanic: Add pvpanic driver framework
Add pvpanic driver framework. Follow-up patches will split the original
pvpanic acpi/of driver as the two seperate files and modify code to
adapt the framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/pvpanic.c | 171 ++---
1 file changed, 39 insertions(+), 132 deletions(-)
diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
index 595ac06..6380540 100644
--- a/drivers/misc/pvpanic/pvpanic.c
+++ b/drivers/misc/pvpanic/pvpanic.c
@@ -8,15 +8,20 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include
+#include
#include
#include
-#include
-#include
#include
#include
-static void __iomem *base;
+static struct {
+ struct platform_device *pdev;
+ void __iomem *base;
+ bool is_ioport;
+} pvpanic_data = {
+ .pdev = NULL,
+ .is_ioport = false,
+};
#define PVPANIC_PANICKED(1 << 0)
@@ -27,7 +32,7 @@
static void
pvpanic_send_event(unsigned int event)
{
- iowrite8(event, base);
+ iowrite8(event, pvpanic_data.base);
}
static int
@@ -43,150 +48,52 @@
.priority = 1, /* let this called before broken drm_fb_helper */
};
-#ifdef CONFIG_ACPI
-static int pvpanic_add(struct acpi_device *device);
-static int pvpanic_remove(struct acpi_device *device);
-
-static const struct acpi_device_id pvpanic_device_ids[] = {
- { "QEMU0001", 0 },
- { "", 0 }
-};
-MODULE_DEVICE_TABLE(acpi, pvpanic_device_ids);
-
-static struct acpi_driver pvpanic_driver = {
- .name = "pvpanic",
- .class ="QEMU",
- .ids = pvpanic_device_ids,
- .ops = {
- .add = pvpanic_add,
- .remove = pvpanic_remove,
- },
- .owner =THIS_MODULE,
-};
-
-static acpi_status
-pvpanic_walk_resources(struct acpi_resource *res, void *context)
+static int pvpanic_platform_probe(struct platform_device *pdev)
{
- struct resource r;
-
- if (acpi_dev_resource_io(res, &r)) {
- base = ioport_map(r.start, resource_size(&r));
- return AE_OK;
- } else if (acpi_dev_resource_memory(res, &r)) {
- base = ioremap(r.start, resource_size(&r));
- return AE_OK;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ void __iomem *base;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res) {
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return -ENODEV;
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (!res)
+ return -ENODEV;
+
+ base = ioport_map(res->start, resource_size(res));
+ if (!base)
+ return -ENODEV;
+ pvpanic_data.is_ioport = true;
}
- return AE_ERROR;
-}
-
-static int pvpanic_add(struct acpi_device *device)
-{
- int ret;
-
- ret = acpi_bus_get_status(device);
- if (ret < 0)
- return ret;
-
- if (!device->status.enabled || !device->status.functional)
- return -ENODEV;
-
- acpi_walk_resources(device->handle, METHOD_NAME__CRS,
- pvpanic_walk_resources, NULL);
-
- if (!base)
- return -ENODEV;
-
+ pvpanic_data.base = base;
atomic_notifier_chain_register(&panic_notifier_list,
&pvpanic_panic_nb);
return 0;
}
-static int pvpanic_remove(struct acpi_device *device)
+static int pvpanic_platform_remove(struct platform_device *pdev)
{
-
atomic_notifier_chain_unregister(&panic_notifier_list,
&pvpanic_panic_nb);
- iounmap(base);
-
- return 0;
-}
-
-static int pvpanic_register_acpi_driver(void)
-{
- return acpi_bus_register_driver(&pvpanic_driver);
-}
-
-static void pvpanic_unregister_acpi_driver(void)
-{
- acpi_bus_unregister_driver(&pvpanic_driver);
-}
-#else
-static int pvpanic_register_acpi_driver(void)
-{
- return -ENODEV;
-}
-static void pvpanic_unregister_acpi_driver(void) {}
-#endif
-
-static int pvpanic_mmio_probe(struct platform_device *pdev)
-{
- struct resource *mem;
-
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem)
- return -EINVAL;
-
- base = devm_ioremap_resource(&pdev->dev, mem);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- atomic_notifier_chain_register(&panic_notifier_list,
- &pvpanic_panic_nb);
-
- return 0;
-}
-
-static int pvpanic_mmio_remove(struct platform_device *pdev)
-{
-
- atomic_notifier_chain_unregister(&panic_notifier_list,
-&pvpanic_panic_nb);
+ if (pvpanic_data.is_io
[PATCH net-next] net: 3c509: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/3com/3c509.c:1265:8: warning: this statement may fall
through [-Wimplicit-fallthrough=]
drivers/net/ethernet/3com/3c509.c:1271:8: warning: this statement may fall
through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/ethernet/3com/3c509.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/3com/3c509.c
b/drivers/net/ethernet/3com/3c509.c
index b223769d6a5e..3da97996bdf3 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -1266,12 +1266,14 @@ el3_up(struct net_device *dev)
pr_cont("Forcing 3c5x9b full-duplex
mode");
break;
}
+ /* fall through */
case 8:
/* set full-duplex mode based on eeprom config
setting */
if ((sw_info & 0x000f) && (sw_info & 0x8000)) {
pr_cont("Setting 3c5x9b full-duplex
mode (from EEPROM configuration bit)");
break;
}
+ /* fall through */
default:
/* xcvr=(0 || 4) OR user has an old 3c5x9 non
"B" model */
pr_cont("Setting 3c5x9/3c5x9B half-duplex
mode");
--
2.20.1
[PATCH v7 2/2] PM-runtime: Replace jiffies based accounting with ktime-based accounting
From: Thara Gopinath
This patch replaces jiffies based accounting for runtime_active_time
and runtime_suspended_time with ktime-based accounting. This makes the
runtime debug counters inline with genpd and other PM subsytems which
use ktime-based accounting.
Timekeeping is initialized before driver_init(). It's only at that time
that PM runtime can be enabled.
Signed-off-by: Thara Gopinath
[switch from ktime to raw nsec]
Signed-off-by: Vincent Guittot
---
drivers/base/power/runtime.c | 17 +
drivers/base/power/sysfs.c | 11 ---
include/linux/pm.h | 6 +++---
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index eccd37f1..e9dae6d7 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -66,8 +66,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
*/
void update_pm_runtime_accounting(struct device *dev)
{
- unsigned long now = jiffies;
- unsigned long delta;
+ u64 now = ktime_to_ns(ktime_get());
+ u64 delta;
delta = now - dev->power.accounting_timestamp;
@@ -77,9 +77,9 @@ void update_pm_runtime_accounting(struct device *dev)
return;
if (dev->power.runtime_status == RPM_SUSPENDED)
- dev->power.suspended_jiffies += delta;
+ dev->power.suspended_time += delta;
else
- dev->power.active_jiffies += delta;
+ dev->power.active_time += delta;
}
static void __update_runtime_status(struct device *dev, enum rpm_status status)
@@ -90,16 +90,17 @@ static void __update_runtime_status(struct device *dev,
enum rpm_status status)
u64 pm_runtime_suspended_time(struct device *dev)
{
- unsigned long flags, time;
+ u64 time;
+ unsigned long flags;
spin_lock_irqsave(&dev->power.lock, flags);
update_pm_runtime_accounting(dev);
- time = dev->power.suspended_jiffies;
+ time = dev->power.suspended_time;
spin_unlock_irqrestore(&dev->power.lock, flags);
- return jiffies_to_nsecs(time);
+ return time;
}
EXPORT_SYMBOL_GPL(pm_runtime_suspended_time);
@@ -1311,7 +1312,7 @@ void pm_runtime_enable(struct device *dev)
/* About to enable runtime pm, set accounting_timestamp to now
*/
if (!dev->power.disable_depth)
- dev->power.accounting_timestamp = jiffies;
+ dev->power.accounting_timestamp =
ktime_to_ns(ktime_get());
} else {
dev_warn(dev, "Unbalanced %s!\n", __func__);
}
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index d713738..96c8a22 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -125,9 +125,12 @@ static ssize_t runtime_active_time_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
int ret;
+ u64 tmp;
spin_lock_irq(&dev->power.lock);
update_pm_runtime_accounting(dev);
- ret = sprintf(buf, "%i\n", jiffies_to_msecs(dev->power.active_jiffies));
+ tmp = dev->power.active_time;
+ do_div(tmp, NSEC_PER_MSEC);
+ ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(&dev->power.lock);
return ret;
}
@@ -138,10 +141,12 @@ static ssize_t runtime_suspended_time_show(struct device
*dev,
struct device_attribute *attr, char *buf)
{
int ret;
+ u64 tmp;
spin_lock_irq(&dev->power.lock);
update_pm_runtime_accounting(dev);
- ret = sprintf(buf, "%i\n",
- jiffies_to_msecs(dev->power.suspended_jiffies));
+ tmp = dev->power.suspended_time;
+ do_div(tmp, NSEC_PER_MSEC);
+ ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(&dev->power.lock);
return ret;
}
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 0bd9de1..3d2cbf9 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -633,9 +633,9 @@ struct dev_pm_info {
int runtime_error;
int autosuspend_delay;
u64 last_busy;
- unsigned long active_jiffies;
- unsigned long suspended_jiffies;
- unsigned long accounting_timestamp;
+ u64 active_time;
+ u64 suspended_time;
+ u64 accounting_timestamp;
#endif
struct pm_subsys_data *subsys_data; /* Owned by the subsystem. */
void (*set_latency_tolerance)(struct device *, s32);
--
2.7.4
[PATCH v7 1/2] PM-runtime: update accounting_timestamp only when enable
Initializing accounting_timestamp to something different from 0 during
pm_runtime_init() doesn't make sense and put useless ordering constraint between
timekeeping_init() and pm_runtime_init().
PM runtime should start accounting time only when it is enable and discard
the period when disabled.
Set accounting_timestamp to now when enabling PM runtime.
Suggested-by: "Rafael J. Wysocki"
Signed-off-by: Vincent Guittot
---
drivers/base/power/runtime.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index fb5e2b6..eccd37f1 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1306,10 +1306,15 @@ void pm_runtime_enable(struct device *dev)
spin_lock_irqsave(&dev->power.lock, flags);
- if (dev->power.disable_depth > 0)
+ if (dev->power.disable_depth > 0) {
dev->power.disable_depth--;
- else
+
+ /* About to enable runtime pm, set accounting_timestamp to now
*/
+ if (!dev->power.disable_depth)
+ dev->power.accounting_timestamp = jiffies;
+ } else {
dev_warn(dev, "Unbalanced %s!\n", __func__);
+ }
WARN(!dev->power.disable_depth &&
dev->power.runtime_status == RPM_SUSPENDED &&
@@ -1506,7 +1511,7 @@ void pm_runtime_init(struct device *dev)
dev->power.request_pending = false;
dev->power.request = RPM_REQ_NONE;
dev->power.deferred_resume = false;
- dev->power.accounting_timestamp = jiffies;
+ dev->power.accounting_timestamp = 0;
INIT_WORK(&dev->power.work, pm_runtime_work);
dev->power.timer_expires = 0;
--
2.7.4
[PATCH v7 0/3] Move pm_runtime accounted time to raw nsec
Move pm_runtime accounted time to raw nsec. The subject of the patchset has changed as 1st patch o the previous versions has been queued by Rafael. Patch 1 set accounting_timestamp to 0 in pm_runtime_init and update it when enable. So we remove ordering constraint between timekeeping_init and pm_runtime_init Patch 2 moves time accounting on raw ns. This patch initially used ktime instead of raw ns but it was easier to move i915 driver on raw ns than on ktime. Change since v6: - move code that set accounting_timestamp in pm_runtime_enable Changes since v5: - removed patches already queued. - set accounting_timestamp to 0 in pm_runtime_init and update it when enable Changes since v4: -Update commit message Changes since v3: - Rebase on v4.20-rc7 without patch that has been queued by Rafael - Simplify the new interface pm_runtime_suspended_time() Changes since v2: - remove patch1 that has been queued by rafael - add new interface in pm_runtime to get accounted time - reorder patchset to prevent compilation error Changes since v1: - updated commit message of patch 1 - Added patches 2 & 3 to move runtime_pm accounting on raw ns Thara Gopinath (1): PM-runtime: Replace jiffies based accounting with ktime-based accounting Vincent Guittot (1): PM-runtime: update accounting_timestamp only when enable drivers/base/power/runtime.c | 26 -- drivers/base/power/sysfs.c | 11 --- include/linux/pm.h | 6 +++--- 3 files changed, 27 insertions(+), 16 deletions(-) -- 2.7.4
[PATCH net-next] intel: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/intel/igb/e1000_82575.c:636:6: warning: this statement may
fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/intel/igb/igb_main.c:6710:6: warning: this statement may
fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/intel/i40e/i40e_xsk.c:237:3: warning: this statement may
fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 3 ++-
drivers/net/ethernet/intel/igb/e1000_82575.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c| 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index 96d849460d9b..774e31405ba0 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -235,9 +235,10 @@ static int i40e_run_xdp_zc(struct i40e_ring *rx_ring,
struct xdp_buff *xdp)
break;
default:
bpf_warn_invalid_xdp_action(act);
+ /* fall through */
case XDP_ABORTED:
trace_xdp_exception(rx_ring->netdev, xdp_prog, act);
- /* fallthrough -- handle aborts by dropping packet */
+ /* fall through - handle aborts by dropping packet */
case XDP_DROP:
result = I40E_XDP_CONSUMED;
break;
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c
b/drivers/net/ethernet/intel/igb/e1000_82575.c
index bafdcf70a353..3ec2ce0725d5 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -638,7 +638,7 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
dev_spec->sgmii_active = true;
break;
}
- /* fall through for I2C based SGMII */
+ /* fall through - for I2C based SGMII */
case E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES:
/* read media type from SFP EEPROM */
ret_val = igb_set_sfp_media_type_82575(hw);
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index dfa357b1a9d6..2c88e47574a7 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6713,7 +6713,7 @@ static int __igb_notify_dca(struct device *dev, void
*data)
igb_setup_dca(adapter);
break;
}
- /* Fall Through since DCA is disabled. */
+ /* Fall Through - since DCA is disabled. */
case DCA_PROVIDER_REMOVE:
if (adapter->flags & IGB_FLAG_DCA_ENABLED) {
/* without this a class_device is left
--
2.20.1
RE: [PATCH net-next] broadcom: Mark expected switch fall-throughs
-Original Message- From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com] Sent: 23 January 2019 13:11 To: Ariel Elior ; Sudarsana Kalluru ; everest-linux...@cavium.com; David S. Miller ; Siva Reddy Kallam ; Prashant Sreedharan ; Michael Chan Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R. Silva Subject: [PATCH net-next] broadcom: Mark expected switch fall-throughs External Email In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:6336:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2231:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/tg3.c:722:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/tg3.c:783:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 2 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +- drivers/net/ethernet/broadcom/tg3.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c index 29738dfa878c..d581d0ae6584 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c @@ -6335,7 +6335,7 @@ int bnx2x_set_led(struct link_params *params, */ if (!vars->link_up) break; - /* else: fall through */ + /* fall through */ case LED_MODE_ON: if (((params->phy[EXT_PHY1].type == PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BCM8727) || diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c index c835f6c7ecd0..c97b642e6537 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c @@ -2230,7 +2230,7 @@ int bnx2x_vf_free(struct bnx2x *bp, struct bnx2x_virtf *vf) rc = bnx2x_vf_close(bp, vf); if (rc) goto op_err; - /* Fallthrough to release resources */ + /* Fall through - to release resources */ case VF_ACQUIRED: DP(BNX2X_MSG_IOV, "about to free resources\n"); bnx2x_vf_free_resc(bp, vf); diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c index b1627dd5f2fd..328373e0578f 100644 --- a/drivers/net/ethernet/broadcom/tg3.c +++ b/drivers/net/ethernet/broadcom/tg3.c @@ -721,7 +721,7 @@ static int tg3_ape_lock(struct tg3 *tp, int locknum) case TG3_APE_LOCK_GPIO: if (tg3_asic_rev(tp) == ASIC_REV_5761) return 0; - /* else: fall through */ + /* fall through */ case TG3_APE_LOCK_GRC: case TG3_APE_LOCK_MEM: if (!tp->pci_fn) @@ -782,7 +782,7 @@ static void tg3_ape_unlock(struct tg3 *tp, int locknum) case TG3_APE_LOCK_GPIO: if (tg3_asic_rev(tp) == ASIC_REV_5761) return; - /* else: fall through */ + /* fall through */ case TG3_APE_LOCK_GRC: case TG3_APE_LOCK_MEM: if (!tp->pci_fn) -- 2.20.1 Acked-by: Sudarsana Kalluru
Re: [PATCH] power: domain: no need to check return value of debugfs_create functions
On Tue, 22 Jan 2019 at 16:23, Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Doesn't this boils done to whether we want to care to check if memory
allocation failed?
Somewhere down the call chain from debugfs_create_dir(), we end up in
alloc_inode() and it looks like that can fail, no?
Kind regards
Uffe
>
> Cc: "Rafael J. Wysocki"
> Cc: Kevin Hilman
> Cc: Ulf Hansson
> Cc: Len Brown
> Cc: linux...@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/base/power/domain.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 500de1dee967..45eafe8cf7dd 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2948,18 +2948,11 @@ static int __init genpd_debug_init(void)
>
> genpd_debugfs_dir = debugfs_create_dir("pm_genpd", NULL);
>
> - if (!genpd_debugfs_dir)
> - return -ENOMEM;
> -
> - d = debugfs_create_file("pm_genpd_summary", S_IRUGO,
> - genpd_debugfs_dir, NULL, &summary_fops);
> - if (!d)
> - return -ENOMEM;
> + debugfs_create_file("pm_genpd_summary", S_IRUGO, genpd_debugfs_dir,
> + NULL, &summary_fops);
>
> list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
> d = debugfs_create_dir(genpd->name, genpd_debugfs_dir);
> - if (!d)
> - return -ENOMEM;
>
> debugfs_create_file("current_state", 0444,
> d, genpd, &status_fops);
> --
> 2.20.1
>
[PATCH net-next] Bluetooth: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: net/bluetooth/rfcomm/core.c:479:6: warning: this statement may fall through [-Wimplicit-fallthrough=] net/bluetooth/l2cap_core.c:4223:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva --- net/bluetooth/l2cap_core.c | 1 + net/bluetooth/rfcomm/core.c | 1 + 2 files changed, 2 insertions(+) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 2a7fb517d460..a5b76e24940a 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -4244,6 +4244,7 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, goto done; break; } + /* fall through */ default: l2cap_chan_set_err(chan, ECONNRESET); diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c index 1a635df80643..3a9e9d9670be 100644 --- a/net/bluetooth/rfcomm/core.c +++ b/net/bluetooth/rfcomm/core.c @@ -483,6 +483,7 @@ static int __rfcomm_dlc_close(struct rfcomm_dlc *d, int err) /* if closing a dlc in a session that hasn't been started, * just close and unlink the dlc */ + /* fall through */ default: rfcomm_dlc_clear_timer(d); -- 2.20.1
[PATCH net-next] broadcom: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:6336:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2231:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/tg3.c:722:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/ethernet/broadcom/tg3.c:783:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 2 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +- drivers/net/ethernet/broadcom/tg3.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c index 29738dfa878c..d581d0ae6584 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c @@ -6335,7 +6335,7 @@ int bnx2x_set_led(struct link_params *params, */ if (!vars->link_up) break; - /* else: fall through */ + /* fall through */ case LED_MODE_ON: if (((params->phy[EXT_PHY1].type == PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BCM8727) || diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c index c835f6c7ecd0..c97b642e6537 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c @@ -2230,7 +2230,7 @@ int bnx2x_vf_free(struct bnx2x *bp, struct bnx2x_virtf *vf) rc = bnx2x_vf_close(bp, vf); if (rc) goto op_err; - /* Fallthrough to release resources */ + /* Fall through - to release resources */ case VF_ACQUIRED: DP(BNX2X_MSG_IOV, "about to free resources\n"); bnx2x_vf_free_resc(bp, vf); diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c index b1627dd5f2fd..328373e0578f 100644 --- a/drivers/net/ethernet/broadcom/tg3.c +++ b/drivers/net/ethernet/broadcom/tg3.c @@ -721,7 +721,7 @@ static int tg3_ape_lock(struct tg3 *tp, int locknum) case TG3_APE_LOCK_GPIO: if (tg3_asic_rev(tp) == ASIC_REV_5761) return 0; - /* else: fall through */ + /* fall through */ case TG3_APE_LOCK_GRC: case TG3_APE_LOCK_MEM: if (!tp->pci_fn) @@ -782,7 +782,7 @@ static void tg3_ape_unlock(struct tg3 *tp, int locknum) case TG3_APE_LOCK_GPIO: if (tg3_asic_rev(tp) == ASIC_REV_5761) return; - /* else: fall through */ + /* fall through */ case TG3_APE_LOCK_GRC: case TG3_APE_LOCK_MEM: if (!tp->pci_fn) -- 2.20.1
Re: [PATCH 3/7] crypto: axis: no need to check return value of debugfs_create functions
On 1/22/19 4:14 PM, Greg Kroah-Hartman wrote: When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Jesper Nilsson Cc: Lars Persson Cc: Herbert Xu Cc: "David S. Miller" Cc: linux-arm-ker...@axis.com Cc: linux-cry...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/crypto/axis/artpec6_crypto.c | 9 - 1 file changed, 9 deletions(-) Acked-by: Lars Persson Thanks, Lars
Re: [PATCH V3 4/6] misc/pvpanic: add pvpanic acpi driver
On Wed, Jan 23, 2019 at 11:47:26PM +0800, Peng Hao wrote: > Make pvpanic acpi driver as seperate file and modify code > in order to adapt the framework. > > Signed-off-by: Peng Hao > --- > drivers/misc/pvpanic/Kconfig| 9 + > drivers/misc/pvpanic/Makefile | 1 + > drivers/misc/pvpanic/pvpanic-acpi.c | 77 > + > 3 files changed, 87 insertions(+) > create mode 100644 drivers/misc/pvpanic/pvpanic-acpi.c > > diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig > index 3e612c6..d274130 100644 > --- a/drivers/misc/pvpanic/Kconfig > +++ b/drivers/misc/pvpanic/Kconfig > @@ -5,3 +5,12 @@ config PVPANIC > This driver provides support for the pvpanic device. pvpanic is > a paravirtualized device provided by QEMU; it lets a virtual machine > (guest) communicate panic events to the host. > + > +if PVPANIC > + > +config PVPANIC_ACPI > + tristate "pvpanic acpi driver" > + depends on ACPI > + default PVPANIC Any reason you ignored the review comments I made for your v1 submission? Please address those comments before you resend this again. greg k-h
Re: [PATCH] fail_function: no need to check return value of debugfs_create functions
On Wed, 23 Jan 2019 07:34:27 +0100
Greg Kroah-Hartman wrote:
> On Wed, Jan 23, 2019 at 07:33:05AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Jan 23, 2019 at 09:11:41AM +0900, Masami Hiramatsu wrote:
> > > On Tue, 22 Jan 2019 16:21:44 +0100
> > > Greg Kroah-Hartman wrote:
> > >
> > > > When calling debugfs functions, there is no need to ever check the
> > > > return value. The function can work or not, but the code logic should
> > > > never do something different based on this.
> > >
> > > Ah, OK. It simplifies the code. But I have a question below,
> > >
> > > >
> > > > Cc: Masami Hiramatsu
> > > > Cc: Kees Cook
> > > > Cc: Josef Bacik
> > > > Cc: Thomas Gleixner
> > > > Cc: "Naveen N. Rao"
> > > > Cc: zhong jiang
> > > > Signed-off-by: Greg Kroah-Hartman
> > > > ---
> > > > kernel/fail_function.c | 23 +--
> > > > 1 file changed, 5 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/kernel/fail_function.c b/kernel/fail_function.c
> > > > index 17f75b545f66..afc779be5ebb 100644
> > > > --- a/kernel/fail_function.c
> > > > +++ b/kernel/fail_function.c
> > > > @@ -152,20 +152,13 @@ static int fei_retval_get(void *data, u64 *val)
> > > > DEFINE_DEBUGFS_ATTRIBUTE(fei_retval_ops, fei_retval_get,
> > > > fei_retval_set,
> > > > "%llx\n");
> > > >
> > > > -static int fei_debugfs_add_attr(struct fei_attr *attr)
> > > > +static void fei_debugfs_add_attr(struct fei_attr *attr)
> > > > {
> > > > struct dentry *dir;
> > > >
> > > > dir = debugfs_create_dir(attr->kp.symbol_name, fei_debugfs_dir);
> > > > - if (!dir)
> > > > - return -ENOMEM;
> > > > -
> > > > - if (!debugfs_create_file("retval", 0600, dir, attr,
> > > > &fei_retval_ops)) {
> > > > - debugfs_remove_recursive(dir);
> > > > - return -ENOMEM;
> > > > - }
> > > >
> > > > - return 0;
> > >
> > > Don't we need to check dir here? If above debugfs_create_dir() returns
> > > NULL,
> > > it seems we will create "retval" under root directory of debugfs.
> >
> > If NULL is returned, your system is out of memory and worse things are
> > about to happen :)
>
> But you aren't the first to ask about this, I guess I should just return
> ENOMEM and then the follow-on files will not be created. I'll go make
> that change to the core of debugfs to help prevent this problem.
I got it, and yes, returning -ENOMEM sounds good to me, especially, in this
case.
Acked-by: Masami Hiramatsu
Thanks!
>
> thanks,
>
> greg k-h
--
Masami Hiramatsu
Re: [PATCH V10 3/4] mmc: sdhci: Add ADMA3 DMA support for V4 enabled host
On 22/01/19 9:56 PM, Sowjanya Komatineni wrote: > Below are the supported DMA types in Host Control1 Register > with Version 4 enable > b'00 - SDMA > b'01 - Not Used > b'10 - ADMA2 > b'11 - ADMA2 or ADMA3 > > ADMA3 uses Command Descriptor to issue an SD command. > A multi-block data transfer is performed by using a pair of CMD > descriptor and ADMA2 descriptor. > > ADMA3 performs multiple of multi-block data transfer by using > Integrated Descriptor which is more suitable for Command Queuing > to fetch both Command and Transfer descriptors. > > Host Capabilities register indiactes the supports of ADMA3 DMA. indiactes -> indicates > > Signed-off-by: Sowjanya Komatineni Acked-by: Adrian Hunter > --- > [V10]: Changes are same as V9 except this series has SDHCI core changes > into seperate patch > > drivers/mmc/host/sdhci.c | 9 - > drivers/mmc/host/sdhci.h | 2 ++ > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index a22e11a65658..c6afe793399e 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -3353,7 +3353,14 @@ void sdhci_cqe_enable(struct mmc_host *mmc) > > ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); > ctrl &= ~SDHCI_CTRL_DMA_MASK; > - if (host->flags & SDHCI_USE_64_BIT_DMA) > + /* > + * Host from V4.10 supports ADMA3 DMA type. > + * ADMA3 performs integrated descriptor which is more suitable > + * for cmd queuing to fetch both command and transfer descriptors. > + */ > + if (host->v4_mode && (host->caps1 & SDHCI_CAN_DO_ADMA3)) > + ctrl |= SDHCI_CTRL_ADMA3; > + else if (host->flags & SDHCI_USE_64_BIT_DMA) > ctrl |= SDHCI_CTRL_ADMA64; > else > ctrl |= SDHCI_CTRL_ADMA32; > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h > index 6cc9a3c2ac66..4070be49d947 100644 > --- a/drivers/mmc/host/sdhci.h > +++ b/drivers/mmc/host/sdhci.h > @@ -88,6 +88,7 @@ > #define SDHCI_CTRL_ADMA1 0x08 > #define SDHCI_CTRL_ADMA32 0x10 > #define SDHCI_CTRL_ADMA64 0x18 > +#define SDHCI_CTRL_ADMA3 0x18 > #define SDHCI_CTRL_8BITBUS 0x20 > #define SDHCI_CTRL_CDTEST_INS 0x40 > #define SDHCI_CTRL_CDTEST_EN0x80 > @@ -230,6 +231,7 @@ > #define SDHCI_RETUNING_MODE_SHIFT 14 > #define SDHCI_CLOCK_MUL_MASK0x00FF > #define SDHCI_CLOCK_MUL_SHIFT 16 > +#define SDHCI_CAN_DO_ADMA3 0x0800 > #define SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */ > > #define SDHCI_CAPABILITIES_1 0x44 >
Re: kmemleak panic
Hi Mike,
On 2019-01-23 06:54, Mike Rapoport wrote:
...
> Resending it as a formal patch now, I took a liberty to add your Tested-by.
>
> >From a847ca684db29a3c09e4dd2a8a008b35cf36e52f Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Wed, 23 Jan 2019 07:38:50 +0200
> Subject: [PATCH] of: fix kmemleak crash caused by imbalance in early memory
> reservation
>
> Marc Gonzalez reported the following kmemleak crash:
>
> Unable to handle kernel paging request at virtual address ffc021e0
> Mem abort info:
> ESR = 0x9606
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x0006
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
> [ffc021e0] pgd=00017e3ba803, pud=00017e3ba803,
> pmd=
> Internal error: Oops: 9606 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 6 PID: 523 Comm: kmemleak Tainted: G S W 5.0.0-rc1 #13
> Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
> pstate: 8085 (Nzcv daIf -PAN -UAO)
> pc : scan_block+0x70/0x190
> lr : scan_block+0x6c/0x190
> sp : ff8012e8bd20
> x29: ff8012e8bd20 x28: ffc0fdbaf018
> x27: ffc02200 x26: 0080
> x25: ff8011aadf70 x24: ffc0f8cc8000
> x23: ff8010dc8000 x22: ff8010dc8830
> x21: ffc021e00ff9 x20: ffc0f8cc8050
> x19: ffc021e0 x18: 2409
> x17: 0200 x16:
> x15: ff8010e14dd8 x14: 2406
> x13: 4c4dd0c6 x12: ffc0f77dad58
> x11: 0001 x10: ff8010d9e688
> x9 : ff8010d9f000 x8 : ff8010d9e688
> x7 : 0002 x6 :
> x5 : ff8011511c20 x4 : 26d1
> x3 : ff8010e14d88 x2 : 5b36396f4e7d4000
> x1 : 00208040 x0 :
> Process kmemleak (pid: 523, stack limit = 0x(ptrval))
> Call trace:
> scan_block+0x70/0x190
> scan_gray_list+0x108/0x1c0
> kmemleak_scan+0x33c/0x7c0
> kmemleak_scan_thread+0x98/0xf0
> kthread+0x11c/0x120
> ret_from_fork+0x10/0x1c
> Code: f9000fb4 d503201f 97d2 35000580 (f9400260)
> ---[ end trace 176d6ed9d86a0c33 ]---
> note: kmemleak[523] exited with preempt_count 2
>
> The crash happens when a no-map area is allocated in
> early_init_dt_alloc_reserved_memory_arch(). The allocated region is
> registered with kmemleak, but it is then removed from memblock using
> memblock_remove() that is not kmemleak-aware.
>
> Replacing __memblock_alloc_base() with memblock_find_in_range() makes sure
> that the allocated memory is not added to kmemleak and then
> memblock_remove()'ing this memory is safe.
>
> As a bonus, since memblock_find_in_range() ensures the allocation in the
> specified range, the bounds check can be removed.
>
> Signed-off-by: Mike Rapoport
> Tested-by: Marc Gonzalez
With the minor fix mentioned below, you can add my:
Acked-by: Marek Szyprowski
> ---
> drivers/of/of_reserved_mem.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 1977ee0adcb1..6807a1cffe55 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -37,21 +37,16 @@ int __init __weak
> early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
>*/
> end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
> align = !align ? SMP_CACHE_BYTES : align;
> - base = __memblock_alloc_base(size, align, end);
> + base = memblock_find_in_range(size, align, start, end);
Please remove a comment about __memblock_alloc_base() above that block
of code. It is no longer needed after this change.
> if (!base)
> return -ENOMEM;
>
> - /*
> - * Check if the allocated region fits in to start..end window
> - */
> - if (base < start) {
> - memblock_free(base, size);
> - return -ENOMEM;
> - }
> -
> *res_base = base;
> if (nomap)
> return memblock_remove(base, size);
> + else
> + return memblock_reserve(base, size);
> +
> return 0;
> }
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH 1/2] dt-bindings: input: sitronix-st1232: add compatible string for ST1633
From: Martin Kepplinger The st1232 driver gains support for the ST1633 controller too; update the bindings doc accordingly. Signed-off-by: Martin Kepplinger --- .../bindings/input/touchscreen/sitronix-st1232.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt index 64ad48b824a2..e73e826e0f2a 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt @@ -1,7 +1,9 @@ -* Sitronix st1232 touchscreen controller +* Sitronix st1232 or st1633 touchscreen controller Required properties: -- compatible: must be "sitronix,st1232" +- compatible: must contain one of + * "sitronix,st1232" + * "sitronix,st1633" - reg: I2C address of the chip - interrupts: interrupt to which the chip is connected -- 2.20.1
[PATCH 2/2] Input: st1232 - add support for st1633
From: Martin Kepplinger
Add support for the Sitronix ST1633 touchscreen controller to the st1232
driver.
Signed-off-by: Martin Kepplinger
---
drivers/input/touchscreen/Kconfig | 6 +-
drivers/input/touchscreen/st1232.c | 130 +
2 files changed, 98 insertions(+), 38 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 068dbbc610fc..7c597a49c265 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1168,11 +1168,11 @@ config TOUCHSCREEN_SIS_I2C
module will be called sis_i2c.
config TOUCHSCREEN_ST1232
- tristate "Sitronix ST1232 touchscreen controllers"
+ tristate "Sitronix ST1232 or ST1633 touchscreen controllers"
depends on I2C
help
- Say Y here if you want to support Sitronix ST1232
- touchscreen controller.
+ Say Y here if you want to support the Sitronix ST1232
+ or ST1633 touchscreen controller.
If unsure, say N.
diff --git a/drivers/input/touchscreen/st1232.c
b/drivers/input/touchscreen/st1232.c
index 11ff32c68025..dc0288f37fda 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -18,18 +18,21 @@
#include
#include
#include
+#include
#include
#include
#include
#define ST1232_TS_NAME "st1232-ts"
+#define ST1633_TS_NAME "st1633-ts"
+
+enum {
+ st1232,
+ st1633,
+};
#define MIN_X 0x00
#define MIN_Y 0x00
-#define MAX_X 0x31f /* (800 - 1) */
-#define MAX_Y 0x1df /* (480 - 1) */
-#define MAX_AREA 0xff
-#define MAX_FINGERS2
struct st1232_ts_finger {
u16 x;
@@ -38,12 +41,24 @@ struct st1232_ts_finger {
bool is_valid;
};
+struct st_chip_info {
+ u8 id;
+ u16 max_x;
+ u16 max_y;
+ u16 max_area;
+ u16 max_fingers;
+ u8 start_reg;
+};
+
struct st1232_ts_data {
struct i2c_client *client;
struct input_dev *input_dev;
- struct st1232_ts_finger finger[MAX_FINGERS];
struct dev_pm_qos_request low_latency_req;
int reset_gpio;
+ const struct st_chip_info *chip_info;
+ int read_buf_len;
+ u8 *read_buf;
+ struct st1232_ts_finger *finger;
};
static int st1232_ts_read_data(struct st1232_ts_data *ts)
@@ -52,40 +67,35 @@ static int st1232_ts_read_data(struct st1232_ts_data *ts)
struct i2c_client *client = ts->client;
struct i2c_msg msg[2];
int error;
- u8 start_reg;
- u8 buf[10];
+ int i, y;
+ u8 start_reg = ts->chip_info->start_reg;
+ u8 *buf = ts->read_buf;
- /* read touchscreen data from ST1232 */
+ /* read touchscreen data */
msg[0].addr = client->addr;
msg[0].flags = 0;
msg[0].len = 1;
msg[0].buf = &start_reg;
- start_reg = 0x10;
msg[1].addr = ts->client->addr;
msg[1].flags = I2C_M_RD;
- msg[1].len = sizeof(buf);
+ msg[1].len = ts->read_buf_len;
msg[1].buf = buf;
error = i2c_transfer(client->adapter, msg, 2);
if (error < 0)
return error;
- /* get "valid" bits */
- finger[0].is_valid = buf[2] >> 7;
- finger[1].is_valid = buf[5] >> 7;
+ for (i = 0, y = 0; i < ts->chip_info->max_fingers; i++, y += 3) {
+ finger[i].is_valid = buf[i + y] >> 7;
+ if (finger[i].is_valid) {
+ finger[i].x = ((buf[i + y] & 0x0070) << 4) | buf[i + 1];
+ finger[i].y = ((buf[i + y] & 0x0007) << 8) | buf[i + 2];
- /* get xy coordinate */
- if (finger[0].is_valid) {
- finger[0].x = ((buf[2] & 0x0070) << 4) | buf[3];
- finger[0].y = ((buf[2] & 0x0007) << 8) | buf[4];
- finger[0].t = buf[8];
- }
-
- if (finger[1].is_valid) {
- finger[1].x = ((buf[5] & 0x0070) << 4) | buf[6];
- finger[1].y = ((buf[5] & 0x0007) << 8) | buf[7];
- finger[1].t = buf[9];
+ /* st1232 includes a z-axis / touch strength */
+ if (ts->chip_info->id == st1232)
+ finger[i].t = buf[i + 6];
+ }
}
return 0;
@@ -104,11 +114,14 @@ static irqreturn_t st1232_ts_irq_handler(int irq, void
*dev_id)
goto end;
/* multi touch protocol */
- for (i = 0; i < MAX_FINGERS; i++) {
+ for (i = 0; i < ts->chip_info->max_fingers; i++) {
if (!finger[i].is_valid)
continue;
- input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, finger[i].t);
+ if (ts->chip_info->id == st1232)
+ input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR,
+finger[i].t);
+
input_report_abs(input_dev, ABS_MT_
general protection fault in rxrpc_connect_call
Hello, syzbot found the following crash on: HEAD commit:787a3b432276 Merge branch 'for-linus' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=104f80c0c0 kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68 dashboard link: https://syzkaller.appspot.com/bug?extid=7966f2a0b2c7da8939b4 compiler: gcc (GCC) 9.0.0 20181231 (experimental) userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15dc0930c0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f3766b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+7966f2a0b2c7da893...@syzkaller.appspotmail.com audit: type=1800 audit(1548224295.427:29): pid=7748 uid=0 auid=4294967295 ses=4294967295 subj==unconfined op=collect_data cause=failed(directio) comm="startpar" name="rc.local" dev="sda1" ino=2432 res=0 kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 7899 Comm: syz-executor751 Not tainted 5.0.0-rc3+ #39 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:rxrpc_connect_call+0x1a3/0x5130 net/rxrpc/conn_client.c:690 Code: fa 4c 89 f0 48 c1 e8 03 80 3c 18 00 0f 85 01 46 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 1e 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 07 46 00 00 48 8b 5b 18 48 8d bb f0 01 00 00 48 RSP: 0018:88808889ee90 EFLAGS: 00010206 RAX: dc00 RBX: RCX: 88808ca0596c RDX: 0003 RSI: 873650fa RDI: 0018 RBP: 88808889f3a8 R08: 006000c0 R09: 8880a9620d20 R10: 8880a9620480 R11: R12: 8880a9177b40 R13: 88809a470160 R14: 88808889f6c8 R15: 8880a9177cc8 FS: () GS:8880ae60(0063) knlGS:08b34840 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 2040 CR3: 90872000 CR4: 001406f0 Call Trace: rxrpc_new_client_call+0xb0b/0x1e50 net/rxrpc/call_object.c:291 rxrpc_new_client_call_for_sendmsg net/rxrpc/sendmsg.c:593 [inline] rxrpc_do_sendmsg+0x16df/0x27ad net/rxrpc/sendmsg.c:649 rxrpc_sendmsg+0x4b8/0x5f0 net/rxrpc/af_rxrpc.c:556 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:631 ___sys_sendmsg+0x409/0x910 net/socket.c:2116 __sys_sendmmsg+0x3bc/0x730 net/socket.c:2204 __compat_sys_sendmmsg net/compat.c:771 [inline] __do_compat_sys_sendmmsg net/compat.c:778 [inline] __se_compat_sys_sendmmsg net/compat.c:775 [inline] __ia32_compat_sys_sendmmsg+0x9f/0x100 net/compat.c:775 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline] do_fast_syscall_32+0x333/0xf98 arch/x86/entry/common.c:397 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 RIP: 0023:0xf7f17869 Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:ff96366c EFLAGS: 0217 ORIG_RAX: 0159 RAX: ffda RBX: 0003 RCX: 20005c00 RDX: 0001 RSI: RDI: 0003 RBP: 2040 R08: R09: R10: R11: R12: R13: R14: R15: Modules linked in: ---[ end trace 32887e7d2c420b9a ]--- RIP: 0010:rxrpc_connect_call+0x1a3/0x5130 net/rxrpc/conn_client.c:690 Code: fa 4c 89 f0 48 c1 e8 03 80 3c 18 00 0f 85 01 46 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 1e 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 07 46 00 00 48 8b 5b 18 48 8d bb f0 01 00 00 48 RSP: 0018:88808889ee90 EFLAGS: 00010206 RAX: dc00 RBX: RCX: 88808ca0596c RDX: 0003 RSI: 873650fa RDI: 0018 RBP: 88808889f3a8 R08: 006000c0 R09: 8880a9620d20 R10: 8880a9620480 R11: R12: 8880a9177b40 R13: 88809a470160 R14: 88808889f6c8 R15: 8880a9177cc8 FS: () GS:8880ae60(0063) knlGS:08b34840 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 2040 CR3: 90872000 CR4: 001406f0 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH net-next] 9p: mark expected switch fall-through
On 1/23/19 1:23 AM, Dominique Martinet wrote: > Gustavo A. R. Silva wrote on Wed, Jan 23, 2019: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> This patch fixes the following warning: >> >> net/9p/trans_xen.c:514:6: warning: this statement may fall through >> [-Wimplicit-fallthrough=] >> >> Warning level 3 was used: -Wimplicit-fallthrough=3 >> >> This patch is part of the ongoing efforts to enabling >> -Wimplicit-fallthrough >> >> Signed-off-by: Gustavo A. R. Silva > > Sure, taking this to my queue for -next > Thanks, Dominique. :) -- Gustavo
[PATCH V3 1/6] misc/pvpanic: preparing for pvpanic driver framework
Preparing for pvpanic driver framework. Create a pvpanic driver
directory and move current driver file to new directory.
Signed-off-by: Peng Hao
---
drivers/misc/Kconfig | 9 +
drivers/misc/Makefile| 2 +-
drivers/misc/pvpanic/Kconfig | 7 +++
drivers/misc/pvpanic/Makefile| 5 +
drivers/misc/{ => pvpanic}/pvpanic.c | 0
5 files changed, 14 insertions(+), 9 deletions(-)
create mode 100644 drivers/misc/pvpanic/Kconfig
create mode 100644 drivers/misc/pvpanic/Makefile
rename drivers/misc/{ => pvpanic}/pvpanic.c (100%)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f417b06..aa3a805 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -513,14 +513,7 @@ config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
-config PVPANIC
- tristate "pvpanic device support"
- depends on HAS_IOMEM && (ACPI || OF)
- help
- This driver provides support for the pvpanic device. pvpanic is
- a paravirtualized device provided by QEMU; it lets a virtual machine
- (guest) communicate panic events to the host.
-
+source "drivers/misc/pvpanic/Kconfig"
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e39ccbb..cfe20b3 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -58,4 +58,4 @@ obj-$(CONFIG_ASPEED_LPC_SNOOP)+= aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
obj-y += cardreader/
-obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-$(CONFIG_PVPANIC) += pvpanic/
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
new file mode 100644
index 000..3e612c6
--- /dev/null
+++ b/drivers/misc/pvpanic/Kconfig
@@ -0,0 +1,7 @@
+config PVPANIC
+ tristate "pvpanic device support"
+ depends on HAS_IOMEM && (ACPI || OF)
+ help
+ This driver provides support for the pvpanic device. pvpanic is
+ a paravirtualized device provided by QEMU; it lets a virtual machine
+ (guest) communicate panic events to the host.
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
new file mode 100644
index 000..6394224
--- /dev/null
+++ b/drivers/misc/pvpanic/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (c) 2018 ZTE Ltd.
+
+obj-$(CONFIG_PVPANIC)+= pvpanic.o
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
similarity index 100%
rename from drivers/misc/pvpanic.c
rename to drivers/misc/pvpanic/pvpanic.c
--
1.8.3.1
[PATCH V3 3/6] misc/pvpanic: add API for pvpanic driver framework
Add pvpanic_add/remove_device API. Follow-up patches will use them to
add/remove specific drivers into framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/pvpanic.c | 32
drivers/misc/pvpanic/pvpanic.h | 14 ++
2 files changed, 46 insertions(+)
create mode 100644 drivers/misc/pvpanic/pvpanic.h
diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
index 227ab4e..f842ee4 100644
--- a/drivers/misc/pvpanic/pvpanic.c
+++ b/drivers/misc/pvpanic/pvpanic.c
@@ -48,6 +48,38 @@
.priority = 1, /* let this called before broken drm_fb_helper */
};
+int pvpanic_add_device(struct device *dev, struct resource *res)
+{
+ struct platform_device *pdev;
+ int ret;
+
+ pdev = platform_device_alloc("pvpanic", -1);
+ if (!pdev)
+ return -ENOMEM;
+
+ pdev->dev.parent = dev;
+
+ ret = platform_device_add_resources(pdev, res, 1);
+ if (ret)
+ goto err;
+
+ ret = platform_device_add(pdev);
+ if (ret)
+ goto err;
+ pvpanic_data.pdev = pdev;
+
+ return 0;
+err:
+ platform_device_put(pdev);
+ return -1;
+}
+
+void pvpanic_remove_device(void)
+{
+ platform_device_unregister(pvpanic_data.pdev);
+ pvpanic_data.pdev = NULL;
+}
+
static int pvpanic_platform_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
diff --git a/drivers/misc/pvpanic/pvpanic.h b/drivers/misc/pvpanic/pvpanic.h
new file mode 100644
index 000..a72ca59
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic.h
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* pvpanic driver framework header file
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ * Author: Peng Hao
+ */
+
+#ifndef __DRIVERS_MISC_PVPANIC_H
+#define __DRIVERS_MISC_PVPANIC_H
+
+extern int pvpanic_add_device(struct device *dev, struct resource *res);
+extern void pvpanic_remove_device(void);
+
+#endif
--
1.8.3.1
[PATCH V3 5/6] misc/pvpanic: add pvpanic mmio driver
Make pvpanic mmio driver as seperate file and modify code
in order to adapt the framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/Kconfig | 4 +++
drivers/misc/pvpanic/Makefile | 1 +
drivers/misc/pvpanic/pvpanic-of.c | 53 +++
3 files changed, 58 insertions(+)
create mode 100644 drivers/misc/pvpanic/pvpanic-of.c
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
index d274130..47f8709 100644
--- a/drivers/misc/pvpanic/Kconfig
+++ b/drivers/misc/pvpanic/Kconfig
@@ -13,4 +13,8 @@ config PVPANIC_ACPI
depends on ACPI
default PVPANIC
+config PVPANIC_OF
+ tristate "pvpanic mmio driver"
+ depends on OF
+
endif
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
index c5b73ca..63ef0db 100644
--- a/drivers/misc/pvpanic/Makefile
+++ b/drivers/misc/pvpanic/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_PVPANIC)+= pvpanic.o
obj-$(CONFIG_PVPANIC_ACPI) += pvpanic-acpi.o
+obj-$(CONFIG_PVPANIC_OF)+= pvpanic-of.o
diff --git a/drivers/misc/pvpanic/pvpanic-of.c
b/drivers/misc/pvpanic/pvpanic-of.c
new file mode 100644
index 000..73ca5f3
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic-of.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * pvpanic of driver.
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ * Author: Peng Hao
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pvpanic.h"
+
+static int pvpanic_mmio_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ ret = pvpanic_add_device(&pdev->dev, res);
+ if (ret)
+ return -ENODEV;
+
+ return 0;
+}
+
+static int pvpanic_mmio_remove(struct platform_device *pdev)
+{
+ pvpanic_remove_device();
+ return 0;
+}
+
+static const struct of_device_id pvpanic_mmio_match[] = {
+ { .compatible = "qemu,pvpanic-mmio", },
+ {}
+};
+
+static struct platform_driver pvpanic_mmio_driver = {
+ .driver = {
+ .name = "pvpanic-mmio",
+ .of_match_table = pvpanic_mmio_match,
+ },
+ .probe = pvpanic_mmio_probe,
+ .remove = pvpanic_mmio_remove,
+};
+
+module_platform_driver(pvpanic_mmio_driver);
--
1.8.3.1
[PATCH V3 4/6] misc/pvpanic: add pvpanic acpi driver
Make pvpanic acpi driver as seperate file and modify code
in order to adapt the framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/Kconfig| 9 +
drivers/misc/pvpanic/Makefile | 1 +
drivers/misc/pvpanic/pvpanic-acpi.c | 77 +
3 files changed, 87 insertions(+)
create mode 100644 drivers/misc/pvpanic/pvpanic-acpi.c
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
index 3e612c6..d274130 100644
--- a/drivers/misc/pvpanic/Kconfig
+++ b/drivers/misc/pvpanic/Kconfig
@@ -5,3 +5,12 @@ config PVPANIC
This driver provides support for the pvpanic device. pvpanic is
a paravirtualized device provided by QEMU; it lets a virtual machine
(guest) communicate panic events to the host.
+
+if PVPANIC
+
+config PVPANIC_ACPI
+ tristate "pvpanic acpi driver"
+ depends on ACPI
+ default PVPANIC
+
+endif
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
index 6394224..c5b73ca 100644
--- a/drivers/misc/pvpanic/Makefile
+++ b/drivers/misc/pvpanic/Makefile
@@ -3,3 +3,4 @@
# Copyright (c) 2018 ZTE Ltd.
obj-$(CONFIG_PVPANIC)+= pvpanic.o
+obj-$(CONFIG_PVPANIC_ACPI) += pvpanic-acpi.o
diff --git a/drivers/misc/pvpanic/pvpanic-acpi.c
b/drivers/misc/pvpanic/pvpanic-acpi.c
new file mode 100644
index 000..a6153fa
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic-acpi.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * pvpanic acpi driver.
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ * Author: Peng Hao
+ */
+#include
+#include
+#include
+#include
+#include "pvpanic.h"
+
+static int pvpanic_add(struct acpi_device *device);
+static int pvpanic_remove(struct acpi_device *device);
+
+static const struct acpi_device_id pvpanic_device_ids[] = {
+ { "QEMU0001", 0 },
+ { "", 0 }
+};
+MODULE_DEVICE_TABLE(acpi, pvpanic_device_ids);
+
+static struct acpi_driver pvpanic_driver = {
+ .name = "pvpanic",
+ .class ="QEMU",
+ .ids = pvpanic_device_ids,
+ .ops = {
+ .add = pvpanic_add,
+ .remove = pvpanic_remove,
+ },
+ .owner =THIS_MODULE,
+};
+
+static acpi_status
+pvpanic_walk_resources(struct acpi_resource *res, void *context)
+{
+ struct resource r;
+ int ret = 0;
+ struct device *dev = context;
+
+ memset(&r, 0, sizeof(r));
+ if (acpi_dev_resource_io(res, &r) || acpi_dev_resource_memory(res, &r))
+ ret = pvpanic_add_device(dev, &r);
+
+ if (!ret)
+ return AE_OK;
+
+ return AE_ERROR;
+}
+static int pvpanic_add(struct acpi_device *device)
+{
+ int ret;
+ acpi_status status;
+
+ ret = acpi_bus_get_status(device);
+ if (ret < 0)
+ return ret;
+
+ if (!device->status.enabled || !device->status.functional)
+ return -ENODEV;
+
+ status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+pvpanic_walk_resources, &device->dev);
+
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+
+ return 0;
+}
+
+static int pvpanic_remove(struct acpi_device *device)
+{
+ pvpanic_remove_device();
+ return 0;
+}
+
+module_acpi_driver(pvpanic_driver);
--
1.8.3.1
Re: [PATCH net-next] 9p: mark expected switch fall-through
Gustavo A. R. Silva wrote on Wed, Jan 23, 2019: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > This patch fixes the following warning: > > net/9p/trans_xen.c:514:6: warning: this statement may fall through > [-Wimplicit-fallthrough=] > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > This patch is part of the ongoing efforts to enabling > -Wimplicit-fallthrough > > Signed-off-by: Gustavo A. R. Silva Sure, taking this to my queue for -next -- Dominique
[PATCH V3 6/6] misc/pvpanic: add new pvpanic pci driver
Add new pvpanic pci driver to pvpanic driver framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/Kconfig | 5
drivers/misc/pvpanic/Makefile | 1 +
drivers/misc/pvpanic/pvpanic-pci.c | 56 ++
3 files changed, 62 insertions(+)
create mode 100644 drivers/misc/pvpanic/pvpanic-pci.c
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
index 47f8709..46b6e05 100644
--- a/drivers/misc/pvpanic/Kconfig
+++ b/drivers/misc/pvpanic/Kconfig
@@ -17,4 +17,9 @@ config PVPANIC_OF
tristate "pvpanic mmio driver"
depends on OF
+config PVPANIC_PCI
+ tristate "pvpanic pci driver"
+ depends on PCI
+ default PVPANIC
+
endif
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
index 63ef0db..7c71f85 100644
--- a/drivers/misc/pvpanic/Makefile
+++ b/drivers/misc/pvpanic/Makefile
@@ -5,3 +5,4 @@
obj-$(CONFIG_PVPANIC)+= pvpanic.o
obj-$(CONFIG_PVPANIC_ACPI) += pvpanic-acpi.o
obj-$(CONFIG_PVPANIC_OF)+= pvpanic-of.o
+obj-$(CONFIG_PVPANIC_PCI) += pvpanic-pci.o
diff --git a/drivers/misc/pvpanic/pvpanic-pci.c
b/drivers/misc/pvpanic/pvpanic-pci.c
new file mode 100644
index 000..b4f453b
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic-pci.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * pvpanic acpi driver.
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ * Author: Peng Hao
+ */
+
+#include
+#include
+#include
+#include
+#include "pvpanic.h"
+
+#define PCI_VENDOR_ID_REDHAT 0x1b36
+#define PCI_DEVICE_ID_REDHAT_PVPANIC 0x0101
+
+static const struct pci_device_id pvpanic_pci_id_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PVPANIC),},
+ {}
+};
+
+static int pvpanic_pci_probe(struct pci_dev *pdev,
+const struct pci_device_id *ent)
+{
+ int ret;
+ struct resource res;
+
+ ret = pcim_enable_device(pdev);
+ if (ret < 0)
+ return ret;
+
+ memset(&res, 0, sizeof(res));
+ res.start = pci_resource_start(pdev, 0);
+ res.end = pci_resource_end(pdev, 0);
+ res.flags = IORESOURCE_MEM;
+ ret = pvpanic_add_device(&pdev->dev, &res);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static void pvpanic_pci_remove(struct pci_dev *pdev)
+{
+ pvpanic_remove_device();
+}
+
+static struct pci_driver pvpanic_pci_driver = {
+ .name = "pvpanic-pci",
+ .id_table = pvpanic_pci_id_tbl,
+ .probe =pvpanic_pci_probe,
+ .remove = pvpanic_pci_remove,
+};
+
+module_pci_driver(pvpanic_pci_driver);
--
1.8.3.1
[PATCH V3 0/6] add pvpanic driver framework
QEMU community requires additional PCI devices to simulate PVPANIC devices so that some architectures can not occupy precious less than 4G of memory space. Previously, I added PCI driver directly to the original version of the driver, which made the whole driver file look a bit cluttered. So Andy Shevchenko suggests: "I would recommend to split it in a way how it's done for ChipIdea USB driver, for example. (drivers/usb/chipidea if I'm not mistaken)". v2 ---> v3 : add change infomation. v1 ---> v2 : add patch to descript the whole patch series. modify text infomation from patch_0002 to patch_0006. modify "SPDX-License-Identifier: GPL-2.0-or-later" to "SPDX-License-Identifier: GPL-2.0+" Peng Hao (6): misc/pvpanic: preparing for pvpanic driver framework misc/pvpanic: Add pvpanic driver framework misc/pvpanic: add API for pvpanic driver framework misc/pvpanic: add pvpanic acpi driver misc/pvpanic: add pvpanic mmio driver misc/pvpanic: add pvpanic pci driver drivers/misc/Kconfig| 9 +- drivers/misc/Makefile | 2 +- drivers/misc/pvpanic.c | 192 drivers/misc/pvpanic/Kconfig| 25 + drivers/misc/pvpanic/Makefile | 8 ++ drivers/misc/pvpanic/pvpanic-acpi.c | 77 +++ drivers/misc/pvpanic/pvpanic-of.c | 53 ++ drivers/misc/pvpanic/pvpanic-pci.c | 56 +++ drivers/misc/pvpanic/pvpanic.c | 131 drivers/misc/pvpanic/pvpanic.h | 14 +++ 10 files changed, 366 insertions(+), 201 deletions(-) delete mode 100644 drivers/misc/pvpanic.c create mode 100644 drivers/misc/pvpanic/Kconfig create mode 100644 drivers/misc/pvpanic/Makefile create mode 100644 drivers/misc/pvpanic/pvpanic-acpi.c create mode 100644 drivers/misc/pvpanic/pvpanic-of.c create mode 100644 drivers/misc/pvpanic/pvpanic-pci.c create mode 100644 drivers/misc/pvpanic/pvpanic.c create mode 100644 drivers/misc/pvpanic/pvpanic.h -- 1.8.3.1
Re: linux-next: Fixes tags need some work in the dma-mapping-fixes tree
On Wed, Jan 23, 2019 at 07:47:47AM +1100, Stephen Rothwell wrote:
> Hi Christoph,
>
> In commit
>
> 702e8ed37bed ("arm64/xen: fix xen-swiotlb cache flushing")
>
> Fixes tag
>
> Fixes: 356da6d0cd ("dma-mapping: bypass indirect calls for dma-direct")
>
> has these problem(s):
>
> - SHA1 should be at least 12 digits long
When did we decide on that? As far as I know it was bumped to 10
a while ago. 12 basically makes the line even more unreadable.
> In commit
>
> 8218a55b6b91 ("sbitmap: Protect swap_lock from hardirq")
>
> Fixes tag
>
> Fixes: ab53dcfb3e7b ("sbitmap: Protect swap_lock from hardirq")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> This later patch appears to already be in Linus' tree as commit
> fe76fc6aaf53 (also with an incorrect Fixes tag :-()
That commit is not from the dma-mapping tree..
[PATCH v2] jffs2: safely remove obsolete dirent from the f->dents list
We may delete a bunch of directory entries, operating such as:
getdents(), unlink(), getdents()..., until the end of the directory.
jffs2 handles f_pos on the directory merely as the position on the
f->dents list. So, the next getdents() may skip some entries
before f_pos, if we remove some entries from the list between two
getdents(), resulting in some entries of the directory cannot be deleted.
Commit 15953580e79b is introduced to resolve this bug by not
removing delete entries from the list immediately.
However, when CONFIG_JFFS2_SUMMARY is not set, it can cause the
following issues:
* 'deletion' dirents is always in the f->dents list, wasting memory
resource. For example:
There is a file named 'file1'. Then we rename it:
mv file1 file2;
mv file2 file3;
...
mv file9 file100
All of file1~file100 dirents always in the f->dents list.
* Though, the list we're traversing is already ordered by CRC,
it could waste much CPU time when the list is very long.
To fix, we define two variables in struct jffs2_inode_info: nr_dir_opening,
obsolete_count, and two new functions: jffs2_dir_open(), jffs2_dir_release().
When open a directory, jffs2_dir_open() will increase nr_dir_opening,
which will be decreased by jffs2_dir_release(). if the value is 0,
it means nobody open the dir and nobody in getdents()/seek() semantics.
Thus, we can remove all obsolete dirent from the list.
When delete a file, jffs2_do_unlink() can remove the dirent directly if
nobody open the directory(i.e. nr_dir_opending == 0). Otherwise, it just
increase obsolete_count, denoting obsolete dirent count of the list.
Fixes: 15953580e79b ("[JFFS2] Improve getdents vs. f_pos handling on NOR
flash.")
Signed-off-by: Yufen Yu
---
fs/jffs2/dir.c | 49 ++
fs/jffs2/jffs2_fs_i.h | 7 +++
fs/jffs2/super.c | 4
fs/jffs2/write.c | 30 +++-
include/uapi/linux/jffs2.h | 4
5 files changed, 85 insertions(+), 9 deletions(-)
diff --git a/fs/jffs2/dir.c b/fs/jffs2/dir.c
index f20cff1194bb..aed872dcd0ca 100644
--- a/fs/jffs2/dir.c
+++ b/fs/jffs2/dir.c
@@ -37,6 +37,8 @@ static int jffs2_mknod (struct inode *,struct dentry
*,umode_t,dev_t);
static int jffs2_rename (struct inode *, struct dentry *,
struct inode *, struct dentry *,
unsigned int);
+static int jffs2_dir_release (struct inode *, struct file *);
+static int jffs2_dir_open (struct inode *, struct file *);
const struct file_operations jffs2_dir_operations =
{
@@ -45,6 +47,8 @@ const struct file_operations jffs2_dir_operations =
.unlocked_ioctl=jffs2_ioctl,
.fsync =jffs2_fsync,
.llseek = generic_file_llseek,
+ .open = jffs2_dir_open,
+ .release = jffs2_dir_release,
};
@@ -865,3 +869,48 @@ static int jffs2_rename (struct inode *old_dir_i, struct
dentry *old_dentry,
return 0;
}
+static int jffs2_dir_open(struct inode *dir_i, struct file *filp)
+{
+#ifndef CONFIG_JFFS2_SUMMARY
+ struct jffs2_inode_info *dir_f = JFFS2_INODE_INFO(dir_i);
+ atomic_inc(&dir_f->nr_dir_opening);
+#endif
+
+ return 0;
+}
+
+static int jffs2_dir_release(struct inode *dir_i, struct file *filp)
+{
+#ifndef CONFIG_JFFS2_SUMMARY
+ struct jffs2_inode_info *dir_f = JFFS2_INODE_INFO(dir_i);
+
+ BUG_ON(atomic_read(&dir_f->nr_dir_opening) <= 0);
+
+ mutex_lock(&dir_f->sem);
+ /* jffs2_dir_open may increase nr_dir_opening after
+* atomic_dec_and_test() returning true.
+* However, it cannot traverse the list until hold
+* mutex dir_f->sem lock, so that we can go on
+* removing.*/
+ if (atomic_dec_and_test(&dir_f->nr_dir_opening) &&
+ dir_f->obsolete_count > JFFS2_OBS_DIRENT_LIMIT) {
+ struct jffs2_full_dirent **prev = &dir_f->dents;
+
+ /* remove all obsolete dirent from the list, which
+* can save memory space and reduce CPU time for
+* traverse the list */
+ while(*prev) {
+ if ((*prev)->raw == NULL && (*prev)->ino == 0) {
+ struct jffs2_full_dirent *this = *prev;
+ *prev = this->next;
+ jffs2_free_full_dirent(this);
+ } else
+ prev = &((*prev)->next);
+ }
+ dir_f->obsolete_count = 0;
+ }
+ mutex_unlock(&dir_f->sem);
+#endif
+
+ return 0;
+}
diff --git a/fs/jffs2/jffs2_fs_i.h b/fs/jffs2/jffs2_fs_i.h
index 2e4a86763c07..a4da25d16cb4 100644
--- a/fs/jffs2/jffs2_fs_i.h
+++ b/fs/jffs2/jffs2_fs_i.h
@@ -50,6 +50,13 @@ struct jffs2_inode_info {
uint16_t flags;
uint8_t usercompr;
+
+ /* obsolete dirent count in the list of 'dents' *
Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake
> On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas wrote:
>
> On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
>> There are some e1000e devices can only be woken up from D3 one time, by
>> plugging ethernet cable. Subsequent cable plugging does set PME bit
>> correctly, but it still doesn't get woken up.
>>
>> Since e1000e connects to the root complex directly, we rely on ACPI to
>> wake it up. In this case, the GPE from _PRW only works once and stops
>> working after that.
>>
>> So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy
>> platform firmwares that have unreliable GPE wake.
>
> This quirk applies to all 0x15bb (E1000_DEV_ID_PCH_CNP_I219_LM7) and
> 0x15bd (E1000_DEV_ID_PCH_CNP_I219_LM6) devices. The e1000e driver
> claims about a zillion different device IDs.
>
> I would be surprised if these two devices are defective but all the
> others work correctly. Could it be that there is a problem with the
> wiring on this particular motherboard or with the ACPI _PRW methods
> (or the way Linux interprets them) in this firmware?
If this is a motherboard issue or platform specific, do you prefer to use
DMI matches here?
As for _PRW, it’s shared by USB controller, Audio controller and ethernet.
Only the ethernet (e1000e) has this issue.
When this issue happens, the e1000e doesn’t get woken up by ethernet cable
plugging, but inserting a USB device or plugging audio jack can wake up all
three devices. So I think Linux interprets ACPI correctly here.
Their _PRW here:
USB controller:
Scope (_SB.PCI0)
{
Device (XDCI)
{
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x6D, 0x04))
}
Audio controller:
Scope (_SB.PCI0)
{
Device (HDAS)
{
…
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x6D, 0x04))
}
Ethernet controller:
Scope (_SB.PCI0)
{
Device (GLAN)
{
…
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x6D, 0x04))
}
}
}
>
> Would you mind attaching a complete dmesg log and "sudo lspci -vvv"
> output to the bugzilla, please?
Sure.
Kai-Heng
>
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/pci/pci-acpi.c | 2 +-
>> drivers/pci/quirks.c | 8
>> include/linux/pci.h| 1 +
>> 3 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
>> index e1949f7efd9c..184e2fc8a294 100644
>> --- a/drivers/pci/pci-acpi.c
>> +++ b/drivers/pci/pci-acpi.c
>> @@ -430,7 +430,7 @@ static void pci_acpi_wake_dev(struct
>> acpi_device_wakeup_context *context)
>>
>> pci_dev = to_pci_dev(context->dev);
>>
>> -if (pci_dev->pme_poll)
>> +if (pci_dev->pme_poll && !pci_dev->unreliable_acpi_wake)
>> pci_dev->pme_poll = false;
>>
>> if (pci_dev->current_state == PCI_D3cold) {
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index b0a413f3f7ca..ed4863496fa8 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -4948,6 +4948,14 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMD,
>> PCI_ANY_ID,
>> DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
>>PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);
>>
>> +static void quirk_unreliable_acpi_wake(struct pci_dev *pdev)
>> +{
>> +pci_info(pdev, "ACPI Wake unreliable, always poll PME\n");
>> +pdev->unreliable_acpi_wake = 1;
>> +}
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bb,
>> quirk_unreliable_acpi_wake);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bd,
>> quirk_unreliable_acpi_wake);
>> +
>> /*
>> * Some IDT switches incorrectly flag an ACS Source Validation error on
>> * completions for con
[PATCH net-next] 9p: mark expected switch fall-through
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: net/9p/trans_xen.c:514:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough Signed-off-by: Gustavo A. R. Silva --- net/9p/trans_xen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index e2fbf3677b9b..29420ebb8f07 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -513,7 +513,7 @@ static void xen_9pfs_front_changed(struct xenbus_device *dev, case XenbusStateClosed: if (dev->state == XenbusStateClosed) break; - /* Missed the backend's CLOSING state -- fallthrough */ + /* fall through - Missed the backend's CLOSING state */ case XenbusStateClosing: xenbus_frontend_closed(dev); break; -- 2.20.1
Re: [PATCH] opp: no need to check return value of debugfs_create functions
On 22-01-19, 16:21, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Viresh Kumar
> Cc: Nishanth Menon
> Cc: Stephen Boyd
> Cc: linux...@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/opp/core.c| 10 +---
> drivers/opp/debugfs.c | 109 +++---
> drivers/opp/opp.h | 15 +++---
> 3 files changed, 37 insertions(+), 97 deletions(-)
Applied with following changes. Thanks Greg.
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 91d15c58eae1..d455b84cce5a 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -793,7 +793,6 @@ static struct opp_device *_add_opp_dev_unlocked(const
struct device *dev,
struct opp_table *opp_table)
{
struct opp_device *opp_dev;
- int ret;
opp_dev = kzalloc(sizeof(*opp_dev), GFP_KERNEL);
if (!opp_dev)
diff --git a/drivers/opp/debugfs.c b/drivers/opp/debugfs.c
index baac1ae33c55..a1c57fe14de4 100644
--- a/drivers/opp/debugfs.c
+++ b/drivers/opp/debugfs.c
@@ -93,7 +93,8 @@ void opp_debug_create_one(struct dev_pm_opp *opp, struct
opp_table *opp_table)
debugfs_create_bool("suspend", S_IRUGO, d, &opp->suspend);
debugfs_create_u32("performance_state", S_IRUGO, d, &opp->pstate);
debugfs_create_ulong("rate_hz", S_IRUGO, d, &opp->rate);
- debugfs_create_ulong("clock_latency_ns", S_IRUGO, d,
&opp->clock_latency_ns);
+ debugfs_create_ulong("clock_latency_ns", S_IRUGO, d,
+&opp->clock_latency_ns);
opp_debug_create_supplies(opp, opp_table, d);
--
viresh
Re: [PATCH 4/6] spi: spi-geni-qcom: Add interconnect support
On 2019-01-23 01:59, Mark Brown wrote: On Tue, Jan 22, 2019 at 12:03:34PM +0530, Alok Chauhan wrote: Get the interconnect paths for SPI based Serial Engine device and vote accordingly based on maximum supported SPI frequency. Still not seeing anything except this patch here in my inbox - like I said what's the story with dependencies? I've added linux-spi mailing list to all the patches sent as part of this series. Not sure why you didn't get other patches. Today I've explicitly added you in all the patches. This change series basically enabled interconnect (as per bindings/interconnect/interconnect.txt) support in GENI QUPs based drivers so appropriate BW request can be put based on SE usages. here is my complete change series: https://lore.kernel.org/lkml/1548069703-26595-1-git-send-email-al...@codeaurora.org/ I hope I answer to your question properly. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,a Linux Foundation Collaborative Project
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On Tue, Jan 22, 2019 at 10:07:07PM +0100, Ard Biesheuvel wrote: > Yes, so much was clear. And the reason this breaks on some arm64 > systems is because > a) non-snooped PCIe TLP attributes may be ignored, and > b) non-x86 CPUs do not snoop the caches when accessing uncached mappings. > > I don't think there is actually any disagreement on this part. And I > think my patch is reasonable, only Christoph is objecting to it on the > grounds that drivers should not go around the DMA API and create > vmap()s of DMA pages with self chosen attributes. I object to it on various grounds. While the above is correct it really is a mid to long-term fix. But even in the short term your patch just maintains a random list of idefs in a random driver, pokes into the dma-mapping internals and lacks any comments in the code explaining on what is going on, leading to futher cargo culting. So it very clearly is not acceptable.
Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain
On Tue, Jan 22, 2019 at 11:59:31AM -0800, Stefano Stabellini wrote: > > if (!virtio_has_iommu_quirk(vdev)) > > return true; > > > > @@ -260,7 +262,7 @@ static bool vring_use_dma_api(struct virtio_device > > *vdev) > > * the DMA API if we're a Xen guest, which at least allows > > * all of the sensible Xen configurations to work correctly. > > */ > > - if (xen_domain()) > > + if (xen_domain() && !dma_dev->dma_mem) > > return true; > > > > return false; > > I can see you spotted a real issue, but this is not the right fix. We > just need something a bit more flexible than xen_domain(): there are > many kinds of Xen domains on different architectures, we basically want > to enable this (return true from vring_use_dma_api) only when the xen > swiotlb is meant to be used. Does the appended patch fix the issue you > have? The problem generally is the other way around - if dma_dev->dma_mem is set the device decription in the device tree explicitly requires using this memory, so we must _always_ use the DMA API. The problem is just that that rproc driver absuses the DMA API in horrible ways.
[PATCH net-next] tipc: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
net/tipc/link.c:1125:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
net/tipc/socket.c:736:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
net/tipc/socket.c:2418:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva
---
net/tipc/link.c | 2 +-
net/tipc/socket.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 2792a3cae682..ac306d17f8ad 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1126,7 +1126,7 @@ static bool tipc_data_input(struct tipc_link *l, struct
sk_buff *skb,
skb_queue_tail(mc_inputq, skb);
return true;
}
- /* else: fall through */
+ /* fall through */
case CONN_MANAGER:
skb_queue_tail(inputq, skb);
return true;
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 1217c90a363b..8fc5acd4820d 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -735,7 +735,7 @@ static __poll_t tipc_poll(struct file *file, struct socket
*sock,
case TIPC_CONNECTING:
if (!tsk->cong_link_cnt && !tsk_conn_cong(tsk))
revents |= EPOLLOUT;
- /* fall thru' */
+ /* fall through */
case TIPC_LISTEN:
if (!skb_queue_empty(&sk->sk_receive_queue))
revents |= EPOLLIN | EPOLLRDNORM;
@@ -2416,7 +2416,7 @@ static int tipc_connect(struct socket *sock, struct
sockaddr *dest,
* case is EINPROGRESS, rather than EALREADY.
*/
res = -EINPROGRESS;
- /* fall thru' */
+ /* fall through */
case TIPC_CONNECTING:
if (!timeout) {
if (previous == TIPC_CONNECTING)
--
2.20.1
Re: [PATCH v3] tty: moxa: Fix coding style issues
On Tue, Jan 22, 2019 at 05:30:55PM -0500, Antoine Robertson wrote: > Fix coding style issues That is really vague, you need to say exactly what type of coding style fixes you made here. And if you made more than one "type" of fix, then you need to break the patch up into a series, only doing one "type" of fix per patch. Yeah, that's a pain for when there are only tiny things that need to be changed, but that way it makes it easier for reviewers, and for fixing if it turns out any of your changes was not ok. I recommend, if you want to do coding style fixes, to do so in the drivers/staging/ part of the kernel. That area has a lot more work to be done and you don't end up doing tiny things like this. thanks, greg k-h
[PATCH -next] spi: bcm2835aux: remove unneeded NULL check of devm_clk_get
Fix a static code checker warning:
drivers/spi/spi-bcm2835aux.c:460
bcm2835aux_spi_probe() warn: passing zero to 'PTR_ERR'
In case of error, the function devm_clk_get() returns ERR_PTR()
and not returns NULL.
Signed-off-by: YueHaibing
---
drivers/spi/spi-bcm2835aux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index 671e374..f7e0548 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -456,7 +456,7 @@ static int bcm2835aux_spi_probe(struct platform_device
*pdev)
}
bs->clk = devm_clk_get(&pdev->dev, NULL);
- if ((!bs->clk) || (IS_ERR(bs->clk))) {
+ if (IS_ERR(bs->clk)) {
err = PTR_ERR(bs->clk);
dev_err(&pdev->dev, "could not get clk: %d\n", err);
goto out_master_put;
--
2.7.0
[PATCH v3 3/5] usb: host: Stops USB controller init if PLL fails to lock
From: Ramneek Mehresh
USB erratum-A006918 workaround tries to start internal PHY inside
uboot (when PLL fails to lock). However, if the workaround also
fails, then USB initialization is also stopped inside Linux.
Erratum-A006918 workaround failure creates "fsl,erratum_a006918"
node in device-tree. Presence of this node in device-tree is
used to stop USB controller initialization in Linux
Signed-off-by: Ramneek Mehresh
Signed-off-by: Suresh Gupta
Signed-off-by: Yinbo Zhu
---
drivers/usb/host/ehci-fsl.c |5 +
drivers/usb/host/fsl-mph-dr-of.c |4
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 8b0f3ed..e276067 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -236,6 +236,11 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
portsc |= PORT_PTS_PTW;
/* fall through */
case FSL_USB2_PHY_UTMI:
+ if (pdata->has_fsl_erratum_a006918) {
+ pr_warn("fsl-ehci: USB PHY clock invalid\n");
+ return -EINVAL;
+ }
+
case FSL_USB2_PHY_UTMI_DUAL:
/* PHY_CLK_VALID bit is de-featured from all controller
* versions below 2.4 and is to be checked only for
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 4f8b8a0..bdc8812 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -230,6 +230,10 @@ static int fsl_usb2_mph_dr_of_probe(struct platform_device
*ofdev)
else
pdata->has_fsl_erratum_14 = 0;
+ if (of_get_property(np, "fsl,erratum_a006918", NULL))
+ pdata->has_fsl_erratum_a006918 = 1;
+ else
+ pdata->has_fsl_erratum_a006918 = 0;
/*
* Determine whether phy_clk_valid needs to be checked
--
1.7.1
[PATCH v3 1/5] usb: fsl: Set USB_EN bit to select ULPI phy
From: Nikhil Badola Set USB_EN bit to select ULPI phy for USB controller version 2.5 Signed-off-by: Nikhil Badola Signed-off-by: Yinbo Zhu --- Change in v3: Code base already has patch[5/6], so remove it. drivers/usb/host/ehci-fsl.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index e3d0c1c..ea7e17b 100644 --- a/drivers/usb/host/ehci-fsl.c +++ b/drivers/usb/host/ehci-fsl.c @@ -122,6 +122,12 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev) tmp |= 0x4; iowrite32be(tmp, hcd->regs + FSL_SOC_USB_CTRL); } + + /* Set USB_EN bit to select ULPI phy for USB controller version 2.5 */ + if (pdata->controller_ver == FSL_USB_VER_2_5 && + pdata->phy_mode == FSL_USB2_PHY_ULPI) + iowrite32be(USB_CTRL_USB_EN, hcd->regs + FSL_SOC_USB_CTRL); + /* * Enable UTMI phy and program PTS field in UTMI mode before asserting * controller reset for USB Controller version 2.5 -- 1.7.1
[PATCH v3 2/5] usb: phy: Workaround for USB erratum-A005728
From: Suresh Gupta
PHY_CLK_VALID bit for UTMI PHY in USBDR does not set even
if PHY is providing valid clock. Workaround for this
involves resetting of PHY and check PHY_CLK_VALID bit
multiple times. If PHY_CLK_VALID bit is still not set even
after 5 retries, it would be safe to deaclare that PHY
clock is not available.
This erratum is applicable for USBDR less then ver 2.4.
Signed-off-by: Suresh Gupta
Signed-off-by: Yinbo Zhu
---
Change in v3:
replace in_be32 with ioread32be
drivers/usb/host/ehci-fsl.c | 37 ++---
drivers/usb/host/ehci-fsl.h |3 +++
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index ea7e17b..8b0f3ed 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -183,6 +183,17 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
return retval;
}
+static bool usb_phy_clk_valid(struct usb_hcd *hcd)
+{
+ void __iomem *non_ehci = hcd->regs;
+ bool ret = true;
+
+ if (!(ioread32be(non_ehci + FSL_SOC_USB_CTRL) & PHY_CLK_VALID))
+ ret = false;
+
+ return ret;
+}
+
static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
enum fsl_usb2_phy_modes phy_mode,
unsigned int port_offset)
@@ -226,6 +237,16 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
/* fall through */
case FSL_USB2_PHY_UTMI:
case FSL_USB2_PHY_UTMI_DUAL:
+ /* PHY_CLK_VALID bit is de-featured from all controller
+* versions below 2.4 and is to be checked only for
+* internal UTMI phy
+*/
+ if (pdata->controller_ver > FSL_USB_VER_2_4 &&
+ pdata->have_sysif_regs && !usb_phy_clk_valid(hcd)) {
+ pr_err("fsl-ehci: USB PHY clock invalid\n");
+ return -EINVAL;
+ }
+
if (pdata->have_sysif_regs && pdata->controller_ver) {
/* controller version 1.6 or above */
tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
@@ -249,17 +270,11 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
break;
}
- /*
-* check PHY_CLK_VALID to determine phy clock presence before writing
-* to portsc
-*/
- if (pdata->check_phy_clk_valid) {
- if (!(ioread32be(non_ehci + FSL_SOC_USB_CTRL) &
- PHY_CLK_VALID)) {
- dev_warn(hcd->self.controller,
-"USB PHY clock invalid\n");
- return -EINVAL;
- }
+ if (pdata->have_sysif_regs &&
+ pdata->controller_ver > FSL_USB_VER_1_6 &&
+ !usb_phy_clk_valid(hcd)) {
+ dev_warn(hcd->self.controller, "USB PHY clock invalid\n");
+ return -EINVAL;
}
ehci_writel(ehci, portsc, &ehci->regs->port_status[port_offset]);
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index cbc4220..9d18c6e 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -50,4 +50,7 @@
#define UTMI_PHY_EN (1<<9)
#define ULPI_PHY_CLK_SEL(1<<10)
#define PHY_CLK_VALID (1<<17)
+
+/* Retry count for checking UTMI PHY CLK validity */
+#define UTMI_PHY_CLK_VALID_CHK_RETRY 5
#endif /* _EHCI_FSL_H */
--
1.7.1
[PATCH v3 5/5] usb :fsl: Change string format for errata property
From: Nikhil Badola Remove USB errata checking code from driver. Applicability of erratum is retrieved by reading corresponding property in device tree. This property is written during device tree fixup. Signed-off-by: Ramneek Mehresh Signed-off-by: Nikhil Badola Signed-off-by: Yinbo Zhu --- drivers/usb/host/fsl-mph-dr-of.c | 14 -- 1 files changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c index bdc8812..ae8f60f 100644 --- a/drivers/usb/host/fsl-mph-dr-of.c +++ b/drivers/usb/host/fsl-mph-dr-of.c @@ -224,16 +224,10 @@ static int fsl_usb2_mph_dr_of_probe(struct platform_device *ofdev) of_property_read_bool(np, "fsl,usb-erratum-a005275"); pdata->has_fsl_erratum_a005697 = of_property_read_bool(np, "fsl,usb_erratum-a005697"); - - if (of_get_property(np, "fsl,usb_erratum_14", NULL)) - pdata->has_fsl_erratum_14 = 1; - else - pdata->has_fsl_erratum_14 = 0; - - if (of_get_property(np, "fsl,erratum_a006918", NULL)) - pdata->has_fsl_erratum_a006918 = 1; - else - pdata->has_fsl_erratum_a006918 = 0; + pdata->has_fsl_erratum_a006918 = + of_property_read_bool(np, "fsl,usb_erratum-a006918"); + pdata->has_fsl_erratum_14 = + of_property_read_bool(np, "fsl,usb_erratum-14"); /* * Determine whether phy_clk_valid needs to be checked -- 1.7.1
[PATCH v3 4/5] usb: linux/fsl_device: Add platform member has_fsl_erratum_a006918
From: Yinbo Zhu
This patch is to add member has_fsl_erratum_a006918 in platform data
Signed-off-by: Yinbo Zhu
---
include/linux/fsl_devices.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 5da56a6..4c613da 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -102,6 +102,7 @@ struct fsl_usb2_platform_data {
unsignedhas_fsl_erratum_14:1;
unsignedhas_fsl_erratum_a005275:1;
unsignedhas_fsl_erratum_a005697:1;
+ unsignedhas_fsl_erratum_a006918:1;
unsignedcheck_phy_clk_valid:1;
/* register save area for suspend/resume */
--
1.7.1
Re: kmemleak panic
On 1/23/2019 11:24 AM, Mike Rapoport wrote:
On Tue, Jan 22, 2019 at 03:12:54PM +0100, Marc Gonzalez wrote:
On 22/01/2019 15:02, Marc Gonzalez wrote:
On 21/01/2019 18:42, Mike Rapoport wrote:
If I understood correctly, the trouble comes from no-map range allocated in
early_init_dt_alloc_reserved_memory_arch().
There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(), but
memblock_remove() does not do kmemleak_free().
I think the best way is to replace __memblock_alloc_base() with
memblock_find_in_range(), e.g something like:
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0adcb1..6807a1cffe55 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -37,21 +37,16 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
*/
end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
align = !align ? SMP_CACHE_BYTES : align;
- base = __memblock_alloc_base(size, align, end);
+ base = memblock_find_in_range(size, align, start, end);
if (!base)
return -ENOMEM;
- /*
-* Check if the allocated region fits in to start..end window
-*/
- if (base < start) {
- memblock_free(base, size);
- return -ENOMEM;
- }
-
*res_base = base;
if (nomap)
return memblock_remove(base, size);
+ else
+ return memblock_reserve(base, size);
+
return 0;
}
Your patch solves the issue. \o/
Great :)
[ Add nvidia devs, but drop schowd...@nvidia.com ]
Resending it as a formal patch now, I took a liberty to add your Tested-by.
From a847ca684db29a3c09e4dd2a8a008b35cf36e52f Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Wed, 23 Jan 2019 07:38:50 +0200
Subject: [PATCH] of: fix kmemleak crash caused by imbalance in early memory
reservation
Marc Gonzalez reported the following kmemleak crash:
Unable to handle kernel paging request at virtual address ffc021e0
Mem abort info:
ESR = 0x9606
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0006
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
[ffc021e0] pgd=00017e3ba803, pud=00017e3ba803,
pmd=
Internal error: Oops: 9606 [#1] PREEMPT SMP
Modules linked in:
CPU: 6 PID: 523 Comm: kmemleak Tainted: G S W 5.0.0-rc1 #13
Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
pstate: 8085 (Nzcv daIf -PAN -UAO)
pc : scan_block+0x70/0x190
lr : scan_block+0x6c/0x190
sp : ff8012e8bd20
x29: ff8012e8bd20 x28: ffc0fdbaf018
x27: ffc02200 x26: 0080
x25: ff8011aadf70 x24: ffc0f8cc8000
x23: ff8010dc8000 x22: ff8010dc8830
x21: ffc021e00ff9 x20: ffc0f8cc8050
x19: ffc021e0 x18: 2409
x17: 0200 x16:
x15: ff8010e14dd8 x14: 2406
x13: 4c4dd0c6 x12: ffc0f77dad58
x11: 0001 x10: ff8010d9e688
x9 : ff8010d9f000 x8 : ff8010d9e688
x7 : 0002 x6 :
x5 : ff8011511c20 x4 : 26d1
x3 : ff8010e14d88 x2 : 5b36396f4e7d4000
x1 : 00208040 x0 :
Process kmemleak (pid: 523, stack limit = 0x(ptrval))
Call trace:
scan_block+0x70/0x190
scan_gray_list+0x108/0x1c0
kmemleak_scan+0x33c/0x7c0
kmemleak_scan_thread+0x98/0xf0
kthread+0x11c/0x120
ret_from_fork+0x10/0x1c
Code: f9000fb4 d503201f 97d2 35000580 (f9400260)
---[ end trace 176d6ed9d86a0c33 ]---
note: kmemleak[523] exited with preempt_count 2
The crash happens when a no-map area is allocated in
early_init_dt_alloc_reserved_memory_arch(). The allocated region is
registered with kmemleak, but it is then removed from memblock using
memblock_remove() that is not kmemleak-aware.
Replacing __memblock_alloc_base() with memblock_find_in_range() makes sure
that the allocated memory is not added to kmemleak and then
memblock_remove()'ing this memory is safe.
As a bonus, since memblock_find_in_range() ensures the allocation in the
specified range, the bounds check can be removed.
Signed-off-by: Mike Rapoport
Tested-by: Marc Gonzalez
---
drivers/of/of_reserved_mem.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0adcb1..6807a1cffe55 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -37,21 +37,16 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
*/
end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
align = !align ? SMP_CACHE_BYTES : align;
- base = __memblock_alloc_base(size, align, end);
+ base = memblock_find_in_range(size, align, start, end);
if (!base)
ret
[PATCH][next] cfg80211: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
net/wireless/wext-compat.c:1327:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
net/wireless/wext-compat.c:1341:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva
---
net/wireless/wext-compat.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 06943d9c9835..d522787c7354 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -1337,6 +1337,7 @@ static struct iw_statistics
*cfg80211_wireless_stats(struct net_device *dev)
wstats.qual.qual = sig + 110;
break;
}
+ /* fall through */
case CFG80211_SIGNAL_TYPE_UNSPEC:
if (sinfo.filled & BIT_ULL(NL80211_STA_INFO_SIGNAL)) {
wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED;
@@ -1345,6 +1346,7 @@ static struct iw_statistics
*cfg80211_wireless_stats(struct net_device *dev)
wstats.qual.qual = sinfo.signal;
break;
}
+ /* fall through */
default:
wstats.qual.updated |= IW_QUAL_LEVEL_INVALID;
wstats.qual.updated |= IW_QUAL_QUAL_INVALID;
--
2.20.1
Re: [PATCH 2/6] soc: qcom: Add wrapper to support for Interconnect path
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
Add the wrapper to support for interconnect path voting
from GENI QUP. This wrapper provides the functionalities
to individual Serial Engine device to get the interconnect
path and to vote for bandwidth based on their need.
This wrapper maintains bandwidth votes from each Serial Engine
and send the aggregated vote from GENI QUP to interconnect
framework.
Signed-off-by: Alok Chauhan
---
drivers/soc/qcom/qcom-geni-se.c | 129
include/linux/qcom-geni-se.h| 11
2 files changed, 140 insertions(+)
diff --git a/drivers/soc/qcom/qcom-geni-se.c
b/drivers/soc/qcom/qcom-geni-se.c
index 6b8ef01..1d8dcb1 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/**
* DOC: Overview
@@ -84,11 +85,21 @@
* @dev: Device pointer of the QUP wrapper core
* @base: Base address of this instance of QUP wrapper core
* @ahb_clks: Handle to the primary & secondary AHB clocks
+ * @icc_path: Array of interconnect path handles
+ * @geni_wrapper_lock: Lock to protect the bus bandwidth request
+ * @cur_avg_bw:Current Bus Average BW request value from GENI
QUP
+ * @cur_peak_bw: Current Bus Peak BW request value from GENI QUP
+ * @peak_bw_list_head: Sorted resource list based on peak bus BW
*/
struct geni_wrapper {
struct device *dev;
void __iomem *base;
struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
+ struct icc_path *icc_path[2];
+ struct mutex geni_wrapper_lock;
+ u32 cur_avg_bw;
+ u32 cur_peak_bw;
+ struct list_head peak_bw_list_head;
};
#define QUP_HW_VER_REG 0x4
@@ -440,6 +451,71 @@ static void geni_se_clks_off(struct geni_se *se)
}
/**
+ * geni_icc_update_bw() - Request to update bw vote on an interconnect
path
+ * @se:Pointer to the concerned serial engine.
+ * @update:Flag to update bw vote.
+ *
+ * This function is used to request set bw vote on interconnect path
handle.
+ */
+void geni_icc_update_bw(struct geni_se *se, bool update)
+{
+ struct geni_se *temp = NULL;
+ struct list_head *ins_list_head;
+ struct geni_wrapper *wrapper;
+
+ mutex_lock(&se->wrapper->geni_wrapper_lock);
+
+ wrapper = se->wrapper;
+
+ if (update) {
+ wrapper->cur_avg_bw += se->avg_bw;
+ ins_list_head = &wrapper->peak_bw_list_head;
+ list_for_each_entry(temp, &wrapper->peak_bw_list_head,
+ peak_bw_list) {
+ if (temp->peak_bw < se->peak_bw)
+ break;
+ ins_list_head = &temp->peak_bw_list;
+ }
+
+ list_add(&se->peak_bw_list, ins_list_head);
+
+ if (ins_list_head == &wrapper->peak_bw_list_head)
+ wrapper->cur_peak_bw = se->peak_bw;
+ } else {
+ if (unlikely(list_empty(&se->peak_bw_list))) {
+ mutex_unlock(&wrapper->geni_wrapper_lock);
+ return;
+ }
+
+ wrapper->cur_avg_bw -= se->avg_bw;
+
+ list_del_init(&se->peak_bw_list);
+ temp = list_first_entry_or_null(&wrapper->peak_bw_list_head,
+ struct geni_se, peak_bw_list);
+ if (temp && temp->peak_bw != wrapper->cur_peak_bw)
+ wrapper->cur_peak_bw = temp->peak_bw;
+ else if (!temp && wrapper->cur_peak_bw)
+ wrapper->cur_peak_bw = 0;
+ }
+
+ /*
+* This bw vote is to enable internal QUP core clock as well as to
+* enable path towards memory.
+*/
+ icc_set_bw(wrapper->icc_path[0], wrapper->cur_avg_bw,
+ wrapper->cur_peak_bw);
+
+ /*
+* This is just register configuration path so doesn't need avg bw.
+* Set only peak bw to enable this path.
+*/
+ icc_set_bw(wrapper->icc_path[1], 0, wrapper->cur_peak_bw);
+
+ mutex_unlock(&wrapper->geni_wrapper_lock);
+}
+EXPORT_SYMBOL(geni_icc_update_bw);
+
+/**
* geni_se_resources_off() - Turn off resources associated with the
serial
* engine
* @se:Pointer to the concerned serial engine.
@@ -707,6 +783,47 @@ void geni_se_rx_dma_unprep(struct geni_se *se,
dma_addr_t iova, size_t len)
}
EXPORT_SYMBOL(geni_se_rx_dma_unprep);
+/**
+ * geni_interconnect_init() - Request to get interconnect path handle
+ * @se:Pointer to the concerned serial engine.
+ *
+ * This function is used to get interconnect path handle.
+ */
+int geni_interconnect_init(struct geni_se *se)
+{
+ struct geni_wrapper *wrapper_rsc;
+
+ if (unlikely(!se || !se->wrapper))
+ r
[PATCH V3] livepatch: non static warnings fix
Sparse reported warnings about non-static symbols. For the variables
a simple static attribute is fine - for the functions referenced by
livepatch via klp_func the symbol-names must be unmodified in the
symbol table and the patchable code has to be emitted. The resolution
is to attach __used attribute to the shared statically declared functions.
Signed-off-by: Nicholas Mc Guire
Suggested-by: Joe Lawrence
Link: https://lkml.org/lkml/2018/12/13/827
---
V2: not all static functions shared need to carry the __noclone
attribute only those that need to be resolved at runtime by
livepatch - so drop the unnecessary __noclone attributes as
well as the Note on __noclone as suggested by Joe Lawrence
- thanks !
V3: fix the wording as proposed by Joe Lawrence
to address that this is not only
about how to fix sparse warnings but also to ensure
traceable/patchable code still being emitted.
Sparse reported the following findings in 5.0-rc3:
CHECK samples/livepatch/livepatch-shadow-mod.c
samples/livepatch/livepatch-shadow-mod.c:99:1: warning: symbol 'dummy_list' was
not declared. Should it be static?
samples/livepatch/livepatch-shadow-mod.c:100:1: warning: symbol
'dummy_list_mutex' was not declared. Should it be static?
samples/livepatch/livepatch-shadow-mod.c:107:23: warning: symbol 'dummy_alloc'
was not declared. Should it be static?
samples/livepatch/livepatch-shadow-mod.c:132:15: warning: symbol 'dummy_free'
was not declared. Should it be static?
samples/livepatch/livepatch-shadow-mod.c:140:15: warning: symbol 'dummy_check'
was not declared. Should it be static?
CHECK samples/livepatch/livepatch-shadow-fix1.c
samples/livepatch/livepatch-shadow-fix1.c:74:14: warning: symbol
'livepatch_fix1_dummy_alloc' was not declared. Should it be static?
samples/livepatch/livepatch-shadow-fix1.c:116:6: warning: symbol
'livepatch_fix1_dummy_free' was not declared. Should it be static?
CHECK samples/livepatch/livepatch-shadow-fix2.c
samples/livepatch/livepatch-shadow-fix2.c:53:6: warning: symbol
'livepatch_fix2_dummy_check' was not declared. Should it be static?
samples/livepatch/livepatch-shadow-fix2.c:81:6: warning: symbol
'livepatch_fix2_dummy_free' was not declared. Should it be static?
Patch was compile tested with: x86_64_defconfig + FTRACE=y
FUNCTION_TRACER=y, SAMPLES=y, LIVEPATCH=y SAMPLE_LIVEPATCH=m
(looks sparse, smatch claan, one coccichek warning left - fix later today)
Patch was runtested with:
insmod samples/livepatch/livepatch-shadow-mod.ko
insmod samples/livepatch/livepatch-shadow-fix1.ko
insmod samples/livepatch/livepatch-shadow-fix2.ko
echo 0 > /sys/kernel/livepatch/livepatch_shadow_fix2/enabled
echo 0 > /sys/kernel/livepatch/livepatch_shadow_fix1/enabled
rmmod livepatch-shadow-fix2
rmmod livepatch-shadow-fix1
rmmod livepatch-shadow-mod
and dmesg output compared to previous run.
Patch is against 5.0-rc3 (localversion-next is next-20190123)
samples/livepatch/livepatch-shadow-fix1.c | 4 ++--
samples/livepatch/livepatch-shadow-fix2.c | 4 ++--
samples/livepatch/livepatch-shadow-mod.c | 11 ++-
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/samples/livepatch/livepatch-shadow-fix1.c
b/samples/livepatch/livepatch-shadow-fix1.c
index a5a5cac..67a73e5 100644
--- a/samples/livepatch/livepatch-shadow-fix1.c
+++ b/samples/livepatch/livepatch-shadow-fix1.c
@@ -71,7 +71,7 @@ static int shadow_leak_ctor(void *obj, void *shadow_data,
void *ctor_data)
return 0;
}
-struct dummy *livepatch_fix1_dummy_alloc(void)
+static struct dummy *livepatch_fix1_dummy_alloc(void)
{
struct dummy *d;
void *leak;
@@ -113,7 +113,7 @@ static void livepatch_fix1_dummy_leak_dtor(void *obj, void
*shadow_data)
__func__, d, *shadow_leak);
}
-void livepatch_fix1_dummy_free(struct dummy *d)
+static void livepatch_fix1_dummy_free(struct dummy *d)
{
void **shadow_leak;
diff --git a/samples/livepatch/livepatch-shadow-fix2.c
b/samples/livepatch/livepatch-shadow-fix2.c
index 52de947..91c21d5 100644
--- a/samples/livepatch/livepatch-shadow-fix2.c
+++ b/samples/livepatch/livepatch-shadow-fix2.c
@@ -50,7 +50,7 @@ struct dummy {
unsigned long jiffies_expire;
};
-bool livepatch_fix2_dummy_check(struct dummy *d, unsigned long jiffies)
+static bool livepatch_fix2_dummy_check(struct dummy *d, unsigned long jiffies)
{
int *shadow_count;
@@ -78,7 +78,7 @@ static void livepatch_fix2_dummy_leak_dtor(void *obj, void
*shadow_data)
__func__, d, *shadow_leak);
}
-void livepatch_fix2_dummy_free(struct dummy *d)
+static void livepatch_fix2_dummy_free(struct dummy *d)
{
void **shadow_leak;
int *shadow_count;
diff --git a/samples/livepatch/livepatch-shadow-mod.c
b/samples/livepatch/livepatch-shadow-mod.c
index 4aa8a88..4d79c6dc 100644
--- a/samples/livepatch/livepatch-shadow-mod.c
+++ b/samples/livepatch/livepatch-shadow-mod.c
@@ -9
[PATCH -next] mtd: docg3: Fix a possible memory leak of mtd->name
In case DOC_CHIPID_G3, mtd->name should be freed in the
err handling path, which is alloced by kasprintf.
Fixes: ae9d4934b2d7 ("mtd: docg3: add multiple floor support")
Signed-off-by: YueHaibing
---
drivers/mtd/devices/docg3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index 60ddc38..cbd25f9 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1867,6 +1867,7 @@ doc_probe_device(struct docg3_cascade *cascade, int
floor, struct device *dev)
nomem4:
kfree(docg3->bbt);
+ kfree(mtd->name);
nomem3:
kfree(mtd);
nomem2:
--
2.7.0
[PATCH -next] mtd: docg3: Fix passing zero to 'PTR_ERR' warning in doc_probe_device
Fix a static code checker warning:
drivers/mtd/devices/docg3.c:1875
doc_probe_device() warn: passing zero to 'ERR_PTR'
Fixes: ae9d4934b2d7 ("mtd: docg3: add multiple floor support")
Signed-off-by: YueHaibing
---
drivers/mtd/devices/docg3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index 4c94fc0..60ddc38 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1872,7 +1872,7 @@ doc_probe_device(struct docg3_cascade *cascade, int
floor, struct device *dev)
nomem2:
kfree(docg3);
nomem1:
- return ERR_PTR(ret);
+ return ret ? ERR_PTR(ret) : NULL;
}
/**
--
2.7.0
[PATCH 1/2] mfd: max77620: Add backup battery charger support
Add PMIC configurations for backup battery charger, which
is a constant voltage and constant current style charger
with a series output resistance.
The max77620 register CNFGBBC(addr: 0x04) defines the
parameters of backup battery charger. This patch adds
support for it.
Signed-off-by: Laxman Dewangan
Signed-off-by: Venkat Reddy Talla
Signed-off-by: Mark Zhang
---
drivers/mfd/max77620.c | 80 ++
1 file changed, 80 insertions(+)
diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c
index d8ddd1a6f304..f58143103185 100644
--- a/drivers/mfd/max77620.c
+++ b/drivers/mfd/max77620.c
@@ -398,6 +398,82 @@ static int max77620_initialise_fps(struct max77620_chip
*chip)
return 0;
}
+static int max77620_init_backup_battery_charging(struct max77620_chip *chip)
+{
+ struct device *dev = chip->dev;
+ struct device_node *np;
+ u32 pval;
+ u8 config;
+ int charging_current;
+ int charging_voltage;
+ int resistor;
+ int ret;
+
+ np = of_get_child_by_name(dev->of_node, "backup-battery");
+ if (!np) {
+ dev_info(dev, "Backup battery charging support disabled\n");
+ ret = regmap_update_bits(chip->rmap, MAX77620_REG_CNFGBBC,
+MAX77620_CNFGBBC_ENABLE, 0);
+ if (ret < 0)
+ dev_err(dev, "Failed to update CNFGBBC: %d\n", ret);
+ return ret;
+ }
+
+ ret = of_property_read_u32(np,
+ "maxim,backup-battery-charging-current", &pval);
+ charging_current = (!ret) ? pval : 50;
+
+ ret = of_property_read_u32(np,
+ "maxim,backup-battery-charging-voltage", &pval);
+ charging_voltage = (!ret) ? pval : 250;
+ charging_voltage /= 1000;
+
+ ret = of_property_read_u32(np,
+ "maxim,backup-battery-output-resister", &pval);
+ resistor = (!ret) ? pval : 1000;
+
+ config = MAX77620_CNFGBBC_ENABLE;
+ if (charging_current <= 50)
+ config |= 0 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 100)
+ config |= 3 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 200)
+ config |= 0 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 400)
+ config |= 3 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 600)
+ config |= 1 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else
+ config |= 2 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+
+ if (charging_current > 100)
+ config |= MAX77620_CNFGBBC_LOW_CURRENT_DISABLE;
+
+ if (charging_voltage <= 2500)
+ config |= 0 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+ else if (charging_voltage <= 3000)
+ config |= 1 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+ else if (charging_voltage <= 3300)
+ config |= 2 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+ else
+ config |= 3 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+
+ if (resistor <= 100)
+ config |= 0 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+ else if (resistor <= 1000)
+ config |= 1 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+ else if (resistor <= 3000)
+ config |= 2 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+ else if (resistor <= 6000)
+ config |= 3 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+
+ ret = regmap_write(chip->rmap, MAX77620_REG_CNFGBBC, config);
+ if (ret < 0)
+ dev_err(dev, "Reg 0x%02x write failed, %d\n",
+ MAX77620_REG_CNFGBBC, ret);
+ return ret;
+}
+
static int max77620_read_es_version(struct max77620_chip *chip)
{
unsigned int val;
@@ -483,6 +559,10 @@ static int max77620_probe(struct i2c_client *client,
if (ret < 0)
return ret;
+ ret = max77620_init_backup_battery_charging(chip);
+ if (ret < 0)
+ return ret;
+
ret = devm_mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE,
mfd_cells, n_mfd_cells, NULL, 0,
regmap_irq_get_domain(chip->top_irq_data));
--
2.19.2
[PATCH 2/2] mfd: max77620: Add low battery monitor support
This patch adds PMIC configurations for low-battery
monitoring by handling max77620 register CNFGGLBL1.
Signed-off-by: Laxman Dewangan
Signed-off-by: Venkat Reddy Talla
Signed-off-by: Mark Zhang
---
drivers/mfd/max77620.c | 57 +-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c
index f58143103185..9e50d145afd8 100644
--- a/drivers/mfd/max77620.c
+++ b/drivers/mfd/max77620.c
@@ -474,6 +474,57 @@ static int max77620_init_backup_battery_charging(struct
max77620_chip *chip)
return ret;
}
+static int max77620_init_low_battery_monitor(struct max77620_chip *chip)
+{
+ struct device *dev = chip->dev;
+ struct device_node *np;
+ bool pval;
+ u8 mask = 0;
+ u8 val = 0;
+ int ret;
+
+ np = of_get_child_by_name(dev->of_node, "low-battery-monitor");
+ if (!np) {
+ dev_info(dev, "Low battery monitoring support disabled\n");
+ return 0;
+ }
+
+ pval = of_property_read_bool(np, "maxim,low-battery-dac-enable");
+ if (pval) {
+ mask |= MAX77620_CNFGGLBL1_LBDAC_EN;
+ val |= MAX77620_CNFGGLBL1_LBDAC_EN;
+ }
+
+ pval = of_property_read_bool(np, "maxim,low-battery-dac-disable");
+ if (pval)
+ mask |= MAX77620_CNFGGLBL1_LBDAC_EN;
+
+ pval = of_property_read_bool(np, "maxim,low-battery-shutdown-enable");
+ if (pval) {
+ mask |= MAX77620_CNFGGLBL1_MPPLD;
+ val |= MAX77620_CNFGGLBL1_MPPLD;
+ }
+
+ pval = of_property_read_bool(np, "maxim,low-battery-shutdown-disable");
+ if (pval)
+ mask |= MAX77620_CNFGGLBL1_MPPLD;
+
+ pval = of_property_read_bool(np, "maxim,low-battery-reset-enable");
+ if (pval) {
+ mask |= MAX77620_CNFGGLBL1_LBRSTEN;
+ val |= MAX77620_CNFGGLBL1_LBRSTEN;
+ }
+
+ pval = of_property_read_bool(np, "maxim,low-battery-reset-disable");
+ if (pval)
+ mask |= MAX77620_CNFGGLBL1_LBRSTEN;
+
+ ret = regmap_update_bits(chip->rmap, MAX77620_REG_CNFGGLBL1, mask, val);
+ if (ret < 0)
+ dev_err(dev, "Reg CNFGGLBL1 update failed: %d\n", ret);
+ return ret;
+}
+
static int max77620_read_es_version(struct max77620_chip *chip)
{
unsigned int val;
@@ -563,7 +614,11 @@ static int max77620_probe(struct i2c_client *client,
if (ret < 0)
return ret;
- ret = devm_mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE,
+ ret = max77620_init_low_battery_monitor(chip);
+ if (ret < 0)
+ return ret;
+
+ ret = devm_mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE,
mfd_cells, n_mfd_cells, NULL, 0,
regmap_irq_get_domain(chip->top_irq_data));
if (ret < 0) {
--
2.19.2
Re: [PATCH 6/7] crypto: ccp: no need to check return value of debugfs_create functions
On Tue, Jan 22, 2019 at 10:06:54PM +, Gary R Hook wrote: > On 1/22/19 9:14 AM, Greg Kroah-Hartman wrote: > > When calling debugfs functions, there is no need to ever check the > > return value. The function can work or not, but the code logic should > > never do something different based on this. > > Stupid question(s) time. > > If we don't care about failures (because the subsystem handles them > without our involvement) why do these functions even have return values? > Why haven't they been changed to void so that they reflect the current > style of intended use? Because on "normal" operations, you use the return value for something (i.e. a parent directory to pass to other functions, or a value so you can remove the file later). > I realize I'm old fashioned, but if a failure occurs, I've always been > of a mind to kick out and not try to do any further work. But debugfs is > to be treated as an exception to that paradigm? Carry on, ignore errors, > don't worry about it? Yes, that is the case here, it goes against what everyone normally thinks about kernel development :) thanks, greg k-h
[PATCH -next] crypto: chelsio - Fix passing zero to 'PTR_ERR' warning in chcr_aead_op
Fix a static code checker warning:
drivers/crypto/chelsio/chcr_algo.c:3681
chcr_aead_op() warn: passing zero to 'PTR_ERR'
Fixes: 2debd3325e55 ("crypto: chcr - Add AEAD algos.")
Signed-off-by: YueHaibing
---
drivers/crypto/chelsio/chcr_algo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c
b/drivers/crypto/chelsio/chcr_algo.c
index adc1b30..18b8a71 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -3676,9 +3676,9 @@ static int chcr_aead_op(struct aead_request *req,
/* Form a WR from req */
skb = create_wr_fn(req, u_ctx->lldi.rxq_ids[a_ctx(tfm)->rx_qidx], size);
- if (IS_ERR(skb) || !skb) {
+ if (IS_ERR_OR_NULL(skb)) {
chcr_dec_wrcount(cdev);
- return PTR_ERR(skb);
+ return PTR_ERR_OR_ZERO(skb);
}
skb->dev = u_ctx->lldi.ports[0];
--
2.7.0
Re: [virtio-dev] [PATCH] virtio: support VIRTIO_F_ORDER_PLATFORM
On 2019/1/23 上午11:49, Michael S. Tsirkin wrote:
On Wed, Jan 23, 2019 at 11:08:04AM +0800, Jason Wang wrote:
On 2019/1/23 上午1:03, Tiwei Bie wrote:
This patch introduces the support for VIRTIO_F_ORDER_PLATFORM.
When this feature is negotiated, driver will use the barriers
suitable for hardware devices.
Signed-off-by: Tiwei Bie
---
drivers/virtio/virtio_ring.c | 8
include/uapi/linux/virtio_config.h | 6 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..27d3f057493e 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -1609,6 +1609,9 @@ static struct virtqueue *vring_create_virtqueue_packed(
!context;
vq->event = virtio_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX);
+ if (virtio_has_feature(vdev, VIRTIO_F_ORDER_PLATFORM))
+ vq->weak_barriers = false;
+
vq->packed.ring_dma_addr = ring_dma_addr;
vq->packed.driver_event_dma_addr = driver_event_dma_addr;
vq->packed.device_event_dma_addr = device_event_dma_addr;
@@ -2079,6 +2082,9 @@ struct virtqueue *__vring_new_virtqueue(unsigned int
index,
!context;
vq->event = virtio_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX);
+ if (virtio_has_feature(vdev, VIRTIO_F_ORDER_PLATFORM))
+ vq->weak_barriers = false;
+
vq->split.queue_dma_addr = 0;
vq->split.queue_size_in_bytes = 0;
@@ -2213,6 +2219,8 @@ void vring_transport_features(struct virtio_device *vdev)
break;
case VIRTIO_F_RING_PACKED:
break;
+ case VIRTIO_F_ORDER_PLATFORM:
+ break;
default:
/* We don't understand this bit. */
__virtio_clear_bit(vdev, i);
diff --git a/include/uapi/linux/virtio_config.h
b/include/uapi/linux/virtio_config.h
index 1196e1c1d4f6..ff8e7dc9d4dd 100644
--- a/include/uapi/linux/virtio_config.h
+++ b/include/uapi/linux/virtio_config.h
@@ -78,6 +78,12 @@
/* This feature indicates support for the packed virtqueue layout. */
#define VIRTIO_F_RING_PACKED 34
+/*
+ * This feature indicates that memory accesses by the driver and the
+ * device are ordered in a way described by the platform.
+ */
+#define VIRTIO_F_ORDER_PLATFORM36
+
/*
* Does the device support Single Root I/O Virtualization?
*/
I wonder whether or not this is sufficient. Is dma barrier implies a mmio
barrier? Looks not.
IIUC we don't need an mmio barrier because we are using a
serializing API: Documentation/memory-barriers.txt says:
Note that, when using writel(), a prior
wmb() is not needed to guarantee that the cache coherent memory writes
have completed before writing to the MMIO region.
Ah, I get this.
See ia64/include/asm/barrier.h:
* Note: "mb()" and its variants cannot be used as a fence to order
* accesses to memory mapped I/O registers. For that, mf.a needs to
* be used. However, we don't want to always use mf.a because (a)
* it's (presumably) much slower than mf and (b) mf.a is supported for
* sequential memory pages only.
*/
#define mb() ia64_mf()
#define rmb() mb()
#define wmb() mb()
#define dma_rmb() mb()
=>efine dma_wmb() mb()
Thanks
Frankly no idea about ia64.
Neither did me.
Sorry. Are any less esoteric platforms
affected?
E.g ppc64?
define dma_wmb() __asm__ __volatile__ (stringify_in_c(SMPWMB) : :
:"memo\
ry")
/*
* Enforce synchronisation of stores vs. spin_unlock
* (this does it explicitly, though our implementation of spin_unlock
* does it implicitely too)
*/
static inline void mmiowb(void)
{
unsigned long tmp;
__asm__ __volatile__("sync; li %0,0; stb %0,%1(13)"
: "=&r" (tmp) : "i" (offsetof(struct paca_struct, io_sync))
: "memory");
}
dma_wmb() is lwsync which is more lightweight than sync I guess?
Thanks
Re: [PATCH 6/6] arm64: dts: sdm845: Add interconnect for GENI QUP
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
Add interconnect ports for GENI QUPs to set bus
capabilities.
Signed-off-by: Alok Chauhan
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c27cbd3..fb0a8a7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -374,6 +374,13 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ interconnects = <&rsc_hlos MASTER_BLSP_1
+ &rsc_hlos SLAVE_EBI1>,
+ <&rsc_hlos MASTER_APPSS_PROC
+ &rsc_hlos SLAVE_BLSP_1>;
+ interconnect-names = "qup-memory", "qup-config";
+
status = "disabled";
i2c0: i2c@88 {
@@ -682,6 +689,13 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ interconnects = <&rsc_hlos MASTER_BLSP_2
+ &rsc_hlos SLAVE_EBI1>,
+ <&rsc_hlos MASTER_APPSS_PROC
+ &rsc_hlos SLAVE_BLSP_2>;
+ interconnect-names = "qup-memory", "qup-config";
+
status = "disabled";
i2c8: i2c@a8 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
Re: [PATCH] kprobes: no need to check return value of debugfs_create functions
On Wed, Jan 23, 2019 at 11:15:16AM +0900, Masami Hiramatsu wrote:
> On Tue, 22 Jan 2019 16:21:46 +0100
> Greg Kroah-Hartman wrote:
>
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on this.
> >
> > Cc: "Naveen N. Rao"
> > Cc: Anil S Keshavamurthy
> > Cc: "David S. Miller"
> > Cc: Masami Hiramatsu
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > kernel/kprobes.c | 25 ++---
> > 1 file changed, 6 insertions(+), 19 deletions(-)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index f4ddfdd2d07e..7287e7de2350 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -2566,33 +2566,20 @@ static const struct file_operations fops_kp = {
> >
> > static int __init debugfs_kprobe_init(void)
> > {
> > - struct dentry *dir, *file;
> > + struct dentry *dir;
> > unsigned int value = 1;
> >
> > dir = debugfs_create_dir("kprobes", NULL);
> > - if (!dir)
> > - return -ENOMEM;
>
> Here, I think IS_ERR(dir) is OK for debugfs_create_file(),
> but dir == NULL has different meaning. I think we'd better
> keep this check. (I see, -ENOMEM will be no good...)
dir == NULL means the system is out of memory. Which I'll change and
just make it return an error, so it is fine to ignore this value.
thanks,
greg k-h
Re: [PATCH 5/6] tty: serial: qcom_geni_serial: Add interconnect support
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
Get the interconnect paths for Uart based Serial Engine device
and vote accordingly based on maximum supported Uart frequency.
Signed-off-by: Alok Chauhan
---
drivers/tty/serial/qcom_geni_serial.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/qcom_geni_serial.c
b/drivers/tty/serial/qcom_geni_serial.c
index a72d6d9..e2ea499 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/* UART specific GENI registers */
#define SE_UART_LOOPBACK_CFG 0x22c
@@ -1348,6 +1349,22 @@ static int qcom_geni_serial_probe(struct
platform_device *pdev)
return ret;
}
+ /* Set the bus quota to a reasonable value */
+ port->se.avg_bw = console ? Bps_to_icc(1000) : Bps_to_icc(2500);
+ port->se.peak_bw = Bps_to_icc(7680);
+ ret = geni_interconnect_init(&port->se);
+ if (ret) {
+ dev_err(&pdev->dev, "interconnect_init failed %d\n", ret);
+ return ret;
+ }
+
+ /*
+* Vote for interconnect path early. This has to move as part of
+* Runtime PM APIs when implemented for better control betwen
+* console and non-console usecases
+*/
+ geni_icc_update_bw(&port->se, true);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -EINVAL;
@@ -1385,8 +1402,15 @@ static int __maybe_unused
qcom_geni_serial_sys_suspend(struct device *dev)
{
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
+ int ret;
+
+ ret = uart_suspend_port(uport->private_data, uport);
+ if (ret)
+ return ret;
+
+ geni_icc_update_bw(&port->se, false);
- return uart_suspend_port(uport->private_data, uport);
+ return 0;
}
static int __maybe_unused qcom_geni_serial_sys_resume(struct device
*dev)
@@ -1394,6 +1418,7 @@ static int __maybe_unused
qcom_geni_serial_sys_resume(struct device *dev)
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
+ geni_icc_update_bw(&port->se, true);
return uart_resume_port(uport->private_data, uport);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
[PATCH v7 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings
Document the bindings used by the Renesas R-Car Gen3 RPC-IF controller.
Signed-off-by: Mason Yang
---
.../devicetree/bindings/spi/spi-renesas-rpc.txt| 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
new file mode 100644
index 000..305bd10
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
@@ -0,0 +1,46 @@
+Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
+
+
+Required properties:
+- compatible: should be an SoC-specific compatible value, followed by
+ "renesas,rcar-gen3-rpc" as a fallback, i.e.,
+ "renesas,r8a77995-rpc", "renesas,rcar-gen3-rpc".
+ "renesas,r8a7795-rpc" (R-Car H3)
+ "renesas,r8a7796-rpc" (R-Car M3-W)
+ "renesas,r8a77965-rpc" (R-Car M3-N)
+ "renesas,r8a77970-rpc" (R-Car V3M)
+ "renesas,r8a77980-rpc" (R-Car V3H)
+ "renesas,r8a77990-rpc" (R-Car E3)
+ "renesas,r8a77995-rpc" (R-Car D3)
+- reg: should contain three register areas:
+ first for the base address of rpc-if registers,
+ second for the direct mapping read mode and
+ third for the write buffer area.
+- reg-names: should contain "regs", "dirmap" and "wbuf"
+- clocks: should contain 1 entries for the module's clock
+- clock-names: should contain "rpc"
+- #address-cells: should be 1
+- #size-cells: should be 0
+
+Example:
+
+ rpc: rpc@ee20 {
+ compatible = "renesas,r8a77995-rpc", "renesas,rcar-gen3-rpc";
+ reg = <0 0xee20 0 0x200>, <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ clocks = <&cpg CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+ };
--
1.9.1
Re: [PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support
On 2019-01-22 14:43, Peter Rosin wrote: On 2019-01-22 07:33, Alok Chauhan wrote: Get the interconnect paths for I2C based Serial Engine device and vote accordingly based on maximum supported I2C frequency. Signed-off-by: Alok Chauhan --- drivers/i2c/busses/i2c-qcom-geni.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index db075bc..e8fe63a 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -14,6 +14,7 @@ #include #include #include +#include Please keep the includes sorted. Probably applies for the other patches in the series as well? Cheers, Peter Sure, will do. Thanks for your comment. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,a Linux Foundation Collaborative Project
[PATCH v7 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver
Add a driver for Renesas R-Car Gen3 RPC-IF SPI controller. Signed-off-by: Mason Yang Signed-off-by: Sergei Shtylyov --- drivers/spi/Kconfig | 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 805 ++ 3 files changed, 812 insertions(+) create mode 100644 drivers/spi/spi-renesas-rpc.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 9f89cb1..6ad1782 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -544,6 +544,12 @@ config SPI_RSPI help SPI driver for Renesas RSPI and QSPI blocks. +config SPI_RENESAS_RPC + tristate "Renesas R-Car Gen3 RPC-IF controller" + depends on ARCH_RENESAS || COMPILE_TEST + help + SPI driver for Renesas R-Car Gen3 RPC-IF. + config SPI_QCOM_QSPI tristate "QTI QSPI controller" depends on ARCH_QCOM diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index f296270..9150732 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -84,6 +84,7 @@ obj-$(CONFIG_SPI_QUP) += spi-qup.o obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o obj-$(CONFIG_SPI_RB4XX)+= spi-rb4xx.o obj-$(CONFIG_SPI_RSPI) += spi-rspi.o +obj-$(CONFIG_SPI_RENESAS_RPC) += spi-renesas-rpc.o obj-$(CONFIG_SPI_S3C24XX) += spi-s3c24xx-hw.o spi-s3c24xx-hw-y := spi-s3c24xx.o spi-s3c24xx-hw-$(CONFIG_SPI_S3C24XX_FIQ) += spi-s3c24xx-fiq.o diff --git a/drivers/spi/spi-renesas-rpc.c b/drivers/spi/spi-renesas-rpc.c new file mode 100644 index 000..0127f25 --- /dev/null +++ b/drivers/spi/spi-renesas-rpc.c @@ -0,0 +1,805 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp. +// Copyright (C) 2018 Macronix International Co., Ltd. +// +// R-Car Gen3 RPC-IF SPI/QSPI/Octa driver +// +// Authors: +// Mason Yang +// + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define RPC_CMNCR 0x // R/W +#define RPC_CMNCR_MD BIT(31) +#define RPC_CMNCR_SFDE BIT(24) // undocumented bit but must be set +#define RPC_CMNCR_MOIIO3(val) (((val) & 0x3) << 22) +#define RPC_CMNCR_MOIIO2(val) (((val) & 0x3) << 20) +#define RPC_CMNCR_MOIIO1(val) (((val) & 0x3) << 18) +#define RPC_CMNCR_MOIIO0(val) (((val) & 0x3) << 16) +#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \ +RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3)) +#define RPC_CMNCR_IO3FV(val) (((val) & 0x3) << 14) // undocumented +#define RPC_CMNCR_IO2FV(val) (((val) & 0x3) << 12) // undocumented +#define RPC_CMNCR_IO0FV(val) (((val) & 0x3) << 8) +#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \ +RPC_CMNCR_IO3FV(3)) +#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0) + +#define RPC_SSLDR 0x0004 // R/W +#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16) +#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8) +#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0) + +#define RPC_DRCR 0x000C // R/W +#define RPC_DRCR_SSLN BIT(24) +#define RPC_DRCR_RBURST(v) v) - 1) & 0x1F) << 16) +#define RPC_DRCR_RCF BIT(9) +#define RPC_DRCR_RBE BIT(8) +#define RPC_DRCR_SSLE BIT(0) + +#define RPC_DRCMR 0x0010 // R/W +#define RPC_DRCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_DRCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_DREAR 0x0014 // R/W +#define RPC_DREAR_EAC(c) (((c) & 0x7) << 0) + +#define RPC_DROPR 0x0018 // R/W + +#define RPC_DRENR 0x001C // R/W +#define RPC_DRENR_CDB(o) (u32)o) & 0x3) << 30)) +#define RPC_DRENR_OCDB(o) (((o) & 0x3) << 28) +#define RPC_DRENR_ADB(o) (((o) & 0x3) << 24) +#define RPC_DRENR_OPDB(o) (((o) & 0x3) << 20) +#define RPC_DRENR_DRDB(o) (((o) & 0x3) << 16) +#define RPC_DRENR_DME BIT(15) +#define RPC_DRENR_CDE BIT(14) +#define RPC_DRENR_OCDE BIT(12) +#define RPC_DRENR_ADE(v) (((v) & 0xF) << 8) +#define RPC_DRENR_OPDE(v) (((v) & 0xF) << 4) + +#define RPC_SMCR 0x0020 // R/W +#define RPC_SMCR_SSLKP BIT(8) +#define RPC_SMCR_SPIRE BIT(2) +#define RPC_SMCR_SPIWE BIT(1) +#define RPC_SMCR_SPIE BIT(0) + +#define RPC_SMCMR 0x0024 // R/W +#define RPC_SMCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_SMCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_SMADR 0x0028 // R/W +#define RPC_SMOPR 0x002C // R/W +#define RPC_SMOPR_OPD3(o) (((o) & 0xFF) << 24) +#define RPC_SMOPR_OPD2(o) (((o) & 0xFF) << 16) +#define RPC_SMOPR_OPD1(o) (((o) & 0xFF) << 8) +#define RPC_SMOPR_OPD0(o) (((o) & 0xFF) << 0) + +#define RPC_SM
[PATCH v7 0/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI driver
Hi Mark, v7 patch is according to Geert and Sergei's comments: 1) Add all R-Car Gen3 model in dts. 2) patch rpc-if child node search. 3) minror coding style. v6 patch is accroding to Geert, Marek and Sergei's comments: 1) spi_controller for new code. 2) "renesas,rcar-gen3-rpc" instead of "renesas,r8a77995-rpc." 3) patch external address read mode w/o u64 readq(). 4) patch dts for write buffer & drop "renesas,rpc-mode". 5) coding style and so on. v5 patch is accroding to Sergei's comments: 1) Read 6 bytes ID from Sergei's patch. 2) regmap_update_bits(). 3) C++ style comment. v4 patch is according to Sergei's comments including: 1) Drop soc_device_match(). 2) Drop unused RPC registers. 3) Use ilog2() instead of fls(). 4) Patch read 6 bytes ID w/ one command. 5) Coding style and so on. v3 patch is according to Marek and Geert's comments including: 1) soc_device_mach() to set up RPC_PHYCNT_STRTIM. 2) get_unaligned(). 3) rpc-mode for rpi-spi-flash or rpc-hyperflash. 4) coding style and so on. v2 patch including: 1) remove RPC clock enable/dis-able control, 2) patch run time PM. 3) add RPC module software reset, 4) add regmap. 5) other coding style and so on. thanks for your review. best regards, Mason Mason Yang (2): spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings .../devicetree/bindings/spi/spi-renesas-rpc.txt| 46 ++ drivers/spi/Kconfig| 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 805 + 4 files changed, 858 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt create mode 100644 drivers/spi/spi-renesas-rpc.c -- 1.9.1
Re: [PATCH 2/6] soc: qcom: Add wrapper to support for Interconnect path
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
Add the wrapper to support for interconnect path voting
from GENI QUP. This wrapper provides the functionalities
to individual Serial Engine device to get the interconnect
path and to vote for bandwidth based on their need.
This wrapper maintains bandwidth votes from each Serial Engine
and send the aggregated vote from GENI QUP to interconnect
framework.
Signed-off-by: Alok Chauhan
---
drivers/soc/qcom/qcom-geni-se.c | 129
include/linux/qcom-geni-se.h| 11
2 files changed, 140 insertions(+)
diff --git a/drivers/soc/qcom/qcom-geni-se.c
b/drivers/soc/qcom/qcom-geni-se.c
index 6b8ef01..1d8dcb1 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/**
* DOC: Overview
@@ -84,11 +85,21 @@
* @dev: Device pointer of the QUP wrapper core
* @base: Base address of this instance of QUP wrapper core
* @ahb_clks: Handle to the primary & secondary AHB clocks
+ * @icc_path: Array of interconnect path handles
+ * @geni_wrapper_lock: Lock to protect the bus bandwidth request
+ * @cur_avg_bw:Current Bus Average BW request value from GENI
QUP
+ * @cur_peak_bw: Current Bus Peak BW request value from GENI QUP
+ * @peak_bw_list_head: Sorted resource list based on peak bus BW
*/
struct geni_wrapper {
struct device *dev;
void __iomem *base;
struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
+ struct icc_path *icc_path[2];
+ struct mutex geni_wrapper_lock;
+ u32 cur_avg_bw;
+ u32 cur_peak_bw;
+ struct list_head peak_bw_list_head;
};
#define QUP_HW_VER_REG 0x4
@@ -440,6 +451,71 @@ static void geni_se_clks_off(struct geni_se *se)
}
/**
+ * geni_icc_update_bw() - Request to update bw vote on an interconnect
path
+ * @se:Pointer to the concerned serial engine.
+ * @update:Flag to update bw vote.
+ *
+ * This function is used to request set bw vote on interconnect path
handle.
+ */
+void geni_icc_update_bw(struct geni_se *se, bool update)
+{
+ struct geni_se *temp = NULL;
+ struct list_head *ins_list_head;
+ struct geni_wrapper *wrapper;
+
+ mutex_lock(&se->wrapper->geni_wrapper_lock);
+
+ wrapper = se->wrapper;
+
+ if (update) {
+ wrapper->cur_avg_bw += se->avg_bw;
+ ins_list_head = &wrapper->peak_bw_list_head;
+ list_for_each_entry(temp, &wrapper->peak_bw_list_head,
+ peak_bw_list) {
+ if (temp->peak_bw < se->peak_bw)
+ break;
+ ins_list_head = &temp->peak_bw_list;
+ }
+
+ list_add(&se->peak_bw_list, ins_list_head);
+
+ if (ins_list_head == &wrapper->peak_bw_list_head)
+ wrapper->cur_peak_bw = se->peak_bw;
+ } else {
+ if (unlikely(list_empty(&se->peak_bw_list))) {
+ mutex_unlock(&wrapper->geni_wrapper_lock);
+ return;
+ }
+
+ wrapper->cur_avg_bw -= se->avg_bw;
+
+ list_del_init(&se->peak_bw_list);
+ temp = list_first_entry_or_null(&wrapper->peak_bw_list_head,
+ struct geni_se, peak_bw_list);
+ if (temp && temp->peak_bw != wrapper->cur_peak_bw)
+ wrapper->cur_peak_bw = temp->peak_bw;
+ else if (!temp && wrapper->cur_peak_bw)
+ wrapper->cur_peak_bw = 0;
+ }
+
+ /*
+* This bw vote is to enable internal QUP core clock as well as to
+* enable path towards memory.
+*/
+ icc_set_bw(wrapper->icc_path[0], wrapper->cur_avg_bw,
+ wrapper->cur_peak_bw);
+
+ /*
+* This is just register configuration path so doesn't need avg bw.
+* Set only peak bw to enable this path.
+*/
+ icc_set_bw(wrapper->icc_path[1], 0, wrapper->cur_peak_bw);
+
+ mutex_unlock(&wrapper->geni_wrapper_lock);
+}
+EXPORT_SYMBOL(geni_icc_update_bw);
+
+/**
* geni_se_resources_off() - Turn off resources associated with the
serial
* engine
* @se:Pointer to the concerned serial engine.
@@ -707,6 +783,47 @@ void geni_se_rx_dma_unprep(struct geni_se *se,
dma_addr_t iova, size_t len)
}
EXPORT_SYMBOL(geni_se_rx_dma_unprep);
+/**
+ * geni_interconnect_init() - Request to get interconnect path handle
+ * @se:Pointer to the concerned serial engine.
+ *
+ * This function is used to get interconnect path handle.
+ */
+int geni_interconnect_init(struct geni_se *se)
+{
+ struct geni_wrapper *wrapper_rsc;
+
+ if (unlikely(!se || !se->wrapper))
+ r
Re: [PATCH 1/6] dt-bindings: soc: qcom: Add interconnect binding for GENI QUP
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
Add documentation for the interconnect and interconnect-names bindings
for the GENI QUP as detailed by bindings/interconnect/interconnect.txt.
Signed-off-by: Alok Chauhan
---
Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt | 10
++
1 file changed, 10 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
index dab7ca9..44d7e02 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
@@ -17,6 +17,12 @@ Required properties if child node exists:
- #address-cells: Must be <1> for Serial Engine Address
- #size-cells: Must be <1> for Serial Engine Address Size
- ranges: Must be present
+- interconnects: phandle to a interconnect provider. Please refer
+ ../interconnect/interconnect.txt for details.
+ Must be 2 paths corresponding to 2 AXI ports.
+- interconnect-names: Port names to differentiate between the
+ 2 interconnect paths defined with interconnect
+ specifier.
Properties for children:
@@ -67,6 +73,10 @@ Example:
#size-cells = <1>;
ranges;
+ interconnects = <&qnoc 11 &qnoc 512>,
+ <&qnoc 0 &qnoc 543>;
+ interconnect-names = "qup-memory", "qup-config";
+
i2c0: i2c@a94000 {
compatible = "qcom,geni-i2c";
reg = <0xa94000 0x4000>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
Re: [PATCH] backing-dev: no need to check return value of debugfs_create functions
On Tue, Jan 22, 2019 at 05:25:03PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 22, 2019 at 05:07:59PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2019-01-22 16:21:07 [+0100], Greg Kroah-Hartman wrote:
> > > diff --git a/mm/backing-dev.c b/mm/backing-dev.c
> > > index 8a8bb8796c6c..85ef344a9c67 100644
> > > --- a/mm/backing-dev.c
> > > +++ b/mm/backing-dev.c
> > > @@ -102,39 +102,25 @@ static int bdi_debug_stats_show(struct seq_file *m,
> > > void *v)
> > > }
> > > DEFINE_SHOW_ATTRIBUTE(bdi_debug_stats);
> > >
> > > -static int bdi_debug_register(struct backing_dev_info *bdi, const char
> > > *name)
> > > +static void bdi_debug_register(struct backing_dev_info *bdi, const char
> > > *name)
> > > {
> > > - if (!bdi_debug_root)
> > > - return -ENOMEM;
> > > -
> > > bdi->debug_dir = debugfs_create_dir(name, bdi_debug_root);
> >
> > If this fails then ->debug_dir is NULL
>
> Wonderful, who cares :)
Ok, after sleeping on it, I'll change this function to return an error
if we are out of memory, that way you will not be creating any files in
any other location if you use the return value like this. That should
solve this issue.
thanks,
greg k-h
Re: [PATCH 0/6] Add interconnect support for GENI QUPs
+Mark Brown On 2019-01-22 12:03, Alok Chauhan wrote: This patch series contains following: * Add wrapper framework to support interconnect path from GENI QUPs. This wrapper enabled and help individual SEs to put their BW request. Adding this wrapper make sense because we don't want individual SEs to request to interconnect driver separately and put individual bw votes from QUP. This wrapper framework does the following: - Request for interconnect path handle - Maintain record of individual SEs' avg/peak bw. - Aggregated avg/peak bw based on how many SE's are active and put single bw request from QUP * Interconnect wrapper API calling from I2C, SPI & Uart driver * dt binding in sdm845 soc for Interconnect path for GENI QUPs * dt binding documentation Alok Chauhan (6): dt-bindings: soc: qcom: Add interconnect binding for GENI QUP soc: qcom: Add wrapper to support for Interconnect path i2c: i2c-qcom-geni: Add interconnect support spi: spi-geni-qcom: Add interconnect support tty: serial: qcom_geni_serial: Add interconnect support arm64: dts: sdm845: Add interconnect for GENI QUP .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 10 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 +++ drivers/i2c/busses/i2c-qcom-geni.c | 13 +++ drivers/soc/qcom/qcom-geni-se.c| 129 + drivers/spi/spi-geni-qcom.c| 20 +++- drivers/tty/serial/qcom_geni_serial.c | 27 - include/linux/qcom-geni-se.h | 11 ++ 7 files changed, 222 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,a Linux Foundation Collaborative Project
[PATCH] block: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/block/drbd/drbd_int.h:1774:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
drivers/block/drbd/drbd_int.h:1774:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
drivers/block/drbd/drbd_int.h:1774:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
drivers/block/drbd/drbd_int.h:1774:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
drivers/block/drbd/drbd_int.h:1774:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
drivers/block/drbd/drbd_receiver.c:3093:6: warning: this statement may fall
through [-Wimplicit-fallthrough=]
drivers/block/drbd/drbd_receiver.c:3120:6: warning: this statement may fall
through [-Wimplicit-fallthrough=]
drivers/block/drbd/drbd_req.c:856:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva
---
drivers/block/drbd/drbd_int.h | 2 +-
drivers/block/drbd/drbd_receiver.c | 4 ++--
drivers/block/drbd/drbd_req.c | 2 +-
drivers/block/rsxx/core.c | 1 +
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index 000a2f4c0e92..f070f7200fc0 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -1778,7 +1778,7 @@ static inline void __drbd_chk_io_error_(struct
drbd_device *device,
_drbd_set_state(_NS(device, disk,
D_INCONSISTENT), CS_HARD, NULL);
break;
}
- /* NOTE fall through for DRBD_META_IO_ERROR or
DRBD_FORCE_DETACH */
+ /* fall through - for DRBD_META_IO_ERROR or DRBD_FORCE_DETACH */
case EP_DETACH:
case EP_CALL_HELPER:
/* Remember whether we saw a READ or WRITE error.
diff --git a/drivers/block/drbd/drbd_receiver.c
b/drivers/block/drbd/drbd_receiver.c
index c7ad88d91a09..74350663443f 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -3094,7 +3094,7 @@ static int drbd_asb_recover_0p(struct drbd_peer_device
*peer_device) __must_hold
rv = 1;
break;
}
- /* Else fall through to one of the other strategies... */
+ /* Else fall through - to one of the other strategies... */
case ASB_DISCARD_OLDER_PRI:
if (self == 0 && peer == 1) {
rv = 1;
@@ -3119,7 +3119,7 @@ static int drbd_asb_recover_0p(struct drbd_peer_device
*peer_device) __must_hold
}
if (after_sb_0p == ASB_DISCARD_ZERO_CHG)
break;
- /* else: fall through */
+ /* else, fall through */
case ASB_DISCARD_LEAST_CHG:
if (ch_self < ch_peer)
rv = -1;
diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index 643a04af213b..3809c7e6be8c 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -866,7 +866,7 @@ int __req_mod(struct drbd_request *req, enum drbd_req_event
what,
} /* else: FIXME can this happen? */
break;
}
- /* else, fall through to BARRIER_ACKED */
+ /* else, fall through - to BARRIER_ACKED */
case BARRIER_ACKED:
/* barrier ack for READ requests does not make sense */
diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 0cf4509d575c..898d522e8338 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -439,6 +439,7 @@ static void card_state_change(struct rsxx_cardinfo *card,
* Fall through so the DMA devices can be attached and
* the user can attempt to pull off their data.
*/
+ /* fall through */
case CARD_STATE_GOOD:
st = rsxx_get_card_size8(card, &card->size8);
if (st)
--
2.20.1
Re: [PATCH 4.20 000/111] 4.20.4-stable review
On Tue, Jan 22, 2019 at 11:24:25AM -0800, Guenter Roeck wrote: > On Mon, Jan 21, 2019 at 02:41:54PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.20.4 release. > > There are 111 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 Wed Jan 23 12:23:56 UTC 2019. > > Anything received after that time might be too late. > > > Build results: > total: 159 pass: 159 fail: 0 > Qemu test results: > total: 343 pass: 343 fail: 0 Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.20 000/111] 4.20.4-stable review
On Tue, Jan 22, 2019 at 03:25:58PM -0700, shuah wrote: > On 1/21/19 6:41 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.20.4 release. > > There are 111 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 Wed Jan 23 12:23:56 UTC 2019. > > 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.20.4-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.20.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] block: aoe: no need to check return value of debugfs_create functions
On Tue, Jan 22, 2019 at 03:29:33PM -0800, Omar Sandoval wrote:
> On Tue, Jan 22, 2019 at 04:21:04PM +0100, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on this.
> >
> > Cc: "Ed L. Cashin"
> > Cc: Jens Axboe
> > Cc: linux-bl...@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > drivers/block/aoe/aoeblk.c | 13 +
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
> > index e2c6aae2d636..b602646bfa04 100644
> > --- a/drivers/block/aoe/aoeblk.c
> > +++ b/drivers/block/aoe/aoeblk.c
> > @@ -207,14 +207,7 @@ aoedisk_add_debugfs(struct aoedev *d)
> > else
> > p++;
> > BUG_ON(*p == '\0');
> > - entry = debugfs_create_file(p, 0444, aoe_debugfs_dir, d,
> > - &aoe_debugfs_fops);
> > - if (IS_ERR_OR_NULL(entry)) {
> > - pr_info("aoe: cannot create debugfs file for %s\n",
> > - d->gd->disk_name);
> > - return;
> > - }
> > - BUG_ON(d->debugfs);
> > + debugfs_create_file(p, 0444, aoe_debugfs_dir, d, &aoe_debugfs_fops);
> > d->debugfs = entry;
>
> Now entry is uninitialized here when we assign it to d->debugfs.
Ah, good catch, I'll go fix this up and post a v2, sorry about that.
greg k-h
Re: [PATCH V2 1/6] misc/pvpanic: preparing for pvpanic driver framework
On Wed, Jan 23, 2019 at 07:37:52PM +0800, Peng Hao wrote:
> Preparing for pvpanic driver framework. Create a pvpanic driver
> directory and move current driver file to new directory.
>
> Signed-off-by: Peng Hao
> ---
> drivers/misc/Kconfig | 9 +
> drivers/misc/Makefile| 2 +-
> drivers/misc/pvpanic/Kconfig | 7 +++
> drivers/misc/pvpanic/Makefile| 5 +
> drivers/misc/{ => pvpanic}/pvpanic.c | 0
> 5 files changed, 14 insertions(+), 9 deletions(-)
> create mode 100644 drivers/misc/pvpanic/Kconfig
> create mode 100644 drivers/misc/pvpanic/Makefile
> rename drivers/misc/{ => pvpanic}/pvpanic.c (100%)
In none of these patches do you say what changed from v1 :(
Please fix up as the documentation says to, and resend as v3.
thanks,
greg k-h
Re: [PATCH v4 1/5] usb: split code locating ACPI companion into port and device
On Tue, Jan 22, 2019 at 02:42:26PM -0800, Dmitry Torokhov wrote: > On Tue, Jan 22, 2019 at 2:29 PM Rajat Jain wrote: > > > > Hi Marcel, > > > > On Sat, Jan 19, 2019 at 11:51 AM Marcel Holtmann > > wrote: > > > > > > Hi Rajat, > > > > > > > In preparation for handling embedded USB devices let's split > > > > usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and > > > > usb_acpi_find_companion_for_port(). > > > > > > > > Signed-off-by: Dmitry Torokhov > > > > Signed-off-by: Rajat Jain > > > > Acked-by: Greg Kroah-Hartman > > > > Tested-by: Sukumar Ghorai > > > > --- > > > > v4: Add Acked-by and Tested-by in signatures. > > > > v3: same as v1 > > > > v2: same as v1 > > > > > > > > drivers/usb/core/usb-acpi.c | 133 +++- > > > > 1 file changed, 72 insertions(+), 61 deletions(-) > > > > > > what is the plan here? I take this via bluetooth-next tree? > > > > Yes, I'd think that would be the best plan. Dmitry / Greg - do you > > have any objections / suggestions? > > That's up to Greg, but since he'd acked the patches I'd assume he's OK > with taking it through bluetooth. As an option Marcel could cut an > immutable branch off 4.20 with the first 2 patches so that he and Greg > can both pull it into their main branches and then git will do the > right thing when Linus pulls from them. Lee uses quite a bit of them > in MFD and other maintainers are known to occasionally make them for > work that needs to be shared between trees. I don't need to take these, they can all go through one tree, which is why I gave my ack to the patch. thanks, greg k-h
Re: [PATCH] fail_function: no need to check return value of debugfs_create functions
On Wed, Jan 23, 2019 at 07:33:05AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 23, 2019 at 09:11:41AM +0900, Masami Hiramatsu wrote:
> > On Tue, 22 Jan 2019 16:21:44 +0100
> > Greg Kroah-Hartman wrote:
> >
> > > When calling debugfs functions, there is no need to ever check the
> > > return value. The function can work or not, but the code logic should
> > > never do something different based on this.
> >
> > Ah, OK. It simplifies the code. But I have a question below,
> >
> > >
> > > Cc: Masami Hiramatsu
> > > Cc: Kees Cook
> > > Cc: Josef Bacik
> > > Cc: Thomas Gleixner
> > > Cc: "Naveen N. Rao"
> > > Cc: zhong jiang
> > > Signed-off-by: Greg Kroah-Hartman
> > > ---
> > > kernel/fail_function.c | 23 +--
> > > 1 file changed, 5 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/kernel/fail_function.c b/kernel/fail_function.c
> > > index 17f75b545f66..afc779be5ebb 100644
> > > --- a/kernel/fail_function.c
> > > +++ b/kernel/fail_function.c
> > > @@ -152,20 +152,13 @@ static int fei_retval_get(void *data, u64 *val)
> > > DEFINE_DEBUGFS_ATTRIBUTE(fei_retval_ops, fei_retval_get, fei_retval_set,
> > >"%llx\n");
> > >
> > > -static int fei_debugfs_add_attr(struct fei_attr *attr)
> > > +static void fei_debugfs_add_attr(struct fei_attr *attr)
> > > {
> > > struct dentry *dir;
> > >
> > > dir = debugfs_create_dir(attr->kp.symbol_name, fei_debugfs_dir);
> > > - if (!dir)
> > > - return -ENOMEM;
> > > -
> > > - if (!debugfs_create_file("retval", 0600, dir, attr, &fei_retval_ops)) {
> > > - debugfs_remove_recursive(dir);
> > > - return -ENOMEM;
> > > - }
> > >
> > > - return 0;
> >
> > Don't we need to check dir here? If above debugfs_create_dir() returns NULL,
> > it seems we will create "retval" under root directory of debugfs.
>
> If NULL is returned, your system is out of memory and worse things are
> about to happen :)
But you aren't the first to ask about this, I guess I should just return
ENOMEM and then the follow-on files will not be created. I'll go make
that change to the core of debugfs to help prevent this problem.
thanks,
greg k-h
Re: [PATCH] fail_function: no need to check return value of debugfs_create functions
On Wed, Jan 23, 2019 at 09:11:41AM +0900, Masami Hiramatsu wrote:
> On Tue, 22 Jan 2019 16:21:44 +0100
> Greg Kroah-Hartman wrote:
>
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on this.
>
> Ah, OK. It simplifies the code. But I have a question below,
>
> >
> > Cc: Masami Hiramatsu
> > Cc: Kees Cook
> > Cc: Josef Bacik
> > Cc: Thomas Gleixner
> > Cc: "Naveen N. Rao"
> > Cc: zhong jiang
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > kernel/fail_function.c | 23 +--
> > 1 file changed, 5 insertions(+), 18 deletions(-)
> >
> > diff --git a/kernel/fail_function.c b/kernel/fail_function.c
> > index 17f75b545f66..afc779be5ebb 100644
> > --- a/kernel/fail_function.c
> > +++ b/kernel/fail_function.c
> > @@ -152,20 +152,13 @@ static int fei_retval_get(void *data, u64 *val)
> > DEFINE_DEBUGFS_ATTRIBUTE(fei_retval_ops, fei_retval_get, fei_retval_set,
> > "%llx\n");
> >
> > -static int fei_debugfs_add_attr(struct fei_attr *attr)
> > +static void fei_debugfs_add_attr(struct fei_attr *attr)
> > {
> > struct dentry *dir;
> >
> > dir = debugfs_create_dir(attr->kp.symbol_name, fei_debugfs_dir);
> > - if (!dir)
> > - return -ENOMEM;
> > -
> > - if (!debugfs_create_file("retval", 0600, dir, attr, &fei_retval_ops)) {
> > - debugfs_remove_recursive(dir);
> > - return -ENOMEM;
> > - }
> >
> > - return 0;
>
> Don't we need to check dir here? If above debugfs_create_dir() returns NULL,
> it seems we will create "retval" under root directory of debugfs.
If NULL is returned, your system is out of memory and worse things are
about to happen :)
thanks,
greg k-h
[PATCH v2 1/2] irqchip: Add driver for Loongson-1 interrupt controller
This controller appeared on Loongson-1 family MCUs
including Loongson-1B and Loongson-1C.
Signed-off-by: Jiaxun Yang
---
drivers/irqchip/Kconfig| 9 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ls1x.c | 194 +
3 files changed, 204 insertions(+)
create mode 100644 drivers/irqchip/irq-ls1x.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3d1e60779078..5dcb5456cd14 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -406,6 +406,15 @@ config IMX_IRQSTEER
help
Support for the i.MX IRQSTEER interrupt multiplexer/remapper.
+config LS1X_IRQ
+ bool "Loongson-1 Interrupt Controller"
+ depends on MACH_LOONGSON32
+ default y
+ select IRQ_DOMAIN
+ select GENERIC_IRQ_CHIP
+ help
+ Support for the Loongson-1 platform Interrupt Controller.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c93713d24b86..7acd0e36d0b4 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -94,3 +94,4 @@ obj-$(CONFIG_CSKY_APB_INTC) += irq-csky-apb-intc.o
obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
+obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
diff --git a/drivers/irqchip/irq-ls1x.c b/drivers/irqchip/irq-ls1x.c
new file mode 100644
index ..b15b01237830
--- /dev/null
+++ b/drivers/irqchip/irq-ls1x.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019, Jiaxun Yang
+ * Loongson-1 platform IRQ support
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct ls_intc_data {
+ void __iomem *base;
+ unsigned int chip;
+};
+
+#define MAX_CHIPS 5
+#define LS_REG_INTC_STATUS 0x00
+#define LS_REG_INTC_EN 0x04
+#define LS_REG_INTC_SET0x08
+#define LS_REG_INTC_CLR0x0c
+#define LS_REG_INTC_POL0x10
+#define LS_REG_INTC_EDGE 0x14
+#define CHIP_SIZE 0x18
+
+static irqreturn_t intc_cascade(int irq, void *data)
+{
+ struct ls_intc_data *intc = irq_get_handler_data(irq);
+ uint32_t irq_reg;
+
+ irq_reg = readl(intc->base + (CHIP_SIZE * intc->chip)
+ + LS_REG_INTC_STATUS);
+ generic_handle_irq(__fls(irq_reg) + (intc->chip * 32) + LS1X_IRQ_BASE);
+
+ return IRQ_HANDLED;
+}
+
+static void ls_intc_set_bit(
+ struct irq_chip_generic *gc, unsigned int offset,
+ u32 mask, bool set)
+{
+ if (set)
+ writel(readl(gc->reg_base + offset) |
+ mask, gc->reg_base + offset);
+ else
+ writel(readl(gc->reg_base + offset) &
+ ~mask, gc->reg_base + offset);
+}
+
+static int ls_intc_set_type(struct irq_data *data, unsigned int type)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ u32 mask = data->mask;
+
+ switch (type) {
+ case IRQ_TYPE_LEVEL_HIGH:
+ ls_intc_set_bit(gc, LS_REG_INTC_EDGE, mask, false);
+ ls_intc_set_bit(gc, LS_REG_INTC_POL, mask, true);
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ ls_intc_set_bit(gc, LS_REG_INTC_EDGE, mask, false);
+ ls_intc_set_bit(gc, LS_REG_INTC_POL, mask, false);
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ ls_intc_set_bit(gc, LS_REG_INTC_EDGE, mask, true);
+ ls_intc_set_bit(gc, LS_REG_INTC_POL, mask, true);
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ ls_intc_set_bit(gc, LS_REG_INTC_EDGE, mask, true);
+ ls_intc_set_bit(gc, LS_REG_INTC_POL, mask, false);
+ break;
+ case IRQ_TYPE_NONE:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+
+static struct irqaction intc_cascade_action = {
+ .handler = intc_cascade,
+ .name = "intc cascade interrupt",
+};
+
+static int __init ls_intc_of_init(struct device_node *node,
+ unsigned int num_chips)
+{
+ struct ls_intc_data *intc[MAX_CHIPS];
+ struct irq_chip_generic *gc;
+ struct irq_chip_type *ct;
+ struct irq_domain *domain;
+ void __iomem *base;
+ int parent_irq[MAX_CHIPS], err = 0;
+ unsigned int i = 0;
+
+ base = of_iomap(node, 0);
+ if (!base)
+ return -ENODEV;
+
+ for (i = 0; i < num_chips; i++) {
+ /* Mask all irqs */
+ writel(0x0, base + (i * CHIP_SIZE) +
+ LS_REG_INTC_EN);
+
+ /* Set all irqs to high level triggered */
+ writel(0x, base + (i * CHIP_SIZE) +
+ LS_REG_INTC_POL);
+
+ in
[PATCH v2 2/2] dt-bindings: interrupt-controller: loongson ls1x intc
Dt-bindings doc about Loongson-1 interrupt controller
Signed-off-by: Jiaxun Yang
---
.../loongson,ls1x-intc.txt| 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
new file mode 100644
index ..afa8fec45f88
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
@@ -0,0 +1,28 @@
+Loongson ls1x Interrupt Controller
+
+Required properties:
+
+- compatible : should be "ingenic,-intc". Valid strings are:
+loongson,ls1b-intc
+loongson,ls1c-intc
+
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 1.
+- interrupts : Specifies the CPU interrupts the controller is connected to,
+- For ls1b, it must have 4 interrupts.
+- For ls1c, it must have 5 interrupts.
+
+Example:
+
+intc: interrupt-controller@1fd01040 {
+ compatible = "loongson,ls1c-intc";
+ reg = <0x1fd01040 0x78>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <2>, <3>, <4>, <5>, <6>;
+};
\ No newline at end of file
--
2.20.1
irqchip: Add driver for Loongson-1 intc v2
v1->v2: Fix SPDX-License-Identifier
Re: [PATCH 1/4] venus: firmware: check fw size against DT memory region size
Sorry for the delayed review! >_<
On Wed, Jan 9, 2019 at 5:46 PM Stanimir Varbanov
wrote:
>
> By historical reasons we defined firmware memory size to be 6MB even
> that the firmware size for all supported Venus versions is 5MBs. Correct
> that by compare the required firmware size returned from mdt loader and
> the one provided by DT reserved memory region. We proceed further if the
> required firmware size is smaller than provided by DT memory region.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/core.h | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 54 +++-
> 2 files changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.h
> b/drivers/media/platform/qcom/venus/core.h
> index 6382cea29185..79c7e816c706 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -134,6 +134,7 @@ struct venus_core {
> struct video_firmware {
> struct device *dev;
> struct iommu_domain *iommu_domain;
> + size_t mapped_mem_size;
> } fw;
> struct mutex lock;
> struct list_head instances;
> diff --git a/drivers/media/platform/qcom/venus/firmware.c
> b/drivers/media/platform/qcom/venus/firmware.c
> index c29acfd70c1b..6b509ffd022a 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -35,14 +35,15 @@
>
> static void venus_reset_cpu(struct venus_core *core)
> {
> + u32 fw_size = core->fw.mapped_mem_size;
> void __iomem *base = core->base;
>
> writel(0, base + WRAPPER_FW_START_ADDR);
> - writel(VENUS_FW_MEM_SIZE, base + WRAPPER_FW_END_ADDR);
> + writel(fw_size, base + WRAPPER_FW_END_ADDR);
> writel(0, base + WRAPPER_CPA_START_ADDR);
> - writel(VENUS_FW_MEM_SIZE, base + WRAPPER_CPA_END_ADDR);
> - writel(VENUS_FW_MEM_SIZE, base + WRAPPER_NONPIX_START_ADDR);
> - writel(VENUS_FW_MEM_SIZE, base + WRAPPER_NONPIX_END_ADDR);
> + writel(fw_size, base + WRAPPER_CPA_END_ADDR);
> + writel(fw_size, base + WRAPPER_NONPIX_START_ADDR);
> + writel(fw_size, base + WRAPPER_NONPIX_END_ADDR);
> writel(0x0, base + WRAPPER_CPU_CGC_DIS);
> writel(0x0, base + WRAPPER_CPU_CLOCK_CONFIG);
>
> @@ -74,6 +75,9 @@ static int venus_load_fw(struct venus_core *core, const
> char *fwname,
> void *mem_va;
> int ret;
>
> + *mem_phys = 0;
> + *mem_size = 0;
> +
> dev = core->dev;
> node = of_parse_phandle(dev->of_node, "memory-region", 0);
> if (!node) {
> @@ -85,28 +89,30 @@ static int venus_load_fw(struct venus_core *core, const
> char *fwname,
> if (ret)
> return ret;
>
> + ret = request_firmware(&mdt, fwname, dev);
> + if (ret < 0)
> + return ret;
> +
> + fw_size = qcom_mdt_get_size(mdt);
> + if (fw_size < 0) {
> + ret = fw_size;
> + goto err_release_fw;
> + }
> +
> *mem_phys = r.start;
> *mem_size = resource_size(&r);
>
> - if (*mem_size < VENUS_FW_MEM_SIZE)
> - return -EINVAL;
> + if (*mem_size < fw_size || fw_size > VENUS_FW_MEM_SIZE) {
Do we still need to check for fw_size > VENUS_FW_MEM_SIZE ? If we
don't then we can remove the definition of VENUS_FW_MEM_SIZE
altogether.
> + ret = -EINVAL;
> + goto err_release_fw;
> + }
>
> mem_va = memremap(r.start, *mem_size, MEMREMAP_WC);
> if (!mem_va) {
> dev_err(dev, "unable to map memory region: %pa+%zx\n",
> &r.start, *mem_size);
> - return -ENOMEM;
> - }
> -
> - ret = request_firmware(&mdt, fwname, dev);
> - if (ret < 0)
> - goto err_unmap;
> -
> - fw_size = qcom_mdt_get_size(mdt);
> - if (fw_size < 0) {
> - ret = fw_size;
> - release_firmware(mdt);
> - goto err_unmap;
> + ret = -ENOMEM;
> + goto err_release_fw;
> }
>
> if (core->use_tz)
> @@ -116,10 +122,9 @@ static int venus_load_fw(struct venus_core *core, const
> char *fwname,
> ret = qcom_mdt_load_no_init(dev, mdt, fwname, VENUS_PAS_ID,
> mem_va, *mem_phys, *mem_size,
> NULL);
>
> - release_firmware(mdt);
> -
> -err_unmap:
> memunmap(mem_va);
> +err_release_fw:
> + release_firmware(mdt);
> return ret;
> }
>
> @@ -135,6 +140,7 @@ static int venus_boot_no_tz(struct venus_core *core,
> phys_addr_t mem_phys,
> return -EPROBE_DEFER;
>
> iommu = core->fw.iommu_domain;
> + core->fw.mapped_mem_size = mem_size;
>
> ret = iommu_map(iommu, VENUS_FW_START_ADDR, mem_phys, mem_size,
> IOMMU_READ | IOMMU_WRITE |
Re: [PATCH 2/4] venus: core: corect maximum hardware load for sdm845
On Wed, Jan 9, 2019 at 5:46 PM Stanimir Varbanov
wrote:
>
> This corects maximum hardware load constant in per SoC resources
s/corect/correct. Same typo is present in patch title.
> for sdm845 aka Venus v4.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index cb411eb85ee4..d95185ea32c3 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -455,7 +455,7 @@ static const struct venus_resources msm8996_res = {
> .reg_tbl_size = ARRAY_SIZE(msm8996_reg_preset),
> .clks = {"core", "iface", "bus", "mbus" },
> .clks_num = 4,
> - .max_load = 2563200,
> + .max_load = 3110400,/* 4096x2160@90 */
> .hfi_version = HFI_VERSION_3XX,
> .vmem_id = VIDC_RESOURCE_NONE,
> .vmem_size = 0,
> --
> 2.17.1
>
Re: [PATCH 4/4] venus: helpers: drop setting of timestap invalid flag
On Wed, Jan 9, 2019 at 5:46 PM Stanimir Varbanov
wrote:
>
> The zero timestap is really a valid so not sure why I discarded it. Fix
s/timestap/timestamp, also in patch title.
> that mistake by drop the code which checks for zero timestamp.
s/drop/dropping
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/helpers.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> b/drivers/media/platform/qcom/venus/helpers.c
> index e436385bc5ab..5cad601d4c57 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -439,9 +439,6 @@ session_process_buf(struct venus_inst *inst, struct
> vb2_v4l2_buffer *vbuf)
> fdata.flags = 0;
> fdata.clnt_data = vbuf->vb2_buf.index;
>
> - if (!fdata.timestamp)
> - fdata.flags |= HFI_BUFFERFLAG_TIMESTAMPINVALID;
> -
> if (type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> fdata.buffer_type = HFI_BUFFER_INPUT;
> fdata.filled_len = vb2_get_plane_payload(vb, 0);
> --
> 2.17.1
>
Re: [PATCH 1/2] thermal/int340x_thermal: Add additional UUIDs
On 三, 2019-01-23 at 11:44 +1100, Joel Stanley wrote:
> Hello Rui,
>
> On Tue, 4 Dec 2018 at 02:12, Zhang Rui wrote:
> >
> > On 三, 2018-10-10 at 01:30 -0700, Matthew Garrett wrote:
> > >
> > > Platforms support more DPTF policies than the driver currently
> > > exposes.
> > > Add them. This effectively reverts
> > > 31908f45a583e8f21db37f402b6e8d5739945afd which removed several
> > > UUIDs
> > > without explaining why.
> > >
> > I'm going to apply this patch series, just with two minor changes,
> > 1. 31908f45a583e8f21db37f402b6e8d5739945afd does not follow the git
> > commit description style 'commit <12+ chars of sha1> (" > line>")'
> > 2. the UUIDs were removed previously because these policies were
> > not
> > used.
> Which tree did this series get applied to?
>
it is in my next branch, and I will queue it for 5.1.
https://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git/log/?h
=next
thanks,
rui
> Cheers,
>
> Joel
>
> >
> >
> > thanks,
> > rui
> >
> > >
> > > Signed-off-by: Matthew Garrett
> > > Cc: Zhang Rui
> > > Cc: Nisha Aram
> > > ---
> > > drivers/thermal/int340x_thermal/int3400_thermal.c | 14
> > > ++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c
> > > b/drivers/thermal/int340x_thermal/int3400_thermal.c
> > > index e26b01c05e82..51c9097eaf7a 100644
> > > --- a/drivers/thermal/int340x_thermal/int3400_thermal.c
> > > +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
> > > @@ -22,6 +22,13 @@ enum int3400_thermal_uuid {
> > > INT3400_THERMAL_PASSIVE_1,
> > > INT3400_THERMAL_ACTIVE,
> > > INT3400_THERMAL_CRITICAL,
> > > + INT3400_THERMAL_ADAPTIVE_PERFORMANCE,
> > > + INT3400_THERMAL_EMERGENCY_CALL_MODE,
> > > + INT3400_THERMAL_PASSIVE_2,
> > > + INT3400_THERMAL_POWER_BOSS,
> > > + INT3400_THERMAL_VIRTUAL_SENSOR,
> > > + INT3400_THERMAL_COOLING_MODE,
> > > + INT3400_THERMAL_HARDWARE_DUTY_CYCLING,
> > > INT3400_THERMAL_MAXIMUM_UUID,
> > > };
> > >
> > > @@ -29,6 +36,13 @@ static char
> > > *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
> > > "42A441D6-AE6A-462b-A84B-4A8CE79027D3",
> > > "3A95C389-E4B8-4629-A526-C52C88626BAE",
> > > "97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
> > > + "63BE270F-1C11-48FD-A6F7-3AF253FF3E2D",
> > > + "5349962F-71E6-431D-9AE8-0A635B710AEE",
> > > + "9E04115A-AE87-4D1C-9500-0F3E340BFE75",
> > > + "F5A35014-C209-46A4-993A-EB56DE7530A1",
> > > + "6ED722A7-9240-48A5-B479-31EEF723D7CF",
> > > + "16CAF1B7-DD38-40ED-B1C1-1B8A1913D531",
> > > + "BE84BABF-C4D4-403D-B495-3128FD44dAC1",
> > > };
> > >
> > > struct int3400_thermal_priv {
Re: kmemleak panic
On Tue, Jan 22, 2019 at 03:12:54PM +0100, Marc Gonzalez wrote:
> On 22/01/2019 15:02, Marc Gonzalez wrote:
>
> > On 21/01/2019 18:42, Mike Rapoport wrote:
> >
> >> If I understood correctly, the trouble comes from no-map range allocated
> >> in
> >> early_init_dt_alloc_reserved_memory_arch().
> >>
> >> There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(),
> >> but
> >> memblock_remove() does not do kmemleak_free().
> >>
> >> I think the best way is to replace __memblock_alloc_base() with
> >> memblock_find_in_range(), e.g something like:
> >>
> >>
> >> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> >> index 1977ee0adcb1..6807a1cffe55 100644
> >> --- a/drivers/of/of_reserved_mem.c
> >> +++ b/drivers/of/of_reserved_mem.c
> >> @@ -37,21 +37,16 @@ int __init __weak
> >> early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
> >> */
> >>end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
> >>align = !align ? SMP_CACHE_BYTES : align;
> >> - base = __memblock_alloc_base(size, align, end);
> >> + base = memblock_find_in_range(size, align, start, end);
> >>if (!base)
> >>return -ENOMEM;
> >>
> >> - /*
> >> - * Check if the allocated region fits in to start..end window
> >> - */
> >> - if (base < start) {
> >> - memblock_free(base, size);
> >> - return -ENOMEM;
> >> - }
> >> -
> >>*res_base = base;
> >>if (nomap)
> >>return memblock_remove(base, size);
> >> + else
> >> + return memblock_reserve(base, size);
> >> +
> >>return 0;
> >> }
> >>
> >
> > Your patch solves the issue. \o/
Great :)
> [ Add nvidia devs, but drop schowd...@nvidia.com ]
>
Resending it as a formal patch now, I took a liberty to add your Tested-by.
>From a847ca684db29a3c09e4dd2a8a008b35cf36e52f Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Wed, 23 Jan 2019 07:38:50 +0200
Subject: [PATCH] of: fix kmemleak crash caused by imbalance in early memory
reservation
Marc Gonzalez reported the following kmemleak crash:
Unable to handle kernel paging request at virtual address ffc021e0
Mem abort info:
ESR = 0x9606
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0006
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
[ffc021e0] pgd=00017e3ba803, pud=00017e3ba803,
pmd=
Internal error: Oops: 9606 [#1] PREEMPT SMP
Modules linked in:
CPU: 6 PID: 523 Comm: kmemleak Tainted: G S W 5.0.0-rc1 #13
Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
pstate: 8085 (Nzcv daIf -PAN -UAO)
pc : scan_block+0x70/0x190
lr : scan_block+0x6c/0x190
sp : ff8012e8bd20
x29: ff8012e8bd20 x28: ffc0fdbaf018
x27: ffc02200 x26: 0080
x25: ff8011aadf70 x24: ffc0f8cc8000
x23: ff8010dc8000 x22: ff8010dc8830
x21: ffc021e00ff9 x20: ffc0f8cc8050
x19: ffc021e0 x18: 2409
x17: 0200 x16:
x15: ff8010e14dd8 x14: 2406
x13: 4c4dd0c6 x12: ffc0f77dad58
x11: 0001 x10: ff8010d9e688
x9 : ff8010d9f000 x8 : ff8010d9e688
x7 : 0002 x6 :
x5 : ff8011511c20 x4 : 26d1
x3 : ff8010e14d88 x2 : 5b36396f4e7d4000
x1 : 00208040 x0 :
Process kmemleak (pid: 523, stack limit = 0x(ptrval))
Call trace:
scan_block+0x70/0x190
scan_gray_list+0x108/0x1c0
kmemleak_scan+0x33c/0x7c0
kmemleak_scan_thread+0x98/0xf0
kthread+0x11c/0x120
ret_from_fork+0x10/0x1c
Code: f9000fb4 d503201f 97d2 35000580 (f9400260)
---[ end trace 176d6ed9d86a0c33 ]---
note: kmemleak[523] exited with preempt_count 2
The crash happens when a no-map area is allocated in
early_init_dt_alloc_reserved_memory_arch(). The allocated region is
registered with kmemleak, but it is then removed from memblock using
memblock_remove() that is not kmemleak-aware.
Replacing __memblock_alloc_base() with memblock_find_in_range() makes sure
that the allocated memory is not added to kmemleak and then
memblock_remove()'ing this memory is safe.
As a bonus, since memblock_find_in_range() ensures the allocation in the
specified range, the bounds check can be removed.
Signed-off-by: Mike Rapoport
Tested-by: Marc Gonzalez
---
drivers/of/of_reserved_mem.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0adcb1..6807a1cffe55 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -37,21 +37,16 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
*/
end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
align = !align ? SMP_CACHE_BYTES : align;
- base = __memblock_alloc_base(size, align, end);
+ base = memblock_find_i
RE: [PATCH 6/7] scsi: qlogic: no need to check return value of debugfs_create functions
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Tuesday, January 22, 2019 8:39 PM
> To: James Bottomley ; Martin Petersen
>
> Cc: linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org; Greg Kroah-
> Hartman ; QLogic-Storage-
> upstr...@cavium.com
> Subject: [PATCH 6/7] scsi: qlogic: no need to check return value of
> debugfs_create functions
>
> External Email
>
> When calling debugfs functions, there is no need to ever check the return
> value. The function can work or not, but the code logic should never do
> something different based on this.
>
> Cc: qlogic-storage-upstr...@cavium.com
> Cc: "James E.J. Bottomley"
> Cc: "Martin K. Petersen"
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/scsi/qedf/qedf_debugfs.c | 18 ++
> drivers/scsi/qedi/qedi_debugfs.c | 17 ++---
> 2 files changed, 4 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/scsi/qedf/qedf_debugfs.c
> b/drivers/scsi/qedf/qedf_debugfs.c
> index c29c162a494f..a32d8ee4666e 100644
> --- a/drivers/scsi/qedf/qedf_debugfs.c
> +++ b/drivers/scsi/qedf/qedf_debugfs.c
> @@ -27,30 +27,19 @@ qedf_dbg_host_init(struct qedf_dbg_ctx *qedf,
> const struct file_operations *fops) {
> char host_dirname[32];
> - struct dentry *file_dentry = NULL;
>
> QEDF_INFO(qedf, QEDF_LOG_DEBUGFS, "Creating debugfs host
> node\n");
> /* create pf dir */
> sprintf(host_dirname, "host%u", qedf->host_no);
> qedf->bdf_dentry = debugfs_create_dir(host_dirname,
> qedf_dbg_root);
> - if (!qedf->bdf_dentry)
> - return;
>
> /* create debugfs files */
> while (dops) {
> if (!(dops->name))
> break;
>
> - file_dentry = debugfs_create_file(dops->name, 0600,
> - qedf->bdf_dentry, qedf,
> - fops);
> - if (!file_dentry) {
> - QEDF_INFO(qedf, QEDF_LOG_DEBUGFS,
> - "Debugfs entry %s creation failed\n",
> - dops->name);
> - debugfs_remove_recursive(qedf->bdf_dentry);
> - return;
> - }
> + debugfs_create_file(dops->name, 0600, qedf->bdf_dentry, qedf,
> + fops);
> dops++;
> fops++;
> }
> @@ -80,9 +69,6 @@ qedf_dbg_init(char *drv_name)
>
> /* create qed dir in root of debugfs. NULL means debugfs root */
> qedf_dbg_root = debugfs_create_dir(drv_name, NULL);
> - if (!qedf_dbg_root)
> - QEDF_INFO(NULL, QEDF_LOG_DEBUGFS, "Init of debugfs "
> - "failed\n");
> }
>
> /**
> diff --git a/drivers/scsi/qedi/qedi_debugfs.c
> b/drivers/scsi/qedi/qedi_debugfs.c
> index fd914ca4149a..5667e4752e2e 100644
> --- a/drivers/scsi/qedi/qedi_debugfs.c
> +++ b/drivers/scsi/qedi/qedi_debugfs.c
> @@ -23,27 +23,16 @@ qedi_dbg_host_init(struct qedi_dbg_ctx *qedi,
>const struct file_operations *fops) {
> char host_dirname[32];
> - struct dentry *file_dentry = NULL;
>
> sprintf(host_dirname, "host%u", qedi->host_no);
> qedi->bdf_dentry = debugfs_create_dir(host_dirname, qedi_dbg_root);
> - if (!qedi->bdf_dentry)
> - return;
>
> while (dops) {
> if (!(dops->name))
> break;
>
> - file_dentry = debugfs_create_file(dops->name, 0600,
> - qedi->bdf_dentry, qedi,
> - fops);
> - if (!file_dentry) {
> - QEDI_INFO(qedi, QEDI_LOG_DEBUGFS,
> - "Debugfs entry %s creation failed\n",
> - dops->name);
> - debugfs_remove_recursive(qedi->bdf_dentry);
> - return;
> - }
> + debugfs_create_file(dops->name, 0600, qedi->bdf_dentry, qedi,
> + fops);
> dops++;
> fops++;
> }
> @@ -60,8 +49,6 @@ void
> qedi_dbg_init(char *drv_name)
> {
> qedi_dbg_root = debugfs_create_dir(drv_name, NULL);
> - if (!qedi_dbg_root)
> - QEDI_INFO(NULL, QEDI_LOG_DEBUGFS, "Init of debugfs failed\n");
> }
>
> void
> --
> 2.20.1
Thanks
Acked-by: Manish Rangankar
linux-next: Fixes tag needs some work in the scsi-fixes tree
Hi Martin,
In commit
a8cf59a6692c ("scsi: communicate max segment size to the DMA mapping code")
Fixes tag
Fixes: 50c2e9107f ("scsi: introduce a max_segment_size host_template
parameters")
has these problem(s):
- SHA1 should be at least 12 digits long
--
Cheers,
Stephen Rothwell
pgpgG9mzGiJEM.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the omap-fixes tree
Hi Tony,
In commit
5a1826e1b175 ("ARM: dts: am335x-shc.dts: fix wrong cd pin level")
Fixes tag
Fixes: e63201f19438 ("mmc: omap_hsmmc: Delete platform data
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
In commit
0b30afcb8948 ("ARM: dts: n900: fix mmc1 card detect gpio polarity")
Fixes tag
Fixes: e63201f19438 ("mmc: omap_hsmmc: Delete platform data GPIO
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
Please do not split Fixes tags across more than one line.
--
Cheers,
Stephen Rothwell
pgp_MeI5RH_JN.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/2] media: docs-rst: Document memory-to-memory video decoder interface
On Tue, Jan 22, 2019 at 11:47 PM Hans Verkuil wrote: > > On 01/22/19 11:02, Tomasz Figa wrote: > > On Mon, Nov 12, 2018 at 8:37 PM Hans Verkuil wrote: > >> > >> Hi Tomasz, > >> > >> A general note for the stateful and stateless patches: they describe > >> specific > >> use-cases of the more generic Codec Interface, and as such should be one > >> level deeper in the section hierarchy. > > > > I wonder what exactly this Codec Interface is. Is it a historical name > > for mem2mem? If so, perhaps it would make sense to rename it? > > Yeah, it should be renamed to "Video Memory-to-Memory Interface", and the > codecs are just specific instances of such an interface. > Ack. > > > >> > >> I.e. instead of being section 4.6/7/8: > >> > >> https://hverkuil.home.xs4all.nl/request-api/uapi/v4l/devices.html > >> > >> they should be 4.5.1/2/3. > >> > > > > FYI, the first RFC started like that, but it only made the spec > > difficult to navigate and the section numbers too long. > > > > Still, no strong opinion. I'm okay moving it there, if you think it's > > better. > > It should be moved and the interface name should be renamed. It makes a lot > more sense with those changes. > > I've posted a patch for this. > Thanks. I've rebased on top of it. [snip] > >>> +3. Query the minimum number of buffers required for the ``CAPTURE`` > >>> queue via > >>> +:c:func:`VIDIOC_G_CTRL`. This is useful if the client intends to use > >>> more > >>> +buffers than the minimum required by hardware/format. > >> > >> Is this step optional or required? Can it change when a resolution change > >> occurs? > > > > Probably not with a simple resolution change, but a case when a stream > > is changed on the fly would trigger what we call "resolution change" > > here, but what would effectively be a "source change" and that could > > include a change in the number of required CAPTURE buffers. > > > >> How does this relate to the checks for the minimum number of buffers that > >> REQBUFS > >> does? > > > > The control returns the minimum that REQBUFS would allow, so the > > application can add few more buffers on top of that and improve the > > pipelining. > > > >> > >> The 'This is useful if' sentence suggests that it is optional, but I think > >> that > >> sentence just confuses the issue. > >> > > > > It used to be optional and I didn't rephrase it after turning it into > > mandatory. How about: > > > > This enables the client to request more buffers > > than the minimum required by hardware/format and achieve better > > pipelining. > > Hmm, OK. It'll do, I guess. I never liked these MIN_BUFFERS controls, I wish > they > would return something like the recommended number of buffers that will give > you > decent performance. > The problem here is that the kernel doesn't know what is decent for the application, since it doesn't know how the results of the decoding are used. Over-allocating would result to a waste of memory, which could then make it less than decent for memory-constrained applications. > > > >>> + > >>> +* **Required fields:** > >>> + > >>> + ``id`` > >>> + set to ``V4L2_CID_MIN_BUFFERS_FOR_CAPTURE`` > >>> + > >>> +* **Return fields:** > >>> + > >>> + ``value`` > >>> + minimum number of buffers required to decode the stream parsed > >>> in > >>> + this initialization sequence. > >>> + > >>> +.. note:: > >>> + > >>> + The minimum number of buffers must be at least the number > >>> required to > >>> + successfully decode the current stream. This may for example be > >>> the > >>> + required DPB size for an H.264 stream given the parsed stream > >>> + configuration (resolution, level). > >>> + > >>> +.. warning:: > >>> + > >>> + The value is guaranteed to be meaningful only after the decoder > >>> + successfully parses the stream metadata. The client must not rely > >>> on the > >>> + query before that happens. > >>> + > >>> +4. **Optional.** Enumerate ``CAPTURE`` formats via > >>> :c:func:`VIDIOC_ENUM_FMT` on > >>> +the ``CAPTURE`` queue. Once the stream information is parsed and > >>> known, the > >>> +client may use this ioctl to discover which raw formats are > >>> supported for > >>> +given stream and select one of them via :c:func:`VIDIOC_S_FMT`. > >> > >> Can the list returned here differ from the list returned in the 'Querying > >> capabilities' > >> step? If so, then I assume it will always be a subset of what was returned > >> in > >> the 'Querying' step? > > > > Depends on whether you're considering just VIDIOC_ENUM_FMT or also > > VIDIOC_G_FMT and VIDIOC_ENUM_FRAMESIZES. > > > > The initial VIDIOC_ENUM_FMT has no way to account for any resolution > > constraints of the formats, so the list would include all raw pixel > > formats that the decoder can handle with selected coded pixel format. > > However, the list can be further narrowed down by using > > VIDIOC_ENUM_FRAMESIZE
[PATCH] arm64: dts: ls1028a: Add Audio DT nodes
This patch adds Audio DT nodes for LS1028ARDB and LS1028AQDS boards.
Signed-off-by: Alison Wang
---
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 62
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 63 +
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi| 57 +++
3 files changed, 182 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index 14c79f4..139728e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -32,6 +32,49 @@
device_type = "memory";
reg = <0x0 0x8000 0x1 0x>;
};
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Speaker Ext",
+ "Line", "Line In Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "Microphone Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Speaker Ext", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&codec>;
+ frame-master;
+ bitclock-master;
+ system-clock-frequency = <2500>;
+ };
+ };
};
&duart0 {
@@ -89,5 +132,24 @@
reg = <0x57>;
};
};
+
+ i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x5>;
+
+ codec: sgtl5000@a {
+ #sound-dai-cells = <0>;
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ VDDA-supply = <®_1p8v>;
+ VDDIO-supply = <®_1p8v>;
+ clocks = <&sys_mclk>;
+ };
+ };
};
};
+
+&sai1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index fdeb417..1b3d5e3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -28,6 +28,49 @@
device_type = "memory";
reg = <0x0 0x8000 0x1 0x000>;
};
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Speaker Ext",
+ "Line", "Line In Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "Microphone Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Speaker Ext", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai4>;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&codec>;
+ frame-master;
+ bitclock-master;
+ system
linux-next: Tree for Jan 23
Hi all, Changes since 20190122: The vfs tree still had its build failure for which I applied a patch. The netfilter-next tree lost its build failures. The slave-dma tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 3027 3265 files changed, 99661 insertions(+), 65144 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 295 trees (counting Linus' and 69 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 (787a3b432276 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid) Merging fixes/master (d8d0c3a7f601 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (49a57857aeea Linux 5.0-rc3) Merging arc-current/for-curr (e6a72b7daeeb ARCv2: lib: memeset: fix doing prefetchw outside of buffer) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (7fa1e2e6afa7 kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (cb73ee40b1b3 net: ip_gre: use erspan key field for tunnel lookup) Merging bpf/master (e7c87bd6cc4e bpf: in __bpf_redirect_no_mac pull mac only if present) Merging ipsec/master (e2612cd496e7 xfrm: Make set-mark default behavior backward compatible) Merging netfilter/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (13e62626c578 wlcore: sdio: Fixup power on/off sequence) Merging mac80211/master (f9d672f1c2ca virt_wifi: fix error return code in virt_wifi_newlink()) Merging rdma-fixes/for-rc (d6f4a21f309d RDMA/uverbs: Mark ioctl responses with UVERBS_ATTR_F_VALID_OUTPUT) Merging sound-current/for-linus (699390381a7b ALSA: hda - Add mute LED support for HP ProBook 470 G5) Merging sound-asoc-fixes/for-linus (3e22c065356d Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (b3ffce399349 Merge branch 'regmap-5.0' into regmap-linus) Merging regulator-fixes/for-linus (6d7062d2d7b0 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (a0683b9a465b Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (d2fd6e81912a PCI: Fix __initdata issue with "pci=disable_acs_redir" parameter) Merging driver-core.current/driver-core-linus (3a34c986324c cacheinfo: Keep the old value if of_property_read_u32 fails) Merging tty.current/tty-linus (815d835b7ba4 serial: fsl_lpuart: fix maximum acceptable baud rate with over-sampling) Merging usb.current/usb-linus (4f9b83892781 Merge tag 'usb-serial-5.0-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus) Merging usb-gadget-fixes/fixes (87b6d2c
Re: [PATCH V3 7/9] x86/alternative: Batch of patch operations
Hi Daniel,
On Fri, 21 Dec 2018 11:27:32 +0100
Daniel Bristot de Oliveira wrote:
> Currently, the patch of an address is done in three steps:
>
> -- Pseudo-code #1 - Current implementation ---
> 1) add an int3 trap to the address that will be patched
> sync cores (send IPI to all other CPUs)
> 2) update all but the first byte of the patched range
> sync cores (send IPI to all other CPUs)
> 3) replace the first byte (int3) by the first byte of replacing opcode
> sync cores (send IPI to all other CPUs)
> -- Pseudo-code #1 ---
>
> When a static key has more than one entry, these steps are called once for
> each entry. The number of IPIs then is linear with regard to the number 'n' of
> entries of a key: O(n*3), which is O(n).
>
> This algorithm works fine for the update of a single key. But we think
> it is possible to optimize the case in which a static key has more than
> one entry. For instance, the sched_schedstats jump label has 56 entries
> in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
> which the thread that is enabling the key is _not_ running.
>
> With this patch, rather than receiving a single patch to be processed, a
> vector
> of patches is passed, enabling the rewrite of the pseudo-code #1 in this
> way:
>
> -- Pseudo-code #2 - This patch ---
> 1) for each patch in the vector:
> add an int3 trap to the address that will be patched
>
> sync cores (send IPI to all other CPUs)
>
> 2) for each patch in the vector:
> update all but the first byte of the patched range
>
> sync cores (send IPI to all other CPUs)
>
> 3) for each patch in the vector:
> replace the first byte (int3) by the first byte of replacing opcode
>
> sync cores (send IPI to all other CPUs)
> -- Pseudo-code #2 - This patch ---
>
> Doing the update in this way, the number of IPI becomes O(3) with regard
> to the number of keys, which is O(1).
>
> The batch mode is done with the function text_poke_bp_batch(), that receives
> two arguments: a vector of "struct text_to_poke", and the number of entries
> in the vector.
>
> The vector must be sorted by the addr field of the text_to_poke structure,
> enabling the binary search of a handler in the poke_int3_handler function
> (a fast path).
>
> Signed-off-by: Daniel Bristot de Oliveira
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Greg Kroah-Hartman
> Cc: Masami Hiramatsu
> Cc: "Steven Rostedt (VMware)"
> Cc: Jiri Kosina
> Cc: Josh Poimboeuf
> Cc: "Peter Zijlstra (Intel)"
> Cc: Chris von Recklinghausen
> Cc: Jason Baron
> Cc: Scott Wood
> Cc: Marcelo Tosatti
> Cc: Clark Williams
> Cc: x...@kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/x86/include/asm/text-patching.h | 15
> arch/x86/kernel/alternative.c| 108 +--
> 2 files changed, 117 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/include/asm/text-patching.h
> b/arch/x86/include/asm/text-patching.h
> index e85ff65c43c3..42ea7846df33 100644
> --- a/arch/x86/include/asm/text-patching.h
> +++ b/arch/x86/include/asm/text-patching.h
> @@ -18,6 +18,20 @@ static inline void apply_paravirt(struct
> paravirt_patch_site *start,
> #define __parainstructions_end NULL
> #endif
>
> +/*
> + * Currently, the max observed size in the kernel code is
> + * JUMP_LABEL_NOP_SIZE/RELATIVEJUMP_SIZE, which are 5.
> + * Raise it if needed.
> + */
> +#define POKE_MAX_OPCODE_SIZE 5
> +
> +struct text_to_poke {
> + void *handler;
> + void *addr;
> + size_t len;
> + const char opcode[POKE_MAX_OPCODE_SIZE];
> +};
> +
> extern void *text_poke_early(void *addr, const void *opcode, size_t len);
>
> /*
> @@ -37,6 +51,7 @@ extern void *text_poke_early(void *addr, const void
> *opcode, size_t len);
> extern void *text_poke(void *addr, const void *opcode, size_t len);
> extern int poke_int3_handler(struct pt_regs *regs);
> extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void
> *handler);
> +extern void text_poke_bp_batch(struct text_to_poke *tp, unsigned int
> nr_entries);
> extern int after_bootmem;
>
> #endif /* _ASM_X86_TEXT_PATCHING_H */
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 6f5ad8587de0..8fa47e5ec709 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> int __read_mostly alternatives_patched;
>
> @@ -738,10 +739,32 @@ static void do_sync_core(void *info)
> }
>
> static bool bp_patching_in_progress;
> +/*
> + * Single poke.
> + */
> static void *bp_int3_handler, *bp_int3_addr;
> +/*
> + * Batching poke.
> + */
> +static struct text_to_poke *bp_int3_tpv;
> +static unsigned int bp_int3_tpv_nr;
> +
> +static int text_bp_batch_bsearch(const void *key, const void *elt)
> +{
> + struct text_to_p
Re: [PATCH] brcm80211: no need to check return value of debugfs_create functions
Arend Van Spriel writes: > The prefix should be 'brcmsmac'. I can fix that during commit. -- Kalle Valo
Re: [PATCH] devlink: Use DIV_ROUND_UP_ULL in DEVLINK_HEALTH_SIZE_TO_BUFFERS
From: Nathan Chancellor
Date: Mon, 21 Jan 2019 21:23:01 -0700
> When building this code on a 32-bit platform such as ARM, there is a
> link time error (lld error shown, happpens with ld.bfd too):
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
referenced by devlink.c
net/core/devlink.o:(devlink_health_buffers_create) in
archive built-in.a
>
> This happens when using a regular division symbol with a u64 dividend.
> Use DIV_ROUND_UP_ULL, which wraps do_div, to avoid this situation.
>
> Fixes: cb5ccfbe73b3 ("devlink: Add health buffer support")
> Signed-off-by: Nathan Chancellor
Applied to net-next.
Re: [PATCH] net: fec: get regulator optional
From: Stefan Agner Date: Mon, 21 Jan 2019 15:58:47 +0100 > According to the device tree binding the phy-supply property is > optional. Use the regulator_get_optional API accordingly. The > code already handles NULL just fine. > > This gets rid of the following warning: > fec 2188000.ethernet: 2188000.ethernet supply phy not found, using dummy > regulator > > Signed-off-by: Stefan Agner Applied.
Re: [PATCH RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug is supported
Thanks Sudeep for reviewing. Please see my comment inline below. On Mon, Jan 21, 2019 at 4:52 PM Sudeep Holla wrote: > > On Mon, Jan 21, 2019 at 11:28:27AM +0530, Pramod Kumar wrote: > > On Fri, Jan 18, 2019 at 5:02 PM Sudeep Holla wrote: > > > On Fri, Jan 18, 2019 at 11:16:20AM +0530, Pramod Kumar wrote: > > > > If CPU hotplug is supported, ipi_cpu_stop should use PSCI cpudie > > > > call to stop the CPU. This call ensures L1/L2 cache flush, > > > > CPUs cache-cohenrecy setting w.r.to interconnect. > > > > > > Firstly, this is not specific to PSCI and I don't see any PSCI calls as > > > $subject claims. > > > > I had seen all the other cpu ops methods where only PSCI supports only > > cpu_die features hence used PSCI reference in my subject line to be more > > clear where this die gets converted in last. > > > > OK, but since you are not directly dealing with PSCI APIs, it's misleading. > I can re-phrase my commit message which links explanation to PSCI. > > > Next, you fail to explain why do you have to ensure > > > caches are cleaned and why do you need that in ipi_cpu_stop ? > > > What's the use case ? > > > > > Need comes from a specific use case where one Accelerator card(SoC) is > > plugged in a sever over a PCIe interface. This Card gets supply from a > > battery, which could provide very less power for a very small time, in case > > of any power loss. Once Card switches to battery, this has to reduce its > > power consumption to its lowest point and back-up the DDR contents asap > > before battery gets fully drained off. > > > > OK, but I was expecting the complete call path for this use-case. OK. Once power loss happens, Application processor gets interrupt and it has to switch to MCU asap so that it can switch-off all irrelevant power domain to reduce battery drain. flow is like this- Power loss interrupt --> interrupt handler -> send IPI to stop all secondary CPUs-> switch primary CPU to ATF which ultimately transition to MCU where all power off action is taken. > > > Since battery can provide limited power for a very short time hence need to > > transition to lowest power. As per the transition process , CPUs power > > domain has to be off but before that it needs to flush out its content to > > system memory(L3) so that content could be backed-up by a MCU, a controller > > consuming very less power. Since we can not afford plugging-out every > > individual CPUs in sequence hence uses ipi_cpu_stop for all other CPUs > > So, you are randomly using ipi_cpu_stop for something it's not supposed to > be used. What do you exactly want to achieve in that context where you need > to save power ? Need to back-up DDR from MCU which will require L1/L2 content gets flushed before CPUs getting shutdown. >Why system off or reset not sufficient ? System off or reset is not sufficient as we can not afford that much delay in transition. Flushing L1/L2 contents to System memory and Bringing out CPUs Clusters out of coherency domain before shutting down Clusters puts rest of system in sane state. If cluster are not being taken out properly from coherency domain before shutting down, it could lead system un-reliable for rest parts. > -- > Regards, > Sudeep >
Re: [PATCH] net/ipv6: lower the level of "link is not ready" messages
From: Lubomir Rintel Date: Mon, 21 Jan 2019 14:54:20 +0100 > This message gets logged far too often for how interesting is it. > > Most distributions nowadays configure NetworkManager to use randomly > generated MAC addresses for Wi-Fi network scans. The interfaces end up > being periodically brought down for the address change. When they're > subsequently brought back up, the message is logged, eventually flooding > the log. > > Perhaps the message is not all that helpful: it seems to be more > interesting to hear when the addrconf actually start, not when it does > not. Let's lower its level. > > Signed-off-by: Lubomir Rintel This has always bugged me too. Applied, thanks!
Re: [PATCH v2 2/2] mm, oom: remove 'prefer children over parent' heuristic
On Mon, Jan 21, 2019 at 10:50:32AM -0800, Shakeel Butt wrote: > From the start of the git history of Linux, the kernel after selecting > the worst process to be oom-killed, prefer to kill its child (if the > child does not share mm with the parent). Later it was changed to prefer > to kill a child who is worst. If the parent is still the worst then the > parent will be killed. > > This heuristic assumes that the children did less work than their parent > and by killing one of them, the work lost will be less. However this is > very workload dependent. If there is a workload which can benefit from > this heuristic, can use oom_score_adj to prefer children to be killed > before the parent. > > The select_bad_process() has already selected the worst process in the > system/memcg. There is no need to recheck the badness of its children > and hoping to find a worse candidate. That's a lot of unneeded racy > work. Also the heuristic is dangerous because it make fork bomb like > workloads to recover much later because we constantly pick and kill > processes which are not memory hogs. So, let's remove this whole > heuristic. This is a great cleanup, thanks! Acked-by: Roman Gushchin
Re: [PATCH 1/3] security: keys: annotate implicit fall through
On Mon, 14 Jan 2019, Mathieu Malaterre wrote: > There is a plan to build the kernel with -Wimplicit-fallthrough and > this place in the code produced a warning (W=1). > > This commit remove the following warning: > > security/keys/keyring.c:248:10: warning: this statement may fall through > [-Wimplicit-fallthrough=] > > Signed-off-by: Mathieu Malaterre All 3 applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general -- James Morris
