[PATCH] MAINTAINERS: edac: drop bouncing email
jetztechnologies.com doesn't exist anymore and emails to Ranganathan are bouncing. Signed-off-by: Alexandre Belloni --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a5b256b25905..424ae080b38a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5292,7 +5292,6 @@ S:Maintained F: drivers/edac/i82443bxgx_edac.c EDAC-I82975X -M: Ranganathan Desikan M: "Arvind R." L: linux-e...@vger.kernel.org S: Maintained -- 2.19.1
Re: [PATCH for-4.20-fixes] cgroup: fix CSS_TASK_ITER_PROCS
On Thu, Nov 08, 2018 at 12:15:15PM -0800, Tejun Heo wrote: > CSS_TASK_ITER_PROCS implements process-only iteration by making > css_task_iter_advance() skip tasks which aren't threadgroup leaders; > however, when an iteration is started css_task_iter_start() calls the > inner helper function css_task_iter_advance_css_set() instead of > css_task_iter_advance(). As the helper doesn't have the skip logic, > when the first task to visit is a non-leader thread, it doesn't get > skipped correctly as shown in the following example. Applied to cgroup/for-4.20-fixes. Thanks. -- tejun
Re: [PATCH 5/7] regulator: core: add enable_count for consumers to debug fs
On Mon, Nov 19, 2018 at 04:26:52PM -0800, Douglas Anderson wrote: > Now that consumers all keep track of their own enable count, let's add > it into the regulator_summary. This patch series contains a bunch of random stuff that's not particularly related to each other or even dependent on each other - it's better to just send unrelated things in unrelated threads, it makes it clear what actual dependencies exist, makes the serieses that are sent easier to understand and stops things getting blocked on unrelated changes earlier in the series. signature.asc Description: PGP signature
Re: [PATCH v2] cpuidle: big.LITTLE: add of_node_put()
On Wed, Nov 21, 2018 at 12:06 AM Rafael J. Wysocki wrote: > > On Tue, Nov 20, 2018 at 4:46 PM Yangtao Li wrote: > > > > The of_node_put() is missing.So we call the of_node_put() to release > > the refcount. > > I would say "of_find_node_by_path() acquires a reference to the node > returned by it and that reference needs to be dropped by its caller. > bl_idle_init() doesn't do that, so fix it." > > Thanks, > Rafael Hi Rafael： You are right, I will change it right away. Yours， Yangtao
Re: [PATCH v2] cpuidle: big.LITTLE: add of_node_put()
On Tue, Nov 20, 2018 at 4:46 PM Yangtao Li wrote: > > The of_node_put() is missing.So we call the of_node_put() to release > the refcount. I would say "of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. bl_idle_init() doesn't do that, so fix it." Thanks, Rafael
Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()
Hi, On Tue, Nov 20, 2018 at 7:55 AM Mark Brown wrote: > > On Mon, Nov 19, 2018 at 04:26:54PM -0800, Douglas Anderson wrote: > > In regulator_force_disable() there was a strange loop that looked like: > > > > while (rdev->open_count--) > > regulator_disable(rdev->supply); > > > > I'm not totally sure what the goal was for this loop, but it seems > > wrong to me. If anything I think maybe we should have been looping > > over our use_count, but even that might be a little strange. For now > > let's just remove the code and we can add something back in if someone > > can explain what's expected. > > This should be using use_count, what that loop is doing is dropping all > the enables that the regulator being force disabled had propagated up > all the enables it passed up the chain of supplies. OK, that makes much more sense then. I can adjust it to do that. I'll wait to see what happens with the rest of the patches in this series and then post up a v2 of this one. The number of disables needed depends on how many of the patches in my series you like. ;-) In general it's hard for me to reason about how the system in general should behave after regulator_force_disable() is called. Is it basically expected that the system will panic soon after? Specifically other consumers of the same regulator will think it's on but it won't actually be on. What should happen if one of those other consumers calls disable/enable? Should the regulator turn back on? ...or is the regulator permanently off until the system reboots? -Doug
Re: [PATCH v9 05/17] tpm: declare struct tpm_header
On Tue, Nov 20, 2018 at 03:08:05PM +0200, Jarkko Sakkinen wrote:
> On Mon, Nov 19, 2018 at 09:33:31PM +, Winkler, Tomas wrote:
> >
> > >
> > > Decleare struct tpm_header that replaces struct tpm_input_header and
> > Typo
>
> Thanks, will fix for the next version.
>
> > > struct tpm_output_header.
> > >
> > > Signed-off-by: Jarkko Sakkinen
> > > Reviewed-by: Stefan Berger
> > > drivers/char/tpm/tpm-interface.c | 9 -
> > > drivers/char/tpm/tpm.h| 27 ---
> > > drivers/char/tpm/tpm2-cmd.c | 4 ++--
> > > drivers/char/tpm/tpm2-space.c | 6 +++---
> > > drivers/char/tpm/tpm_i2c_atmel.c | 5 ++---
> > > drivers/char/tpm/tpm_vtpm_proxy.c | 8
> > > drivers/char/tpm/xen-tpmfront.c | 2 +-
> > > 7 files changed, 28 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> > > interface.c
> > > index 7ac6ada8428c..cb0d44c158ae 100644
> > > +++ b/drivers/char/tpm/tpm-interface.c
> > > @@ -67,7 +67,7 @@ static int tpm_validate_command(struct tpm_chip
> > > *chip,
> > >const u8 *cmd,
> > >size_t len)
> > > {
> > > - const struct tpm_input_header *header = (const void *)cmd;
> > > + const struct tpm_header *header = (const void *)cmd;
> >
> >
> > Sometimes it is casted (void *), sometimes (struct tpm_header *)
> > Better to use one convention
>
> I would prefer (const void *) because it is shorter form, and no
> need to duplicate the type name two times, that way also more
> readable. Anyway, agreed that we do have inconsistency with these.
It is better to pass in 'const void *cmd' than to explicitly cast like
this.
I generally discourage casts to voids to save typing, just creates
confusion what is going on. Better to try to avoid casts by
constructing the code properly.
Jason
[PATCH v1 04/15] platform/x86: i2c-mutli-instantiate: Defer probe when no adapter found
Likewise the rest of the i2c_acpi_new_device() users, defer the probe
of the i2c-multi-intantiate driver in case adapter is not yet found.
Signed-off-by: Andy Shevchenko
---
drivers/platform/x86/i2c-multi-instantiate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index e3345da82c84..16a0eabe1e31 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -75,7 +75,7 @@ static int i2c_multi_inst_probe(struct platform_device *pdev)
if (IS_ERR(multi->clients[i]))
ret = PTR_ERR(multi->clients[i]);
else if (!multi->clients[i])
- ret = -ENODEV;
+ ret = -EPROBE_DEFER; /* Wait for i2c-adapter to load */
else
ret = 0;
if (ret) {
--
2.19.1
[PATCH v1 00/15] i2c-multi-instantiate: Adapt for INT3515 and alike
Currently i2c-multi-instantiate driver does not support the case of INT3515 USB PD device, where: - Interrupt() is used instead of GpioInt() - All slaves may be the same from IP point of view - There can be variadic amount of slaves This series is addressing all above. Notes: - series has been smoke tested (Heikki would do BAT or more) on Coffee Lake system - patch for BOSC0200 might be considered as RFC since the modalias potential issue The idea is to push this either through PDx86 tree (needs Rafael's ACKs) or ACPI. In any case it needs tags from Heikki, Hans, Mika, Wolfram and Jonathan. Testing and comments are warmly welcome. Andy Shevchenko (15): platform/x86: intel_cht_int33fe: Remove duplicate NULL check platform/x86: intel_cht_int33fe: Accept errors of i2c_acpi_new_device() platform/x86: i2c-multi-instantiate: Accept errors of i2c_acpi_new_device() platform/x86: i2c-mutli-instantiate: Defer probe when no adapter found i2c: acpi: Return error pointers from i2c_acpi_new_device() i2c: acpi: Assign fwnode for devices created via i2c_acpi_new_device() i2c: acpi: Use ACPI_FAILURE instead of !ACPI_SUCCESS i2c: acpi: Introduce i2c_acpi_get_i2c_resource() helper platform/x86: i2c-multi-instantiate: Count I2cSerialBus() resources platform/x86: i2c-multi-instantiate: Distinguish IRQ resource type platform/x86: i2c-multi-instantiate: Introduce IOAPIC IRQ support platform/x86: i2c-multi-instantiate: Allow to have same slaves ACPI / scan: Create platform device for INT3515 ACPI nodes ACPI / scan: Create platform device for BOSC0200 ACPI nodes iio: inv_mpu6050: Use i2c_acpi_get_i2c_resource() helper drivers/acpi/scan.c | 2 + drivers/i2c/i2c-core-acpi.c | 43 + drivers/iio/accel/bmc150-accel-i2c.c | 1 - drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 16 ++-- drivers/platform/x86/i2c-multi-instantiate.c | 99 drivers/platform/x86/intel_cht_int33fe.c | 34 +-- drivers/usb/typec/tps6598x.c | 8 +- include/linux/acpi.h | 11 +++ 8 files changed, 158 insertions(+), 56 deletions(-) -- 2.19.1
[PATCH v1 02/15] platform/x86: intel_cht_int33fe: Accept errors of i2c_acpi_new_device()
In the future i2c_acpi_new_device() will return error pointer in some cases. Prepare i2c-multi-instantiate driver to support that. Signed-off-by: Andy Shevchenko --- drivers/platform/x86/intel_cht_int33fe.c | 28 +++- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c index 431151d4e611..367d6e304ade 100644 --- a/drivers/platform/x86/intel_cht_int33fe.c +++ b/drivers/platform/x86/intel_cht_int33fe.c @@ -168,8 +168,14 @@ static int cht_int33fe_probe(struct platform_device *pdev) board_info.dev_name = "max17047"; board_info.properties = max17047_props; data->max17047 = i2c_acpi_new_device(dev, 1, &board_info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for i2c-adapter to load */ + if (IS_ERR(data->max17047)) + ret = PTR_ERR(data->max17047); + else if (!data->max17047) + ret = -EPROBE_DEFER; /* Wait for i2c-adapter to load */ + else + ret = 0; + if (ret) + return ret; } data->connections[0].endpoint[0] = "port0"; @@ -194,7 +200,13 @@ static int cht_int33fe_probe(struct platform_device *pdev) board_info.irq = fusb302_irq; data->fusb302 = i2c_acpi_new_device(dev, 2, &board_info); - if (!data->fusb302) + if (IS_ERR(data->fusb302)) + ret = PTR_ERR(data->fusb302); + else if (!data->fusb302) + ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + else + ret = 0; + if (ret) goto out_unregister_max17047; memset(&board_info, 0, sizeof(board_info)); @@ -202,7 +214,13 @@ static int cht_int33fe_probe(struct platform_device *pdev) strlcpy(board_info.type, "pi3usb30532", I2C_NAME_SIZE); data->pi3usb30532 = i2c_acpi_new_device(dev, 3, &board_info); - if (!data->pi3usb30532) + if (IS_ERR(data->pi3usb30532)) + ret = PTR_ERR(data->pi3usb30532); + else if (!data->pi3usb30532) + ret = -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + else + ret = 0; + if (ret) goto out_unregister_fusb302; platform_set_drvdata(pdev, data); @@ -217,7 +235,7 @@ static int cht_int33fe_probe(struct platform_device *pdev) device_connections_remove(data->connections); - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + return ret; } static int cht_int33fe_remove(struct platform_device *pdev) -- 2.19.1
[PATCH v1 11/15] platform/x86: i2c-multi-instantiate: Introduce IOAPIC IRQ support
If ACPI table provides an Interrupt() resource we may consider to use it
instead of GpioInt() one.
Here we leave an error condition, when getting IRQ resource, to the driver
to decide how to proceed, because some drivers may consider IRQ resource
optional.
Signed-off-by: Andy Shevchenko
---
drivers/platform/x86/i2c-multi-instantiate.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index 336ef28e072d..3334fafb4d8c 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -18,6 +18,7 @@
#define IRQ_RESOURCE_TYPE GENMASK(1, 0)
#define IRQ_RESOURCE_NONE 0
#define IRQ_RESOURCE_GPIO 1
+#define IRQ_RESOURCE_APIC 2
struct i2c_inst_data {
const char *type;
@@ -104,6 +105,14 @@ static int i2c_multi_inst_probe(struct platform_device
*pdev)
}
board_info.irq = ret;
break;
+ case IRQ_RESOURCE_APIC:
+ ret = platform_get_irq(pdev, inst_data[i].irq_idx);
+ if (ret < 0) {
+ dev_dbg(dev, "Error requesting irq at index %d:
%d\n",
+ inst_data[i].irq_idx, ret);
+ }
+ board_info.irq = ret;
+ break;
default:
board_info.irq = 0;
break;
--
2.19.1
[PATCH v1 07/15] i2c: acpi: Use ACPI_FAILURE instead of !ACPI_SUCCESS
Convert to use ACPI_FAILURE instead of !ACPI_SUCCESS. Signed-off-by: Andy Shevchenko --- drivers/i2c/i2c-core-acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c index 478862abb82a..99553b1469b4 100644 --- a/drivers/i2c/i2c-core-acpi.c +++ b/drivers/i2c/i2c-core-acpi.c @@ -65,7 +65,7 @@ static int i2c_acpi_fill_info(struct acpi_resource *ares, void *data) status = acpi_get_handle(lookup->device_handle, sb->resource_source.string_ptr, &lookup->adapter_handle); - if (!ACPI_SUCCESS(status)) + if (ACPI_FAILURE(status)) return 1; info->addr = sb->slave_address; -- 2.19.1
[PATCH v1 08/15] i2c: acpi: Introduce i2c_acpi_get_i2c_resource() helper
Besides current two users one more is coming. Definitely makes sense to
introduce a helper.
No functional change intended.
Signed-off-by: Andy Shevchenko
---
drivers/i2c/i2c-core-acpi.c | 31 +++
include/linux/acpi.h| 11 +++
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 99553b1469b4..59b8b191d752 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -45,6 +45,23 @@ struct i2c_acpi_lookup {
u32 min_speed;
};
+bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
+ struct acpi_resource_i2c_serialbus **i2c)
+{
+ struct acpi_resource_i2c_serialbus *sb;
+
+ if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
+ return false;
+
+ sb = &ares->data.i2c_serial_bus;
+ if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+ return false;
+
+ *i2c = sb;
+ return true;
+}
+EXPORT_SYMBOL_GPL(i2c_acpi_get_i2c_resource);
+
static int i2c_acpi_fill_info(struct acpi_resource *ares, void *data)
{
struct i2c_acpi_lookup *lookup = data;
@@ -52,11 +69,7 @@ static int i2c_acpi_fill_info(struct acpi_resource *ares,
void *data)
struct acpi_resource_i2c_serialbus *sb;
acpi_status status;
- if (info->addr || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
- return 1;
-
- sb = &ares->data.i2c_serial_bus;
- if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+ if (info->addr || !i2c_acpi_get_i2c_resource(ares, &sb))
return 1;
if (lookup->index != -1 && lookup->n++ != lookup->index)
@@ -529,13 +542,7 @@ i2c_acpi_space_handler(u32 function, acpi_physical_address
command,
goto err;
}
- if (!value64 || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- ret = AE_BAD_PARAMETER;
- goto err;
- }
-
- sb = &ares->data.i2c_serial_bus;
- if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C) {
+ if (!value64 || !i2c_acpi_get_i2c_resource(ares, &sb)) {
ret = AE_BAD_PARAMETER;
goto err;
}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index ed80f147bd50..6afc6e3c4c5c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1054,6 +1054,17 @@ static inline int acpi_dev_gpio_irq_get(struct
acpi_device *adev, int index)
}
#endif
+#if defined(CONFIG_ACPI) && IS_ENABLED(CONFIG_I2C)
+bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
+ struct acpi_resource_i2c_serialbus **i2c);
+#else
+static inline bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
+struct acpi_resource_i2c_serialbus
**i2c)
+{
+ return false;
+}
+#endif
+
/* Device properties */
#ifdef CONFIG_ACPI
--
2.19.1
[PATCH v1 13/15] ACPI / scan: Create platform device for INT3515 ACPI nodes
The ACPI device with INT3515 _HID is representing a complex USB PD
hardware infrastructure which includes several I2C slave ICs.
We add an ID to the I2C multi instantiate list to enumerate
all I2C slaves correctly.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/scan.c | 1 +
drivers/platform/x86/i2c-multi-instantiate.c | 9 +
drivers/usb/typec/tps6598x.c | 8
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index bd1c59fb0e17..e9eda5558c1f 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1541,6 +1541,7 @@ static bool acpi_device_enumeration_by_parent(struct
acpi_device *device)
static const struct acpi_device_id i2c_multi_instantiate_ids[] = {
{"BSG1160", },
{"INT33FE", },
+ {"INT3515", },
{}
};
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index 1e078a961245..efaf34cbbc7b 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -158,12 +158,21 @@ static const struct i2c_inst_data bsg1160_data[] = {
{}
};
+static const struct i2c_inst_data int3515_data[] = {
+ { "tps6598x", IRQ_RESOURCE_APIC, 0 },
+ { "tps6598x", IRQ_RESOURCE_APIC, 1 },
+ { "tps6598x", IRQ_RESOURCE_APIC, 2 },
+ { "tps6598x", IRQ_RESOURCE_APIC, 3 },
+ {}
+};
+
/*
* Note new device-ids must also be added to i2c_multi_instantiate_ids in
* drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
*/
static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
{ "BSG1160", (unsigned long)bsg1160_data },
+ { "INT3515", (unsigned long)int3515_data },
{ }
};
MODULE_DEVICE_TABLE(acpi, i2c_multi_inst_acpi_ids);
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index c84c8c189e90..1c0033ad8738 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -501,19 +501,19 @@ static int tps6598x_remove(struct i2c_client *client)
return 0;
}
-static const struct acpi_device_id tps6598x_acpi_match[] = {
- { "INT3515", 0 },
+static const struct i2c_device_id tps6598x_id[] = {
+ { "tps6598x" },
{ }
};
-MODULE_DEVICE_TABLE(acpi, tps6598x_acpi_match);
+MODULE_DEVICE_TABLE(i2c, tps6598x_id);
static struct i2c_driver tps6598x_i2c_driver = {
.driver = {
.name = "tps6598x",
- .acpi_match_table = tps6598x_acpi_match,
},
.probe_new = tps6598x_probe,
.remove = tps6598x_remove,
+ .id_table = tps6598x_id,
};
module_i2c_driver(tps6598x_i2c_driver);
--
2.19.1
[PATCH v1 14/15] ACPI / scan: Create platform device for BOSC0200 ACPI nodes
On some laptops the ACPI device with BOSC0200 _HID is representing
two accelerometers under one node.
We add an ID to the I2C multi instantiate list to enumerate
all I2C slaves correctly.
For reference here is the relevant DSDT blurb from the Yoga 11e:
Device (ACC)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "BOSC0200") // _HID: Hardware ID
Name (_CID, "BOSC0200") // _CID: Compatible ID
Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
I2cSerialBusV2 (0x0018, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
})
Return (RBUF) /* \_SB_.PCI0.I2C3.ACC_._CRS.RBUF */
}
Reported-by: Jeremy Cline
Cc: Steven Presser
Signed-off-by: Andy Shevchenko
---
drivers/acpi/scan.c | 1 +
drivers/iio/accel/bmc150-accel-i2c.c | 1 -
drivers/platform/x86/i2c-multi-instantiate.c | 7 +++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index e9eda5558c1f..e46c877fa9f1 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1539,6 +1539,7 @@ static bool acpi_device_enumeration_by_parent(struct
acpi_device *device)
* which i2c_device_id to use for each resource.
*/
static const struct acpi_device_id i2c_multi_instantiate_ids[] = {
+ {"BOSC0200", },
{"BSG1160", },
{"INT33FE", },
{"INT3515", },
diff --git a/drivers/iio/accel/bmc150-accel-i2c.c
b/drivers/iio/accel/bmc150-accel-i2c.c
index 8ffc308d5fd0..9d22a4d9d568 100644
--- a/drivers/iio/accel/bmc150-accel-i2c.c
+++ b/drivers/iio/accel/bmc150-accel-i2c.c
@@ -64,7 +64,6 @@ static const struct acpi_device_id bmc150_accel_acpi_match[]
= {
{"BMA250E", bma250e},
{"BMA222E", bma222e},
{"BMA0280", bma280},
- {"BOSC0200"},
{ },
};
MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index efaf34cbbc7b..c90137d30a98 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -151,6 +151,12 @@ static int i2c_multi_inst_remove(struct platform_device
*pdev)
return 0;
}
+static const struct i2c_inst_data bosc0200_data[] = {
+ { "bmc150_accel" },
+ { "bmc150_accel" },
+ {}
+};
+
static const struct i2c_inst_data bsg1160_data[] = {
{ "bmc150_accel", IRQ_RESOURCE_GPIO, 0 },
{ "bmc150_magn" },
@@ -171,6 +177,7 @@ static const struct i2c_inst_data int3515_data[] = {
* drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
*/
static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
+ { "BOSC0200", (unsigned long)bosc0200_data },
{ "BSG1160", (unsigned long)bsg1160_data },
{ "INT3515", (unsigned long)int3515_data },
{ }
--
2.19.1
[PATCH v1 09/15] platform/x86: i2c-multi-instantiate: Count I2cSerialBus() resources
Instead of relying on hard coded and thus expected number of I2C clients,
count the real amount provided by firmware.
This allows to support non-fixed amount of the slaves.
Signed-off-by: Andy Shevchenko
---
drivers/platform/x86/i2c-multi-instantiate.c | 34 ++--
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index 16a0eabe1e31..d17686e10d08 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
struct i2c_inst_data {
const char *type;
@@ -23,6 +24,31 @@ struct i2c_multi_inst_data {
struct i2c_client *clients[0];
};
+static int i2c_multi_inst_count(struct acpi_resource *ares, void *data)
+{
+ struct acpi_resource_i2c_serialbus *sb;
+ int *count = data;
+
+ if (i2c_acpi_get_i2c_resource(ares, &sb))
+ *count = *count + 1;
+
+ return 1;
+}
+
+static int i2c_multi_inst_count_resources(struct acpi_device *adev)
+{
+ LIST_HEAD(r);
+ int count = 0;
+ int ret;
+
+ ret = acpi_dev_get_resources(adev, &r, i2c_multi_inst_count, &count);
+ if (ret < 0)
+ return ret;
+
+ acpi_dev_free_resource_list(&r);
+ return count;
+}
+
static int i2c_multi_inst_probe(struct platform_device *pdev)
{
struct i2c_multi_inst_data *multi;
@@ -44,15 +70,17 @@ static int i2c_multi_inst_probe(struct platform_device
*pdev)
adev = ACPI_COMPANION(dev);
/* Count number of clients to instantiate */
- for (i = 0; inst_data[i].type; i++) {}
+ ret = i2c_multi_inst_count_resources(adev);
+ if (ret < 0)
+ return ret;
multi = devm_kmalloc(dev,
- offsetof(struct i2c_multi_inst_data, clients[i]),
+ offsetof(struct i2c_multi_inst_data, clients[ret]),
GFP_KERNEL);
if (!multi)
return -ENOMEM;
- multi->num_clients = i;
+ multi->num_clients = ret;
for (i = 0; i < multi->num_clients; i++) {
memset(&board_info, 0, sizeof(board_info));
--
2.19.1
Re: [PATCH 2/7] regulator: core: Don't assume always_on when is_enabled returns err
On Mon, Nov 19, 2018 at 04:26:49PM -0800, Douglas Anderson wrote: > At boot sometimes regulators (like qcom-rpmh-regulator) will return > -EINVAL if we don't know the enable state of the regulator. We > shouldn't take this to mean that the regulator is an always-on > regulator, but that was what was happening since "-EINVAL" is non-zero > and a few places in the code were not properly checking for errors. This still results in breakage - if the regulator fails to read when we're initializing then we won't flag the regualtor as always_on, the regulator would need to tell the framework when it becomes readable. This hardware really is fragile :( signature.asc Description: PGP signature
[PATCH v1 06/15] i2c: acpi: Assign fwnode for devices created via i2c_acpi_new_device()
i2c_acpi_new_device() doesn't assign fwnode like it's done, for example, in i2c_acpi_register_devices() path. Assign fwnode in i2c_acpi_new_device() as it's done elsewhere. Signed-off-by: Andy Shevchenko --- drivers/i2c/i2c-core-acpi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c index af4b5bd5d973..478862abb82a 100644 --- a/drivers/i2c/i2c-core-acpi.c +++ b/drivers/i2c/i2c-core-acpi.c @@ -420,6 +420,7 @@ struct i2c_client *i2c_acpi_new_device(struct device *dev, int index, if (!adapter) return NULL; + info->fwnode = acpi_fwnode_handle(adev); return i2c_new_device(adapter, info); } EXPORT_SYMBOL_GPL(i2c_acpi_new_device); -- 2.19.1
[PATCH v1 12/15] platform/x86: i2c-multi-instantiate: Allow to have same slaves
Currently the driver will not enumerate the devices where I2C slaves
are of the same type.
Add an instance number to make them unique.
Signed-off-by: Andy Shevchenko
---
drivers/platform/x86/i2c-multi-instantiate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index 3334fafb4d8c..1e078a961245 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -92,8 +92,8 @@ static int i2c_multi_inst_probe(struct platform_device *pdev)
for (i = 0; i < multi->num_clients; i++) {
memset(&board_info, 0, sizeof(board_info));
strlcpy(board_info.type, inst_data[i].type, I2C_NAME_SIZE);
- snprintf(name, sizeof(name), "%s-%s", match->id,
-inst_data[i].type);
+ snprintf(name, sizeof(name), "%s-%s.%d", match->id,
+inst_data[i].type, i);
board_info.dev_name = name;
switch (inst_data[i].flags & IRQ_RESOURCE_TYPE) {
case IRQ_RESOURCE_GPIO:
--
2.19.1
[PATCH v1 15/15] iio: inv_mpu6050: Use i2c_acpi_get_i2c_resource() helper
ACPI provides a generic helper to get I2C Serial Bus resources.
Use it instead of open coded variant.
Signed-off-by: Andy Shevchenko
---
drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
index d78a10403bac..a961b5a06fe6 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
@@ -91,18 +91,14 @@ static int asus_acpi_get_sensor_info(struct acpi_device
*adev,
static int acpi_i2c_check_resource(struct acpi_resource *ares, void *data)
{
+ struct acpi_resource_i2c_serialbus *sb;
u32 *addr = data;
- if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
-
- sb = &ares->data.i2c_serial_bus;
- if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- if (*addr)
- *addr |= (sb->slave_address << 16);
- else
- *addr = sb->slave_address;
- }
+ if (i2c_acpi_get_i2c_resource(ares, &sb)) {
+ if (*addr)
+ *addr |= (sb->slave_address << 16);
+ else
+ *addr = sb->slave_address;
}
/* Tell the ACPI core that we already copied this address */
--
2.19.1
[PATCH v1 01/15] platform/x86: intel_cht_int33fe: Remove duplicate NULL check
Since i2c_unregister_device() became NULL-aware we may remove duplicate NULL check. Signed-off-by: Andy Shevchenko --- drivers/platform/x86/intel_cht_int33fe.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c index 464fe93657b5..431151d4e611 100644 --- a/drivers/platform/x86/intel_cht_int33fe.c +++ b/drivers/platform/x86/intel_cht_int33fe.c @@ -213,8 +213,7 @@ static int cht_int33fe_probe(struct platform_device *pdev) i2c_unregister_device(data->fusb302); out_unregister_max17047: - if (data->max17047) - i2c_unregister_device(data->max17047); + i2c_unregister_device(data->max17047); device_connections_remove(data->connections); @@ -227,8 +226,7 @@ static int cht_int33fe_remove(struct platform_device *pdev) i2c_unregister_device(data->pi3usb30532); i2c_unregister_device(data->fusb302); - if (data->max17047) - i2c_unregister_device(data->max17047); + i2c_unregister_device(data->max17047); device_connections_remove(data->connections); -- 2.19.1
[PATCH v1 05/15] i2c: acpi: Return error pointers from i2c_acpi_new_device()
The caller would like to know the reason why the i2c_acpi_new_device() fails.
For example, if adapter is not available, it might be in the future and we
would like to re-probe the clients again. But at the same time we would like to
bail out if the error seems unrecoverable, such as out of memory condition.
To achieve this, return error pointer in some cases.
Signed-off-by: Andy Shevchenko
---
drivers/i2c/i2c-core-acpi.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 32affd3fa8bd..af4b5bd5d973 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -387,6 +387,7 @@ struct notifier_block i2c_acpi_notifier = {
* Also see i2c_new_device, which this function calls to create the i2c-client.
*
* Returns a pointer to the new i2c-client, or NULL if the adapter is not
found.
+ * In some cases might return an error pointer.
*/
struct i2c_client *i2c_acpi_new_device(struct device *dev, int index,
struct i2c_board_info *info)
@@ -399,7 +400,7 @@ struct i2c_client *i2c_acpi_new_device(struct device *dev,
int index,
adev = ACPI_COMPANION(dev);
if (!adev)
- return NULL;
+ return ERR_PTR(-ENODEV);
memset(&lookup, 0, sizeof(lookup));
lookup.info = info;
@@ -409,9 +410,11 @@ struct i2c_client *i2c_acpi_new_device(struct device *dev,
int index,
ret = acpi_dev_get_resources(adev, &resource_list,
i2c_acpi_fill_info, &lookup);
acpi_dev_free_resource_list(&resource_list);
+ if (ret < 0)
+ return ERR_PTR(ret);
- if (ret < 0 || !info->addr)
- return NULL;
+ if (!info->addr)
+ return ERR_PTR(-EADDRNOTAVAIL);
adapter = i2c_acpi_find_adapter_by_handle(lookup.adapter_handle);
if (!adapter)
--
2.19.1
[PATCH v1 10/15] platform/x86: i2c-multi-instantiate: Distinguish IRQ resource type
As a preparatory patch switch the driver to distinguish IRQ resource type.
For now, only GpioInt() is supported.
Signed-off-by: Andy Shevchenko
---
drivers/platform/x86/i2c-multi-instantiate.c | 27 +---
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index d17686e10d08..336ef28e072d 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,9 +15,14 @@
#include
#include
+#define IRQ_RESOURCE_TYPE GENMASK(1, 0)
+#define IRQ_RESOURCE_NONE 0
+#define IRQ_RESOURCE_GPIO 1
+
struct i2c_inst_data {
const char *type;
- int gpio_irq_idx;
+ unsigned int flags;
+ int irq_idx;
};
struct i2c_multi_inst_data {
@@ -88,16 +94,19 @@ static int i2c_multi_inst_probe(struct platform_device
*pdev)
snprintf(name, sizeof(name), "%s-%s", match->id,
inst_data[i].type);
board_info.dev_name = name;
- board_info.irq = 0;
- if (inst_data[i].gpio_irq_idx != -1) {
- ret = acpi_dev_gpio_irq_get(adev,
- inst_data[i].gpio_irq_idx);
+ switch (inst_data[i].flags & IRQ_RESOURCE_TYPE) {
+ case IRQ_RESOURCE_GPIO:
+ ret = acpi_dev_gpio_irq_get(adev, inst_data[i].irq_idx);
if (ret < 0) {
dev_err(dev, "Error requesting irq at index %d:
%d\n",
- inst_data[i].gpio_irq_idx, ret);
+ inst_data[i].irq_idx, ret);
goto error;
}
board_info.irq = ret;
+ break;
+ default:
+ board_info.irq = 0;
+ break;
}
multi->clients[i] = i2c_acpi_new_device(dev, i, &board_info);
if (IS_ERR(multi->clients[i]))
@@ -134,9 +143,9 @@ static int i2c_multi_inst_remove(struct platform_device
*pdev)
}
static const struct i2c_inst_data bsg1160_data[] = {
- { "bmc150_accel", 0 },
- { "bmc150_magn", -1 },
- { "bmg160", -1 },
+ { "bmc150_accel", IRQ_RESOURCE_GPIO, 0 },
+ { "bmc150_magn" },
+ { "bmg160" },
{}
};
--
2.19.1
[PATCH v1 03/15] platform/x86: i2c-multi-instantiate: Accept errors of i2c_acpi_new_device()
In the future i2c_acpi_new_device() will return error pointer in some cases.
Prepare i2c-multi-instantiate driver to support that.
Signed-off-by: Andy Shevchenko
---
drivers/platform/x86/i2c-multi-instantiate.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
b/drivers/platform/x86/i2c-multi-instantiate.c
index 5456581b473c..e3345da82c84 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -72,9 +72,14 @@ static int i2c_multi_inst_probe(struct platform_device *pdev)
board_info.irq = ret;
}
multi->clients[i] = i2c_acpi_new_device(dev, i, &board_info);
- if (!multi->clients[i]) {
- dev_err(dev, "Error creating i2c-client, idx %d\n", i);
+ if (IS_ERR(multi->clients[i]))
+ ret = PTR_ERR(multi->clients[i]);
+ else if (!multi->clients[i])
ret = -ENODEV;
+ else
+ ret = 0;
+ if (ret) {
+ dev_err(dev, "Error creating i2c-client, idx %d\n", i);
goto error;
}
}
--
2.19.1
Re: Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree
Hi Charles, On 2018-11-20 16:36, Charles Keepax wrote: > On Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote: >> On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote: >>> On 2018-11-20 15:47, Charles Keepax wrote: On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote: > On 2018-05-17 18:41, Mark Brown wrote: >> Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO >> number > This patch causes following kernel warning on Samsung Exynos4412 based > Trats2 board: > > wm8994 4-001a: Failed to get supply 'DBVDD1': -517 > wm8994 4-001a: Failed to get supplies: -517 >> This is really weird, because the error in your log relates to >> DBVDD1 which is an independent regulator supplied by a separate >> regulator. I am really having some difficulty seeing how the >> patch interfers. It is definitely that patch which causes the >> issue, like you revert it and things work again? > Wait does the board still boot just you have an extra probe defer > now? Or does it actually fail? The board boots fine. The only new thing is the mentioned warning, which I would like to have fixed. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH] perf tools: Restore proper cwd on return from mnt ns
Em Tue, Nov 20, 2018 at 11:56:18AM +0100, Jiri Olsa escreveu: > On Mon, Nov 19, 2018 at 08:10:06AM -0800, Arnaldo Carvalho de Melo wrote: > > Em Thu, Nov 01, 2018 at 06:00:01PM +0100, Jiri Olsa escreveu: > > > Adding the current working directory to be part of the cookie > > > and restoring it in the nsinfo__mountns_exit call. > > > > > diff --git a/tools/perf/util/namespaces.c b/tools/perf/util/namespaces.c > > > index cf8bd123cf73..fb0458b7e6aa 100644 > > > --- a/tools/perf/util/namespaces.c > > > +++ b/tools/perf/util/namespaces.c > > > > > @@ -199,9 +201,13 @@ void nsinfo__mountns_enter(struct nsinfo *nsi, > > > if (snprintf(curpath, PATH_MAX, "/proc/self/ns/mnt") >= PATH_MAX) > > > return; > > > > > + oldcwd = get_current_dir_name(); > > > > Breaks the build with bionic (Android), where get_current_dir_name() is > > not available: > > > > /tmp/build/perf/libperf.a(libperf-in.o):hist.c:function > > nsinfo__mountns_enter: error: undefined reference to 'get_current_dir_name' > > collect2: error: ld returned 1 exit status > > Makefile.perf:534: recipe for target '/tmp/build/perf/perf' failed > > make[2]: *** [/tmp/build/perf/perf] Error 1 > > Makefile.perf:206: recipe for target 'sub-make' failed > > make[1]: *** [sub-make] Error 2 > > Makefile:69: recipe for target 'all' failed > > make: *** [all] Error 2 > > make: Leaving directory '/git/linux/tools/perf' > > [root@seventh ~]# > > > > The container builds are ongoing, its possoble that this becomes an > > issue in uCLibc, wasn't on musl libc (Alpine Linux). > > will check, thanks I fixed this already, by adding a test for that get_current_dir_name() function and a simple implementation based on strdup(getcwd(bf)), take a look at my perf/urgent branch - Arnaldo
Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()
On Mon, Nov 19, 2018 at 04:26:54PM -0800, Douglas Anderson wrote: > In regulator_force_disable() there was a strange loop that looked like: > > while (rdev->open_count--) > regulator_disable(rdev->supply); > > I'm not totally sure what the goal was for this loop, but it seems > wrong to me. If anything I think maybe we should have been looping > over our use_count, but even that might be a little strange. For now > let's just remove the code and we can add something back in if someone > can explain what's expected. This should be using use_count, what that loop is doing is dropping all the enables that the regulator being force disabled had propagated up all the enables it passed up the chain of supplies. signature.asc Description: PGP signature
Re: [PATCH v9 02/15] sched/cpufreq: Prepare schedutil for Energy Aware Scheduling
On Tuesday 20 Nov 2018 at 16:25:14 (+0100), Peter Zijlstra wrote:
> On Tue, Nov 20, 2018 at 10:16:02AM +0530, Viresh Kumar wrote:
> > On 19-11-18, 14:18, Quentin Perret wrote:
> > > @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct
> > > sugov_cpu *sg_cpu)
> >
> > > - if ((util + cpu_util_dl(rq)) >= max)
> > > - return max;
> > > + if (type == FREQUENCY_UTIL) {
> > > + /*
> > > + * For frequency selection we do not make cpu_util_dl() a
> > > + * permanent part of this sum because we want to use
> > > + * cpu_bw_dl() later on, but we need to check if the
> > > + * CFS+RT+DL sum is saturated (ie. no idle time) such
> > > + * that we select f_max when there is no idle time.
> > > + *
> > > + * NOTE: numerical errors or stop class might cause us
> > > + * to not quite hit saturation when we should --
> > > + * something for later.
> > > + */
> > > +
> > > + if ((util + cpu_util_dl(rq)) >= max)
> > > + return max;
> > > + } else {
> > > + /*
> > > + * OTOH, for energy computation we need the estimated
> > > + * running time, so include util_dl and ignore dl_bw.
> > > + */
> > > + util += cpu_util_dl(rq);
> > > + if (util >= max)
> > > + return max;
> > > + }
> >
> > Maybe write above as:
> >
> > dl_util = cpu_util_dl(rq);
> >
> > if ((util + dl_util) >= max)
> > return max;
> >
> > if (type != FREQUENCY_UTIL)
> > util += dl_util;
> >
> >
> > as both the if/else parts were doing almost the same thing.
>
> A little like so ?
>
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -201,8 +201,8 @@ static unsigned int get_next_freq(struct
> unsigned long schedutil_freq_util(int cpu, unsigned long util_cfs,
> unsigned long max, enum schedutil_type type)
> {
> + unsigned long dl_util, util, irq;
> struct rq *rq = cpu_rq(cpu);
> - unsigned long util, irq;
>
> if (type == FREQUENCY_UTIL && rt_rq_is_runnable(&rq->rt))
> return max;
> @@ -225,30 +225,26 @@ unsigned long schedutil_freq_util(int cp
> util = util_cfs;
> util += cpu_util_rt(rq);
>
> - if (type == FREQUENCY_UTIL) {
> - /*
> - * For frequency selection we do not make cpu_util_dl() a
> - * permanent part of this sum because we want to use
> - * cpu_bw_dl() later on, but we need to check if the
> - * CFS+RT+DL sum is saturated (ie. no idle time) such
> - * that we select f_max when there is no idle time.
> - *
> - * NOTE: numerical errors or stop class might cause us
> - * to not quite hit saturation when we should --
> - * something for later.
> - */
> -
> - if ((util + cpu_util_dl(rq)) >= max)
> - return max;
> - } else {
> - /*
> - * OTOH, for energy computation we need the estimated
> - * running time, so include util_dl and ignore dl_bw.
> - */
> - util += cpu_util_dl(rq);
> - if (util >= max)
> - return max;
> - }
> + dl_util = cpu_util_dl(rq);
> +
> + /*
> + * NOTE: numerical errors or stop class might cause us to not quite hit
> + * saturation when we should -- something for later.
> + */
> + if (util + dl_util > max)
> + return max;
> +
> + /*
> + * For frequency selection we do not make cpu_util_dl() a permanent
> + * part of this sum because we want to use cpu_bw_dl() later on, but we
> + * need to check if the CFS+RT+DL sum is saturated (ie. no idle time)
> + * such that we select f_max when there is no idle time.
We probably want move that paragraph to the comment above no ? Other
than that, the change LGTM.
> + *
> + * OTOH, for energy computation we need the estimated running time, so
> + * do include util_dl and ignore dl_bw.
> + */
> + if (type == ENERGY_UTIL)
> + util += dl_util;
>
> /*
>* There is still idle time; further improve the number by using the
> @@ -262,21 +258,18 @@ unsigned long schedutil_freq_util(int cp
> util = scale_irq_capacity(util, irq, max);
> util += irq;
>
> - if (type == FREQUENCY_UTIL) {
> - /*
> - * Bandwidth required by DEADLINE must always be granted
> - * while, for FAIR and RT, we use blocked utilization of
> - * IDLE CPUs as a mechanism to gracefully reduce the
> - * frequency when no tasks show up for longer periods of
> - * time.
> - *
> - * Ideally we would like to set bw_dl as min/guaranteed
> - * freq and ut
[PATCH v2] cpuidle: big.LITTLE: add of_node_put()
The of_node_put() is missing.So we call the of_node_put() to release
the refcount.
Signed-off-by: Yangtao Li
---
Changes in v2
-update changelog
-do that right after its last use
to also cover error handling.
---
drivers/cpuidle/cpuidle-big_little.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-big_little.c
b/drivers/cpuidle/cpuidle-big_little.c
index db2ede565f1a..650f063ef809 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -174,8 +174,12 @@ static int __init bl_idle_init(void)
/*
* Initialize the driver just for a compliant set of machines
*/
- if (!of_match_node(compatible_machine_match, root))
+ if (!of_match_node(compatible_machine_match, root)){
+ of_node_put(root);
return -ENODEV;
+ }
+
+ of_node_put(root);
if (!mcpm_is_available())
return -EUNATCH;
--
2.17.0
Re: [PATCH] debugobjects: scale the static pool size
On 11/20/2018 10:12 AM, Qian Cai wrote: > >> On Nov 20, 2018, at 8:50 AM, Waiman Long wrote: >> >> On 11/20/2018 01:42 AM, Qian Cai wrote: >>> The current value of the early boot static pool size is not big enough >>> for systems with large number of CPUs with timer or/and workqueue >>> objects selected. As the results, systems have 60+ CPUs with both timer >>> and workqueue objects enabled could trigger "ODEBUG: Out of memory. >>> ODEBUG disabled". Hence, fixed it by computing it according to >>> CONFIG_NR_CPUS and CONFIG_DEBUG_OBJECTS_* options. >>> >>> Signed-off-by: Qian Cai >>> --- >>> lib/debugobjects.c | 53 +- >>> 1 file changed, 52 insertions(+), 1 deletion(-) >>> >>> diff --git a/lib/debugobjects.c b/lib/debugobjects.c >>> index 70935ed91125..372dc34206d5 100644 >>> --- a/lib/debugobjects.c >>> +++ b/lib/debugobjects.c >>> @@ -23,7 +23,53 @@ >>> #define ODEBUG_HASH_BITS14 >>> #define ODEBUG_HASH_SIZE(1 << ODEBUG_HASH_BITS) >>> >>> +/* >>> + * Some debug objects are allocated during the early boot. Enabling some >>> + * options like timers or workqueue objects may increase the size required >>> + * significantly with large number of CPUs. For example, >>> + * >>> + * No. CPUs x 2 (worker pool) objects: >>> + * >>> + * start_kernel >>> + * workqueue_init_early >>> + * init_worker_pool >>> + * init_timer_key >>> + * debug_object_init >>> + * >>> + * No. CPUs objects (CONFIG_HIGH_RES_TIMERS): >>> + * >>> + * sched_init >>> + * hrtick_rq_init >>> + * hrtimer_init >>> + * >>> + * CONFIG_DEBUG_OBJECTS_WORK: >>> + * No. CPUs x 6 (workqueue) objects: >>> + * >>> + * workqueue_init_early >>> + * alloc_workqueue >>> + * __alloc_workqueue_key >>> + * alloc_and_link_pwqs >>> + * init_pwq >>> + * >>> + * Also, plus No. CPUs objects: >>> + * >>> + * perf_event_init >>> + *__init_srcu_struct >>> + * init_srcu_struct_fields >>> + *init_srcu_struct_nodes >>> + * __init_work >>> + * >>> + * Increase the number a bit more in case the implmentatins are changed in >>> + * the future. >>> + */ >>> +#if defined(CONFIG_NR_CPUS) && defined(CONFIG_DEBUG_OBJECTS_TIMERS) && \ >>> +!defined(CONFIG_DEBUG_OBJECTS_WORK) >>> +#define ODEBUG_POOL_SIZE (CONFIG_NR_CPUS * 10) >>> +#elif defined(CONFIG_NR_CPUS) && defined(CONFIG_DEBUG_OBJECTS_WORK) >>> +#define ODEBUG_POOL_SIZE (CONFIG_NR_CPUS * 30) >>> +#else >>> #define ODEBUG_POOL_SIZE1024 >>> +#endif /* CONFIG_NR_CPUS */ >>> #define ODEBUG_POOL_MIN_LEVEL 256 >>> >> CONFIG_NR_CPUS is always defined. You don't need to put that as a #if >> condition. Where does the scaling factor 30 come from? It looks high to me. > Hmm, looks like some architectures could have it undefined since it depends > on CONFIG_SMP where the later can be disabled. For example alpha, > > config NR_CPUS > int "Maximum number of CPUs (2-32)" > range 2 32 > depends on SMP include/linux/threads.h: #ifndef CONFIG_NR_CPUS /* FIXME: This should be fixed in the arch's Kconfig */ #define CONFIG_NR_CPUS 1 #endif > Scaling factor 30 came from the data, with all the debug_objects options > enabled, I have, > > 64-CPU: ODEBUG: 1114 of 1114 active objects replaced > 256-CPU: ODEBUG: 4378 of 4378 active objects replaced > > I also give a bit room for growth in the future since the implementation > details > could always change. (4378-1114)/(256-64) = 17 So the max scaling factor is 17. I would say you could round it up to 20 at most. Cheers, Longman
[PATCH v2 2/2] dt-bindings: iio: adc: Add docs for AD7606 ADC
Document support for AD7606 Analog to Digital Converter.
Signed-off-by: Stefan Popa
---
Changes in v2:
- fixed indentation issues.
- used gpios instead of gpio.
- added vendor prefix for conversion-start-gpios, first-data-gpios,
and range-gpios.
.../devicetree/bindings/iio/adc/adi,ad7606.txt | 54 ++
MAINTAINERS| 1 +
2 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
new file mode 100644
index 000..02fae23
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
@@ -0,0 +1,54 @@
+Analog Devices AD7606 Simultaneous Sampling ADC
+
+Required properties for the AD7606:
+
+- compatible: Must be one of
+ * "adi,ad7605-4"
+ * "adi,ad7606-8"
+ * "adi,ad7606-6"
+ * "adi,ad7606-4"
+- reg: SPI chip select number for the device
+- spi-max-frequency: Max SPI frequency to use
+ see: Documentation/devicetree/bindings/spi/spi-bus.txt
+- spi-cpha: See Documentation/devicetree/bindings/spi/spi-bus.txt
+- avcc-supply: phandle to the Avcc power supply
+- interrupts: IRQ line for the ADC
+ see:
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+- adi,conversion-start-gpios: must be the device tree identifier of the CONVST
pin.
+ This logic input is used to initiate conversions on the analog
+ input channels.
+
+Optional properties:
+
+- reset-gpios: must be the device tree identifier of the RESET pin. If
specified,
+ it will be asserted during driver probe.
+- standby-gpios: must be the device tree identifier of the STBY pin. This pin
is used
+ to place the AD7606 into one of two power-down modes, Standby
mode or
+ Shutdown mode.
+- adi,first-data-gpios: must be the device tree identifier of the FRSTDATA pin.
+ The FRSTDATA output indicates when the first channel, V1, is
+ being read back on either the parallel, byte or serial
interface.
+- adi,range-gpios: must be the device tree identifier of the RANGE pin. The
polarity on
+ this pin determines the input range of the analog input channels.
If
+ this pin is tied to a logic high, the analog input range is ±10V
for
+ all channels. If this pin is tied to a logic low, the analog
input range
+ is ±5V for all channels.
+
+Example:
+
+ adc@0 {
+ compatible = "adi,ad7606-8";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ spi-cpol;
+
+ avcc-supply = <&adc_vref>;
+
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+
+ adi,conversion-start-gpios = <&gpio 17 0>;
+ reset-gpios = <&gpio 27 0>;
+ adi,first-data-gpios = <&gpio 22 0>;
+ standby-gpios = <&gpio 24 0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 843545d..6d63db4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -845,6 +845,7 @@ L: linux-...@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/adc/ad7606.c
+F: Documentation/devicetree/bindings/iio/adc/ad7606.txt
ANALOG DEVICES INC AD9389B DRIVER
M: Hans Verkuil
--
2.7.4
Re: [PATCH cgroup/for-4.21 1/2] cpuset: Minor cgroup2 interface updates
Hello, Peter. On Tue, Nov 20, 2018 at 01:46:24PM +0100, Peter Zijlstra wrote: > Why though? The Changelog doesn't give rationale for the actual changes. Ah yeah, sorry about that. > And I'm not sure I agree with either one of them. > > The partition is a scheduling feature; So is everything with cpuset.cpus prefix. They're all modifying how scheduler handles the cpus. > and I like 0/1 much better to type, so why not allow that? Mostly for consistency and it's generally better to keep interfaces minimal - e.g. what if we need to add support for more key words to the file? Would we assign incrementing integers to them? Thanks. -- tejun
[PATCH v2 1/2] staging: iio: ad7606: Move out of staging
Move ad7606 ADC driver out of staging and into the mainline. Signed-off-by: Stefan Popa --- Changes in v2: - Simplified the Kconfig menu. - Added SPDX-License-Identifier. - Ordered the includes alphabetically. - Used a threaded interrupt. - Replaced ad7606_poll_bh_to_ring() with ad7606_trigger_handler(). - Used a trigger. - Replaced wait_event_interruptible() with wait_for_completion_timeout(). - Replaced wake_up_interruptible() with complete(). - Used devm_iio_triggered_buffer_setup(). - Added buffer_ops. - Used single line comments where needed. - Removed the gap between docs and struct. - Added ad7606_of_match[]. MAINTAINERS | 7 + drivers/iio/adc/Kconfig | 28 ++ drivers/iio/adc/Makefile | 3 + drivers/iio/adc/ad7606.c | 608 +++ drivers/iio/adc/ad7606.h | 107 ++ drivers/iio/adc/ad7606_par.c | 110 +++ drivers/iio/adc/ad7606_spi.c | 88 + drivers/staging/iio/adc/Kconfig | 34 -- drivers/staging/iio/adc/Makefile | 3 - drivers/staging/iio/adc/ad7606.c | 565 drivers/staging/iio/adc/ad7606.h | 106 -- drivers/staging/iio/adc/ad7606_par.c | 113 --- drivers/staging/iio/adc/ad7606_spi.c | 79 - 13 files changed, 951 insertions(+), 900 deletions(-) create mode 100644 drivers/iio/adc/ad7606.c create mode 100644 drivers/iio/adc/ad7606.h create mode 100644 drivers/iio/adc/ad7606_par.c create mode 100644 drivers/iio/adc/ad7606_spi.c delete mode 100644 drivers/staging/iio/adc/ad7606.c delete mode 100644 drivers/staging/iio/adc/ad7606.h delete mode 100644 drivers/staging/iio/adc/ad7606_par.c delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c diff --git a/MAINTAINERS b/MAINTAINERS index f642044..843545d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -839,6 +839,13 @@ S: Supported F: drivers/iio/dac/ad5758.c F: Documentation/devicetree/bindings/iio/dac/ad5758.txt +ANALOG DEVICES INC AD7606 DRIVER +M: Stefan Popa +L: linux-...@vger.kernel.org +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/iio/adc/ad7606.c + ANALOG DEVICES INC AD9389B DRIVER M: Hans Verkuil L: linux-me...@vger.kernel.org diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index a52fea8..c3f61c9 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -58,6 +58,34 @@ config AD7476 To compile this driver as a module, choose M here: the module will be called ad7476. +config AD7606 + tristate + depends on GPIOLIB || COMPILE_TEST + depends on HAS_IOMEM + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + +config AD7606_IFACE_PARALLEL + tristate "Analog Devices AD7606 ADC driver with parallel interface support" + select AD7606 + help + Say yes here to build parallel interface support for Analog Devices: + ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the + module will be called ad7606_parallel. + +config AD7606_IFACE_SPI + tristate "Analog Devices AD7606 ADC driver with spi interface support" + depends on SPI + select AD7606 + help + Say yes here to build spi interface support for Analog Devices: + ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the + module will be called ad7606_spi. + config AD7766 tristate "Analog Devices AD7766/AD7767 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a6e6a0b..b734f4f 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -8,6 +8,9 @@ obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o obj-$(CONFIG_AD7266) += ad7266.o obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o +obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o +obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o +obj-$(CONFIG_AD7606) += ad7606.o obj-$(CONFIG_AD7923) += ad7923.o obj-$(CONFIG_AD7476) += ad7476.o obj-$(CONFIG_AD7766) += ad7766.o diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c new file mode 100644 index 000..4e09635 --- /dev/null +++ b/drivers/iio/adc/ad7606.c @@ -0,0 +1,608 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * AD7606 SPI ADC driver + * + * Copyright 2011 Analog Devices Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include "ad7606.h" + +/* + * Scales are computed as 5000/32768 and 1/32768 respectively, + * so that
Re: [PATCH] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table
On 11/20/2018 05:35 PM, kbuild test robot wrote: > Hi Cyrille, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on mtd/spi-nor/next] > [also build test ERROR on v4.20-rc3 next-20181120] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Tudor-Ambarus-microchip-com/mtd-spi-nor-parse-SFDP-4-byte-Address-Instruction-Table/20181120-223821 > base: git://git.infradead.org/linux-mtd.git spi-nor/next > config: i386-randconfig-x005-201846 (attached as .config) > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >drivers/mtd//spi-nor/spi-nor.c: In function 'spi_nor_parse_4bait': >>> drivers/mtd//spi-nor/spi-nor.c:3165:15: error: implicit declaration of >>> function 'spi_nor_sort_erase_mask'; did you mean 'spi_nor_set_erase_type'? >>> [-Werror=implicit-function-declaration] > erase_mask = spi_nor_sort_erase_mask(map, erase_mask); > ^~~ That's fine. I already specified that this patch depends on the spi_nor_sort_erase_mask() function introduced in https://patchwork.ozlabs.org/patch/999105/ Thanks! ta
Re: Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree
On Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote: > On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote: > > No board file, everything in DT. > This is really weird, because the error in your log relates to > DBVDD1 which is an independent regulator supplied by a separate > regulator. I am really having some difficulty seeing how the > patch interfers. It is definitely that patch which causes the > issue, like you revert it and things work again? It's a warning in the GPIO code, the switch to the gpiod API will have triggered it. signature.asc Description: PGP signature
Re: [PATCH v2] PCI: dwc: Adjust Kconfig to allow IMX6 PCIe host on IMX7
On Fri, Nov 16, 2018 at 12:08:33AM +, Trent Piepho wrote: > The IMX6 PCI-e host drier also supports the IMX7d. However, the > Kconfig dependencies of the driver prevented it from being enabled > unless the kernel was built with both IMX6 and IMX7 support. It works > fine to build with only IMX7 support enabled. > > Cc: Andrey Smirnov > Reviewed-by: Lucas Stach > Signed-off-by: Trent Piepho > --- > Changes from v1: > Ported to current kernel > > drivers/pci/controller/dwc/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to pci/dwc for v4.21, thanks. Lorenzo > diff --git a/drivers/pci/controller/dwc/Kconfig > b/drivers/pci/controller/dwc/Kconfig > index 91b0194240a5..6aafec3fad00 100644 > --- a/drivers/pci/controller/dwc/Kconfig > +++ b/drivers/pci/controller/dwc/Kconfig > @@ -89,8 +89,8 @@ config PCI_EXYNOS > select PCIE_DW_HOST > > config PCI_IMX6 > - bool "Freescale i.MX6 PCIe controller" > - depends on SOC_IMX6Q || (ARM && COMPILE_TEST) > + bool "Freescale i.MX6/7 PCIe controller" > + depends on SOC_IMX6Q || SOC_IMX7D || (ARM && COMPILE_TEST) > depends on PCI_MSI_IRQ_DOMAIN > select PCIE_DW_HOST > > -- > 2.14.4 >
Re: [PATCH] thermal: tegra: add get_trend ops
On Tue, Nov 20, 2018 at 05:11:17PM +0800, Wei Ni wrote:
> Add support for get_trend ops that allows soctherm
> sensors to be used with the step-wise governor.
>
> Signed-off-by: Wei Ni
> ---
> drivers/thermal/tegra/soctherm.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/thermal/tegra/soctherm.c
> b/drivers/thermal/tegra/soctherm.c
> index ed28110a3535..d2951fbe2b7c 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -488,9 +488,43 @@ static int tegra_thermctl_set_trip_temp(void *data, int
> trip, int temp)
> return 0;
> }
>
> +static int tegra_thermctl_get_trend(void *data, int trip,
> + enum thermal_trend *trend)
> +{
> + struct tegra_thermctl_zone *zone = data;
> + struct thermal_zone_device *tz = zone->tz;
> + int trip_temp, temp, last_temp, ret;
> +
> + if (!tz)
> + return -EINVAL;
> +
> + ret = tz->ops->get_trip_temp(zone->tz, trip, &trip_temp);
> + if (ret)
> + return ret;
> +
> + mutex_lock(&tz->lock);
> + temp = tz->temperature;
> + last_temp = tz->last_temperature;
> + mutex_unlock(&tz->lock);
> +
> + if (temp > trip_temp) {
> + if (temp >= last_temp)
> + *trend = THERMAL_TREND_RAISING;
> + else
> + *trend = THERMAL_TREND_STABLE;
> + } else if (temp < trip_temp) {
> + *trend = THERMAL_TREND_DROPPING;
> + } else {
> + *trend = THERMAL_TREND_STABLE;
> + }
> +
> + return 0;
> +}
This looks like a reimplementation of the get_tz_trend() helper. Is
seems like that helper already has everything we need. Perhaps this
isn't working because of-thermal installs of_thermal_get_trend(), a
function that returns -EINVAL if the driver doesn't implement the
->get_trend() callback.
Perhaps a better way would be to do something like this in
thermal_zone_of_add_sensor():
if (ops->get_trend)
tzd->ops->get_trend = of_thermal_get_trend;
That's similar to how ->set_trips() and ->set_emul_temp() are set up
and should make sure that get_tz_trend() will do the right thing for
all drivers that don't implement a special ->get_trend().
Thierry
signature.asc
Description: PGP signature
Re: [PATCH] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table
Hi Cyrille, Thank you for the patch! Yet something to improve: [auto build test ERROR on mtd/spi-nor/next] [also build test ERROR on v4.20-rc3 next-20181120] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tudor-Ambarus-microchip-com/mtd-spi-nor-parse-SFDP-4-byte-Address-Instruction-Table/20181120-223821 base: git://git.infradead.org/linux-mtd.git spi-nor/next config: i386-randconfig-x005-201846 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/mtd//spi-nor/spi-nor.c: In function 'spi_nor_parse_4bait': >> drivers/mtd//spi-nor/spi-nor.c:3165:15: error: implicit declaration of >> function 'spi_nor_sort_erase_mask'; did you mean 'spi_nor_set_erase_type'? >> [-Werror=implicit-function-declaration] erase_mask = spi_nor_sort_erase_mask(map, erase_mask); ^~~ spi_nor_set_erase_type Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:ffs Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls Cyclomatic Complexity 2 include/asm-generic/bitops/fls64.h:fls64 Cyclomatic Complexity 1 arch/x86/include/asm/arch_hweight.h:__arch_hweight32 Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32 Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64 Cyclomatic Complexity 3 include/linux/log2.h:is_power_of_2 Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD Cyclomatic Complexity 1 include/linux/list.h:__list_add_valid Cyclomatic Complexity 1 include/linux/list.h:__list_del_entry_valid Cyclomatic Complexity 2 include/linux/list.h:__list_add Cyclomatic Complexity 1 include/linux/list.h:list_add_tail Cyclomatic Complexity 1 include/linux/list.h:__list_del Cyclomatic Complexity 2 include/linux/list.h:__list_del_entry Cyclomatic Complexity 1 include/linux/list.h:list_del Cyclomatic Complexity 2 arch/x86/include/asm/div64.h:div_u64_rem Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name Cyclomatic Complexity 2 include/linux/device.h:dev_name Cyclomatic Complexity 1 include/linux/device.h:dev_of_node Cyclomatic Complexity 67 include/linux/slab.h:kmalloc_large Cyclomatic Complexity 3 include/linux/slab.h:kmalloc Cyclomatic Complexity 1 include/linux/mtd/mtd.h:mtd_get_of_node Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_get_protocol_data_nbits Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_get_protocol_width Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_region_is_last Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_region_end Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_region_mark_end Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_region_mark_overlay Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_has_uniform_erase Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_get_flash_node Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:write_sr Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:write_enable Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:write_disable Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:mtd_to_spi_nor Cyclomatic Complexity 3 drivers/mtd//spi-nor/spi-nor.c:spi_nor_convert_opcode Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:spi_nor_convert_3to4_read Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:spi_nor_convert_3to4_program Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:spi_nor_convert_3to4_erase Cyclomatic Complexity 4 drivers/mtd//spi-nor/spi-nor.c:spi_nor_set_4byte_opcodes Cyclomatic Complexity 8 drivers/mtd//spi-nor/spi-nor.c:set_4byte Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:erase_chip Cyclomatic Complexity 2 drivers/mtd//spi-nor/spi-nor.c:spi_nor_s3an_addr_convert Cyclomatic Complexity 4 drivers/mtd//spi-nor/spi-nor.c:spi_nor_erase_sector Cyclomatic Complexity 1 drivers/mtd//spi-nor/spi-nor.c:spi_nor_div_by_erase_size Cyclomatic Complexity 6 drivers/mtd//spi-nor/spi-nor.c:spi_nor_find_best_erase_type Cyclomatic Complexity 2 drivers/mtd//spi-nor/spi-nor.c:spi_nor_region_next Cyclomatic Complexity 3 drivers/mtd//spi-nor/spi-nor.c:spi_nor_find_erase_region Cyclomatic Complexity 3 drivers/mtd//spi-nor/spi-nor.c:spi_nor_init_erase_cmd Cyclomatic Complexity 4 drivers/mtd//spi-nor/spi-nor.c:stm_get_locked_range Cyclomatic Complexity 7 drivers/mtd//sp
Re: Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree
On Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote: > On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote: > > On 2018-11-20 15:47, Charles Keepax wrote: > > > On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote: > > >> On 2018-05-17 18:41, Mark Brown wrote: > > >>> Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO > > >>> number > > >> This patch causes following kernel warning on Samsung Exynos4412 based > > >> Trats2 board: > > >> > > >> wm8994 4-001a: Failed to get supply 'DBVDD1': -517 > > >> wm8994 4-001a: Failed to get supplies: -517 > This is really weird, because the error in your log relates to > DBVDD1 which is an independent regulator supplied by a separate > regulator. I am really having some difficulty seeing how the > patch interfers. It is definitely that patch which causes the > issue, like you revert it and things work again? Wait does the board still boot just you have an extra probe defer now? Or does it actually fail? Thanks, Charles
NULL pointer dereference in smb2_queryfs with v4.19.2
Hi, My machine just rebooted after the connection to the Samba server hosting a CIFS mount was lost. Kernel version 4.19.2. The oops was recorded in pstore: <3>[533816.847894] CIFS VFS: Server store has not responded in 120 seconds. Reconnecting... <1>[533925.390079] BUG: unable to handle kernel NULL pointer dereference at <6>[533925.390082] PGD 0 P4D 0 <4>[533925.390085] Oops: [#1] PREEMPT SMP PTI <4>[533925.390087] CPU: 1 PID: 30794 Comm: sadc Tainted: P O 4.19.2-gentoo #1 <4>[533925.390088] Hardware name: System manufacturer System Product Name/P9X79 WS, BIOS 4802 06/02/2015 <4>[533925.390099] RIP: 0010:SMB2_close_free+0x8/0x10 [cifs] <4>[533925.390100] Code: 65 48 33 1c 25 28 00 00 00 75 09 48 83 c4 18 5b 5d 41 5c c3 e8 89 ac 29 e0 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 07 <48> 8b 38 e9 50 8d fe ff 66 66 66 66 90 4c 8d 54 24 08 48 83 e4 f0 <4>[533925.390101] RSP: 0018:c9002c2dfbb8 EFLAGS: 00010246 <4>[533925.390102] RAX: RBX: 880fae7e5800 RCX: <4>[533925.390104] RDX: 880fdf521180 RSI: 0206 RDI: c9002c2dfd68 <4>[533925.390105] RBP: c9002c2dfdf0 R08: R09: 002503ee <4>[533925.390106] R10: c9002c2dfbc0 R11: 000f4240 R12: c9002c2dfc50 <4>[533925.390107] R13: 880fad03a200 R14: 880fdf521000 R15: <4>[533925.390108] FS: 7fb5cff85740() GS:88100f84() knlGS: <4>[533925.390109] CS: 0010 DS: ES: CR0: 80050033 <4>[533925.390110] CR2: CR3: 000118d32001 CR4: 000626e0 <4>[533925.390111] Call Trace: <4>[533925.390119] smb2_queryfs+0x162/0x360 [cifs] <4>[533925.390124] ? lookup_fast+0xc8/0x2d0 <4>[533925.390126] ? legitimize_path.isra.8+0x28/0x50 <4>[533925.390127] ? __vfs_getxattr+0x2a/0x70 <4>[533925.390130] ? get_vfs_caps_from_disk+0x65/0x170 <4>[533925.390135] ? cifs_statfs+0x97/0x1f0 [cifs] <4>[533925.390140] ? smb2_set_next_command+0x60/0x60 [cifs] <4>[533925.390144] cifs_statfs+0x97/0x1f0 [cifs] <4>[533925.390147] statfs_by_dentry+0x42/0x60 <4>[533925.390148] vfs_statfs+0x16/0xc0 <4>[533925.390150] user_statfs+0x54/0xa0 <4>[533925.390151] __se_sys_statfs+0x25/0x60 <4>[533925.390153] do_syscall_64+0x5c/0x160 <4>[533925.390156] entry_SYSCALL_64_after_hwframe+0x44/0xa9 <4>[533925.390158] RIP: 0033:0x7fb5cf8ca467 <4>[533925.390159] Code: 2c 00 64 c7 00 16 00 00 00 b8 ff ff ff ff eb b8 e8 6e 4f 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 b8 89 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f1 e9 2c 00 f7 d8 64 89 01 48 <4>[533925.390160] RSP: 002b:7ffc47a0c7f8 EFLAGS: 0246 ORIG_RAX: 0089 <4>[533925.390162] RAX: ffda RBX: 7ffc47a0c9a0 RCX: 7fb5cf8ca467 <4>[533925.390163] RDX: 7ffc47a0c9a9 RSI: 7ffc47a0c800 RDI: 7ffc47a0c9a0 <4>[533925.390164] RBP: 7ffc47a0c800 R08: R09: 000d <4>[533925.390165] R10: 7fb5cfb9a560 R11: 0246 R12: 7ffc47a0c8b0 <4>[533925.390166] R13: 000b R14: 561829c584d4 R15: 7ffc47a0c920 <4>[533925.390167] Modules linked in: xt_nat hfsplus hfs msdos nfnetlink_queue nfnetlink_log cp210x usbserial squashfs cfg80211 drbg seqiv xfrm6_mode_tunnel xfrm4_mode_tunnel nvidia_uvm(PO) rfcomm xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 xt_tcpudp devlink ebtable_filter ebtables ip6table_filter ip6_tables ipt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype iptable_filter ip_tables bpfilter xt_conntrack x_tables br_netfilter bridge stp llc arc4 md4 md5 xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key cmac xfrm_algo nls_utf8 cifs ccm sctp bnep nvidia_drm(PO) algif_skcipher nvidia_modeset(PO) nls_iso8859_1 nls_cp437 vfat fat joydev amdkfd iTCO_wdt nvidia(PO) evdev iTCO_vendor_support uinput intel_rapl amdgpu snd_hda_codec_realtek x86_pkg_temp_thermal intel_powerclamp <4>[533925.390197] snd_hda_codec_hdmi snd_hda_codec_generic crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_usb_audio pcbc snd_hda_intel chash snd_usbmidi_lib aesni_intel snd_hda_codec snd_rawmidi gpu_sched snd_seq_device crypto_simd ttm snd_hda_core bcache btusb snd_hwdep drm_kms_helper btrtl cryptd snd_pcm btbcm uas glue_helper btintel crc64 drm snd_timer intel_cstate bluetooth drm_panel_orientation_quirks snd intel_uncore syscopyarea soundcore i2c_i801 efi_pstore wmi_bmof intel_rapl_perf efivars sysfillrect e1000e ecdh_generic sysimgblt lpc_ich mei_me fb_sys_fops button firewire_ohci sch_fq_codel nct6775 hwmon_vid coretemp openvswitch nsh nf_nat_ipv6 nf_nat_ipv4 nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vhost_net tun vhost tap kvm_intel kvm irqbypass msr cpuid <4>[533925.390226] efivarfs virtio_ring virtio xts aes_x86_64 ecb cbc sha1_generic iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi bonding vxlan ip6_udp_tunnel udp_tunnel macvlan igb i2c_algo_bit dca e1000
Re: [PATCH 3/7] doc/vm: New documentation for memory performance
On Tue, Nov 20, 2018 at 02:51:50PM +0100, Mike Rapoport wrote: > On Wed, Nov 14, 2018 at 03:49:16PM -0700, Keith Busch wrote: > > Platforms may provide system memory where some physical address ranges > > perform differently than others. These heterogeneous memory attributes are > > common to the node that provides the memory and exported by the kernel. > > > > Add new documentation providing a brief overview of such systems and > > the attributes the kernel makes available to aid applications wishing > > to query this information. > > > > Signed-off-by: Keith Busch > > --- > > Documentation/vm/numaperf.rst | 71 > > +++ > > As this document describes user-space interfaces it belongs to > Documentation/admin-guide/mm. Thanks for the feedback. I'll move this and combine with the memory cache doc in the v2.
Re: [RFC PATCH 2/3] mm, memory_hotplug: deobfuscate migration part of offlining
> Signed-off-by: Michal Hocko
[...]
> + do {
> + for (pfn = start_pfn; pfn;)
> + {
> + /* start memory hot removal */
Should we change thAT comment? I mean, this is not really the hot-
removal stage.
Maybe "start memory migration" suits better? or memory offlining?
> + ret = -EINTR;
> + if (signal_pending(current)) {
> + reason = "signal backoff";
> + goto failed_removal_isolated;
> + }
>
> - cond_resched();
> - lru_add_drain_all();
> - drain_all_pages(zone);
> + cond_resched();
> + lru_add_drain_all();
> + drain_all_pages(zone);
>
> - pfn = scan_movable_pages(start_pfn, end_pfn);
> - if (pfn) { /* We have movable pages */
> - ret = do_migrate_range(pfn, end_pfn);
> - goto repeat;
> - }
> + pfn = scan_movable_pages(pfn, end_pfn);
> + if (pfn) {
> + /* TODO fatal migration failures
> should bail out */
> + do_migrate_range(pfn, end_pfn);
> + }
> + }
> +
> + /*
> + * dissolve free hugepages in the memory block
> before doing offlining
> + * actually in order to make hugetlbfs's object
> counting consistent.
> + */
> + ret = dissolve_free_huge_pages(start_pfn, end_pfn);
> + if (ret) {
> + reason = "failure to dissolve huge pages";
> + goto failed_removal_isolated;
> + }
> + /* check again */
> + offlined_pages = check_pages_isolated(start_pfn,
> end_pfn);
> + } while (offlined_pages < 0);
>
> - /*
> - * dissolve free hugepages in the memory block before doing
> offlining
> - * actually in order to make hugetlbfs's object counting
> consistent.
> - */
> - ret = dissolve_free_huge_pages(start_pfn, end_pfn);
> - if (ret) {
> - reason = "failure to dissolve huge pages";
> - goto failed_removal_isolated;
> - }
> - /* check again */
> - offlined_pages = check_pages_isolated(start_pfn, end_pfn);
> - if (offlined_pages < 0)
> - goto repeat;
This indeed looks much nicer and it is easier to follow.
With the changes commented by David:
Reviewed-by: Oscar Salvador
[PATCH v6 2/7] dmaengine: xilinx_dma: in axidma slave_sg and dma_cyclic mode align split descriptors
Whenever a single or cyclic transaction is prepared, the driver
could eventually split it over several SG descriptors in order
to deal with the HW maximum transfer length.
This could end up in DMA operations starting from a misaligned
address. This seems fatal for the HW if DRE (Data Realignment Engine)
is not enabled.
This patch eventually adjusts the transfer size in order to make sure
all operations start from an aligned address.
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in v2:
- don't introduce copy_mask field, rather rely on already-esistent
copy_align field. Suggested by Radhey Shyam Pandey
- reword title
Changes in v3:
- fix bug introduced in v2: wrong copy size when DRE is enabled
- use implementation suggested by Radhey Shyam Pandey
Changes in v4:
- rework on the top of 1/6
Changes in v5:
- fix typo in commit title
- add hint about "DRE" meaning in commit message
Changes in v6:
None
---
drivers/dma/xilinx/xilinx_dma.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 2c1db500284f..cbf34dd5e966 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -975,6 +975,15 @@ static int xilinx_dma_calc_copysize(struct xilinx_dma_chan
*chan,
copy = min_t(size_t, size - done,
chan->xdev->max_buffer_len);
+ if ((copy + done < size) &&
+ chan->xdev->common.copy_align) {
+ /*
+* If this is not the last descriptor, make sure
+* the next one will be properly aligned
+*/
+ copy = rounddown(copy,
+(1 << chan->xdev->common.copy_align));
+ }
return copy;
}
--
2.17.1
[PATCH] edac: i82975x: fix spelling mistake "reserverd" -> "reserved"
Fix a spelling mistake in a register layout description. Signed-off-by: Alexandre Belloni --- drivers/edac/i82975x_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/i82975x_edac.c b/drivers/edac/i82975x_edac.c index 892815eaa97b..40249e9c9d26 100644 --- a/drivers/edac/i82975x_edac.c +++ b/drivers/edac/i82975x_edac.c @@ -104,7 +104,7 @@ NOTE: Only ONE of the three must be enabled * * 31:14 Base Addr of 16K memory-mapped * configuration space -* 13:1 reserverd +* 13:1 reserved * 0mem-mapped config space enable */ -- 2.19.1
Re: Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree
On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote:
> Hi Charles,
>
> On 2018-11-20 15:47, Charles Keepax wrote:
> > On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> >> On 2018-05-17 18:41, Mark Brown wrote:
> >>> Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO number
> >> This patch causes following kernel warning on Samsung Exynos4412 based
> >> Trats2 board:
> >>
> >> wm8994 4-001a: Failed to get supply 'DBVDD1': -517
> >> wm8994 4-001a: Failed to get supplies: -517
> > How is the wm8994 being registered on this board? I am having
> > difficulty finding a device tree or a board file that relates to
> > the board and includes the wm8994.
>
>
> Please check arch/arm/boot/dts/exynos4412-trats2.dts details. The I2C device
> is defined in exynos4412-midas.dtsi, it uses "wlf,wm1811" compatible.
>
Ok got it, thanks.
>
> >>> @@ -203,6 +203,18 @@ static const struct i2c_board_info wm1277_devs[] = {
> >>> { I2C_BOARD_INFO("wm8958", 0x1a), /* WM8958 is the superset */
> >>> .platform_data = &wm8994_pdata,
> >>> .irq = GLENFARCLAS_PMIC_IRQ_BASE + WM831X_IRQ_GPIO_2,
> >>> + .dev_name = "wm8958",
> >>> + },
> >>> +};
> >>> +
> >>> +static struct gpiod_lookup_table wm8994_gpiod_table = {
> >>> + .dev_id = "i2c-wm8958", /* I2C device name */
> >>> + .table = {
> >>> + GPIO_LOOKUP("GPION", 6,
> >>> + "wlf,ldo1ena", GPIO_ACTIVE_HIGH),
> >>> + GPIO_LOOKUP("GPION", 4,
> >>> + "wlf,ldo2ena", GPIO_ACTIVE_HIGH),
> >>> + { },
> >>> },
> >>> };
> > If its being done through a board file I guess you will need the
> > equivalent of this.
>
>
> No board file, everything in DT.
>
This is really weird, because the error in your log relates to
DBVDD1 which is an independent regulator supplied by a separate
regulator. I am really having some difficulty seeing how the
patch interfers. It is definitely that patch which causes the
issue, like you revert it and things work again?
Thanks,
Charles
[PATCH v6 1/7] dmaengine: xilinx_dma: commonize DMA copy size calculation
This patch removes a bit of duplicated code by introducing a new
function that implements calculations for DMA copy size, and
prepares for changes to the copy size calculation that will
happen in following patches.
Suggested-by: Vinod Koul
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in v4:
- introduce this patch in the patch series
Changes in v5:
None
Changes in v6:
- 2/7 was basically redoing what done here. Anticipate
here the introduction of a local temporary variable
so that 2/7 just add stuff
- add dma chan ptr argument to xilinx_calc_cma_copysize()
to prepare for 2/7
- introduce max_buffer_len variable in advance, to prepare
for 4/7
- reword for above changes
---
drivers/dma/xilinx/xilinx_dma.c | 39 ++---
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index c12442312595..2c1db500284f 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -423,6 +423,7 @@ struct xilinx_dma_config {
* @rxs_clk: DMA s2mm stream clock
* @nr_channels: Number of channels DMA device supports
* @chan_id: DMA channel identifier
+ * @max_buffer_len: Max buffer length
*/
struct xilinx_dma_device {
void __iomem *regs;
@@ -442,6 +443,7 @@ struct xilinx_dma_device {
struct clk *rxs_clk;
u32 nr_channels;
u32 chan_id;
+ u32 max_buffer_len;
};
/* Macros */
@@ -957,6 +959,25 @@ static int xilinx_dma_alloc_chan_resources(struct dma_chan
*dchan)
return 0;
}
+/**
+ * xilinx_dma_calc_copysize - Calculate the amount of data to copy
+ * @chan: Driver specific DMA channel
+ * @size: Total data that needs to be copied
+ * @done: Amount of data that has been already copied
+ *
+ * Return: Amount of data that has to be copied
+ */
+static int xilinx_dma_calc_copysize(struct xilinx_dma_chan *chan,
+ int size, int done)
+{
+ size_t copy;
+
+ copy = min_t(size_t, size - done,
+chan->xdev->max_buffer_len);
+
+ return copy;
+}
+
/**
* xilinx_dma_tx_status - Get DMA transaction status
* @dchan: DMA channel
@@ -990,7 +1011,7 @@ static enum dma_status xilinx_dma_tx_status(struct
dma_chan *dchan,
list_for_each_entry(segment, &desc->segments, node) {
hw = &segment->hw;
residue += (hw->control - hw->status) &
- XILINX_DMA_MAX_TRANS_LEN;
+ chan->xdev->max_buffer_len;
}
}
spin_unlock_irqrestore(&chan->lock, flags);
@@ -1250,7 +1271,7 @@ static void xilinx_cdma_start_transfer(struct
xilinx_dma_chan *chan)
/* Start the transfer */
dma_ctrl_write(chan, XILINX_DMA_REG_BTT,
- hw->control & XILINX_DMA_MAX_TRANS_LEN);
+ hw->control & chan->xdev->max_buffer_len);
}
list_splice_tail_init(&chan->pending_list, &chan->active_list);
@@ -1353,7 +1374,7 @@ static void xilinx_dma_start_transfer(struct
xilinx_dma_chan *chan)
/* Start the transfer */
dma_ctrl_write(chan, XILINX_DMA_REG_BTT,
- hw->control & XILINX_DMA_MAX_TRANS_LEN);
+ hw->control & chan->xdev->max_buffer_len);
}
list_splice_tail_init(&chan->pending_list, &chan->active_list);
@@ -1714,7 +1735,7 @@ xilinx_cdma_prep_memcpy(struct dma_chan *dchan,
dma_addr_t dma_dst,
struct xilinx_cdma_tx_segment *segment;
struct xilinx_cdma_desc_hw *hw;
- if (!len || len > XILINX_DMA_MAX_TRANS_LEN)
+ if (!len || len > chan->xdev->max_buffer_len)
return NULL;
desc = xilinx_dma_alloc_tx_descriptor(chan);
@@ -1804,8 +1825,8 @@ static struct dma_async_tx_descriptor
*xilinx_dma_prep_slave_sg(
* Calculate the maximum number of bytes to transfer,
* making sure it is less than the hw limit
*/
- copy = min_t(size_t, sg_dma_len(sg) - sg_used,
-XILINX_DMA_MAX_TRANS_LEN);
+ copy = xilinx_dma_calc_copysize(chan, sg_dma_len(sg),
+ sg_used);
hw = &segment->hw;
/* Fill in the descriptor */
@@ -1909,8 +1930,8 @@ static struct dma_async_tx_descriptor
*xilinx_dma_prep_dma_cyclic(
* Calculate the maximum number of bytes to transfer,
* making sure it is less than the hw limit
*/
- copy = min_t(size_t,
[PATCH v6 6/7] dt-bindings: dmaengine: xilinx_dma: drop include-sg property
This property is not needed anymore, because the driver now autodetects it.
Delete references in documentation.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
Reviewed-by: Rob Herring
---
Changes in v2:
- cc DT maintainer
Changes in v3:
- cc DT maintainerS/ML
Changes in v4:
None
Changes in v5:
None
Changes in v6:
Fix wrong property name in commit title
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index 2fce9fb4b270..93b6d961dd4f 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -37,9 +37,6 @@ Required properties:
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
-Optional properties:
-- xlnx,include-sg: Tells configured for Scatter-mode in
- the hardware.
Optional properties for AXI DMA:
- xlnx,sg-length-width: Should be set to the width in bits of the length
register as configured in h/w. Takes values {8...26}. If the property
--
2.17.1
[PATCH v6 4/7] dmaengine: xilinx_dma: program hardware supported buffer length
From: Radhey Shyam Pandey
AXI-DMA IP supports configurable (c_sg_length_width) buffer length
register width, hence read buffer length (xlnx,sg-length-width) DT
property and ensure that driver doesn't program buffer length
exceeding the supported limit. For VDMA and CDMA there is no change.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Michal Simek
Signed-off-by: Andrea Merello [rebase, reword]
---
Changes in v2:
- drop original patch and replace with the one in Xilinx tree
Changes in v3:
- cc DT maintainers/ML
Changes in v4:
- upper bound for the property should be 26, not 23
- add warn for width > 23 as per xilinx original patch
- rework due to changes introduced in 1/6
Changes in v5:
None
Changes in v6:
None
---
drivers/dma/xilinx/xilinx_dma.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index cbf34dd5e966..0716db61f1d0 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -161,7 +161,9 @@
#define XILINX_DMA_REG_BTT 0x28
/* AXI DMA Specific Masks/Bit fields */
-#define XILINX_DMA_MAX_TRANS_LEN GENMASK(22, 0)
+#define XILINX_DMA_MAX_TRANS_LEN_MIN 8
+#define XILINX_DMA_MAX_TRANS_LEN_MAX 23
+#define XILINX_DMA_V2_MAX_TRANS_LEN_MAX26
#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
#define XILINX_DMA_CR_CYCLIC_BD_EN_MASKBIT(4)
#define XILINX_DMA_CR_COALESCE_SHIFT 16
@@ -2622,7 +2624,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
struct xilinx_dma_device *xdev;
struct device_node *child, *np = pdev->dev.of_node;
struct resource *io;
- u32 num_frames, addr_width;
+ u32 num_frames, addr_width, len_width;
int i, err;
/* Allocate and initialize the DMA engine structure */
@@ -2654,10 +2656,24 @@ static int xilinx_dma_probe(struct platform_device
*pdev)
/* Retrieve the DMA engine properties from the device tree */
xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
- xdev->max_buffer_len = XILINX_DMA_MAX_TRANS_LEN;
+ xdev->max_buffer_len = GENMASK(XILINX_DMA_MAX_TRANS_LEN_MAX - 1, 0);
- if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
+ if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
xdev->mcdma = of_property_read_bool(node, "xlnx,mcdma");
+ if (!of_property_read_u32(node, "xlnx,sg-length-width",
+ &len_width)) {
+ if (len_width < XILINX_DMA_MAX_TRANS_LEN_MIN ||
+ len_width > XILINX_DMA_V2_MAX_TRANS_LEN_MAX) {
+ dev_warn(xdev->dev,
+"invalid xlnx,sg-length-width property
value. Using default width\n");
+ } else {
+ if (len_width > XILINX_DMA_MAX_TRANS_LEN_MAX)
+ dev_warn(xdev->dev, "Please ensure that
IP supports buffer length > 23 bits\n");
+ xdev->max_buffer_len =
+ GENMASK(len_width - 1, 0);
+ }
+ }
+ }
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
err = of_property_read_u32(node, "xlnx,num-fstores",
--
2.17.1
[PATCH v6 5/7] dmaengine: xilinx_dma: autodetect whether the HW supports scatter-gather
The AXIDMA and CDMA HW can be either direct-access or scatter-gather
version. These are SW incompatible.
The driver can handle both versions: a DT property was used to
tell the driver whether to assume the HW is in scatter-gather mode.
This patch makes the driver to autodetect this information. The DT
property is not required anymore.
No changes for VDMA.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in v2:
- autodetect only in !VDMA case
Changes in v3:
- cc DT maintainers/ML
Changes in v4:
- fix typos in commit message
Changes in v5:
None
Changes in v6:
None
---
drivers/dma/xilinx/xilinx_dma.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 0716db61f1d0..41bd8caca09e 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -86,6 +86,7 @@
#define XILINX_DMA_DMASR_DMA_DEC_ERR BIT(6)
#define XILINX_DMA_DMASR_DMA_SLAVE_ERR BIT(5)
#define XILINX_DMA_DMASR_DMA_INT_ERR BIT(4)
+#define XILINX_DMA_DMASR_SG_MASK BIT(3)
#define XILINX_DMA_DMASR_IDLE BIT(1)
#define XILINX_DMA_DMASR_HALTEDBIT(0)
#define XILINX_DMA_DMASR_DELAY_MASKGENMASK(31, 24)
@@ -412,7 +413,6 @@ struct xilinx_dma_config {
* @dev: Device Structure
* @common: DMA device structure
* @chan: Driver specific DMA channel
- * @has_sg: Specifies whether Scatter-Gather is present or not
* @mcdma: Specifies whether Multi-Channel is present or not
* @flush_on_fsync: Flush on frame sync
* @ext_addr: Indicates 64 bit addressing is supported by dma device
@@ -432,7 +432,6 @@ struct xilinx_dma_device {
struct device *dev;
struct dma_device common;
struct xilinx_dma_chan *chan[XILINX_DMA_MAX_CHANS_PER_DEVICE];
- bool has_sg;
bool mcdma;
u32 flush_on_fsync;
bool ext_addr;
@@ -2417,7 +2416,6 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device
*xdev,
chan->dev = xdev->dev;
chan->xdev = xdev;
- chan->has_sg = xdev->has_sg;
chan->desc_pendingcount = 0x0;
chan->ext_addr = xdev->ext_addr;
/* This variable ensures that descriptors are not
@@ -2517,6 +2515,15 @@ static int xilinx_dma_chan_probe(struct
xilinx_dma_device *xdev,
chan->stop_transfer = xilinx_dma_stop_transfer;
}
+ /* check if SG is enabled (only for AXIDMA and CDMA) */
+ if (xdev->dma_config->dmatype != XDMA_TYPE_VDMA) {
+ if (dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
+ XILINX_DMA_DMASR_SG_MASK)
+ chan->has_sg = true;
+ dev_dbg(chan->dev, "ch %d: SG %s\n", chan->id,
+ chan->has_sg ? "enabled" : "disabled");
+ }
+
/* Initialize the tasklet */
tasklet_init(&chan->tasklet, xilinx_dma_do_tasklet,
(unsigned long)chan);
@@ -2655,7 +2662,6 @@ static int xilinx_dma_probe(struct platform_device *pdev)
return PTR_ERR(xdev->regs);
/* Retrieve the DMA engine properties from the device tree */
- xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
xdev->max_buffer_len = GENMASK(XILINX_DMA_MAX_TRANS_LEN_MAX - 1, 0);
if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
--
2.17.1
[PATCH v6 3/7] dt-bindings: dmaengine: xilinx_dma: add optional xlnx,sg-length-width property
The width of the "length register" cannot be autodetected, and it is now
specified with a DT property. Add documentation for it.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: Radhey Shyam Pandey
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in v2:
- change property name
- property is now optional
- cc DT maintainer
Changes in v3:
- reword
- cc DT maintainerS and ML
Changes in v4:
- specify the unit, the valid range and the default value
Changes in v5:
- commit message trivial fix
- fix spaces before tab
Changes in v6:
None
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index 174af2c45e77..2fce9fb4b270 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -41,6 +41,10 @@ Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
Optional properties for AXI DMA:
+- xlnx,sg-length-width: Should be set to the width in bits of the length
+ register as configured in h/w. Takes values {8...26}. If the property
+ is missing or invalid then the default value 23 is used. This is the
+ maximum value that is supported by all IP versions.
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
--
2.17.1
[PATCH v6 7/7] dmaengine: xilinx_dma: Drop SG support for VDMA IP
xilinx_vdma_start_transfer() is used only for VDMA IP, still it contains
conditional code on has_sg variable. has_sg is set only whenever the HW
does support SG mode, that is never true for VDMA IP.
This patch drops the never-taken branches.
Signed-off-by: Andrea Merello
Reviewed-by: Radhey Shyam Pandey
---
Changes in V4: introduced this patch in series
Changes in v5:
None
Changes in v6:
None
---
drivers/dma/xilinx/xilinx_dma.c | 84 +
1 file changed, 32 insertions(+), 52 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 41bd8caca09e..a37e28a43885 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1100,6 +1100,8 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
struct xilinx_dma_tx_descriptor *desc, *tail_desc;
u32 reg, j;
struct xilinx_vdma_tx_segment *tail_segment;
+ struct xilinx_vdma_tx_segment *segment, *last = NULL;
+ int i = 0;
/* This function was invoked with lock held */
if (chan->err)
@@ -1119,14 +1121,6 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
tail_segment = list_last_entry(&tail_desc->segments,
struct xilinx_vdma_tx_segment, node);
- /*
-* If hardware is idle, then all descriptors on the running lists are
-* done, start new transfers
-*/
- if (chan->has_sg)
- dma_ctrl_write(chan, XILINX_DMA_REG_CURDESC,
- desc->async_tx.phys);
-
/* Configure the hardware using info in the config structure */
if (chan->has_vflip) {
reg = dma_read(chan, XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP);
@@ -1143,15 +1137,11 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
else
reg &= ~XILINX_DMA_DMACR_FRAMECNT_EN;
- /*
-* With SG, start with circular mode, so that BDs can be fetched.
-* In direct register mode, if not parking, enable circular mode
-*/
- if (chan->has_sg || !config->park)
- reg |= XILINX_DMA_DMACR_CIRC_EN;
-
+ /* If not parking, enable circular mode */
if (config->park)
reg &= ~XILINX_DMA_DMACR_CIRC_EN;
+ else
+ reg |= XILINX_DMA_DMACR_CIRC_EN;
dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
@@ -1173,48 +1163,38 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
return;
/* Start the transfer */
- if (chan->has_sg) {
- dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
- tail_segment->phys);
- list_splice_tail_init(&chan->pending_list, &chan->active_list);
- chan->desc_pendingcount = 0;
- } else {
- struct xilinx_vdma_tx_segment *segment, *last = NULL;
- int i = 0;
-
- if (chan->desc_submitcount < chan->num_frms)
- i = chan->desc_submitcount;
-
- list_for_each_entry(segment, &desc->segments, node) {
- if (chan->ext_addr)
- vdma_desc_write_64(chan,
- XILINX_VDMA_REG_START_ADDRESS_64(i++),
- segment->hw.buf_addr,
- segment->hw.buf_addr_msb);
- else
- vdma_desc_write(chan,
+ if (chan->desc_submitcount < chan->num_frms)
+ i = chan->desc_submitcount;
+
+ list_for_each_entry(segment, &desc->segments, node) {
+ if (chan->ext_addr)
+ vdma_desc_write_64(chan,
+ XILINX_VDMA_REG_START_ADDRESS_64(i++),
+ segment->hw.buf_addr,
+ segment->hw.buf_addr_msb);
+ else
+ vdma_desc_write(chan,
XILINX_VDMA_REG_START_ADDRESS(i++),
segment->hw.buf_addr);
- last = segment;
- }
-
- if (!last)
- return;
+ last = segment;
+ }
- /* HW expects these parameters to be same for one transaction */
- vdma_desc_write(chan, XILINX_DMA_REG_HSIZE, last->hw.hsize);
- vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
- last->hw.stride);
- vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
+ if (!last)
+ return;
- chan->desc_submitcount++;
- chan->desc_pendingcount--;
- list_del(&desc->node);
- list_add_tail(&desc->node, &chan->active_li
Re: [RFC 0/3] Unify CPU topology across ARM64 & RISC-V
On 11/20/2018 4:11 AM, Sudeep Holla wrote: On Thu, Nov 15, 2018 at 11:31:33AM -0700, Jeffrey Hugo wrote: [...] I was interested in testing these on QDF2400, an ARM64 platform, since this series touches core ARM64 code and I'd hate to see a regression. However, I can't figure out what baseline to use to apply these. Different patches cause different conflicts of a variety of baselines I attempted. Good to know that we can test DT configuration on QDF2400. I always assumed it's ACPI only. It is ACPI only in the production configuration. I suppose we could hack things up to do basic DT sanity, but I expect it would be nasty and non-trivial. What are these intended to apply to? The series alone may not get the package/socket ids correct on QDF2400. I have not yet added support for the same as I wanted to get the initial feedback on DT bindings. The movement of DT binding and corresponding code should not regress and you should be able to validate only that part. On a cursory glance, it looks like some of the reorganized code would also be used in the ACPI path (things that are common between DT and ACPI). I do not expect problems, but I still feel its prudent to do a sanity check on actual hardware. -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: Re: STIBP by default.. Revert?
On Mon, 19 Nov 2018, Arjan van de Ven wrote: > In the documentation, AMD officially recommends against this by default, > and I can speak for Intel that our position is that as well: this really > must not be on by default. Thanks for pointing to the AMD doc, it's indeed clearly stated there. Is there any chance this could perhaps be added to Intel documentation as well, so that we avoid cases like this in the future? The revision 3.0 of Intel doc from may 2018 [1] I am always looking into doesn't say anything discouraging about STIBP to me. [1] https://software.intel.com/security-software-guidance/api-app/sites/default/files/336996-Speculative-Execution-Side-Channel-Mitigations.pdf?_gclid=5b78f4d130faf8.22277271-5b78f4d130fb70.17467890&_utm_source=xakep&_utm_campaign=mention17&_utm_medium=inline&_utm_content=lnk223716354570 Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH v9 02/15] sched/cpufreq: Prepare schedutil for Energy Aware Scheduling
On Tue, Nov 20, 2018 at 10:16:02AM +0530, Viresh Kumar wrote:
> On 19-11-18, 14:18, Quentin Perret wrote:
> > @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct sugov_cpu
> > *sg_cpu)
>
> > - if ((util + cpu_util_dl(rq)) >= max)
> > - return max;
> > + if (type == FREQUENCY_UTIL) {
> > + /*
> > +* For frequency selection we do not make cpu_util_dl() a
> > +* permanent part of this sum because we want to use
> > +* cpu_bw_dl() later on, but we need to check if the
> > +* CFS+RT+DL sum is saturated (ie. no idle time) such
> > +* that we select f_max when there is no idle time.
> > +*
> > +* NOTE: numerical errors or stop class might cause us
> > +* to not quite hit saturation when we should --
> > +* something for later.
> > +*/
> > +
> > + if ((util + cpu_util_dl(rq)) >= max)
> > + return max;
> > + } else {
> > + /*
> > +* OTOH, for energy computation we need the estimated
> > +* running time, so include util_dl and ignore dl_bw.
> > +*/
> > + util += cpu_util_dl(rq);
> > + if (util >= max)
> > + return max;
> > + }
>
> Maybe write above as:
>
> dl_util = cpu_util_dl(rq);
>
> if ((util + dl_util) >= max)
> return max;
>
> if (type != FREQUENCY_UTIL)
> util += dl_util;
>
>
> as both the if/else parts were doing almost the same thing.
A little like so ?
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -201,8 +201,8 @@ static unsigned int get_next_freq(struct
unsigned long schedutil_freq_util(int cpu, unsigned long util_cfs,
unsigned long max, enum schedutil_type type)
{
+ unsigned long dl_util, util, irq;
struct rq *rq = cpu_rq(cpu);
- unsigned long util, irq;
if (type == FREQUENCY_UTIL && rt_rq_is_runnable(&rq->rt))
return max;
@@ -225,30 +225,26 @@ unsigned long schedutil_freq_util(int cp
util = util_cfs;
util += cpu_util_rt(rq);
- if (type == FREQUENCY_UTIL) {
- /*
-* For frequency selection we do not make cpu_util_dl() a
-* permanent part of this sum because we want to use
-* cpu_bw_dl() later on, but we need to check if the
-* CFS+RT+DL sum is saturated (ie. no idle time) such
-* that we select f_max when there is no idle time.
-*
-* NOTE: numerical errors or stop class might cause us
-* to not quite hit saturation when we should --
-* something for later.
-*/
-
- if ((util + cpu_util_dl(rq)) >= max)
- return max;
- } else {
- /*
-* OTOH, for energy computation we need the estimated
-* running time, so include util_dl and ignore dl_bw.
-*/
- util += cpu_util_dl(rq);
- if (util >= max)
- return max;
- }
+ dl_util = cpu_util_dl(rq);
+
+ /*
+* NOTE: numerical errors or stop class might cause us to not quite hit
+* saturation when we should -- something for later.
+*/
+ if (util + dl_util > max)
+ return max;
+
+ /*
+* For frequency selection we do not make cpu_util_dl() a permanent
+* part of this sum because we want to use cpu_bw_dl() later on, but we
+* need to check if the CFS+RT+DL sum is saturated (ie. no idle time)
+* such that we select f_max when there is no idle time.
+*
+* OTOH, for energy computation we need the estimated running time, so
+* do include util_dl and ignore dl_bw.
+*/
+ if (type == ENERGY_UTIL)
+ util += dl_util;
/*
* There is still idle time; further improve the number by using the
@@ -262,21 +258,18 @@ unsigned long schedutil_freq_util(int cp
util = scale_irq_capacity(util, irq, max);
util += irq;
- if (type == FREQUENCY_UTIL) {
- /*
-* Bandwidth required by DEADLINE must always be granted
-* while, for FAIR and RT, we use blocked utilization of
-* IDLE CPUs as a mechanism to gracefully reduce the
-* frequency when no tasks show up for longer periods of
-* time.
-*
-* Ideally we would like to set bw_dl as min/guaranteed
-* freq and util + bw_dl as requested freq. However,
-* cpufreq is not yet ready for such an interface. So,
-* we only do the latter for now.
-*/
+ /*
+* Bandwidth required by DEADLINE
Re: [PATCH] cpuidle: big.LITTLE: add of_node_put()
On Tue, Nov 20, 2018 at 2:00 PM Yangtao Li wrote:
>
> use of_node_put() to release the refcount.
I gather that the of_node_put() is missing?
If so, that should be stated in the changelog too.
> Signed-off-by: Yangtao Li
> ---
> drivers/cpuidle/cpuidle-big_little.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-big_little.c
> b/drivers/cpuidle/cpuidle-big_little.c
> index db2ede565f1a..a3b8bc09bac8 100644
> --- a/drivers/cpuidle/cpuidle-big_little.c
> +++ b/drivers/cpuidle/cpuidle-big_little.c
> @@ -174,8 +174,10 @@ static int __init bl_idle_init(void)
> /*
> * Initialize the driver just for a compliant set of machines
> */
> - if (!of_match_node(compatible_machine_match, root))
> - return -ENODEV;
> + if (!of_match_node(compatible_machine_match, root)){
> + ret = -ENODEV;
> + goto out_release_node;
> + }
>
> if (!mcpm_is_available())
> return -EUNATCH;
> @@ -222,6 +224,8 @@ static int __init bl_idle_init(void)
> kfree(bl_idle_big_driver.cpumask);
> out_uninit_little:
> kfree(bl_idle_little_driver.cpumask);
> +out_release_node:
> + of_node_put(root);
>
> return ret;
> }
> --
> 2.17.0
>
Re: Cleaning up numbering for new x86 syscalls?
On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote: > > * Andy Lutomirski: > > > 5. Adjust the scripts so that we only have to wire up new syscalls > > once. They'll have a nr above 1024, and they'll have the same nr on > > all x86 variants. > > Is there a sufficiently sized gap on all other architectures as well? > The restriction to the x86 variants seems arbitrary to me. > Fair point. We have this shiny "generic" syscall list. Maybe we can get x86 synced up with it for new syscalls.
Re: STIBP by default.. Revert?
On Sun, 18 Nov 2018, Linus Torvalds wrote: > This was marked for stable, and honestly, nowhere in the discussion > did I see any mention of just *how* bad the performance impact of this > was. > > When performance goes down by 50% on some loads, people need to start > asking themselves whether it was worth it. It's apparently better to > just disable SMT entirely, which is what security-conscious people do > anyway. > > So why do that STIBP slow-down by default when the people who *really* > care already disabled SMT? > > I think we should use the same logic as for L1TF: we default to > something that doesn't kill performance. Warn once about it, and let > the crazy people say "I'd rather take a 50% performance hit than > worry about a theoretical issue". Just to update status quo here -- Thomas is working on polishing Tim's set into mergeable state, I've just sent him small addition on top that makes IBPB also be controlled via the same toggle. That should make the whole 'spectre v2 userspace-to-userspace' mitigation control consistent and undestandable. And also give us even few more % back that are lost due to IBPB as well. -- Jiri Kosina SUSE Labs
Re: RFC: userspace exception fixups
On Tue, Nov 20, 2018 at 2:11 AM Jarkko Sakkinen wrote: > > On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen > > wrote: > > > > > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wrote: > > > > 1. The kernel needs some way to know *when* to apply this fixup. > > > > Decoding the instruction stream and doing it to all exceptions that > > > > hit an ENCLU instruction seems like a poor design. > > > > > > I'm not sure why you would ever need to do any type of fixup as the idea > > > is to just return to AEP i.e. from chosen exceptions (EPCM, #UD) the AEP > > > would work the same way as for exceptions that the kernel can deal with > > > except filling the exception information to registers. > > > > Sure, but how does the kernel know when to do that and when to send a > > signal? I don't really like decoding the instruction stream to figure > > it out. > > Hmm... why you have to decode instruction stream to find that out? Would > just depend on exception type (#GP with EPCM, #UD). What is "#GP with EPCM"? We certainly don't want to react to #UD in general by mucking with some regs and retrying -- that will infinite loop and confuse everyone. I'm not even 100% convinced that decoding the insn stream is useful -- AEP can point to something that isn't ENCLU. IOW the kernel needs to know *when* to apply this special behavior. Sadly there is no bit in the exception frame that says "came from SGX".
Re: [RFC PATCH 2/3] mm, memory_hotplug: deobfuscate migration part of offlining
On Tue 20-11-18 16:13:35, Oscar Salvador wrote:
>
> > Signed-off-by: Michal Hocko
> [...]
> > + do {
> > + for (pfn = start_pfn; pfn;)
> > + {
> > + /* start memory hot removal */
>
> Should we change thAT comment? I mean, this is not really the hot-
> removal stage.
>
> Maybe "start memory migration" suits better? or memory offlining?
I will just drop it. It doesn't really explain anything.
[...]
>
> This indeed looks much nicer and it is easier to follow.
> With the changes commented by David:
>
> Reviewed-by: Oscar Salvador
Thanks!
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 1/3] PCI: dwc: allow to limit registers set length
On Tue, Nov 20, 2018 at 02:27:03PM +0100, Stefan Agner wrote:
> Add length to the struct dw_pcie and check that the accessors
> dw_pcie_(rd|wr)_own_conf() do not read/write beyond that point.
>
> Signed-off-by: Stefan Agner
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 4
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
> 2 files changed, 5 insertions(+)
Hi Stefan,
may I kindly ask you please to rebase this series against my pci/dwc
branch ? I will apply it with Lucas tags then.
Please CC me on the patches.
Thanks,
Lorenzo
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 29a05759a294..b422538ee0bb 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -29,6 +29,8 @@ static int dw_pcie_rd_own_conf(struct pcie_port *pp, int
> where, int size,
> return pp->ops->rd_own_conf(pp, where, size, val);
>
> pci = to_dw_pcie_from_pp(pp);
> + if (pci->dbi_length && where + size > pci->dbi_length)
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> return dw_pcie_read(pci->dbi_base + where, size, val);
> }
>
> @@ -41,6 +43,8 @@ static int dw_pcie_wr_own_conf(struct pcie_port *pp, int
> where, int size,
> return pp->ops->wr_own_conf(pp, where, size, val);
>
> pci = to_dw_pcie_from_pp(pp);
> + if (pci->dbi_length && where + size > pci->dbi_length)
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> return dw_pcie_write(pci->dbi_base + where, size, val);
> }
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 9f1a5e399b70..5be5f369abf2 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -215,6 +215,7 @@ struct dw_pcie {
> struct device *dev;
> void __iomem*dbi_base;
> void __iomem*dbi_base2;
> + int dbi_length;
> u32 num_viewport;
> u8 iatu_unroll_enabled;
> struct pcie_portpp;
> --
> 2.19.1
>
Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google)
wrote:
>
> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
> where we don't need to modify core VFS structures to get the same
> behavior of the seal. This solves several side-effects pointed out by
> Andy [2].
>
> [1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/
> [2]
> https://lore.kernel.org/lkml/69ce06cc-e47c-4992-848a-66eb23ee6...@amacapital.net/
>
> Suggested-by: Andy Lutomirski
> Fixes: 5e653c2923fd ("mm: Add an F_SEAL_FUTURE_WRITE seal to memfd")
What tree is that commit in? Can we not just fold this in?
Re: [PATCH] debugobjects: scale the static pool size
> On Nov 20, 2018, at 8:50 AM, Waiman Long wrote: > > On 11/20/2018 01:42 AM, Qian Cai wrote: >> The current value of the early boot static pool size is not big enough >> for systems with large number of CPUs with timer or/and workqueue >> objects selected. As the results, systems have 60+ CPUs with both timer >> and workqueue objects enabled could trigger "ODEBUG: Out of memory. >> ODEBUG disabled". Hence, fixed it by computing it according to >> CONFIG_NR_CPUS and CONFIG_DEBUG_OBJECTS_* options. >> >> Signed-off-by: Qian Cai >> --- >> lib/debugobjects.c | 53 +- >> 1 file changed, 52 insertions(+), 1 deletion(-) >> >> diff --git a/lib/debugobjects.c b/lib/debugobjects.c >> index 70935ed91125..372dc34206d5 100644 >> --- a/lib/debugobjects.c >> +++ b/lib/debugobjects.c >> @@ -23,7 +23,53 @@ >> #define ODEBUG_HASH_BITS 14 >> #define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS) >> >> +/* >> + * Some debug objects are allocated during the early boot. Enabling some >> + * options like timers or workqueue objects may increase the size required >> + * significantly with large number of CPUs. For example, >> + * >> + * No. CPUs x 2 (worker pool) objects: >> + * >> + * start_kernel >> + * workqueue_init_early >> + * init_worker_pool >> + * init_timer_key >> + * debug_object_init >> + * >> + * No. CPUs objects (CONFIG_HIGH_RES_TIMERS): >> + * >> + * sched_init >> + * hrtick_rq_init >> + * hrtimer_init >> + * >> + * CONFIG_DEBUG_OBJECTS_WORK: >> + * No. CPUs x 6 (workqueue) objects: >> + * >> + * workqueue_init_early >> + * alloc_workqueue >> + * __alloc_workqueue_key >> + * alloc_and_link_pwqs >> + * init_pwq >> + * >> + * Also, plus No. CPUs objects: >> + * >> + * perf_event_init >> + *__init_srcu_struct >> + * init_srcu_struct_fields >> + *init_srcu_struct_nodes >> + * __init_work >> + * >> + * Increase the number a bit more in case the implmentatins are changed in >> + * the future. >> + */ >> +#if defined(CONFIG_NR_CPUS) && defined(CONFIG_DEBUG_OBJECTS_TIMERS) && \ >> +!defined(CONFIG_DEBUG_OBJECTS_WORK) >> +#define ODEBUG_POOL_SIZE(CONFIG_NR_CPUS * 10) >> +#elif defined(CONFIG_NR_CPUS) && defined(CONFIG_DEBUG_OBJECTS_WORK) >> +#define ODEBUG_POOL_SIZE(CONFIG_NR_CPUS * 30) >> +#else >> #define ODEBUG_POOL_SIZE 1024 >> +#endif /* CONFIG_NR_CPUS */ >> #define ODEBUG_POOL_MIN_LEVEL256 >> > > CONFIG_NR_CPUS is always defined. You don't need to put that as a #if > condition. Where does the scaling factor 30 come from? It looks high to me. Hmm, looks like some architectures could have it undefined since it depends on CONFIG_SMP where the later can be disabled. For example alpha, config NR_CPUS int "Maximum number of CPUs (2-32)" range 2 32 depends on SMP Scaling factor 30 came from the data, with all the debug_objects options enabled, I have, 64-CPU: ODEBUG: 1114 of 1114 active objects replaced 256-CPU: ODEBUG: 4378 of 4378 active objects replaced I also give a bit room for growth in the future since the implementation details could always change. > > For UP system, CONFIG_NR_CPUS will be 1. I think it is better to have a > guarantee minimum plus a multiplier of the # of configured CPUs. > Something like > > 512 + CONFIG_NR_CPUS * > > where should be the sum of all early allocation objects > that scale with the number of cpus. The guarantee minimum will cover > other miscellaneous objects. That is a good catch. I’ll fix that.
Re: [PATCH v1 1/1] arm64: Early boot time stamps
On 18-11-20 14:55:23, Marc Zyngier wrote: > > Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where > > this minimum is defined in aarch64 specs. I will change it to 56. > > See D10.1.2 (The system counter) in the ARM ARM[1], which says: > > > The Generic Timer provides a system counter with the following > specification: > Width At least 56 bits wide. > The value returned by any 64-bit read of the counter is > zero-extended to 64 bits. > > > This is not AArch64-specific though, and 32bit systems implementing the > generic timers have the exact same requirements. Thank you, makes sense. I was thinking there could be AArch64 specific minimum limit. > > > I will send v2 soon. > > Please wait a bit and give others a chance to review this too. I already sent, but will wait in the future before sending v3. > > Thanks, > > M. > > [1] https://static.docs.arm.com/ddi0487/da/DDI0487D_a_armv8_arm.pdf > -- > Jazz is not dead. It just smells funny...
Re: [PATCH v2] watchdog: cpwd: add of_node_put()
On 11/20/18 6:54 AM, Yangtao Li wrote: use of_node_put() to release the refcount. Signed-off-by: Yangtao Li Reviewed-by: Guenter Roeck --- Changes in v2: -do that right after its last use to also cover error handling. --- drivers/watchdog/cpwd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c index aee0b25cf10d..32156e199c51 100644 --- a/drivers/watchdog/cpwd.c +++ b/drivers/watchdog/cpwd.c @@ -570,6 +570,8 @@ static int cpwd_probe(struct platform_device *op) if (str_prop) p->timeout = simple_strtoul(str_prop, NULL, 10); + of_node_put(options); + /* CP1400s seem to have broken PLD implementations-- the * interrupt_mask register cannot be written, so no timer * interrupts can be masked within the PLD.
Re: [RFC PATCH 1/3] mm, memory_hotplug: try to migrate full section worth of pages
On Tue 20-11-18 15:51:32, Oscar Salvador wrote: > On Tue, 2018-11-20 at 14:43 +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > do_migrate_range has been limiting the number of pages to migrate to > > 256 > > for some reason which is not documented. > > When looking back at old memory-hotplug commits one feels pretty sad > about the brevity of the changelogs. Well, things evolve and we've become much more careful about changelogs over time. It still gets quite a lot of time to push back on changelogs even these days though. People still keep forgetting that "what" is not as important as "why" because the former is usually quite easy to understand from reading the diff. The intention behind is usually what gets forgotten after years. I guess people realize this much more after few excavation git blame tours. > > Signed-off-by: Michal Hocko > > Reviewed-by: Oscar Salvador Thanks! -- Michal Hocko SUSE Labs
Re: Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree
Hi Charles,
On 2018-11-20 15:47, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
>> On 2018-05-17 18:41, Mark Brown wrote:
>>> Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO number
>> This patch causes following kernel warning on Samsung Exynos4412 based
>> Trats2 board:
>>
>> wm8994 4-001a: Failed to get supply 'DBVDD1': -517
>> wm8994 4-001a: Failed to get supplies: -517
> How is the wm8994 being registered on this board? I am having
> difficulty finding a device tree or a board file that relates to
> the board and includes the wm8994.
Please check arch/arm/boot/dts/exynos4412-trats2.dts details. The I2C device
is defined in exynos4412-midas.dtsi, it uses "wlf,wm1811" compatible.
>>> @@ -203,6 +203,18 @@ static const struct i2c_board_info wm1277_devs[] = {
>>> { I2C_BOARD_INFO("wm8958", 0x1a), /* WM8958 is the superset */
>>> .platform_data = &wm8994_pdata,
>>> .irq = GLENFARCLAS_PMIC_IRQ_BASE + WM831X_IRQ_GPIO_2,
>>> + .dev_name = "wm8958",
>>> + },
>>> +};
>>> +
>>> +static struct gpiod_lookup_table wm8994_gpiod_table = {
>>> + .dev_id = "i2c-wm8958", /* I2C device name */
>>> + .table = {
>>> + GPIO_LOOKUP("GPION", 6,
>>> + "wlf,ldo1ena", GPIO_ACTIVE_HIGH),
>>> + GPIO_LOOKUP("GPION", 4,
>>> + "wlf,ldo2ena", GPIO_ACTIVE_HIGH),
>>> + { },
>>> },
>>> };
> If its being done through a board file I guess you will need the
> equivalent of this.
No board file, everything in DT.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH 00/16] staging: vchiq: dead code removal & misc fixes
Hi All, This series was written in parallel with reading and understanding the vchiq code. So excuse me for the lack of logic in the sequence of patches. The main focus was to delete as much code as possible, I've counted around 550 lines, which is not bad. Apart from that there are some patches enforcing proper kernel APIs usage. The only patch that really changes code is the vchiq_ioc_copy_element_data() rewrite. The last commit updates the TODO list with some of my observations, I realise some of the might be a little opinionated. If anything it's going to force a discussion on the topic, which is nice. It was developed on top of the latest linux-next, and was tested on a RPIv3B+ with audio, video and running vchiq_test. Regards, Nicolas RFC -> PATCH, as per Stefan's comments: - Remove semaphore initialization from remove_event_create() (commit 9) - Join all three semaphore to completion patches (commit 11) - Update probe/init commit message (commit 14) - Update TODO commit message and clean up (commit 16) - Fix spelling on some of the patches === Nicolas Saenz Julienne (16): staging: vchiq_core: rework vchiq_get_config staging: vchiq_arm: rework close/remove_service IOCTLS staging: vchiq_shim: delete vchi_service_create staging: vchiq_arm: use list_for_each_entry when accessing bulk_waiter_list staging: vchiq_arm: get rid of vchi_mh.h staging: vchiq_arm: rework vchiq_ioc_copy_element_data staging: vchiq-core: get rid of is_master distinction staging: vchiq_core: remove unnecessary safety checks in vchiq_init_state staging: vchiq_core: do not initialize semaphores twice staging: vchiq_core: don't add a wmb() before remote_event_signal() staging: vchiq: use completions instead of semaphores staging: vchiq_util: get rid of unneeded memory barriers staging: vchiq_core: fix logic redundancy in parse_open staging: vchiq_arm: rework probe and init functions staging: vchiq_arm: fix open/release cdev functions staging: vchiq: add more tasks to the TODO list .../staging/vc04_services/interface/vchi/TODO | 42 ++ .../vc04_services/interface/vchi/vchi.h | 8 - .../vc04_services/interface/vchi/vchi_mh.h| 42 -- .../interface/vchiq_arm/vchiq_2835_arm.c | 18 +- .../interface/vchiq_arm/vchiq_arm.c | 598 -- .../interface/vchiq_arm/vchiq_core.c | 523 --- .../interface/vchiq_arm/vchiq_core.h | 47 +- .../interface/vchiq_arm/vchiq_if.h| 11 +- .../interface/vchiq_arm/vchiq_shim.c | 32 - .../interface/vchiq_arm/vchiq_util.c | 48 +- .../interface/vchiq_arm/vchiq_util.h | 6 +- 11 files changed, 435 insertions(+), 940 deletions(-) delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_mh.h -- 2.19.1
[PATCH 04/16] staging: vchiq_arm: use list_for_each_entry when accessing bulk_waiter_list
The resulting code is way more readeable and intuitive compared to plain
list_for_each.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 52 ++-
1 file changed, 16 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 835152799433..76de36e9e3b6 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -280,16 +280,11 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
"%s(%p): returning %d", __func__, instance, status);
if (status == VCHIQ_SUCCESS) {
- struct list_head *pos, *next;
+ struct bulk_waiter_node *waiter, *next;
- list_for_each_safe(pos, next,
- &instance->bulk_waiter_list) {
- struct bulk_waiter_node *waiter;
-
- waiter = list_entry(pos,
- struct bulk_waiter_node,
- list);
- list_del(pos);
+ list_for_each_entry_safe(waiter, next,
+&instance->bulk_waiter_list, list) {
+ list_del(&waiter->list);
vchiq_log_info(vchiq_arm_log_level,
"bulk_waiter - cleaned up %pK for pid
%d",
waiter, waiter->pid);
@@ -473,7 +468,6 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle,
void *data,
VCHIQ_SERVICE_T *service;
VCHIQ_STATUS_T status;
struct bulk_waiter_node *waiter = NULL;
- struct list_head *pos;
service = find_service_by_handle(handle);
if (!service)
@@ -484,13 +478,9 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T
handle, void *data,
unlock_service(service);
mutex_lock(&instance->bulk_waiter_list_mutex);
- list_for_each(pos, &instance->bulk_waiter_list) {
- if (list_entry(pos, struct bulk_waiter_node,
- list)->pid == current->pid) {
- waiter = list_entry(pos,
- struct bulk_waiter_node,
- list);
- list_del(pos);
+ list_for_each_entry(waiter, &instance->bulk_waiter_list, list) {
+ if (waiter->pid == current->pid) {
+ list_del(&waiter->list);
break;
}
}
@@ -1135,21 +1125,16 @@ vchiq_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
ret = -ENOMEM;
break;
}
+
args.userdata = &waiter->bulk_waiter;
} else if (args.mode == VCHIQ_BULK_MODE_WAITING) {
- struct list_head *pos;
-
mutex_lock(&instance->bulk_waiter_list_mutex);
- list_for_each(pos, &instance->bulk_waiter_list) {
- if (list_entry(pos, struct bulk_waiter_node,
- list)->pid == current->pid) {
- waiter = list_entry(pos,
- struct bulk_waiter_node,
- list);
- list_del(pos);
+ list_for_each_entry(waiter, &instance->bulk_waiter_list,
+ list) {
+ if (waiter->pid == current->pid) {
+ list_del(&waiter->list);
break;
}
-
}
mutex_unlock(&instance->bulk_waiter_list_mutex);
if (!waiter) {
@@ -2163,16 +2148,11 @@ vchiq_release(struct inode *inode, struct file *file)
vchiq_release_internal(instance->state, NULL);
{
- struct list_head *pos, *next;
-
- list_for_each_safe(pos, next,
- &instance->bulk_waiter_list) {
- struct bulk_waiter_node *waiter;
+ struct bulk_waiter_node *waiter, *next;
- waiter = list_entry(pos,
- struct bulk_waiter_node,
- list);
- list_del(pos);
+ list_for_each_entry_safe(waiter, next,
+ &instance->bulk_waiter_list, list) {
+ list_del(&waiter->list
Re: [PATCH v1 1/1] arm64: Early boot time stamps
On 20/11/2018 14:40, Pavel Tatashin wrote:
>>> +static __init void sched_clock_early_init(void)
>>> +{
>>> + u64 freq = arch_timer_get_cntfrq();
>>> + u64 (*read_time)(void) = arch_counter_get_cntvct;
>>
>> We already have arch_timer_read_counter which is exposed from
>> arm_arch_timer.h.
>
> OK
>
>>
>>> +
>>> + /* Early clock is available only on platforms with known freqs */
>>
>> This comment is misleading. It should read something like:
>>
>> /*
>> * The arm64 boot protocol mandates that CNTFRQ_EL0 reflects
>> * the timer frequency. To avoid breakage on misconfigured
>> * systems, do not register the early sched_clock if the
>> * programmed value if zero. Other random values will just
>> * result in random output.
>> */
>>
>
> OK
>
>>> + if (!freq)
>>> + return;
>>> +
>>> + sched_clock_register(read_time, BITS_PER_LONG, freq);
>>
>> This doesn't seem right. The counter has an architected minimum of 56
>> bits, and you can't assume that it is going to be more than that.
>
> Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where
> this minimum is defined in aarch64 specs. I will change it to 56.
See D10.1.2 (The system counter) in the ARM ARM[1], which says:
The Generic Timer provides a system counter with the following
specification:
Width At least 56 bits wide.
The value returned by any 64-bit read of the counter is
zero-extended to 64 bits.
This is not AArch64-specific though, and 32bit systems implementing the
generic timers have the exact same requirements.
> I will send v2 soon.
Please wait a bit and give others a chance to review this too.
Thanks,
M.
[1] https://static.docs.arm.com/ddi0487/da/DDI0487D_a_armv8_arm.pdf
--
Jazz is not dead. It just smells funny...
Re: [PATCH] mmc: core: Remove timeout when enabling cache
On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote: > On 20 November 2018 at 15:00, Sjoerd Simons > wrote: > > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote: > > > + Hal Emmerich > > > > > > On 20 November 2018 at 12:38, Sjoerd Simons > > > wrote: > > > > On Tue, 2018-11-20 at 11:23 +0100, Wolfram Sang wrote: > > > > So if you know the pattern, or just happen to hit it often in > > > > e.g. > > > > automated testing, it does show up during development. > > > > Otherwise it > > > > can > > > > appear to "happen once in a while randomly". > > > > > > I don't quite follow. As far as I understand, the extended > > > timeout is > > > needed when turning the cache on. > > > > > > The above seems more related to flushing the cache, no? Flushing > > > have > > > no timeout (also reported to be an issue [1]), which happens > > > either > > > at > > > _mmc_hw_reset() or at _mmc_suspend(). > > > > > > What is the relation here? > > > > Yes it's the kinda of behaviour you would expect on a flush indeed! > > I > > don't know what the card actaully does when turning the cache on, > > whether it's actually flush of something persistent when turning > > the > > cache on after a hard poweroff or doing some other validation. > > > > All i can share is what our testing seems to indicate, which is > > that > > there is a wide spread in the time the card needs *and* there seems > > to > > be strong correlation to the I/O activity before the hard power off > > and > > the time taken by "cache on". > > So the hard power off, means that you are cutting the power to the > platform and not doing a graceful power off? Just so I understand > correctly. Correct. With hard power off i mean cutting the power to the board in some way. When doing a gracefull power off, the issue does not occur on my boards (cache on is fast). Presumably as the eMMC got its cache flushed as part of the shutdown procedure.. > > > Using no limit of the timeout, would mean we may hang for ~10 > > > minutes > > > (MMC_OPS_TIMEOUT_MS) instead, no thanks. > > > > Probably a silly question, but would this actually cause e.g. boot > > to > > hang while waiting for the card (assuming rootfs is somewhere > > else)? > > Nope. > > [...] Then i'm probably just being dense, but i'm unsure what the issue is with waiting for 10 minuts in this case. Apart from having to wait for 10 minutes before the user gets an indication in the kernel that the card is not usable? -- Sjoerd Simons Collabora Ltd.
[PATCH 01/16] staging: vchiq_core: rework vchiq_get_config
The function is overly complicated for what it's ultimately achieving.
It's simply filling up a structure.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 12
.../interface/vchiq_arm/vchiq_core.c | 30 +--
.../interface/vchiq_arm/vchiq_if.h| 3 +-
3 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 45de21c210c1..5af3f2651bd3 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1480,13 +1480,11 @@ vchiq_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
ret = -EINVAL;
break;
}
- status = vchiq_get_config(instance, args.config_size, &config);
- if (status == VCHIQ_SUCCESS) {
- if (copy_to_user((void __user *)args.pconfig,
- &config, args.config_size) != 0) {
- ret = -EFAULT;
- break;
- }
+
+ vchiq_get_config(&config);
+ if (copy_to_user(args.pconfig, &config, args.config_size)) {
+ ret = -EFAULT;
+ break;
}
} break;
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 7642ced31436..89f1ccdc3b98 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -3583,28 +3583,14 @@ vchiq_get_peer_version(VCHIQ_SERVICE_HANDLE_T handle,
short *peer_version)
return status;
}
-VCHIQ_STATUS_T
-vchiq_get_config(VCHIQ_INSTANCE_T instance,
- int config_size, VCHIQ_CONFIG_T *pconfig)
-{
- VCHIQ_CONFIG_T config;
-
- (void)instance;
-
- config.max_msg_size = VCHIQ_MAX_MSG_SIZE;
- config.bulk_threshold = VCHIQ_MAX_MSG_SIZE;
- config.max_outstanding_bulks = VCHIQ_NUM_SERVICE_BULKS;
- config.max_services = VCHIQ_MAX_SERVICES;
- config.version= VCHIQ_VERSION;
- config.version_min= VCHIQ_VERSION_MIN;
-
- if (config_size > sizeof(VCHIQ_CONFIG_T))
- return VCHIQ_ERROR;
-
- memcpy(pconfig, &config,
- min(config_size, (int)(sizeof(VCHIQ_CONFIG_T;
-
- return VCHIQ_SUCCESS;
+void vchiq_get_config(VCHIQ_CONFIG_T *config)
+{
+ config->max_msg_size = VCHIQ_MAX_MSG_SIZE;
+ config->bulk_threshold = VCHIQ_MAX_MSG_SIZE;
+ config->max_outstanding_bulks = VCHIQ_NUM_SERVICE_BULKS;
+ config->max_services = VCHIQ_MAX_SERVICES;
+ config->version= VCHIQ_VERSION;
+ config->version_min= VCHIQ_VERSION_MIN;
}
VCHIQ_STATUS_T
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
index e4109a83e628..87829a244465 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
@@ -164,8 +164,7 @@ extern VCHIQ_STATUS_T
vchiq_bulk_receive_handle(VCHIQ_SERVICE_HANDLE_T service,
extern int vchiq_get_client_id(VCHIQ_SERVICE_HANDLE_T service);
extern void *vchiq_get_service_userdata(VCHIQ_SERVICE_HANDLE_T service);
extern int vchiq_get_service_fourcc(VCHIQ_SERVICE_HANDLE_T service);
-extern VCHIQ_STATUS_T vchiq_get_config(VCHIQ_INSTANCE_T instance,
- int config_size, VCHIQ_CONFIG_T *pconfig);
+extern void vchiq_get_config(VCHIQ_CONFIG_T *config);
extern VCHIQ_STATUS_T vchiq_set_service_option(VCHIQ_SERVICE_HANDLE_T service,
VCHIQ_SERVICE_OPTION_T option, int value);
--
2.19.1
[PATCH 06/16] staging: vchiq_arm: rework vchiq_ioc_copy_element_data
The function is passed to vchiq_core.c for it to go trough all the
transfer elements (an array of pointers to data) and copy them into the
actual transfer memory (contiguous memory).
The logic in the function was "copy an element and return, except when
the element is empty, in which case look for the next non-empty element
and copy it. The function will be called as many times as necessary until
all the elements are copied".
Now, this approach already forces the function to loop around elements
and felt convoluted, so it was changed to a more straightforward "Copy
all the elements into memory as long as they fit".
The resulting function is shorter and simpler.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 89 +++
1 file changed, 31 insertions(+), 58 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 525458551a22..7fa734991db9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -752,74 +752,48 @@ static void close_delivered(USER_SERVICE_T *user_service)
}
struct vchiq_io_copy_callback_context {
- struct vchiq_element *current_element;
- size_t current_element_offset;
+ struct vchiq_element *element;
+ size_t element_offset;
unsigned long elements_to_go;
- size_t current_offset;
};
-static ssize_t
-vchiq_ioc_copy_element_data(
- void *context,
- void *dest,
- size_t offset,
- size_t maxsize)
+static ssize_t vchiq_ioc_copy_element_data(void *context, void *dest,
+ size_t offset, size_t maxsize)
{
- long res;
+ struct vchiq_io_copy_callback_context *cc = context;
+ size_t total_bytes_copied = 0;
size_t bytes_this_round;
- struct vchiq_io_copy_callback_context *copy_context =
- (struct vchiq_io_copy_callback_context *)context;
-
- if (offset != copy_context->current_offset)
- return 0;
-
- if (!copy_context->elements_to_go)
- return 0;
-
- /*
-* Complex logic here to handle the case of 0 size elements
-* in the middle of the array of elements.
-*
-* Need to skip over these 0 size elements.
-*/
- while (1) {
- bytes_this_round = min(copy_context->current_element->size -
- copy_context->current_element_offset,
- maxsize);
-
- if (bytes_this_round)
- break;
- copy_context->elements_to_go--;
- copy_context->current_element++;
- copy_context->current_element_offset = 0;
+ while (total_bytes_copied < maxsize) {
+ if (!cc->elements_to_go)
+ return total_bytes_copied;
- if (!copy_context->elements_to_go)
- return 0;
- }
+ if (!cc->element->size) {
+ cc->elements_to_go--;
+ cc->element++;
+ cc->element_offset = 0;
+ continue;
+ }
- res = copy_from_user(dest,
-copy_context->current_element->data +
-copy_context->current_element_offset,
-bytes_this_round);
+ bytes_this_round = min(cc->element->size - cc->element_offset,
+ maxsize - total_bytes_copied);
- if (res != 0)
- return -EFAULT;
+ if (copy_from_user(dest + total_bytes_copied,
+ cc->element->data + cc->element_offset,
+ bytes_this_round))
+ return -EFAULT;
- copy_context->current_element_offset += bytes_this_round;
- copy_context->current_offset += bytes_this_round;
+ cc->element_offset += bytes_this_round;
+ total_bytes_copied += bytes_this_round;
- /*
-* Check if done with current element, and if so advance to the next.
-*/
- if (copy_context->current_element_offset ==
- copy_context->current_element->size) {
- copy_context->elements_to_go--;
- copy_context->current_element++;
- copy_context->current_element_offset = 0;
+ if (cc->element_offset == cc->element->size) {
+ cc->elements_to_go--;
+ cc->element++;
+ cc->element_offset = 0;
+ }
}
- return bytes_this_round;
+ return maxsize;
}
/**
@@ -836,10 +810,9 @@ vchiq_ioc_qu
[PATCH 09/16] staging: vchiq_core: do not initialize semaphores twice
vchiq_init_state() initialises a series of semaphores to then call
remote_event_create() on the same semaphores, which initializes them
again. We get rid of the second initialization.
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchiq_arm/vchiq_core.c| 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index dee5ea7bfe4f..8b23ea5322e8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -418,12 +418,11 @@ vchiq_set_conn_state(VCHIQ_STATE_T *state,
VCHIQ_CONNSTATE_T newstate)
}
static inline void
-remote_event_create(VCHIQ_STATE_T *state, REMOTE_EVENT_T *event)
+remote_event_create(REMOTE_EVENT_T *event)
{
event->armed = 0;
/* Don't clear the 'fired' flag because it may already have been set
** by the other side. */
- sema_init((struct semaphore *)((char *)state + event->event), 0);
}
static inline int
@@ -2237,18 +2236,18 @@ vchiq_init_state(VCHIQ_STATE_T *state,
VCHIQ_SLOT_ZERO_T *slot_zero)
state->data_quota = state->slot_queue_available - 1;
local->trigger.event = offsetof(VCHIQ_STATE_T, trigger_event);
- remote_event_create(state, &local->trigger);
+ remote_event_create(&local->trigger);
local->tx_pos = 0;
local->recycle.event = offsetof(VCHIQ_STATE_T, recycle_event);
- remote_event_create(state, &local->recycle);
+ remote_event_create(&local->recycle);
local->slot_queue_recycle = state->slot_queue_available;
local->sync_trigger.event = offsetof(VCHIQ_STATE_T, sync_trigger_event);
- remote_event_create(state, &local->sync_trigger);
+ remote_event_create(&local->sync_trigger);
local->sync_release.event = offsetof(VCHIQ_STATE_T, sync_release_event);
- remote_event_create(state, &local->sync_release);
+ remote_event_create(&local->sync_release);
/* At start-of-day, the slot is empty and available */
((VCHIQ_HEADER_T *)SLOT_DATA_FROM_INDEX(state, local->slot_sync))->msgid
--
2.19.1
[PATCH 07/16] staging: vchiq-core: get rid of is_master distinction
VCHIQ bulk transfers are what most people call DMA transfers. The CPU
sends a list of physical addresses to the VideoCore which then access
the memory directly without the need for CPU interaction. With this
setup we call the CPU the "slave" and the VideoCore the "master".
There seems to be an option to switch roles in vchiq. Which nobody is
using nor is properly implemented. So we get rid of the "is_master == 1"
option, and all the related code.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_2835_arm.c | 12 +-
.../interface/vchiq_arm/vchiq_core.c | 300 +++---
.../interface/vchiq_arm/vchiq_core.h | 11 +-
3 files changed, 38 insertions(+), 285 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 014583cdf367..ecee54a31f8d 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -163,7 +163,7 @@ int vchiq_platform_init(struct platform_device *pdev,
VCHIQ_STATE_T *state)
*(char **)&g_fragments_base[i * g_fragments_size] = NULL;
sema_init(&g_free_fragments_sema, MAX_FRAGMENTS);
- if (vchiq_init_state(state, vchiq_slot_zero, 0) != VCHIQ_SUCCESS)
+ if (vchiq_init_state(state, vchiq_slot_zero) != VCHIQ_SUCCESS)
return -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -278,16 +278,6 @@ vchiq_complete_bulk(VCHIQ_BULK_T *bulk)
bulk->actual);
}
-void
-vchiq_transfer_bulk(VCHIQ_BULK_T *bulk)
-{
- /*
-* This should only be called on the master (VideoCore) side, but
-* provide an implementation to avoid the need for ifdefery.
-*/
- BUG();
-}
-
void
vchiq_dump_platform_state(void *dump_context)
{
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 8c7bda2e7cb6..34a892011296 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -85,8 +85,6 @@ int vchiq_core_log_level = VCHIQ_LOG_DEFAULT;
int vchiq_core_msg_log_level = VCHIQ_LOG_DEFAULT;
int vchiq_sync_log_level = VCHIQ_LOG_DEFAULT;
-static atomic_t pause_bulks_count = ATOMIC_INIT(0);
-
static DEFINE_SPINLOCK(service_spinlock);
DEFINE_SPINLOCK(bulk_waiter_spinlock);
static DEFINE_SPINLOCK(quota_spinlock);
@@ -1222,32 +1220,7 @@ notify_bulks(VCHIQ_SERVICE_T *service,
VCHIQ_BULK_QUEUE_T *queue,
(queue == &service->bulk_tx) ? 't' : 'r',
queue->process, queue->remote_notify, queue->remove);
- if (service->state->is_master) {
- while (queue->remote_notify != queue->process) {
- VCHIQ_BULK_T *bulk =
- &queue->bulks[BULK_INDEX(queue->remote_notify)];
- int msgtype = (bulk->dir == VCHIQ_BULK_TRANSMIT) ?
- VCHIQ_MSG_BULK_RX_DONE : VCHIQ_MSG_BULK_TX_DONE;
- int msgid = VCHIQ_MAKE_MSG(msgtype, service->localport,
- service->remoteport);
- /* Only reply to non-dummy bulk requests */
- if (bulk->remote_data) {
- status = queue_message(
- service->state,
- NULL,
- msgid,
- memcpy_copy_callback,
- &bulk->actual,
- 4,
- 0);
- if (status != VCHIQ_SUCCESS)
- break;
- }
- queue->remote_notify++;
- }
- } else {
- queue->remote_notify = queue->process;
- }
+ queue->remote_notify = queue->process;
if (status == VCHIQ_SUCCESS) {
while (queue->remove != queue->remote_notify) {
@@ -1385,63 +1358,6 @@ poll_services(VCHIQ_STATE_T *state)
}
}
-/* Called by the slot handler or application threads, holding the bulk mutex.
*/
-static int
-resolve_bulks(VCHIQ_SERVICE_T *service, VCHIQ_BULK_QUEUE_T *queue)
-{
- VCHIQ_STATE_T *state = service->state;
- int resolved = 0;
-
- while ((queue->process != queue->local_insert) &&
- (queue->process != queue->remote_insert)) {
- VCHIQ_BULK_T *bulk = &queue->bulks[BULK_INDEX(queue->process)];
-
- vchiq_log_trace(vchiq_core_log_level,
- "%d: rb:%d %cx - li=%x ri=%x p=%x",
-
[PATCH 05/16] staging: vchiq_arm: get rid of vchi_mh.h
The concept of VCHI_MEM_HANDLE_T is introduced by this header file and
was meant to be used with bulk transfers. After a quick look in
vchiq_core.c it is pretty clear that it actually accomplishes nothing
nor alters the bulk transfers in any way.
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchi/vchi.h | 3 --
.../vc04_services/interface/vchi/vchi_mh.h| 42 ---
.../interface/vchiq_arm/vchiq_2835_arm.c | 6 +--
.../interface/vchiq_arm/vchiq_arm.c | 27 ++--
.../interface/vchiq_arm/vchiq_core.c | 17
.../interface/vchiq_arm/vchiq_core.h | 10 ++---
.../interface/vchiq_arm/vchiq_if.h| 8 ++--
7 files changed, 27 insertions(+), 86 deletions(-)
delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_mh.h
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 379a16ebfd5b..e326926eac31 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -36,7 +36,6 @@
#include "interface/vchi/vchi_cfg.h"
#include "interface/vchi/vchi_common.h"
-#include "vchi_mh.h"
/**
Global defs
@@ -239,7 +238,6 @@ extern int32_t
vchi_bulk_queue_receive(VCHI_SERVICE_HANDLE_T handle,
// Prepare interface for a transfer from the other side into relocatable
memory.
int32_t vchi_bulk_queue_receive_reloc(const VCHI_SERVICE_HANDLE_T handle,
- VCHI_MEM_HANDLE_T h_dst,
uint32_t offset,
uint32_t data_size,
const VCHI_FLAGS_T flags,
@@ -261,7 +259,6 @@ extern int32_t
vchi_bulk_queue_transmit(VCHI_SERVICE_HANDLE_T handle,
#endif
extern int32_t vchi_bulk_queue_transmit_reloc(VCHI_SERVICE_HANDLE_T handle,
- VCHI_MEM_HANDLE_T h_src,
uint32_t offset,
uint32_t data_size,
VCHI_FLAGS_T flags,
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi_mh.h
b/drivers/staging/vc04_services/interface/vchi/vchi_mh.h
deleted file mode 100644
index 198bd076b666..
--- a/drivers/staging/vc04_services/interface/vchi/vchi_mh.h
+++ /dev/null
@@ -1,42 +0,0 @@
-/**
- * Copyright (c) 2010-2012 Broadcom. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions, and the following disclaimer,
- *without modification.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- * 3. The names of the above-listed copyright holders may not be used
- *to endorse or promote products derived from this software without
- *specific prior written permission.
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") version 2, as published by the Free
- * Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
- * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef VCHI_MH_H_
-#define VCHI_MH_H_
-
-#include
-
-typedef int32_t VCHI_MEM_HANDLE_T;
-#define VCHI_MEM_HANDLE_INVALID 0
-
-#endif
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 83d740feab96..014583cdf367 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -247,13 +247,10 @@ remote_event_signal(REMOTE_EVENT_T *event)
}
VCHIQ_STATUS_T
-vchiq_prepare_bulk_data(VCHIQ_BULK_T *bulk, VCHI_MEM_HANDLE_T memhandle,
- void *offset, int siz
[PATCH 10/16] staging: vchiq_core: don't add a wmb() before remote_event_signal()
It's the first thing remote_event_signal() does.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_core.c| 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 8b23ea5322e8..5791c2b670fa 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1137,9 +1137,6 @@ queue_message_sync(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T
*service,
size);
}
- /* Make sure the new header is visible to the peer. */
- wmb();
-
remote_event_signal(&state->remote->sync_trigger);
if (VCHIQ_MSG_TYPE(msgid) != VCHIQ_MSG_PAUSE)
@@ -3269,7 +3266,6 @@ static void
release_message_sync(VCHIQ_STATE_T *state, VCHIQ_HEADER_T *header)
{
header->msgid = VCHIQ_MSGID_PADDING;
- wmb();
remote_event_signal(&state->remote->sync_release);
}
--
2.19.1
[PATCH v2] watchdog: cpwd: add of_node_put()
use of_node_put() to release the refcount. Signed-off-by: Yangtao Li --- Changes in v2: -do that right after its last use to also cover error handling. --- drivers/watchdog/cpwd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c index aee0b25cf10d..32156e199c51 100644 --- a/drivers/watchdog/cpwd.c +++ b/drivers/watchdog/cpwd.c @@ -570,6 +570,8 @@ static int cpwd_probe(struct platform_device *op) if (str_prop) p->timeout = simple_strtoul(str_prop, NULL, 10); + of_node_put(options); + /* CP1400s seem to have broken PLD implementations-- the * interrupt_mask register cannot be written, so no timer * interrupts can be masked within the PLD. -- 2.17.0
[PATCH 13/16] staging: vchiq_core: fix logic redundancy in parse_open
We update sync to reflect that the firmware version is compatible with
that option. We don't need to check both of them again further down the
code.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_core.c| 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index a45cdd08e209..5ee667d46eb5 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1461,9 +1461,7 @@ parse_open(VCHIQ_STATE_T *state, VCHIQ_HEADER_T *header)
service->sync = 0;
/* Acknowledge the OPEN */
- if (service->sync &&
- (state->version_common >=
-VCHIQ_VERSION_SYNCHRONOUS_MODE)) {
+ if (service->sync) {
if (queue_message_sync(
state,
NULL,
--
2.19.1
[PATCH 08/16] staging: vchiq_core: remove unnecessary safety checks in vchiq_init_state
vchiq_init_state() checks the initial contents of slot_zero are correct.
These are set in vchiq_init_slots(), using the same hard-coded defaults
as the checks. Both functions are called sequentially and Video Core
isn't yet aware of the slot's address. There is no way the contents of
slot_zero changed in between functions, making the checks useless.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_core.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 34a892011296..dee5ea7bfe4f 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2170,65 +2170,6 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T
*slot_zero)
return VCHIQ_ERROR;
}
- /* Check the input configuration */
-
- if (slot_zero->magic != VCHIQ_MAGIC) {
- vchiq_loud_error_header();
- vchiq_loud_error("Invalid VCHIQ magic value found.");
- vchiq_loud_error("slot_zero=%pK: magic=%x (expected %x)",
- slot_zero, slot_zero->magic, VCHIQ_MAGIC);
- vchiq_loud_error_footer();
- return VCHIQ_ERROR;
- }
-
- if (slot_zero->version < VCHIQ_VERSION_MIN) {
- vchiq_loud_error_header();
- vchiq_loud_error("Incompatible VCHIQ versions found.");
- vchiq_loud_error("slot_zero=%pK: VideoCore version=%d (minimum
%d)",
- slot_zero, slot_zero->version, VCHIQ_VERSION_MIN);
- vchiq_loud_error("Restart with a newer VideoCore image.");
- vchiq_loud_error_footer();
- return VCHIQ_ERROR;
- }
-
- if (VCHIQ_VERSION < slot_zero->version_min) {
- vchiq_loud_error_header();
- vchiq_loud_error("Incompatible VCHIQ versions found.");
- vchiq_loud_error("slot_zero=%pK: version=%d (VideoCore minimum
%d)",
- slot_zero, VCHIQ_VERSION, slot_zero->version_min);
- vchiq_loud_error("Restart with a newer kernel.");
- vchiq_loud_error_footer();
- return VCHIQ_ERROR;
- }
-
- if ((slot_zero->slot_zero_size != sizeof(VCHIQ_SLOT_ZERO_T)) ||
-(slot_zero->slot_size != VCHIQ_SLOT_SIZE) ||
-(slot_zero->max_slots != VCHIQ_MAX_SLOTS) ||
-(slot_zero->max_slots_per_side != VCHIQ_MAX_SLOTS_PER_SIDE)) {
- vchiq_loud_error_header();
- if (slot_zero->slot_zero_size != sizeof(VCHIQ_SLOT_ZERO_T))
- vchiq_loud_error("slot_zero=%pK: slot_zero_size=%d
(expected %d)",
- slot_zero, slot_zero->slot_zero_size,
- (int)sizeof(VCHIQ_SLOT_ZERO_T));
- if (slot_zero->slot_size != VCHIQ_SLOT_SIZE)
- vchiq_loud_error("slot_zero=%pK: slot_size=%d (expected
%d)",
- slot_zero, slot_zero->slot_size,
- VCHIQ_SLOT_SIZE);
- if (slot_zero->max_slots != VCHIQ_MAX_SLOTS)
- vchiq_loud_error("slot_zero=%pK: max_slots=%d (expected
%d)",
- slot_zero, slot_zero->max_slots,
- VCHIQ_MAX_SLOTS);
- if (slot_zero->max_slots_per_side != VCHIQ_MAX_SLOTS_PER_SIDE)
- vchiq_loud_error("slot_zero=%pK: max_slots_per_side=%d
(expected %d)",
- slot_zero, slot_zero->max_slots_per_side,
- VCHIQ_MAX_SLOTS_PER_SIDE);
- vchiq_loud_error_footer();
- return VCHIQ_ERROR;
- }
-
- if (VCHIQ_VERSION < slot_zero->version)
- slot_zero->version = VCHIQ_VERSION;
-
local = &slot_zero->slave;
remote = &slot_zero->master;
--
2.19.1
[PATCH 12/16] staging: vchiq_util: get rid of unneeded memory barriers
All the memory operations featured in this file modify/access memory that is only accessed by the CPU. So we can assume that all the memory barrier handling done by the completion routines is good enough for us. Signed-off-by: Nicolas Saenz Julienne --- .../interface/vchiq_arm/vchiq_util.c | 32 --- 1 file changed, 32 deletions(-) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c index 44b954daa74a..4b8554bc647e 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c @@ -84,20 +84,7 @@ void vchiu_queue_push(VCHIU_QUEUE_T *queue, VCHIQ_HEADER_T *header) flush_signals(current); } - /* -* Write to queue->storage must be visible after read from -* queue->read -*/ - smp_mb(); - queue->storage[queue->write & (queue->size - 1)] = header; - - /* -* Write to queue->storage must be visible before write to -* queue->write -*/ - smp_wmb(); - queue->write++; complete(&queue->push); @@ -112,12 +99,6 @@ VCHIQ_HEADER_T *vchiu_queue_peek(VCHIU_QUEUE_T *queue) complete(&queue->push); // We haven't removed anything from the queue. - /* -* Read from queue->storage must be visible after read from -* queue->write -*/ - smp_rmb(); - return queue->storage[queue->read & (queue->size - 1)]; } @@ -130,20 +111,7 @@ VCHIQ_HEADER_T *vchiu_queue_pop(VCHIU_QUEUE_T *queue) flush_signals(current); } - /* -* Read from queue->storage must be visible after read from -* queue->write -*/ - smp_rmb(); - header = queue->storage[queue->read & (queue->size - 1)]; - - /* -* Read from queue->storage must be visible before write to -* queue->read -*/ - smp_mb(); - queue->read++; complete(&queue->pop); -- 2.19.1
[PATCH 11/16] staging: vchiq: use completions instead of semaphores
It is preferred in the kernel to avoid using semaphores to wait for
events, as they are optimised for the opposite situation; where the
common case is that they are available and may block only occasionally.
FYI see this thread: https://lkml.org/lkml/2008/4/11/323.
Also completions are semantically more explicit in this case.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 60 ++-
.../interface/vchiq_arm/vchiq_core.c | 100 +-
.../interface/vchiq_arm/vchiq_core.h | 26 ++---
.../interface/vchiq_arm/vchiq_util.c | 16 +--
.../interface/vchiq_arm/vchiq_util.h | 6 +-
5 files changed, 106 insertions(+), 102 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 7fa734991db9..20359924ed45 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -44,7 +44,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -121,9 +121,9 @@ typedef struct user_service_struct {
int message_available_pos;
int msg_insert;
int msg_remove;
- struct semaphore insert_event;
- struct semaphore remove_event;
- struct semaphore close_event;
+ struct completion insert_event;
+ struct completion remove_event;
+ struct completion close_event;
VCHIQ_HEADER_T * msg_queue[MSG_QUEUE_SIZE];
} USER_SERVICE_T;
@@ -138,8 +138,8 @@ struct vchiq_instance_struct {
VCHIQ_COMPLETION_DATA_T completions[MAX_COMPLETIONS];
int completion_insert;
int completion_remove;
- struct semaphore insert_event;
- struct semaphore remove_event;
+ struct completion insert_event;
+ struct completion remove_event;
struct mutex completion_mutex;
int connected;
@@ -562,7 +562,8 @@ add_completion(VCHIQ_INSTANCE_T instance, VCHIQ_REASON_T
reason,
vchiq_log_trace(vchiq_arm_log_level,
"%s - completion queue full", __func__);
DEBUG_COUNT(COMPLETION_QUEUE_FULL_COUNT);
- if (down_interruptible(&instance->remove_event) != 0) {
+ if (wait_for_completion_interruptible(
+ &instance->remove_event)) {
vchiq_log_info(vchiq_arm_log_level,
"service_callback interrupted");
return VCHIQ_RETRY;
@@ -600,7 +601,7 @@ add_completion(VCHIQ_INSTANCE_T instance, VCHIQ_REASON_T
reason,
insert++;
instance->completion_insert = insert;
- up(&instance->insert_event);
+ complete(&instance->insert_event);
return VCHIQ_SUCCESS;
}
@@ -673,7 +674,8 @@ service_callback(VCHIQ_REASON_T reason, VCHIQ_HEADER_T
*header,
}
DEBUG_TRACE(SERVICE_CALLBACK_LINE);
- if (down_interruptible(&user_service->remove_event)
+ if (wait_for_completion_interruptible(
+ &user_service->remove_event)
!= 0) {
vchiq_log_info(vchiq_arm_log_level,
"%s interrupted", __func__);
@@ -705,7 +707,7 @@ service_callback(VCHIQ_REASON_T reason, VCHIQ_HEADER_T
*header,
}
spin_unlock(&msg_queue_spinlock);
- up(&user_service->insert_event);
+ complete(&user_service->insert_event);
header = NULL;
}
@@ -745,7 +747,7 @@ static void close_delivered(USER_SERVICE_T *user_service)
unlock_service(user_service->service);
/* Wake the user-thread blocked in close_ or remove_service */
- up(&user_service->close_event);
+ complete(&user_service->close_event);
user_service->close_pending = 0;
}
@@ -867,7 +869,7 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned
long arg)
if (status == VCHIQ_SUCCESS) {
/* Wake the completion thread and ask it to exit */
instance->closing = 1;
- up(&instance->insert_event);
+ complete(&instance->insert_event);
}
break;
@@ -948,9 +950,9 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned
long arg)
instance->completion_remove - 1;
user_service->msg_insert = 0;
user_service->msg_remove = 0;
- sema_init(&user_service->insert_event, 0);
- sema_init(&user_service->remove_event, 0);
- sema_init(&user_service
[PATCH 16/16] staging: vchiq: add more tasks to the TODO list
The TODO list was missing some tasks needed before upstreaming the device. Signed-off-by: Nicolas Saenz Julienne --- .../staging/vc04_services/interface/vchi/TODO | 42 +++ 1 file changed, 42 insertions(+) diff --git a/drivers/staging/vc04_services/interface/vchi/TODO b/drivers/staging/vc04_services/interface/vchi/TODO index 0b3ec75ff627..fc2752bc95b2 100644 --- a/drivers/staging/vc04_services/interface/vchi/TODO +++ b/drivers/staging/vc04_services/interface/vchi/TODO @@ -49,3 +49,45 @@ such as dev_info, dev_dbg, and friends. A short top-down description of this driver's architecture (function of kthreads, userspace, limitations) could be very helpful for reviewers. + +7) Review and comment memory barriers + +There is a heavy use of memory barriers in this driver, it would be very +beneficial to go over all of them and, if correct, comment on their merits. +Extra points to whomever confidently reviews the remote_event_*() family of +functions. + +8) Get rid of custom function return values + +Most functions use a custom set of return values, we should force proper Linux +error numbers. Special care is needed for VCHIQ_RETRY. + +9) Reformat core code with more sane indentations + +The code follows the 80 characters limitation yet tends to go 3 or 4 levels of +indentation deep making it very unpleasant to read. This is specially relevant +in the character driver ioctl code and in the core thread functions. + +10) Reorganize file structure: Move char driver to it's own file and join both +platform files + +The cdev is defined alongside with the platform code in vchiq_arm.c. It would +be nice to completely decouple it from the actual core code. For instance to be +able to use bcm2835-audio without having /dev/vchiq created. One could argue +it's better for security reasons or general cleanliness. It could even be +interesting to create two different kernel modules, something the likes of +vchiq-core.ko and vchiq-dev.ko. This would also ease the upstreaming process. + +The code in vchiq_bcm2835_arm.c should fit in the generic platform file. + +12) Get rid of all the struct typedefs + +Most structs are typedefd, it's not encouraged in the kernel. + +13) Get rid of all non essential global structures and create a proper per +device structure + +The first thing one generally sees in a probe function is a memory allocation +for all the device specific data. This structure is then passed all over the +driver. This is good practice since it makes the driver work regardless of the +number of devices probed. -- 2.19.1
[PATCH 03/16] staging: vchiq_shim: delete vchi_service_create
No one is using the API neither in the actual staging tree nor in the
downstream tree (https://github.com/raspberrypi/linux).
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchi/vchi.h | 5 ---
.../interface/vchiq_arm/vchiq_shim.c | 32 ---
2 files changed, 37 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 01381904775d..379a16ebfd5b 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -113,11 +113,6 @@ extern uint32_t vchi_current_time(VCHI_INSTANCE_T
instance_handle);
/**
Global service API
*/
-// Routine to create a named service
-extern int32_t vchi_service_create(VCHI_INSTANCE_T instance_handle,
- SERVICE_CREATION_T *setup,
- VCHI_SERVICE_HANDLE_T *handle);
-
// Routine to destroy a service
extern int32_t vchi_service_destroy(const VCHI_SERVICE_HANDLE_T handle);
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index c3223fcdaf87..81cac68f4b78 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -660,38 +660,6 @@ int32_t vchi_service_open(VCHI_INSTANCE_T instance_handle,
}
EXPORT_SYMBOL(vchi_service_open);
-int32_t vchi_service_create(VCHI_INSTANCE_T instance_handle,
- SERVICE_CREATION_T *setup,
- VCHI_SERVICE_HANDLE_T *handle)
-{
- VCHIQ_INSTANCE_T instance = (VCHIQ_INSTANCE_T)instance_handle;
- struct shim_service *service = service_alloc(instance, setup);
-
- *handle = (VCHI_SERVICE_HANDLE_T)service;
-
- if (service) {
- VCHIQ_SERVICE_PARAMS_T params;
- VCHIQ_STATUS_T status;
-
- memset(¶ms, 0, sizeof(params));
- params.fourcc = setup->service_id;
- params.callback = shim_callback;
- params.userdata = service;
- params.version = setup->version.version;
- params.version_min = setup->version.version_min;
- status = vchiq_add_service(instance, ¶ms, &service->handle);
-
- if (status != VCHIQ_SUCCESS) {
- service_free(service);
- service = NULL;
- *handle = NULL;
- }
- }
-
- return (service != NULL) ? 0 : -1;
-}
-EXPORT_SYMBOL(vchi_service_create);
-
int32_t vchi_service_close(const VCHI_SERVICE_HANDLE_T handle)
{
int32_t ret = -1;
--
2.19.1
[PATCH 14/16] staging: vchiq_arm: rework probe and init functions
Moves the allocation of a chardev region and class creation to the init
function of the driver since those functions are meant to be run on a
per driver basis, as opposed to the code run in the probe function which
is run in a per device basis.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 71 ---
1 file changed, 45 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 20359924ed45..03cc6947c03c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -166,7 +166,6 @@ static struct cdevvchiq_cdev;
static dev_t vchiq_devid;
static VCHIQ_STATE_T g_state;
static struct class *vchiq_class;
-static struct device *vchiq_dev;
static DEFINE_SPINLOCK(msg_queue_spinlock);
static struct platform_device *bcm2835_camera;
@@ -3557,34 +3556,19 @@ static int vchiq_probe(struct platform_device *pdev)
if (err != 0)
goto failed_platform_init;
- err = alloc_chrdev_region(&vchiq_devid, VCHIQ_MINOR, 1, DEVICE_NAME);
- if (err != 0) {
- vchiq_log_error(vchiq_arm_log_level,
- "Unable to allocate device number");
- goto failed_platform_init;
- }
cdev_init(&vchiq_cdev, &vchiq_fops);
vchiq_cdev.owner = THIS_MODULE;
err = cdev_add(&vchiq_cdev, vchiq_devid, 1);
if (err != 0) {
vchiq_log_error(vchiq_arm_log_level,
"Unable to register device");
- goto failed_cdev_add;
+ goto failed_platform_init;
}
- /* create sysfs entries */
- vchiq_class = class_create(THIS_MODULE, DEVICE_NAME);
- err = PTR_ERR(vchiq_class);
- if (IS_ERR(vchiq_class))
- goto failed_class_create;
-
- vchiq_dev = device_create(vchiq_class, NULL,
- vchiq_devid, NULL, "vchiq");
- err = PTR_ERR(vchiq_dev);
- if (IS_ERR(vchiq_dev))
+ if (IS_ERR(device_create(vchiq_class, &pdev->dev, vchiq_devid,
+NULL, "vchiq")))
goto failed_device_create;
- /* create debugfs entries */
vchiq_debugfs_init();
vchiq_log_info(vchiq_arm_log_level,
@@ -3599,11 +3583,7 @@ static int vchiq_probe(struct platform_device *pdev)
return 0;
failed_device_create:
- class_destroy(vchiq_class);
-failed_class_create:
cdev_del(&vchiq_cdev);
-failed_cdev_add:
- unregister_chrdev_region(vchiq_devid, 1);
failed_platform_init:
vchiq_log_warning(vchiq_arm_log_level, "could not load vchiq");
return err;
@@ -3614,9 +3594,7 @@ static int vchiq_remove(struct platform_device *pdev)
platform_device_unregister(bcm2835_camera);
vchiq_debugfs_deinit();
device_destroy(vchiq_class, vchiq_devid);
- class_destroy(vchiq_class);
cdev_del(&vchiq_cdev);
- unregister_chrdev_region(vchiq_devid, 1);
return 0;
}
@@ -3629,7 +3607,48 @@ static struct platform_driver vchiq_driver = {
.probe = vchiq_probe,
.remove = vchiq_remove,
};
-module_platform_driver(vchiq_driver);
+
+static int __init vchiq_driver_init(void)
+{
+ int ret;
+
+ vchiq_class = class_create(THIS_MODULE, DEVICE_NAME);
+ if (IS_ERR(vchiq_class)) {
+ pr_err("Failed to create vchiq class\n");
+ return PTR_ERR(vchiq_class);
+ }
+
+ ret = alloc_chrdev_region(&vchiq_devid, VCHIQ_MINOR, 1, DEVICE_NAME);
+ if (ret) {
+ pr_err("Failed to allocate vchiq's chrdev region\n");
+ goto class_destroy;
+ }
+
+ ret = platform_driver_register(&vchiq_driver);
+ if (ret) {
+ pr_err("Failed to register vchiq driver\n");
+ goto region_unregister;
+ }
+
+ return 0;
+
+region_unregister:
+ platform_driver_unregister(&vchiq_driver);
+
+class_destroy:
+ class_destroy(vchiq_class);
+
+ return ret;
+}
+module_init(vchiq_driver_init);
+
+static void __exit vchiq_driver_exit(void)
+{
+ platform_driver_unregister(&vchiq_driver);
+ unregister_chrdev_region(vchiq_devid, 1);
+ class_destroy(vchiq_class);
+}
+module_exit(vchiq_driver_exit);
MODULE_LICENSE("Dual BSD/GPL");
MODULE_DESCRIPTION("Videocore VCHIQ driver");
--
2.19.1
[PATCH 02/16] staging: vchiq_arm: rework close/remove_service IOCTLS
The implementation of both IOCTLS was the same except for one function
call. This joins both implementations and updates the code to avoid
unneeded indentations.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 66 +++
1 file changed, 24 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 5af3f2651bd3..835152799433 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1019,55 +1019,37 @@ vchiq_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
}
} break;
- case VCHIQ_IOC_CLOSE_SERVICE: {
+ case VCHIQ_IOC_CLOSE_SERVICE:
+ case VCHIQ_IOC_REMOVE_SERVICE: {
VCHIQ_SERVICE_HANDLE_T handle = (VCHIQ_SERVICE_HANDLE_T)arg;
+ USER_SERVICE_T *user_service;
service = find_service_for_instance(instance, handle);
- if (service != NULL) {
- USER_SERVICE_T *user_service =
- (USER_SERVICE_T *)service->base.userdata;
- /* close_pending is false on first entry, and when the
- wait in vchiq_close_service has been interrupted. */
- if (!user_service->close_pending) {
- status = vchiq_close_service(service->handle);
- if (status != VCHIQ_SUCCESS)
- break;
- }
-
- /* close_pending is true once the underlying service
- has been closed until the client library calls the
- CLOSE_DELIVERED ioctl, signalling close_event. */
- if (user_service->close_pending &&
- down_interruptible(&user_service->close_event))
- status = VCHIQ_RETRY;
- } else
+ if (!service) {
ret = -EINVAL;
- } break;
+ break;
+ }
- case VCHIQ_IOC_REMOVE_SERVICE: {
- VCHIQ_SERVICE_HANDLE_T handle = (VCHIQ_SERVICE_HANDLE_T)arg;
+ user_service = service->base.userdata;
- service = find_service_for_instance(instance, handle);
- if (service != NULL) {
- USER_SERVICE_T *user_service =
- (USER_SERVICE_T *)service->base.userdata;
- /* close_pending is false on first entry, and when the
- wait in vchiq_close_service has been interrupted. */
- if (!user_service->close_pending) {
- status = vchiq_remove_service(service->handle);
- if (status != VCHIQ_SUCCESS)
- break;
- }
+ /* close_pending is false on first entry, and when the
+ wait in vchiq_close_service has been interrupted. */
+ if (!user_service->close_pending) {
+ status = (cmd == VCHIQ_IOC_CLOSE_SERVICE) ?
+vchiq_close_service(service->handle) :
+vchiq_remove_service(service->handle);
+ if (status != VCHIQ_SUCCESS)
+ break;
+ }
- /* close_pending is true once the underlying service
- has been closed until the client library calls the
- CLOSE_DELIVERED ioctl, signalling close_event. */
- if (user_service->close_pending &&
- down_interruptible(&user_service->close_event))
- status = VCHIQ_RETRY;
- } else
- ret = -EINVAL;
- } break;
+ /* close_pending is true once the underlying service
+ has been closed until the client library calls the
+ CLOSE_DELIVERED ioctl, signalling close_event. */
+ if (user_service->close_pending &&
+ down_interruptible(&user_service->close_event))
+ status = VCHIQ_RETRY;
+ break;
+ }
case VCHIQ_IOC_USE_SERVICE:
case VCHIQ_IOC_RELEASE_SERVICE: {
--
2.19.1
[PATCH 15/16] staging: vchiq_arm: fix open/release cdev functions
Both functions checked the minor number of the cdev prior running the
code. This was useless since the number of devices is already limited by
alloc_chrdev_region.
This removes the check and reindents the code where relevant.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 247 +++---
1 file changed, 100 insertions(+), 147 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 03cc6947c03c..0caee2d6946f 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -63,8 +63,6 @@
#undef MODULE_PARAM_PREFIX
#define MODULE_PARAM_PREFIX DEVICE_NAME "."
-#define VCHIQ_MINOR 0
-
/* Some per-instance constants */
#define MAX_COMPLETIONS 128
#define MAX_SERVICES 64
@@ -1955,195 +1953,150 @@ vchiq_compat_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
#endif
-/
-*
-* vchiq_open
-*
-***/
-
-static int
-vchiq_open(struct inode *inode, struct file *file)
+static int vchiq_open(struct inode *inode, struct file *file)
{
- int dev = iminor(inode) & 0x0f;
+ VCHIQ_STATE_T *state = vchiq_get_state();
+ VCHIQ_INSTANCE_T instance;
vchiq_log_info(vchiq_arm_log_level, "vchiq_open");
- switch (dev) {
- case VCHIQ_MINOR: {
- VCHIQ_STATE_T *state = vchiq_get_state();
- VCHIQ_INSTANCE_T instance;
- if (!state) {
- vchiq_log_error(vchiq_arm_log_level,
+ if (!state) {
+ vchiq_log_error(vchiq_arm_log_level,
"vchiq has no connection to VideoCore");
- return -ENOTCONN;
- }
-
- instance = kzalloc(sizeof(*instance), GFP_KERNEL);
- if (!instance)
- return -ENOMEM;
+ return -ENOTCONN;
+ }
- instance->state = state;
- instance->pid = current->tgid;
+ instance = kzalloc(sizeof(*instance), GFP_KERNEL);
+ if (!instance)
+ return -ENOMEM;
- vchiq_debugfs_add_instance(instance);
+ instance->state = state;
+ instance->pid = current->tgid;
- init_completion(&instance->insert_event);
- init_completion(&instance->remove_event);
- mutex_init(&instance->completion_mutex);
- mutex_init(&instance->bulk_waiter_list_mutex);
- INIT_LIST_HEAD(&instance->bulk_waiter_list);
+ vchiq_debugfs_add_instance(instance);
- file->private_data = instance;
- } break;
+ init_completion(&instance->insert_event);
+ init_completion(&instance->remove_event);
+ mutex_init(&instance->completion_mutex);
+ mutex_init(&instance->bulk_waiter_list_mutex);
+ INIT_LIST_HEAD(&instance->bulk_waiter_list);
- default:
- vchiq_log_error(vchiq_arm_log_level,
- "Unknown minor device: %d", dev);
- return -ENXIO;
- }
+ file->private_data = instance;
return 0;
}
-/
-*
-* vchiq_release
-*
-***/
-
-static int
-vchiq_release(struct inode *inode, struct file *file)
+static int vchiq_release(struct inode *inode, struct file *file)
{
- int dev = iminor(inode) & 0x0f;
+ VCHIQ_INSTANCE_T instance = file->private_data;
+ VCHIQ_STATE_T *state = vchiq_get_state();
+ VCHIQ_SERVICE_T *service;
int ret = 0;
+ int i;
- switch (dev) {
- case VCHIQ_MINOR: {
- VCHIQ_INSTANCE_T instance = file->private_data;
- VCHIQ_STATE_T *state = vchiq_get_state();
- VCHIQ_SERVICE_T *service;
- int i;
+ vchiq_log_info(vchiq_arm_log_level, "%s: instance=%lx", __func__,
+ (unsigned long)instance);
- vchiq_log_info(vchiq_arm_log_level,
- "%s: instance=%lx",
- __func__, (unsigned long)instance);
+ if (!state) {
+ ret = -EPERM;
+ goto out;
+ }
- if (!state) {
- ret = -EPERM;
- goto out;
- }
+ /* Ensure videocore is awake to allow termination. */
+ vchiq_use_internal(instance->state, NULL, USE_TYPE_VCHIQ);
- /* Ensure videocore is awake to allow termination. */
- vchiq_use_internal(instance->state, NULL,
- USE_TYPE_VCHIQ);
+ mutex_lock(&i
Re: [PATCH v1 1/1] arm64: Early boot time stamps
On Tue, Nov 20, 2018 at 09:40:10AM -0500, Pavel Tatashin wrote:
> > > +static __init void sched_clock_early_init(void)
> > > +{
> > > + u64 freq = arch_timer_get_cntfrq();
> > > + u64 (*read_time)(void) = arch_counter_get_cntvct;
> >
> > We already have arch_timer_read_counter which is exposed from
> > arm_arch_timer.h.
>
> OK
>
> >
> > > +
> > > + /* Early clock is available only on platforms with known freqs */
> >
> > This comment is misleading. It should read something like:
> >
> > /*
> > * The arm64 boot protocol mandates that CNTFRQ_EL0 reflects
> > * the timer frequency. To avoid breakage on misconfigured
> > * systems, do not register the early sched_clock if the
> > * programmed value if zero. Other random values will just
> > * result in random output.
> > */
> >
>
> OK
>
> > > + if (!freq)
> > > + return;
> > > +
> > > + sched_clock_register(read_time, BITS_PER_LONG, freq);
> >
> > This doesn't seem right. The counter has an architected minimum of 56
> > bits, and you can't assume that it is going to be more than that.
>
> Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where
> this minimum is defined in aarch64 specs. I will change it to 56.
See section G5.1.2 of the ARM ARM for details.
Thanks,
Andrew Murray
>
> I will send v2 soon.
>
> Thank you,
> Pasha
Re: [RFC PATCH 1/3] mm, memory_hotplug: try to migrate full section worth of pages
On Tue, 2018-11-20 at 14:43 +0100, Michal Hocko wrote: > From: Michal Hocko > > do_migrate_range has been limiting the number of pages to migrate to > 256 > for some reason which is not documented. When looking back at old memory-hotplug commits one feels pretty sad about the brevity of the changelogs. > Signed-off-by: Michal Hocko Reviewed-by: Oscar Salvador
Re: [PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks
On Tue, Nov 20, 2018 at 1:32 PM Li, Aubrey wrote: > Thanks for your program, Samuel, it's very helpful. But I saw a different > output on my side, May I have your glibc version? > This system is running glibc 2.27, and kernel 4.18.7. The Xeon Gold 5120 also happens to be one of the Skylake-SP models with a single 512-bit FMA unit, instead of 2. Samuel.
Re: Applied "regulator: wm8994: Pass descriptor instead of GPIO number" to the regulator tree
On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> On 2018-05-17 18:41, Mark Brown wrote:
> > Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO number
>
> This patch causes following kernel warning on Samsung Exynos4412 based
> Trats2 board:
>
> wm8994 4-001a: Failed to get supply 'DBVDD1': -517
> wm8994 4-001a: Failed to get supplies: -517
How is the wm8994 being registered on this board? I am having
difficulty finding a device tree or a board file that relates to
the board and includes the wm8994.
> > @@ -203,6 +203,18 @@ static const struct i2c_board_info wm1277_devs[] = {
> > { I2C_BOARD_INFO("wm8958", 0x1a), /* WM8958 is the superset */
> > .platform_data = &wm8994_pdata,
> > .irq = GLENFARCLAS_PMIC_IRQ_BASE + WM831X_IRQ_GPIO_2,
> > + .dev_name = "wm8958",
> > + },
> > +};
> > +
> > +static struct gpiod_lookup_table wm8994_gpiod_table = {
> > + .dev_id = "i2c-wm8958", /* I2C device name */
> > + .table = {
> > + GPIO_LOOKUP("GPION", 6,
> > + "wlf,ldo1ena", GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("GPION", 4,
> > + "wlf,ldo2ena", GPIO_ACTIVE_HIGH),
> > + { },
> > },
> > };
If its being done through a board file I guess you will need the
equivalent of this.
Thanks,
Charles
Re: [PATCH] watchdog: cpwd: add of_node_put()
On Tue, Nov 20, 2018 at 10:34 PM Guenter Roeck wrote: > > On 11/20/18 5:23 AM, Yangtao Li wrote: > > use of_node_put() to release the refcount. > > > > Signed-off-by: Yangtao Li > > --- > > drivers/watchdog/cpwd.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c > > index aee0b25cf10d..d3a81642ada5 100644 > > --- a/drivers/watchdog/cpwd.c > > +++ b/drivers/watchdog/cpwd.c > > @@ -617,6 +617,7 @@ static int cpwd_probe(struct platform_device *op) > > > > platform_set_drvdata(op, p); > > cpwd_device = p; > > + of_node_put(options); > > It would be better to do that right after its last use to also cover > error handling. > > Guenter > > > return 0; > > > > out_unregister: > > > Hi Guenter： Yes, you're right. I will send the second version right away. Yours, Yangtao
[PATCH v2 1/1] arm64: Early boot time stamps
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c| 25 +
drivers/clocksource/arm_arch_timer.c | 8
include/clocksource/arm_arch_timer.h | 3 +++
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f4fc1e0544b7..7a43e63b737b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -279,8 +280,32 @@ arch_initcall(reserve_memblock_reserved_regions);
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
+/*
+ * Get time stamps available early in boot, useful to identify boot time issues
+ * from the early boot.
+ */
+static __init void sched_clock_early_init(void)
+{
+ u64 freq = arch_timer_get_cntfrq();
+
+ /*
+* The arm64 boot protocol mandates that CNTFRQ_EL0 reflects
+* the timer frequency. To avoid breakage on misconfigured
+* systems, do not register the early sched_clock if the
+* programmed value if zero. Other random values will just
+* result in random output.
+*/
+ if (!freq)
+ return;
+
+ arch_timer_read_counter = arch_counter_get_cntvct;
+ sched_clock_register(arch_timer_read_counter, ARCH_TIMER_NBITS, freq);
+}
+
void __init setup_arch(char **cmdline_p)
{
+ sched_clock_early_init();
+
init_mm.start_code = (unsigned long) _text;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 9a7d4dc00b6e..e4843ad48bd3 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -175,13 +175,13 @@ static struct clocksource clocksource_counter = {
.name = "arch_sys_counter",
.rating = 400,
.read = arch_counter_read,
- .mask = CLOCKSOURCE_MASK(56),
+ .mask = CLOCKSOURCE_MASK(ARCH_TIMER_NBITS),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
static struct cyclecounter cyclecounter __ro_after_init = {
.read = arch_counter_read_cc,
- .mask = CLOCKSOURCE_MASK(56),
+ .mask = CLOCKSOURCE_MASK(ARCH_TIMER_NBITS),
};
struct ate_acpi_oem_info {
@@ -963,8 +963,8 @@ static void __init arch_counter_register(unsigned type)
timecounter_init(&arch_timer_kvm_info.timecounter,
&cyclecounter, start_count);
- /* 56 bits minimum, so we assume worst case rollover */
- sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
+ sched_clock_register(arch_timer_read_counter, ARCH_TIMER_NBITS,
+arch_timer_rate);
}
static void arch_timer_stop(struct clock_event_device *clk)
diff --git a/include/clocksource/arm_arch_timer.h
b/include/clocksource/arm_arch_timer.h
index 349e5957c949..c485512e1d01 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -71,6 +71,9 @@ enum arch_timer_spi_nr {
#define ARCH_TIMER_EVT_STREAM_FREQ \
(USEC_PER_SEC / ARCH_TIMER_EVT_STREAM_PERIOD_US)
+/* 56 bits minimum, so we assume worst case rollover */
+#defineARCH_TIMER_NBITS56
+
struct arch_timer_kvm_info {
struct timecounter timecounter;
int virtual_irq;
--
2.19.1
[PATCH v2 0/1] Early boot time stamps for arm64
Changelog: v1 - v2 Addressed comments from Marc Zyngier I made early boot time stamps available for SPARC and X86. x86: https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatas...@oracle.com sparc: https://www.spinics.net/lists/sparclinux/msg18063.html As discussed at plumbers, I would like to add the same for arm64. The implementation does not have to be perfect, and should work only when early clock is easy to determine. arm64 defines a clock register, and thus makes it easy, but on some platforms frequency register is broken, so if it is not known, simply don't initialize clock early. dmesg before: https://paste.ubuntu.com/p/3pJ5kgJHyN dmesg after: https://paste.ubuntu.com/p/RHKGVd9nSM As seen from the above with base smp_init is finished after 0.47s: [0.464585] SMP: Total of 8 processors activated. But, in reality, 3.2s is missing which is a quiet long considering this is only 60G domain. Pavel Tatashin (1): arm64: Early boot time stamps arch/arm64/kernel/setup.c| 25 + drivers/clocksource/arm_arch_timer.c | 8 include/clocksource/arm_arch_timer.h | 3 +++ 3 files changed, 32 insertions(+), 4 deletions(-) -- 2.19.1
Re: [PATCH v1 1/1] arm64: Early boot time stamps
> > +static __init void sched_clock_early_init(void)
> > +{
> > + u64 freq = arch_timer_get_cntfrq();
> > + u64 (*read_time)(void) = arch_counter_get_cntvct;
>
> We already have arch_timer_read_counter which is exposed from
> arm_arch_timer.h.
OK
>
> > +
> > + /* Early clock is available only on platforms with known freqs */
>
> This comment is misleading. It should read something like:
>
> /*
> * The arm64 boot protocol mandates that CNTFRQ_EL0 reflects
> * the timer frequency. To avoid breakage on misconfigured
> * systems, do not register the early sched_clock if the
> * programmed value if zero. Other random values will just
> * result in random output.
> */
>
OK
> > + if (!freq)
> > + return;
> > +
> > + sched_clock_register(read_time, BITS_PER_LONG, freq);
>
> This doesn't seem right. The counter has an architected minimum of 56
> bits, and you can't assume that it is going to be more than that.
Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where
this minimum is defined in aarch64 specs. I will change it to 56.
I will send v2 soon.
Thank you,
Pasha
Re: [PATCH v2 3/3] PCI: imx6: limit DBI register length
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Define the length of the DBI registers. This makes sure that
> the kernel does not access registers beyond that point, avoiding
> the following abort on a i.MX 6Quad:
> # cat /sys/devices/soc0/soc/1ffc000.pcie/pci\:00/\:00\:00.0/config
> [ 100.021433] Unhandled fault: imprecise external abort (0x1406) at
> 0xb6ea7000
> ...
> [ 100.056423] PC is at dw_pcie_read+0x50/0x84
> [ 100.060790] LR is at dw_pcie_rd_own_conf+0x44/0x48
> ...
>
> Signed-off-by: Stefan Agner
Reviewed-by: Lucas Stach
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 7ac1a639fe91..41d6127b40ad 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -41,6 +41,7 @@ enum imx6_pcie_variants {
>
> struct imx6_pcie_drvdata {
> > enum imx6_pcie_variants variant;
> > > + int dbi_length;
> };
>
> struct imx6_pcie {
> @@ -779,6 +780,8 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> > break;
> > }
>
> > + pci->dbi_length = imx6_pcie->drvdata->dbi_length;
> +
> > /* Grab GPR config register range */
> > imx6_pcie->iomuxc_gpr =
> > syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> @@ -839,7 +842,7 @@ static void imx6_pcie_shutdown(struct platform_device
> *pdev)
> }
>
> static const struct imx6_pcie_drvdata drvdata[] = {
> > - [IMX6Q] = { .variant = IMX6Q },
> > + [IMX6Q] = { .variant = IMX6Q, .dbi_length = 0x15c },
> > [IMX6SX] = { .variant = IMX6SX },
> > [IMX6QP] = { .variant = IMX6QP },
> > [IMX7D] = { .variant = IMX7D },
Re: [PATCH v2 2/3] PCI: imx6: introduce drvdata
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Introduce driver data struct. This will simplify handling of device
> specific differences.
>
> Signed-off-by: Stefan Agner
Reviewed-by: Lucas Stach
> ---
> Changes in v2:
> - Split drvdata introduction in a separate patch
> - Use an array instead of individual struct imx6_pcie_drvdata declarations
>
> drivers/pci/controller/dwc/pci-imx6.c | 38 +--
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 4a9a673b4777..7ac1a639fe91 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -39,6 +39,10 @@ enum imx6_pcie_variants {
> > IMX7D,
> };
>
> +struct imx6_pcie_drvdata {
> > + enum imx6_pcie_variants variant;
> +};
> +
> struct imx6_pcie {
> > > struct dw_pcie *pci;
> > > int reset_gpio;
> @@ -50,7 +54,6 @@ struct imx6_pcie {
> > > struct regmap *iomuxc_gpr;
> > > struct reset_control*pciephy_reset;
> > > struct reset_control*apps_reset;
> > - enum imx6_pcie_variants variant;
> > > u32 tx_deemph_gen1;
> > > u32 tx_deemph_gen2_3p5db;
> > > u32 tx_deemph_gen2_6db;
> @@ -58,6 +61,7 @@ struct imx6_pcie {
> > > u32 tx_swing_low;
> > > int link_gen;
> > > struct regulator*vpcie;
> > + const struct imx6_pcie_drvdata *drvdata;
> };
>
> /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
> @@ -285,7 +289,7 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie
> *imx6_pcie)
> {
> > struct device *dev = imx6_pcie->pci->dev;
>
> > - switch (imx6_pcie->variant) {
> > + switch (imx6_pcie->drvdata->variant) {
> > case IMX7D:
> > reset_control_assert(imx6_pcie->pciephy_reset);
> > reset_control_assert(imx6_pcie->apps_reset);
> @@ -327,7 +331,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie
> *imx6_pcie)
> > struct device *dev = pci->dev;
> > int ret = 0;
>
> > - switch (imx6_pcie->variant) {
> > + switch (imx6_pcie->drvdata->variant) {
> > case IMX6SX:
> > ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
> > if (ret) {
> @@ -430,7 +434,7 @@ static void imx6_pcie_deassert_core_reset(struct
> imx6_pcie *imx6_pcie)
> > !imx6_pcie->gpio_active_high);
> > }
>
> > - switch (imx6_pcie->variant) {
> > + switch (imx6_pcie->drvdata->variant) {
> > case IMX7D:
> > reset_control_deassert(imx6_pcie->pciephy_reset);
> > imx7d_pcie_wait_for_phy_pll_lock(imx6_pcie);
> @@ -468,7 +472,7 @@ static void imx6_pcie_deassert_core_reset(struct
> imx6_pcie *imx6_pcie)
>
> static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> {
> > - switch (imx6_pcie->variant) {
> > + switch (imx6_pcie->drvdata->variant) {
> > case IMX7D:
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> > IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
> @@ -560,7 +564,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie
> *imx6_pcie)
> > dw_pcie_writel_dbi(pci, PCIE_RC_LCR, tmp);
>
> > /* Start LTSSM. */
> > - if (imx6_pcie->variant == IMX7D)
> > + if (imx6_pcie->drvdata->variant == IMX7D)
> > reset_control_deassert(imx6_pcie->apps_reset);
> > else
> > regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> @@ -585,7 +589,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie
> *imx6_pcie)
> > tmp |= PORT_LOGIC_SPEED_CHANGE;
> > dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, tmp);
>
> > - if (imx6_pcie->variant != IMX7D) {
> > + if (imx6_pcie->drvdata->variant != IMX7D) {
> > /*
> > * On i.MX7, DIRECT_SPEED_CHANGE behaves differently
> > * from i.MX6 family when no link speed transition
> @@ -703,8 +707,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> > pci->ops = &dw_pcie_ops;
>
> > imx6_pcie->pci = pci;
> > - imx6_pcie->variant =
> > - (enum imx6_pcie_variants)of_device_get_match_data(dev);
> > + imx6_pcie->drvdata = of_device_get_match_data(dev);
>
> > dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
> @@ -748,7 +751,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> > return PTR_ERR(imx6_pcie->pcie);
> > }
>
> > - switch (imx6_pcie->variant) {
> > + switch (imx6_pcie->drvdata->variant) {
> > case IMX6SX:
> > imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
> > "pcie_inbound_axi");
> @@ -835,11 +838,
Re: [PATCH v2 1/3] PCI: dwc: allow to limit registers set length
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Add length to the struct dw_pcie and check that the accessors
> dw_pcie_(rd|wr)_own_conf() do not read/write beyond that point.
>
> Signed-off-by: Stefan Agner
FWIW:
Reviewed-by: Lucas Stach
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 4
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 29a05759a294..b422538ee0bb 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -29,6 +29,8 @@ static int dw_pcie_rd_own_conf(struct pcie_port *pp, int
> where, int size,
> > return pp->ops->rd_own_conf(pp, where, size, val);
>
> > pci = to_dw_pcie_from_pp(pp);
> > + if (pci->dbi_length && where + size > pci->dbi_length)
> > + return PCIBIOS_BAD_REGISTER_NUMBER;
> > return dw_pcie_read(pci->dbi_base + where, size, val);
> }
>
> @@ -41,6 +43,8 @@ static int dw_pcie_wr_own_conf(struct pcie_port *pp, int
> where, int size,
> > return pp->ops->wr_own_conf(pp, where, size, val);
>
> > pci = to_dw_pcie_from_pp(pp);
> > + if (pci->dbi_length && where + size > pci->dbi_length)
> > + return PCIBIOS_BAD_REGISTER_NUMBER;
> > return dw_pcie_write(pci->dbi_base + where, size, val);
> }
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 9f1a5e399b70..5be5f369abf2 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -215,6 +215,7 @@ struct dw_pcie {
> > > struct device *dev;
> > > void __iomem*dbi_base;
> > > void __iomem*dbi_base2;
> > > + int dbi_length;
> > > u32 num_viewport;
> > > u8 iatu_unroll_enabled;
> > > struct pcie_portpp;
Re: [RFC PATCH 2/3] mm, memory_hotplug: deobfuscate migration part of offlining
On 20.11.18 15:34, Michal Hocko wrote:
> On Tue 20-11-18 15:26:43, David Hildenbrand wrote:
> [...]
>>> + do {
>>> + for (pfn = start_pfn; pfn;)
>>> + {
>>
>> { on a new line looks weird.
>>
>>> + /* start memory hot removal */
>>> + ret = -EINTR;
>>
>> I think we can move that into the "if (signal_pending(current))"
>>
>> (if my eyes are not wrong, this will not be touched otherwise)
>
> Better?
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 9cd161db3061..6bc3aee30f5e 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1592,11 +1592,10 @@ static int __ref __offline_pages(unsigned long
> start_pfn,
> }
>
> do {
> - for (pfn = start_pfn; pfn;)
> - {
> + for (pfn = start_pfn; pfn;) {
> /* start memory hot removal */
> - ret = -EINTR;
> if (signal_pending(current)) {
> + ret = -EINTR;
> reason = "signal backoff";
> goto failed_removal_isolated;
> }
>
Reviewed-by: David Hildenbrand
:)
--
Thanks,
David / dhildenb
Re: [PATCH] watchdog: cpwd: add of_node_put()
On 11/20/18 5:23 AM, Yangtao Li wrote: use of_node_put() to release the refcount. Signed-off-by: Yangtao Li --- drivers/watchdog/cpwd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c index aee0b25cf10d..d3a81642ada5 100644 --- a/drivers/watchdog/cpwd.c +++ b/drivers/watchdog/cpwd.c @@ -617,6 +617,7 @@ static int cpwd_probe(struct platform_device *op) platform_set_drvdata(op, p); cpwd_device = p; + of_node_put(options); It would be better to do that right after its last use to also cover error handling. Guenter return 0; out_unregister:
[PATCH v3] usb: hub: add retry routine after intr URB submit error
The hub sends hot-plug events to the host trough it's interrupt URB. The
driver takes care of completing the URB and re-submitting it. Completion
errors are handled in the hub_event() work, yet submission errors are
ignored, rendering the device unresponsive. All further events are lost.
It is fairly hard to find this issue in the wild, since you have to time
the USB hot-plug event with the URB submission failure. For instance it
could be the system running out of memory or some malfunction in the USB
controller driver. Nevertheless, it's pretty reasonable to think it'll
happen sometime. One can trigger this issue using eBPF's function
override feature (see BCC's inject.py script).
This patch adds a retry routine to the event of a submission error. The
HUB driver will try to re-submit the URB once every second until it's
successful or the HUB is disconnected.
As some USB subsystems already take care of this issue, the
implementation was inspired from usbhid/hid_core.c's.
Signed-off-by: Nicolas Saenz Julienne
---
v3: As per Oliver's request:
- Take care of race condition between disconnect and irq
v2: as per Alan's and Oliver's comments:
- Rename timer
- Delete the timer on disconnect
- Don't reset HUB nor exponential slowdown the timer, 1s fixed retry
period
- Check for -ESHUTDOWN prior kicking the timer
drivers/usb/core/hub.c | 45 --
drivers/usb/core/hub.h | 2 ++
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c6077d582d29..630490a35301 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -607,6 +607,38 @@ static int hub_port_status(struct usb_hub *hub, int port1,
status, change, NULL);
}
+static void hub_resubmit_irq_urb(struct usb_hub *hub)
+{
+ unsigned long flags;
+ int status;
+
+ spin_lock_irqsave(&hub->irq_urb_lock, flags);
+
+ if (hub->quiescing) {
+ spin_unlock_irqrestore(&hub->irq_urb_lock, flags);
+ return;
+ }
+
+ status = usb_submit_urb(hub->urb, GFP_ATOMIC);
+ if (status && status != -ENODEV && status != -EPERM &&
+ status != -ESHUTDOWN) {
+ dev_err(hub->intfdev, "resubmit --> %d\n", status);
+ mod_timer(&hub->irq_urb_retry,
+ jiffies + msecs_to_jiffies(MSEC_PER_SEC));
+
+ }
+
+ spin_unlock_irqrestore(&hub->irq_urb_lock, flags);
+}
+
+static void hub_retry_irq_urb(struct timer_list *t)
+{
+ struct usb_hub *hub = from_timer(hub, t, irq_urb_retry);
+
+ hub_resubmit_irq_urb(hub);
+}
+
+
static void kick_hub_wq(struct usb_hub *hub)
{
struct usb_interface *intf;
@@ -709,12 +741,7 @@ static void hub_irq(struct urb *urb)
kick_hub_wq(hub);
resubmit:
- if (hub->quiescing)
- return;
-
- status = usb_submit_urb(hub->urb, GFP_ATOMIC);
- if (status != 0 && status != -ENODEV && status != -EPERM)
- dev_err(hub->intfdev, "resubmit --> %d\n", status);
+ hub_resubmit_irq_urb(hub);
}
/* USB 2.0 spec Section 11.24.2.3 */
@@ -1254,10 +1281,13 @@ enum hub_quiescing_type {
static void hub_quiesce(struct usb_hub *hub, enum hub_quiescing_type type)
{
struct usb_device *hdev = hub->hdev;
+ unsigned long flags;
int i;
/* hub_wq and related activity won't re-trigger */
+ spin_lock_irqsave(&hub->irq_urb_lock, flags);
hub->quiescing = 1;
+ spin_unlock_irqrestore(&hub->irq_urb_lock, flags);
if (type != HUB_SUSPEND) {
/* Disconnect all the children */
@@ -1268,6 +1298,7 @@ static void hub_quiesce(struct usb_hub *hub, enum
hub_quiescing_type type)
}
/* Stop hub_wq and related activity */
+ del_timer_sync(&hub->irq_urb_retry);
usb_kill_urb(hub->urb);
if (hub->has_indicators)
cancel_delayed_work_sync(&hub->leds);
@@ -1800,6 +1831,8 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
INIT_DELAYED_WORK(&hub->leds, led_work);
INIT_DELAYED_WORK(&hub->init_work, NULL);
INIT_WORK(&hub->events, hub_event);
+ spin_lock_init(&hub->irq_urb_lock);
+ timer_setup(&hub->irq_urb_retry, hub_retry_irq_urb, 0);
usb_get_intf(intf);
usb_get_dev(hdev);
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 4accfb63f7dc..a9e24e4b8df1 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -69,6 +69,8 @@ struct usb_hub {
struct delayed_work leds;
struct delayed_work init_work;
struct work_struct events;
+ spinlock_t irq_urb_lock;
+ struct timer_list irq_urb_retry;
struct usb_port **ports;
};
--
2.19.1
