Re: [PATCH 2/2] power: supply: Add Spreadtrum SC2731 charger support
Hi Sebastian,
On 31 August 2018 at 05:27, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 11:08:59AM +0800, Baolin Wang wrote:
>> >> +static int sc2731_charger_hw_init(struct sc2731_charger_info *info)
>> >> +{
>> >> + int ret;
>> >> +
>> >> + /* Enable charger module */
>> >> + ret = regmap_update_bits(info->regmap, SC2731_MODULE_EN1,
>> >> +SC2731_CHARGE_EN, SC2731_CHARGE_EN);
>> >> + if (ret)
>> >> + return ret;
>> >> +
>> >> + /* Set default charge termination current to 120 mA */
>> >> + ret = regmap_update_bits(info->regmap, info->base +
>> >> SC2731_CHG_CFG2,
>> >> +SC2731_TERMINATION_CUR_MASK, 0x2);
>> >
>> > Looks like DeviceTree property.
>>
>> OK.
>>
>> >
>> >> + if (ret)
>> >> + goto error;
>> >> +
>> >> + /* Set default charge termination voltage to 4.35V */
>> >
>> > Looks like DeviceTree property.
>>
>> OK. Thanks for your comments.
>
> I did not review this in detail, but had quick look at this.
> Please make sure to derive battery specific DT values using
> this:
>
> Documentation/devicetree/bindings/power/supply/battery.txt
Sure. Will look at this file. Thanks.
--
Baolin Wang
Best Regards
Re: [PATCH 2/2] power: supply: Add Spreadtrum SC2731 charger support
Hi Sebastian,
On 31 August 2018 at 05:27, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 11:08:59AM +0800, Baolin Wang wrote:
>> >> +static int sc2731_charger_hw_init(struct sc2731_charger_info *info)
>> >> +{
>> >> + int ret;
>> >> +
>> >> + /* Enable charger module */
>> >> + ret = regmap_update_bits(info->regmap, SC2731_MODULE_EN1,
>> >> +SC2731_CHARGE_EN, SC2731_CHARGE_EN);
>> >> + if (ret)
>> >> + return ret;
>> >> +
>> >> + /* Set default charge termination current to 120 mA */
>> >> + ret = regmap_update_bits(info->regmap, info->base +
>> >> SC2731_CHG_CFG2,
>> >> +SC2731_TERMINATION_CUR_MASK, 0x2);
>> >
>> > Looks like DeviceTree property.
>>
>> OK.
>>
>> >
>> >> + if (ret)
>> >> + goto error;
>> >> +
>> >> + /* Set default charge termination voltage to 4.35V */
>> >
>> > Looks like DeviceTree property.
>>
>> OK. Thanks for your comments.
>
> I did not review this in detail, but had quick look at this.
> Please make sure to derive battery specific DT values using
> this:
>
> Documentation/devicetree/bindings/power/supply/battery.txt
Sure. Will look at this file. Thanks.
--
Baolin Wang
Best Regards
Re: [PATCH 5/8] RISC-V: Rename im_okay_therefore_i_am to found_boot_cpu
On Thu, Aug 30, 2018 at 09:11:11AM -0700, Atish Patra wrote: > On 8/30/18 7:41 AM, Christoph Hellwig wrote: > > > struct device_node *dn = NULL; > > > - int hart, im_okay_therefore_i_am = 0; > > > + int hart, found_boot_cpu = 0; > > > > If you rename this anyway please switch to use a bool. > > > > I can address the comment on this patch and fold it in my series to avoid > unnecessary conflict. > > @Palmer: You can drop this patch. If Palmer is ok with it how about you include a respin of his whole series? There are some overlaps I think and having a single person in charge might be helpful. Btw, I've found your series in my linux-kernel folder, but it did not make it to linux-riscv or my personal inbox despite the CC.
Re: [PATCH 5/8] RISC-V: Rename im_okay_therefore_i_am to found_boot_cpu
On Thu, Aug 30, 2018 at 09:11:11AM -0700, Atish Patra wrote: > On 8/30/18 7:41 AM, Christoph Hellwig wrote: > > > struct device_node *dn = NULL; > > > - int hart, im_okay_therefore_i_am = 0; > > > + int hart, found_boot_cpu = 0; > > > > If you rename this anyway please switch to use a bool. > > > > I can address the comment on this patch and fold it in my series to avoid > unnecessary conflict. > > @Palmer: You can drop this patch. If Palmer is ok with it how about you include a respin of his whole series? There are some overlaps I think and having a single person in charge might be helpful. Btw, I've found your series in my linux-kernel folder, but it did not make it to linux-riscv or my personal inbox despite the CC.
Re: [PATCH v6 1/2] leds: core: Introduce LED pattern trigger
Hi Jacek, On 31 August 2018 at 03:55, Jacek Anaszewski wrote: > Hi Baolin, > > On 08/30/2018 09:40 AM, Baolin Wang wrote: >> Some LED controllers have support for autonomously controlling >> brightness over time, according to some preprogrammed pattern or >> function. > > I think that this commit message should be rearranged, so that > the software pattern was mentioned in the first place. Please keep > in mind that LED triggers are defined as kernel based sources of > LED events in the first place. Sure. > >> >> This patch adds pattern trigger that LED device can configure the >> pattern and trigger it. >> >> Signed-off-by: Raphael Teysseyre >> Signed-off-by: Baolin Wang >> --- >> Changes from v5: >> - Add one 'hw_pattern' file for hardware patterns. >> >> Changes from v4: >> - Change the repeat file to return the originally written number. >> - Improve comments. >> - Fix some build warnings. >> >> Changes from v3: >> - Reset pattern number to 0 if user provides incorrect pattern string. >> - Support one pattern. >> >> Changes from v2: >> - Remove hardware_pattern boolen. >> - Chnage the pattern string format. >> >> Changes from v1: >> - Use ATTRIBUTE_GROUPS() to define attributes. >> - Introduce hardware_pattern flag to determine if software pattern >> or hardware pattern. >> - Re-implement pattern_trig_store_pattern() function. >> - Remove pattern_get() interface. >> - Improve comments. >> - Other small optimization. >> --- >> .../ABI/testing/sysfs-class-led-trigger-pattern| 41 +++ >> drivers/leds/trigger/Kconfig |7 + >> drivers/leds/trigger/Makefile |1 + >> drivers/leds/trigger/ledtrig-pattern.c | 344 >> >> include/linux/leds.h | 16 + >> 5 files changed, 409 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> create mode 100644 drivers/leds/trigger/ledtrig-pattern.c >> >> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> new file mode 100644 >> index 000..dda8bbc >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> @@ -0,0 +1,41 @@ >> +What:/sys/class/leds//pattern >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a software pattern for the LED, that supports altering >> + the brightness for the specified duration with one software >> + timer. >> + >> + The pattern is given by a series of tuples, of brightness and >> + duration (ms). The LED is expected to traverse the series and >> + each brightness value for the specified duration. Duration of >> + 0 means brightness should immediately change to new value. >> + >> + The format of the software pattern values should be: >> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 >> + duration_3 ...". >> + >> +What:/sys/class/leds//hw_pattern >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a hardware pattern for the LED, for LED hardware that >> + supports altering the brightness as a function of time. >> + >> + The pattern is given by a series of tuples, of brightness and >> + duration (ms). The LED is expected to traverse the series and >> + each brightness value for the specified duration. Duration of >> + 0 means brightness should immediately change to new value. >> + >> + The format of the hardware pattern values should be: >> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 >> + duration_3 ...". > > hw_pattern interface should have separate description for each driver > supporting it. This is why we are to have a separate file for it. > So, here I'd just mention that each driver is expected to provide its > own ABI documentation for hw_pattern. > > E.g. in case of sc27xx you should describe the specific semantics of > each tuple, which will refer to a breathing curve settings. Sure. Will do. > >> + >> +What:/sys/class/leds//repeat >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a pattern repeat number. 0 means repeat indefinitely. >> + >> + This file will always return the originally written repeat >> + number. >> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig >> index 4018af7..b76fc3c 100644 >> --- a/drivers/leds/trigger/Kconfig >> +++ b/drivers/leds/trigger/Kconfig >> @@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV >> This allows LEDs to be controlled by network device activity. >> If unsure, say Y. >> >>
Re: [PATCH v6 1/2] leds: core: Introduce LED pattern trigger
Hi Jacek, On 31 August 2018 at 03:55, Jacek Anaszewski wrote: > Hi Baolin, > > On 08/30/2018 09:40 AM, Baolin Wang wrote: >> Some LED controllers have support for autonomously controlling >> brightness over time, according to some preprogrammed pattern or >> function. > > I think that this commit message should be rearranged, so that > the software pattern was mentioned in the first place. Please keep > in mind that LED triggers are defined as kernel based sources of > LED events in the first place. Sure. > >> >> This patch adds pattern trigger that LED device can configure the >> pattern and trigger it. >> >> Signed-off-by: Raphael Teysseyre >> Signed-off-by: Baolin Wang >> --- >> Changes from v5: >> - Add one 'hw_pattern' file for hardware patterns. >> >> Changes from v4: >> - Change the repeat file to return the originally written number. >> - Improve comments. >> - Fix some build warnings. >> >> Changes from v3: >> - Reset pattern number to 0 if user provides incorrect pattern string. >> - Support one pattern. >> >> Changes from v2: >> - Remove hardware_pattern boolen. >> - Chnage the pattern string format. >> >> Changes from v1: >> - Use ATTRIBUTE_GROUPS() to define attributes. >> - Introduce hardware_pattern flag to determine if software pattern >> or hardware pattern. >> - Re-implement pattern_trig_store_pattern() function. >> - Remove pattern_get() interface. >> - Improve comments. >> - Other small optimization. >> --- >> .../ABI/testing/sysfs-class-led-trigger-pattern| 41 +++ >> drivers/leds/trigger/Kconfig |7 + >> drivers/leds/trigger/Makefile |1 + >> drivers/leds/trigger/ledtrig-pattern.c | 344 >> >> include/linux/leds.h | 16 + >> 5 files changed, 409 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> create mode 100644 drivers/leds/trigger/ledtrig-pattern.c >> >> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> new file mode 100644 >> index 000..dda8bbc >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> @@ -0,0 +1,41 @@ >> +What:/sys/class/leds//pattern >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a software pattern for the LED, that supports altering >> + the brightness for the specified duration with one software >> + timer. >> + >> + The pattern is given by a series of tuples, of brightness and >> + duration (ms). The LED is expected to traverse the series and >> + each brightness value for the specified duration. Duration of >> + 0 means brightness should immediately change to new value. >> + >> + The format of the software pattern values should be: >> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 >> + duration_3 ...". >> + >> +What:/sys/class/leds//hw_pattern >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a hardware pattern for the LED, for LED hardware that >> + supports altering the brightness as a function of time. >> + >> + The pattern is given by a series of tuples, of brightness and >> + duration (ms). The LED is expected to traverse the series and >> + each brightness value for the specified duration. Duration of >> + 0 means brightness should immediately change to new value. >> + >> + The format of the hardware pattern values should be: >> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 >> + duration_3 ...". > > hw_pattern interface should have separate description for each driver > supporting it. This is why we are to have a separate file for it. > So, here I'd just mention that each driver is expected to provide its > own ABI documentation for hw_pattern. > > E.g. in case of sc27xx you should describe the specific semantics of > each tuple, which will refer to a breathing curve settings. Sure. Will do. > >> + >> +What:/sys/class/leds//repeat >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a pattern repeat number. 0 means repeat indefinitely. >> + >> + This file will always return the originally written repeat >> + number. >> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig >> index 4018af7..b76fc3c 100644 >> --- a/drivers/leds/trigger/Kconfig >> +++ b/drivers/leds/trigger/Kconfig >> @@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV >> This allows LEDs to be controlled by network device activity. >> If unsure, say Y. >> >>
[PATCH V6 3/4] clk: add managed version of clk_bulk_get_all
This patch introduces the managed version of clk_bulk_get_all.
Cc: Michael Turquette
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* improve 'devres->clks = *clks' according to Stephen's suggestion
v2->v3:
* a minor fix of build warning on PowerPC platform.
v1->v2:
* new patch
---
drivers/clk/clk-devres.c | 24
include/linux/clk.h | 23 +++
2 files changed, 47 insertions(+)
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index d854e26..12c8745 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -70,6 +70,30 @@ int __must_check devm_clk_bulk_get(struct device *dev, int
num_clks,
}
EXPORT_SYMBOL_GPL(devm_clk_bulk_get);
+int __must_check devm_clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+ struct clk_bulk_devres *devres;
+ int ret;
+
+ devres = devres_alloc(devm_clk_bulk_release,
+ sizeof(*devres), GFP_KERNEL);
+ if (!devres)
+ return -ENOMEM;
+
+ ret = clk_bulk_get_all(dev, >clks);
+ if (ret > 0) {
+ *clks = devres->clks;
+ devres->num_clks = ret;
+ devres_add(dev, devres);
+ } else {
+ devres_free(devres);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devm_clk_bulk_get_all);
+
static int devm_clk_match(struct device *dev, void *res, void *data)
{
struct clk **c = res;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index e9433c7..c705271 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -346,6 +346,22 @@ int __must_check clk_bulk_get_all(struct device *dev,
*/
int __must_check devm_clk_bulk_get(struct device *dev, int num_clks,
struct clk_bulk_data *clks);
+/**
+ * devm_clk_bulk_get_all - managed get multiple clk consumers
+ * @dev: device for clock "consumer"
+ * @clks: pointer to the clk_bulk_data table of consumer
+ *
+ * Returns a positive value for the number of clocks obtained while the
+ * clock references are stored in the clk_bulk_data table in @clks field.
+ * Returns 0 if there're none and a negative value if something failed.
+ *
+ * This helper function allows drivers to get several clk
+ * consumers in one operation with management, the clks will
+ * automatically be freed when the device is unbound.
+ */
+
+int __must_check devm_clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks);
/**
* devm_clk_get - lookup and obtain a managed reference to a clock producer.
@@ -691,6 +707,13 @@ static inline int __must_check devm_clk_bulk_get(struct
device *dev, int num_clk
return 0;
}
+static inline int __must_check devm_clk_bulk_get_all(struct device *dev,
+struct clk_bulk_data
**clks)
+{
+
+ return 0;
+}
+
static inline struct clk *devm_get_clk_from_child(struct device *dev,
struct device_node *np, const char *con_id)
{
--
2.7.4
[PATCH V6 3/4] clk: add managed version of clk_bulk_get_all
This patch introduces the managed version of clk_bulk_get_all.
Cc: Michael Turquette
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* improve 'devres->clks = *clks' according to Stephen's suggestion
v2->v3:
* a minor fix of build warning on PowerPC platform.
v1->v2:
* new patch
---
drivers/clk/clk-devres.c | 24
include/linux/clk.h | 23 +++
2 files changed, 47 insertions(+)
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index d854e26..12c8745 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -70,6 +70,30 @@ int __must_check devm_clk_bulk_get(struct device *dev, int
num_clks,
}
EXPORT_SYMBOL_GPL(devm_clk_bulk_get);
+int __must_check devm_clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+ struct clk_bulk_devres *devres;
+ int ret;
+
+ devres = devres_alloc(devm_clk_bulk_release,
+ sizeof(*devres), GFP_KERNEL);
+ if (!devres)
+ return -ENOMEM;
+
+ ret = clk_bulk_get_all(dev, >clks);
+ if (ret > 0) {
+ *clks = devres->clks;
+ devres->num_clks = ret;
+ devres_add(dev, devres);
+ } else {
+ devres_free(devres);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devm_clk_bulk_get_all);
+
static int devm_clk_match(struct device *dev, void *res, void *data)
{
struct clk **c = res;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index e9433c7..c705271 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -346,6 +346,22 @@ int __must_check clk_bulk_get_all(struct device *dev,
*/
int __must_check devm_clk_bulk_get(struct device *dev, int num_clks,
struct clk_bulk_data *clks);
+/**
+ * devm_clk_bulk_get_all - managed get multiple clk consumers
+ * @dev: device for clock "consumer"
+ * @clks: pointer to the clk_bulk_data table of consumer
+ *
+ * Returns a positive value for the number of clocks obtained while the
+ * clock references are stored in the clk_bulk_data table in @clks field.
+ * Returns 0 if there're none and a negative value if something failed.
+ *
+ * This helper function allows drivers to get several clk
+ * consumers in one operation with management, the clks will
+ * automatically be freed when the device is unbound.
+ */
+
+int __must_check devm_clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks);
/**
* devm_clk_get - lookup and obtain a managed reference to a clock producer.
@@ -691,6 +707,13 @@ static inline int __must_check devm_clk_bulk_get(struct
device *dev, int num_clk
return 0;
}
+static inline int __must_check devm_clk_bulk_get_all(struct device *dev,
+struct clk_bulk_data
**clks)
+{
+
+ return 0;
+}
+
static inline struct clk *devm_get_clk_from_child(struct device *dev,
struct device_node *np, const char *con_id)
{
--
2.7.4
[PATCH V6 2/4] clk: add new APIs to operate on all available clocks
This patch introduces of_clk_bulk_get_all and clk_bulk_x_all APIs
to users who just want to handle all available clocks from device tree
without need to know the detailed clock information likes clock numbers
and names. This is useful in writing some generic drivers to handle clock
part.
Cc: Stephen Boyd
Cc: Masahiro Yamada
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* no changes
v2->v3:
* remove #if define condition
* use kmalloc_array
v1->v2:
* make of_clk_bulk_get_all private
* add clk_bulk_get/put_all
---
drivers/clk/clk-bulk.c | 51 ++
include/linux/clk.h| 42 -
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index 4460ac5..6a7118d 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -17,9 +17,11 @@
*/
#include
+#include
#include
#include
#include
+#include
static int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
struct clk_bulk_data *clks)
@@ -49,6 +51,32 @@ static int __must_check of_clk_bulk_get(struct device_node
*np, int num_clks,
return ret;
}
+static int __must_check of_clk_bulk_get_all(struct device_node *np,
+ struct clk_bulk_data **clks)
+{
+ struct clk_bulk_data *clk_bulk;
+ int num_clks;
+ int ret;
+
+ num_clks = of_clk_get_parent_count(np);
+ if (!num_clks)
+ return 0;
+
+ clk_bulk = kmalloc_array(num_clks, sizeof(*clk_bulk), GFP_KERNEL);
+ if (!clk_bulk)
+ return -ENOMEM;
+
+ ret = of_clk_bulk_get(np, num_clks, clk_bulk);
+ if (ret) {
+ kfree(clk_bulk);
+ return ret;
+ }
+
+ *clks = clk_bulk;
+
+ return num_clks;
+}
+
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks)
{
while (--num_clks >= 0) {
@@ -88,6 +116,29 @@ int __must_check clk_bulk_get(struct device *dev, int
num_clks,
}
EXPORT_SYMBOL(clk_bulk_get);
+void clk_bulk_put_all(int num_clks, struct clk_bulk_data *clks)
+{
+ if (IS_ERR_OR_NULL(clks))
+ return;
+
+ clk_bulk_put(num_clks, clks);
+
+ kfree(clks);
+}
+EXPORT_SYMBOL(clk_bulk_put_all);
+
+int __must_check clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+ struct device_node *np = dev_of_node(dev);
+
+ if (!np)
+ return 0;
+
+ return of_clk_bulk_get_all(np, clks);
+}
+EXPORT_SYMBOL(clk_bulk_get_all);
+
#ifdef CONFIG_HAVE_CLK_PREPARE
/**
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 4f750c4..e9433c7 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -312,7 +312,26 @@ struct clk *clk_get(struct device *dev, const char *id);
*/
int __must_check clk_bulk_get(struct device *dev, int num_clks,
struct clk_bulk_data *clks);
-
+/**
+ * clk_bulk_get_all - lookup and obtain all available references to clock
+ * producer.
+ * @dev: device for clock "consumer"
+ * @clks: pointer to the clk_bulk_data table of consumer
+ *
+ * This helper function allows drivers to get all clk consumers in one
+ * operation. If any of the clk cannot be acquired then any clks
+ * that were obtained will be freed before returning to the caller.
+ *
+ * Returns a positive value for the number of clocks obtained while the
+ * clock references are stored in the clk_bulk_data table in @clks field.
+ * Returns 0 if there're none and a negative value if something failed.
+ *
+ * Drivers must assume that the clock source is not enabled.
+ *
+ * clk_bulk_get should not be called from within interrupt context.
+ */
+int __must_check clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks);
/**
* devm_clk_bulk_get - managed get multiple clk consumers
* @dev: device for clock "consumer"
@@ -488,6 +507,19 @@ void clk_put(struct clk *clk);
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks);
/**
+ * clk_bulk_put_all - "free" all the clock source
+ * @num_clks: the number of clk_bulk_data
+ * @clks: the clk_bulk_data table of consumer
+ *
+ * Note: drivers must ensure that all clk_bulk_enable calls made on this
+ * clock source are balanced by clk_bulk_disable calls prior to calling
+ * this function.
+ *
+ * clk_bulk_put_all should not be called from within interrupt context.
+ */
+void clk_bulk_put_all(int num_clks, struct clk_bulk_data *clks);
+
+/**
* devm_clk_put- "free" a managed clock source
* @dev: device used to acquire the clock
* @clk: clock source acquired with devm_clk_get()
@@ -642,6 +674,12 @@ static inline int __must_check clk_bulk_get(struct device
*dev, int num_clks,
return 0;
}
+static inline int __must_check clk_bulk_get_all(struct device *dev,
+
Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> > If I force output with "-f", the resulting file has no occurrences
> > of "phandle".
>
> Are you booting with BootX or Open Firmware ?
Assuming you are using BootX (or miBoot), can you try this patch ?
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -37,6 +37,7 @@ static unsigned long __initdata bootx_dt_strend;
static unsigned long __initdata bootx_node_chosen;
static boot_infos_t * __initdata bootx_info;
static char __initdata bootx_disp_path[256];
+static int __initdata bootx_phandle;
/* Is boot-info compatible ? */
#define BOOT_INFO_IS_COMPATIBLE(bi) \
@@ -258,6 +259,8 @@ static void __init bootx_scan_dt_build_strings(unsigned
long base,
namep = pp->name ? (char *)(base + pp->name) : NULL;
if (namep == NULL || strcmp(namep, "name") == 0)
goto next;
+ if (!strcmp(namep, "phandle") || !strcmp(namep,
"linux,phandle"))
+ bootx_phandle = -1;
/* get/create string entry */
soff = bootx_dt_find_string(namep);
if (soff == 0)
@@ -310,6 +313,7 @@ static void __init bootx_scan_dt_build_struct(unsigned long
base,
*mem_end = _ALIGN_UP((unsigned long)lp + 1, 4);
/* get and store all properties */
+ has_phandle = false;
while (*ppp) {
struct bootx_dt_prop *pp =
(struct bootx_dt_prop *)(base + *ppp);
@@ -330,6 +334,12 @@ static void __init bootx_scan_dt_build_struct(unsigned
long base,
ppp = >next;
}
+ /* add a phandle */
+ if (bootx_phandle > 0) {
+ bootx_dt_add_prop("phandle", _phandle, 4, mem_end);
+ bootx_phandle++;
+ }
+
if (node == bootx_node_chosen) {
bootx_add_chosen_props(base, mem_end);
if (bootx_info->dispDeviceRegEntryOffset == 0)
@@ -385,6 +395,8 @@ static unsigned long __init bootx_flatten_dt(unsigned long
start)
bootx_dt_add_string("linux,bootx-height", _end);
bootx_dt_add_string("linux,bootx-linebytes", _end);
bootx_dt_add_string("linux,bootx-addr", _end);
+ if (bootx_phandle > 0)
+ bootx_dt_add_string("phandle", _end);
/* Wrap up strings */
hdr->off_dt_strings = bootx_dt_strbase - mem_start;
hdr->dt_strings_size = bootx_dt_strend - bootx_dt_strbase;
@@ -482,6 +494,7 @@ void __init bootx_init(unsigned long r3, unsigned long r4)
bootx_dt_strbase = bootx_dt_strend = 0;
bootx_node_chosen = 0;
bootx_disp_path[0] = 0;
+ bootx_phandle = 1;
if (!BOOT_INFO_IS_V2_COMPATIBLE(bi))
bi->logicalDisplayBase = bi->dispDeviceBase;
[PATCH V6 2/4] clk: add new APIs to operate on all available clocks
This patch introduces of_clk_bulk_get_all and clk_bulk_x_all APIs
to users who just want to handle all available clocks from device tree
without need to know the detailed clock information likes clock numbers
and names. This is useful in writing some generic drivers to handle clock
part.
Cc: Stephen Boyd
Cc: Masahiro Yamada
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* no changes
v2->v3:
* remove #if define condition
* use kmalloc_array
v1->v2:
* make of_clk_bulk_get_all private
* add clk_bulk_get/put_all
---
drivers/clk/clk-bulk.c | 51 ++
include/linux/clk.h| 42 -
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index 4460ac5..6a7118d 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -17,9 +17,11 @@
*/
#include
+#include
#include
#include
#include
+#include
static int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
struct clk_bulk_data *clks)
@@ -49,6 +51,32 @@ static int __must_check of_clk_bulk_get(struct device_node
*np, int num_clks,
return ret;
}
+static int __must_check of_clk_bulk_get_all(struct device_node *np,
+ struct clk_bulk_data **clks)
+{
+ struct clk_bulk_data *clk_bulk;
+ int num_clks;
+ int ret;
+
+ num_clks = of_clk_get_parent_count(np);
+ if (!num_clks)
+ return 0;
+
+ clk_bulk = kmalloc_array(num_clks, sizeof(*clk_bulk), GFP_KERNEL);
+ if (!clk_bulk)
+ return -ENOMEM;
+
+ ret = of_clk_bulk_get(np, num_clks, clk_bulk);
+ if (ret) {
+ kfree(clk_bulk);
+ return ret;
+ }
+
+ *clks = clk_bulk;
+
+ return num_clks;
+}
+
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks)
{
while (--num_clks >= 0) {
@@ -88,6 +116,29 @@ int __must_check clk_bulk_get(struct device *dev, int
num_clks,
}
EXPORT_SYMBOL(clk_bulk_get);
+void clk_bulk_put_all(int num_clks, struct clk_bulk_data *clks)
+{
+ if (IS_ERR_OR_NULL(clks))
+ return;
+
+ clk_bulk_put(num_clks, clks);
+
+ kfree(clks);
+}
+EXPORT_SYMBOL(clk_bulk_put_all);
+
+int __must_check clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+ struct device_node *np = dev_of_node(dev);
+
+ if (!np)
+ return 0;
+
+ return of_clk_bulk_get_all(np, clks);
+}
+EXPORT_SYMBOL(clk_bulk_get_all);
+
#ifdef CONFIG_HAVE_CLK_PREPARE
/**
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 4f750c4..e9433c7 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -312,7 +312,26 @@ struct clk *clk_get(struct device *dev, const char *id);
*/
int __must_check clk_bulk_get(struct device *dev, int num_clks,
struct clk_bulk_data *clks);
-
+/**
+ * clk_bulk_get_all - lookup and obtain all available references to clock
+ * producer.
+ * @dev: device for clock "consumer"
+ * @clks: pointer to the clk_bulk_data table of consumer
+ *
+ * This helper function allows drivers to get all clk consumers in one
+ * operation. If any of the clk cannot be acquired then any clks
+ * that were obtained will be freed before returning to the caller.
+ *
+ * Returns a positive value for the number of clocks obtained while the
+ * clock references are stored in the clk_bulk_data table in @clks field.
+ * Returns 0 if there're none and a negative value if something failed.
+ *
+ * Drivers must assume that the clock source is not enabled.
+ *
+ * clk_bulk_get should not be called from within interrupt context.
+ */
+int __must_check clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks);
/**
* devm_clk_bulk_get - managed get multiple clk consumers
* @dev: device for clock "consumer"
@@ -488,6 +507,19 @@ void clk_put(struct clk *clk);
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks);
/**
+ * clk_bulk_put_all - "free" all the clock source
+ * @num_clks: the number of clk_bulk_data
+ * @clks: the clk_bulk_data table of consumer
+ *
+ * Note: drivers must ensure that all clk_bulk_enable calls made on this
+ * clock source are balanced by clk_bulk_disable calls prior to calling
+ * this function.
+ *
+ * clk_bulk_put_all should not be called from within interrupt context.
+ */
+void clk_bulk_put_all(int num_clks, struct clk_bulk_data *clks);
+
+/**
* devm_clk_put- "free" a managed clock source
* @dev: device used to acquire the clock
* @clk: clock source acquired with devm_clk_get()
@@ -642,6 +674,12 @@ static inline int __must_check clk_bulk_get(struct device
*dev, int num_clks,
return 0;
}
+static inline int __must_check clk_bulk_get_all(struct device *dev,
+
Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> > If I force output with "-f", the resulting file has no occurrences
> > of "phandle".
>
> Are you booting with BootX or Open Firmware ?
Assuming you are using BootX (or miBoot), can you try this patch ?
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -37,6 +37,7 @@ static unsigned long __initdata bootx_dt_strend;
static unsigned long __initdata bootx_node_chosen;
static boot_infos_t * __initdata bootx_info;
static char __initdata bootx_disp_path[256];
+static int __initdata bootx_phandle;
/* Is boot-info compatible ? */
#define BOOT_INFO_IS_COMPATIBLE(bi) \
@@ -258,6 +259,8 @@ static void __init bootx_scan_dt_build_strings(unsigned
long base,
namep = pp->name ? (char *)(base + pp->name) : NULL;
if (namep == NULL || strcmp(namep, "name") == 0)
goto next;
+ if (!strcmp(namep, "phandle") || !strcmp(namep,
"linux,phandle"))
+ bootx_phandle = -1;
/* get/create string entry */
soff = bootx_dt_find_string(namep);
if (soff == 0)
@@ -310,6 +313,7 @@ static void __init bootx_scan_dt_build_struct(unsigned long
base,
*mem_end = _ALIGN_UP((unsigned long)lp + 1, 4);
/* get and store all properties */
+ has_phandle = false;
while (*ppp) {
struct bootx_dt_prop *pp =
(struct bootx_dt_prop *)(base + *ppp);
@@ -330,6 +334,12 @@ static void __init bootx_scan_dt_build_struct(unsigned
long base,
ppp = >next;
}
+ /* add a phandle */
+ if (bootx_phandle > 0) {
+ bootx_dt_add_prop("phandle", _phandle, 4, mem_end);
+ bootx_phandle++;
+ }
+
if (node == bootx_node_chosen) {
bootx_add_chosen_props(base, mem_end);
if (bootx_info->dispDeviceRegEntryOffset == 0)
@@ -385,6 +395,8 @@ static unsigned long __init bootx_flatten_dt(unsigned long
start)
bootx_dt_add_string("linux,bootx-height", _end);
bootx_dt_add_string("linux,bootx-linebytes", _end);
bootx_dt_add_string("linux,bootx-addr", _end);
+ if (bootx_phandle > 0)
+ bootx_dt_add_string("phandle", _end);
/* Wrap up strings */
hdr->off_dt_strings = bootx_dt_strbase - mem_start;
hdr->dt_strings_size = bootx_dt_strend - bootx_dt_strbase;
@@ -482,6 +494,7 @@ void __init bootx_init(unsigned long r3, unsigned long r4)
bootx_dt_strbase = bootx_dt_strend = 0;
bootx_node_chosen = 0;
bootx_disp_path[0] = 0;
+ bootx_phandle = 1;
if (!BOOT_INFO_IS_V2_COMPATIBLE(bi))
bi->logicalDisplayBase = bi->dispDeviceBase;
[PATCH V6 4/4] video: simplefb: switch to use clk_bulk API to simplify clock operations
Switching to use clk_bulk API to simplify clock operations.
Cc: Hans de Goede
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Cc: Masahiro Yamada
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v5->v6:
* address Hans's comments
v4->v5:
* fix wrong setting of par->clks_enabled
v3->v4:
* no changes
v2->v3:
* fix a build warning on x86 platform due to a wrong
of the prototype of simplefb_clocks_enable
v1->v2:
* switch to clk_bulk_get_all from of_clk_bulk_get_all
---
drivers/video/fbdev/simplefb.c | 72 +++---
1 file changed, 18 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 9a9d748..89fb1e7 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -181,8 +181,8 @@ struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
bool clks_enabled;
- unsigned int clk_count;
- struct clk **clks;
+ int clk_count;
+ struct clk_bulk_data *clks;
#endif
#if defined CONFIG_OF && defined CONFIG_REGULATOR
bool regulators_enabled;
@@ -214,37 +214,13 @@ static int simplefb_clocks_get(struct simplefb_par *par,
struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct clk *clock;
- int i;
if (dev_get_platdata(>dev) || !np)
return 0;
- par->clk_count = of_clk_get_parent_count(np);
- if (!par->clk_count)
- return 0;
-
- par->clks = kcalloc(par->clk_count, sizeof(struct clk *), GFP_KERNEL);
- if (!par->clks)
- return -ENOMEM;
-
- for (i = 0; i < par->clk_count; i++) {
- clock = of_clk_get(np, i);
- if (IS_ERR(clock)) {
- if (PTR_ERR(clock) == -EPROBE_DEFER) {
- while (--i >= 0) {
- if (par->clks[i])
- clk_put(par->clks[i]);
- }
- kfree(par->clks);
- return -EPROBE_DEFER;
- }
- dev_err(>dev, "%s: clock %d not found: %ld\n",
- __func__, i, PTR_ERR(clock));
- continue;
- }
- par->clks[i] = clock;
- }
+ par->clk_count = clk_bulk_get_all(>dev, >clks);
+ if (par->clk_count == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
return 0;
}
@@ -252,39 +228,27 @@ static int simplefb_clocks_get(struct simplefb_par *par,
static void simplefb_clocks_enable(struct simplefb_par *par,
struct platform_device *pdev)
{
- int i, ret;
+ int ret;
- for (i = 0; i < par->clk_count; i++) {
- if (par->clks[i]) {
- ret = clk_prepare_enable(par->clks[i]);
- if (ret) {
- dev_err(>dev,
- "%s: failed to enable clock %d: %d\n",
- __func__, i, ret);
- clk_put(par->clks[i]);
- par->clks[i] = NULL;
- }
- }
- }
- par->clks_enabled = true;
+ if (par->clk_count <= 0)
+ return;
+
+ ret = clk_bulk_prepare_enable(par->clk_count, par->clks);
+ if (ret)
+ dev_warn(>dev, "failed to enable clocks\n");
+ else
+ par->clks_enabled = true;
}
static void simplefb_clocks_destroy(struct simplefb_par *par)
{
- int i;
-
- if (!par->clks)
+ if (par->clk_count <= 0)
return;
- for (i = 0; i < par->clk_count; i++) {
- if (par->clks[i]) {
- if (par->clks_enabled)
- clk_disable_unprepare(par->clks[i]);
- clk_put(par->clks[i]);
- }
- }
+ if (par->clks_enabled)
+ clk_bulk_disable_unprepare(par->clk_count, par->clks);
- kfree(par->clks);
+ clk_bulk_put_all(par->clk_count, par->clks);
}
#else
static int simplefb_clocks_get(struct simplefb_par *par,
--
2.7.4
[PATCH V6 4/4] video: simplefb: switch to use clk_bulk API to simplify clock operations
Switching to use clk_bulk API to simplify clock operations.
Cc: Hans de Goede
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Cc: Masahiro Yamada
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v5->v6:
* address Hans's comments
v4->v5:
* fix wrong setting of par->clks_enabled
v3->v4:
* no changes
v2->v3:
* fix a build warning on x86 platform due to a wrong
of the prototype of simplefb_clocks_enable
v1->v2:
* switch to clk_bulk_get_all from of_clk_bulk_get_all
---
drivers/video/fbdev/simplefb.c | 72 +++---
1 file changed, 18 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 9a9d748..89fb1e7 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -181,8 +181,8 @@ struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
bool clks_enabled;
- unsigned int clk_count;
- struct clk **clks;
+ int clk_count;
+ struct clk_bulk_data *clks;
#endif
#if defined CONFIG_OF && defined CONFIG_REGULATOR
bool regulators_enabled;
@@ -214,37 +214,13 @@ static int simplefb_clocks_get(struct simplefb_par *par,
struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct clk *clock;
- int i;
if (dev_get_platdata(>dev) || !np)
return 0;
- par->clk_count = of_clk_get_parent_count(np);
- if (!par->clk_count)
- return 0;
-
- par->clks = kcalloc(par->clk_count, sizeof(struct clk *), GFP_KERNEL);
- if (!par->clks)
- return -ENOMEM;
-
- for (i = 0; i < par->clk_count; i++) {
- clock = of_clk_get(np, i);
- if (IS_ERR(clock)) {
- if (PTR_ERR(clock) == -EPROBE_DEFER) {
- while (--i >= 0) {
- if (par->clks[i])
- clk_put(par->clks[i]);
- }
- kfree(par->clks);
- return -EPROBE_DEFER;
- }
- dev_err(>dev, "%s: clock %d not found: %ld\n",
- __func__, i, PTR_ERR(clock));
- continue;
- }
- par->clks[i] = clock;
- }
+ par->clk_count = clk_bulk_get_all(>dev, >clks);
+ if (par->clk_count == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
return 0;
}
@@ -252,39 +228,27 @@ static int simplefb_clocks_get(struct simplefb_par *par,
static void simplefb_clocks_enable(struct simplefb_par *par,
struct platform_device *pdev)
{
- int i, ret;
+ int ret;
- for (i = 0; i < par->clk_count; i++) {
- if (par->clks[i]) {
- ret = clk_prepare_enable(par->clks[i]);
- if (ret) {
- dev_err(>dev,
- "%s: failed to enable clock %d: %d\n",
- __func__, i, ret);
- clk_put(par->clks[i]);
- par->clks[i] = NULL;
- }
- }
- }
- par->clks_enabled = true;
+ if (par->clk_count <= 0)
+ return;
+
+ ret = clk_bulk_prepare_enable(par->clk_count, par->clks);
+ if (ret)
+ dev_warn(>dev, "failed to enable clocks\n");
+ else
+ par->clks_enabled = true;
}
static void simplefb_clocks_destroy(struct simplefb_par *par)
{
- int i;
-
- if (!par->clks)
+ if (par->clk_count <= 0)
return;
- for (i = 0; i < par->clk_count; i++) {
- if (par->clks[i]) {
- if (par->clks_enabled)
- clk_disable_unprepare(par->clks[i]);
- clk_put(par->clks[i]);
- }
- }
+ if (par->clks_enabled)
+ clk_bulk_disable_unprepare(par->clk_count, par->clks);
- kfree(par->clks);
+ clk_bulk_put_all(par->clk_count, par->clks);
}
#else
static int simplefb_clocks_get(struct simplefb_par *par,
--
2.7.4
[PATCH V6 0/4] clk: new APIs to handle all available clocks
This patch series is a continue of discussion from here,
https://patchwork.kernel.org/patch/9986293/
that some users may want to handle all available clocks from device
tree without need to know the detailed clock information likes clock
numbers and names. This is useful in writing some generic drivers to
handle clock part.
Note:
This patch series is tested on MX6Q SDB cpufreq driver with a minor change
to switch to use clk_bulk_get_all.
But patch 4 only test compiling. Hopefully someone could help test
the function.
v3->v4:
* improve 'devres->clks = *clks' according to Stephen's suggestion
v2->v3:
* address all comments from Stephen
* fix build warnings on other architectures.
v1->v2:
* add clk_bulk_{get|put}_all() which only supports DT platform currently
* remove _all variants and the wrapper struct clk_bulk
* make of_clk_bulk_get and of_clk_bulk_get_all private until someone
proves they need it because they don't have a struct device pointer.
Dong Aisheng (4):
clk: bulk: add of_clk_bulk_get()
clk: add new APIs to operate on all available clocks
clk: add managed version of clk_bulk_get_all
video: simplefb: switch to use clk_bulk API to simplify clock
operations
drivers/clk/clk-bulk.c | 80 ++
drivers/clk/clk-devres.c | 24 +
drivers/video/fbdev/simplefb.c | 72 ++---
include/linux/clk.h| 65 +-
4 files changed, 186 insertions(+), 55 deletions(-)
--
2.7.4
[PATCH V6 1/4] clk: bulk: add of_clk_bulk_get()
'clock-names' property is optional in DT, so of_clk_bulk_get() is
introduced here to handle this for DT users without 'clock-names'
specified. Later clk_bulk_get_all() will be implemented on top of
it and this API will be kept private until someone proves they need
it because they don't have a struct device pointer.
Cc: Stephen Boyd
Cc: Michael Turquette
Cc: Russell King
Reported-by: Shawn Guo
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* no changes
v2->v3:
* remove #if define condition
* remove EXPORT_SYMBOL
---
drivers/clk/clk-bulk.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index 6904ed6..4460ac5 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -19,6 +19,35 @@
#include
#include
#include
+#include
+
+static int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
+ struct clk_bulk_data *clks)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < num_clks; i++)
+ clks[i].clk = NULL;
+
+ for (i = 0; i < num_clks; i++) {
+ clks[i].clk = of_clk_get(np, i);
+ if (IS_ERR(clks[i].clk)) {
+ ret = PTR_ERR(clks[i].clk);
+ pr_err("%pOF: Failed to get clk index: %d ret: %d\n",
+ np, i, ret);
+ clks[i].clk = NULL;
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ clk_bulk_put(i, clks);
+
+ return ret;
+}
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks)
{
--
2.7.4
Re: [PATCH 0/6] x86/alternatives: text_poke() fixes
On Fri, 31 Aug 2018 13:46:35 +0900
Masami Hiramatsu wrote:
> On Thu, 30 Aug 2018 10:32:12 -0700
> Nadav Amit wrote:
>
> > This patch-set addresses some issues that were raised in a recent
> > correspondence and might affect the security and the correctness of code
> > patching. (Note that patching performance is not addressed by this
> > patch-set).
> >
> > The main issue that the patches deal with is the fact that the fixmap
> > PTEs that are used for patching are available for access from other
> > cores and might be exploited. They are not even flushed from the TLB in
> > remote cores, so the risk is even higher. Address this issue by
> > introducing a temporary mm that is only used during patching.
> > Unfortunately, due to init ordering, fixmap is still used during
> > boot-time patching. Future patches can eliminate the need for it.
> >
> > The second issue is the missing lockdep assertion to ensure text_mutex
> > is taken. It is actually not always taken, so fix the instances that
> > were found not to take the lock (although they should be safe even
> > without taking the lock).
> >
> > Finally, try to be more conservative and to map a single page, instead
> > of two, when possible. This helps both security and performance.
> >
> > In addition, there is some cleanup of the patching code to make it more
> > readable.
>
> OK, this series looks good to me, and tested with ftracetest, kprobe testsets.
>
> Reviewed-by: Masami Hiramatsu
> Tested-by: Masami Hiramatsu
Oh, I missed a note.
To apply this series on -tip tree, we have to revert Jiri's text_mutex
checker.
9222f606506c ("x86/alternatives: Lockdep-enforce text_mutex in text_poke*()")
Thanks!
--
Masami Hiramatsu
[PATCH V6 0/4] clk: new APIs to handle all available clocks
This patch series is a continue of discussion from here,
https://patchwork.kernel.org/patch/9986293/
that some users may want to handle all available clocks from device
tree without need to know the detailed clock information likes clock
numbers and names. This is useful in writing some generic drivers to
handle clock part.
Note:
This patch series is tested on MX6Q SDB cpufreq driver with a minor change
to switch to use clk_bulk_get_all.
But patch 4 only test compiling. Hopefully someone could help test
the function.
v3->v4:
* improve 'devres->clks = *clks' according to Stephen's suggestion
v2->v3:
* address all comments from Stephen
* fix build warnings on other architectures.
v1->v2:
* add clk_bulk_{get|put}_all() which only supports DT platform currently
* remove _all variants and the wrapper struct clk_bulk
* make of_clk_bulk_get and of_clk_bulk_get_all private until someone
proves they need it because they don't have a struct device pointer.
Dong Aisheng (4):
clk: bulk: add of_clk_bulk_get()
clk: add new APIs to operate on all available clocks
clk: add managed version of clk_bulk_get_all
video: simplefb: switch to use clk_bulk API to simplify clock
operations
drivers/clk/clk-bulk.c | 80 ++
drivers/clk/clk-devres.c | 24 +
drivers/video/fbdev/simplefb.c | 72 ++---
include/linux/clk.h| 65 +-
4 files changed, 186 insertions(+), 55 deletions(-)
--
2.7.4
[PATCH V6 1/4] clk: bulk: add of_clk_bulk_get()
'clock-names' property is optional in DT, so of_clk_bulk_get() is
introduced here to handle this for DT users without 'clock-names'
specified. Later clk_bulk_get_all() will be implemented on top of
it and this API will be kept private until someone proves they need
it because they don't have a struct device pointer.
Cc: Stephen Boyd
Cc: Michael Turquette
Cc: Russell King
Reported-by: Shawn Guo
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* no changes
v2->v3:
* remove #if define condition
* remove EXPORT_SYMBOL
---
drivers/clk/clk-bulk.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index 6904ed6..4460ac5 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -19,6 +19,35 @@
#include
#include
#include
+#include
+
+static int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
+ struct clk_bulk_data *clks)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < num_clks; i++)
+ clks[i].clk = NULL;
+
+ for (i = 0; i < num_clks; i++) {
+ clks[i].clk = of_clk_get(np, i);
+ if (IS_ERR(clks[i].clk)) {
+ ret = PTR_ERR(clks[i].clk);
+ pr_err("%pOF: Failed to get clk index: %d ret: %d\n",
+ np, i, ret);
+ clks[i].clk = NULL;
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ clk_bulk_put(i, clks);
+
+ return ret;
+}
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks)
{
--
2.7.4
Re: [PATCH 0/6] x86/alternatives: text_poke() fixes
On Fri, 31 Aug 2018 13:46:35 +0900
Masami Hiramatsu wrote:
> On Thu, 30 Aug 2018 10:32:12 -0700
> Nadav Amit wrote:
>
> > This patch-set addresses some issues that were raised in a recent
> > correspondence and might affect the security and the correctness of code
> > patching. (Note that patching performance is not addressed by this
> > patch-set).
> >
> > The main issue that the patches deal with is the fact that the fixmap
> > PTEs that are used for patching are available for access from other
> > cores and might be exploited. They are not even flushed from the TLB in
> > remote cores, so the risk is even higher. Address this issue by
> > introducing a temporary mm that is only used during patching.
> > Unfortunately, due to init ordering, fixmap is still used during
> > boot-time patching. Future patches can eliminate the need for it.
> >
> > The second issue is the missing lockdep assertion to ensure text_mutex
> > is taken. It is actually not always taken, so fix the instances that
> > were found not to take the lock (although they should be safe even
> > without taking the lock).
> >
> > Finally, try to be more conservative and to map a single page, instead
> > of two, when possible. This helps both security and performance.
> >
> > In addition, there is some cleanup of the patching code to make it more
> > readable.
>
> OK, this series looks good to me, and tested with ftracetest, kprobe testsets.
>
> Reviewed-by: Masami Hiramatsu
> Tested-by: Masami Hiramatsu
Oh, I missed a note.
To apply this series on -tip tree, we have to revert Jiri's text_mutex
checker.
9222f606506c ("x86/alternatives: Lockdep-enforce text_mutex in text_poke*()")
Thanks!
--
Masami Hiramatsu
Re: [PATCH 0/6] x86/alternatives: text_poke() fixes
On Thu, 30 Aug 2018 10:32:12 -0700 Nadav Amit wrote: > This patch-set addresses some issues that were raised in a recent > correspondence and might affect the security and the correctness of code > patching. (Note that patching performance is not addressed by this > patch-set). > > The main issue that the patches deal with is the fact that the fixmap > PTEs that are used for patching are available for access from other > cores and might be exploited. They are not even flushed from the TLB in > remote cores, so the risk is even higher. Address this issue by > introducing a temporary mm that is only used during patching. > Unfortunately, due to init ordering, fixmap is still used during > boot-time patching. Future patches can eliminate the need for it. > > The second issue is the missing lockdep assertion to ensure text_mutex > is taken. It is actually not always taken, so fix the instances that > were found not to take the lock (although they should be safe even > without taking the lock). > > Finally, try to be more conservative and to map a single page, instead > of two, when possible. This helps both security and performance. > > In addition, there is some cleanup of the patching code to make it more > readable. OK, this series looks good to me, and tested with ftracetest, kprobe testsets. Reviewed-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Thank you! > > RFC->v1: > - Added handling of error in get_locked_pte() > - Remove lockdep assertion, clarify text_mutex use instead [masami] > - Comment fix [peterz] > - Removed remainders of text_poke return value [masami] > - Use __weak for poking_init instead of macros [masami] > - Simplify error handling in poking_init [masami] > > Cc: Andy Lutomirski > Cc: Masami Hiramatsu > Cc: Kees Cook > Cc: Peter Zijlstra > Link: https://lkml.org/lkml/2018/8/24/586 > > Andy Lutomirski (1): > x86/mm: temporary mm struct > > Nadav Amit (5): > x86/alternatives: clarify text_mutex use in text_poke > fork: provide a function for copying init_mm > x86/alternatives: initializing temporary mm for patching > x86/alternatives: use temporary mm for text poking > x86/alternatives: remove text_poke() return value > > arch/x86/include/asm/mmu_context.h | 20 > arch/x86/include/asm/pgtable.h | 3 + > arch/x86/include/asm/text-patching.h | 4 +- > arch/x86/kernel/alternative.c| 173 +++ > arch/x86/mm/init_64.c| 29 + > include/linux/sched/task.h | 1 + > init/main.c | 3 + > kernel/fork.c| 24 +++- > 8 files changed, 226 insertions(+), 31 deletions(-) > > -- > 2.17.1 > -- Masami Hiramatsu
Re: [PATCH 0/6] x86/alternatives: text_poke() fixes
On Thu, 30 Aug 2018 10:32:12 -0700 Nadav Amit wrote: > This patch-set addresses some issues that were raised in a recent > correspondence and might affect the security and the correctness of code > patching. (Note that patching performance is not addressed by this > patch-set). > > The main issue that the patches deal with is the fact that the fixmap > PTEs that are used for patching are available for access from other > cores and might be exploited. They are not even flushed from the TLB in > remote cores, so the risk is even higher. Address this issue by > introducing a temporary mm that is only used during patching. > Unfortunately, due to init ordering, fixmap is still used during > boot-time patching. Future patches can eliminate the need for it. > > The second issue is the missing lockdep assertion to ensure text_mutex > is taken. It is actually not always taken, so fix the instances that > were found not to take the lock (although they should be safe even > without taking the lock). > > Finally, try to be more conservative and to map a single page, instead > of two, when possible. This helps both security and performance. > > In addition, there is some cleanup of the patching code to make it more > readable. OK, this series looks good to me, and tested with ftracetest, kprobe testsets. Reviewed-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Thank you! > > RFC->v1: > - Added handling of error in get_locked_pte() > - Remove lockdep assertion, clarify text_mutex use instead [masami] > - Comment fix [peterz] > - Removed remainders of text_poke return value [masami] > - Use __weak for poking_init instead of macros [masami] > - Simplify error handling in poking_init [masami] > > Cc: Andy Lutomirski > Cc: Masami Hiramatsu > Cc: Kees Cook > Cc: Peter Zijlstra > Link: https://lkml.org/lkml/2018/8/24/586 > > Andy Lutomirski (1): > x86/mm: temporary mm struct > > Nadav Amit (5): > x86/alternatives: clarify text_mutex use in text_poke > fork: provide a function for copying init_mm > x86/alternatives: initializing temporary mm for patching > x86/alternatives: use temporary mm for text poking > x86/alternatives: remove text_poke() return value > > arch/x86/include/asm/mmu_context.h | 20 > arch/x86/include/asm/pgtable.h | 3 + > arch/x86/include/asm/text-patching.h | 4 +- > arch/x86/kernel/alternative.c| 173 +++ > arch/x86/mm/init_64.c| 29 + > include/linux/sched/task.h | 1 + > init/main.c | 3 + > kernel/fork.c| 24 +++- > 8 files changed, 226 insertions(+), 31 deletions(-) > > -- > 2.17.1 > -- Masami Hiramatsu
Re: [RFC PATCH 2/6] x86/mm: temporary mm struct
On Wed, 29 Aug 2018 18:59:52 -0700
Andy Lutomirski wrote:
>
>
> > On Aug 29, 2018, at 6:38 PM, Masami Hiramatsu wrote:
> >
> > On Wed, 29 Aug 2018 08:41:00 -0700
> > Andy Lutomirski wrote:
> >
> >>> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu
> >>> wrote:
> >>> On Wed, 29 Aug 2018 01:11:43 -0700
> >>> Nadav Amit wrote:
> >>>
> From: Andy Lutomirski
>
> Sometimes we want to set a temporary page-table entries (PTEs) in one of
> the cores, without allowing other cores to use - even speculatively -
> these mappings. There are two benefits for doing so:
>
> (1) Security: if sensitive PTEs are set, temporary mm prevents their use
> in other cores. This hardens the security as it prevents exploding a
> dangling pointer to overwrite sensitive data using the sensitive PTE.
>
> (2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in
> remote page-tables.
>
> To do so a temporary mm_struct can be used. Mappings which are private
> for this mm can be set in the userspace part of the address-space.
> During the whole time in which the temporary mm is loaded, interrupts
> must be disabled.
>
> The first use-case for temporary PTEs, which will follow, is for poking
> the kernel text.
>
> [ Commit message was written by Nadav ]
>
> Cc: Andy Lutomirski
> Cc: Masami Hiramatsu
> Cc: Kees Cook
> Cc: Peter Zijlstra
> Signed-off-by: Nadav Amit
> ---
> arch/x86/include/asm/mmu_context.h | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/x86/include/asm/mmu_context.h
> b/arch/x86/include/asm/mmu_context.h
> index eeeb9289c764..96afc8c0cf15 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -338,4 +338,24 @@ static inline unsigned long
> __get_current_cr3_fast(void)
> return cr3;
> }
>
> +typedef struct {
> + struct mm_struct *prev;
> +} temporary_mm_state_t;
> +
> +static inline temporary_mm_state_t use_temporary_mm(struct mm_struct
> *mm)
> +{
> + temporary_mm_state_t state;
> +
> + lockdep_assert_irqs_disabled();
> + state.prev = this_cpu_read(cpu_tlbstate.loaded_mm);
> + switch_mm_irqs_off(NULL, mm, current);
> + return state;
> +}
> >>>
> >>> Hmm, why don't we return mm_struct *prev directly?
> >>
> >> I did it this way to make it easier to add future debugging stuff
> >> later. Also, when I first wrote this, I stashed the old CR3 instead
> >> of the old mm_struct, and it seemed like callers should be insulated
> >> from details like this.
> >
> > Hmm, I see. But in that case, we should call it "struct temporary_mm"
> > and explicitly allocate (and pass) it, since we can not return the
> > data structure from stack.
>
> Why not?
Ah, ok as far as it returns a data structure as immediate value.
(I don't recommend it because it hides a copy..)
>
> > If we can combine it with new mm, it will
> > be more encapsulated e.g.
> >
> > struct temporary_mm {
> >struct mm_struct *mm;
> >struct mm_struct *prev;
> > };
> >
> > static struct temporary_mm poking_tmp_mm;
> >
> > poking_init()
> > {
> >if (init_temporary_mm(_mm, _mm))
> >goto error;
> >...
> > }
> >
> > text_poke_safe()
> > {
> >...
> >use_temporary_mm(_mm);
> >...
> >unuse_temporary_mm(_mm);
> > }
> >
> > Any thought?
>
> That seems more complicated for not very much gain.
Hmm, OK. anyway that is just a style note. The code itself looks good for me.
Thank you,
>
--
Masami Hiramatsu
Re: [RFC PATCH 2/6] x86/mm: temporary mm struct
On Wed, 29 Aug 2018 18:59:52 -0700
Andy Lutomirski wrote:
>
>
> > On Aug 29, 2018, at 6:38 PM, Masami Hiramatsu wrote:
> >
> > On Wed, 29 Aug 2018 08:41:00 -0700
> > Andy Lutomirski wrote:
> >
> >>> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu
> >>> wrote:
> >>> On Wed, 29 Aug 2018 01:11:43 -0700
> >>> Nadav Amit wrote:
> >>>
> From: Andy Lutomirski
>
> Sometimes we want to set a temporary page-table entries (PTEs) in one of
> the cores, without allowing other cores to use - even speculatively -
> these mappings. There are two benefits for doing so:
>
> (1) Security: if sensitive PTEs are set, temporary mm prevents their use
> in other cores. This hardens the security as it prevents exploding a
> dangling pointer to overwrite sensitive data using the sensitive PTE.
>
> (2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in
> remote page-tables.
>
> To do so a temporary mm_struct can be used. Mappings which are private
> for this mm can be set in the userspace part of the address-space.
> During the whole time in which the temporary mm is loaded, interrupts
> must be disabled.
>
> The first use-case for temporary PTEs, which will follow, is for poking
> the kernel text.
>
> [ Commit message was written by Nadav ]
>
> Cc: Andy Lutomirski
> Cc: Masami Hiramatsu
> Cc: Kees Cook
> Cc: Peter Zijlstra
> Signed-off-by: Nadav Amit
> ---
> arch/x86/include/asm/mmu_context.h | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/x86/include/asm/mmu_context.h
> b/arch/x86/include/asm/mmu_context.h
> index eeeb9289c764..96afc8c0cf15 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -338,4 +338,24 @@ static inline unsigned long
> __get_current_cr3_fast(void)
> return cr3;
> }
>
> +typedef struct {
> + struct mm_struct *prev;
> +} temporary_mm_state_t;
> +
> +static inline temporary_mm_state_t use_temporary_mm(struct mm_struct
> *mm)
> +{
> + temporary_mm_state_t state;
> +
> + lockdep_assert_irqs_disabled();
> + state.prev = this_cpu_read(cpu_tlbstate.loaded_mm);
> + switch_mm_irqs_off(NULL, mm, current);
> + return state;
> +}
> >>>
> >>> Hmm, why don't we return mm_struct *prev directly?
> >>
> >> I did it this way to make it easier to add future debugging stuff
> >> later. Also, when I first wrote this, I stashed the old CR3 instead
> >> of the old mm_struct, and it seemed like callers should be insulated
> >> from details like this.
> >
> > Hmm, I see. But in that case, we should call it "struct temporary_mm"
> > and explicitly allocate (and pass) it, since we can not return the
> > data structure from stack.
>
> Why not?
Ah, ok as far as it returns a data structure as immediate value.
(I don't recommend it because it hides a copy..)
>
> > If we can combine it with new mm, it will
> > be more encapsulated e.g.
> >
> > struct temporary_mm {
> >struct mm_struct *mm;
> >struct mm_struct *prev;
> > };
> >
> > static struct temporary_mm poking_tmp_mm;
> >
> > poking_init()
> > {
> >if (init_temporary_mm(_mm, _mm))
> >goto error;
> >...
> > }
> >
> > text_poke_safe()
> > {
> >...
> >use_temporary_mm(_mm);
> >...
> >unuse_temporary_mm(_mm);
> > }
> >
> > Any thought?
>
> That seems more complicated for not very much gain.
Hmm, OK. anyway that is just a style note. The code itself looks good for me.
Thank you,
>
--
Masami Hiramatsu
Re: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault
On Thu, Aug 30, 2018 at 6:49 PM Tony Luck wrote: > > Just checking "do we have a non-canonical address" at the bottom of that > call stack and flipping bit 63 back on again seems like a bad idea. You could literally do something like /* Make it canonical in case we flipped the high bit */ addr = (long)(addr<<1)>>1; in the call to clflush and it magically does the right thing. Pretty? No. But with a big comment about what is going on and why it's done, I think it's prettier than your much bigger patch. I dunno. It does strike me as a bit hacky, but I'd rather have a *small* one-liner hack that generates two instructions, than add a complex hack that modifies the page tables three times and has a serializing instruction in it. Both are subtle fixes for a subtle issue, but one seems pretty harmless in comparison. Hmm? But I'll bow to the x86 maintainers. Linus
Re: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault
On Thu, Aug 30, 2018 at 6:49 PM Tony Luck wrote: > > Just checking "do we have a non-canonical address" at the bottom of that > call stack and flipping bit 63 back on again seems like a bad idea. You could literally do something like /* Make it canonical in case we flipped the high bit */ addr = (long)(addr<<1)>>1; in the call to clflush and it magically does the right thing. Pretty? No. But with a big comment about what is going on and why it's done, I think it's prettier than your much bigger patch. I dunno. It does strike me as a bit hacky, but I'd rather have a *small* one-liner hack that generates two instructions, than add a complex hack that modifies the page tables three times and has a serializing instruction in it. Both are subtle fixes for a subtle issue, but one seems pretty harmless in comparison. Hmm? But I'll bow to the x86 maintainers. Linus
Re: 32-bit PTI with THP = userspace corruption
> > I am seeing userland corruption and application crashes on multiple > > 32-bit machines with 4.19-rc1+git. The machines vary: PII, PIII, P4. > > They are all Intel. AMD Duron/Athlon/AthlonMP have been fine in my tests > > so far (may be configuration dependent). > > Thanks for the report! I'll try to reproduce the problem tomorrow and > investigate it. Can you please check if any of the kernel configurations > that show the bug has CONFIG_X86_PAE set? If not, can you please test > if enabling this option still triggers the problem? Will check, but out of my memery there were 2 G3 HP Proliants that did not fit into the pattern (problem did not appear). I have more than 4G RAM in those and HIGHMEM_4G there, maybe that's it? -- Meelis Roos (mr...@linux.ee)
Re: 32-bit PTI with THP = userspace corruption
> > I am seeing userland corruption and application crashes on multiple > > 32-bit machines with 4.19-rc1+git. The machines vary: PII, PIII, P4. > > They are all Intel. AMD Duron/Athlon/AthlonMP have been fine in my tests > > so far (may be configuration dependent). > > Thanks for the report! I'll try to reproduce the problem tomorrow and > investigate it. Can you please check if any of the kernel configurations > that show the bug has CONFIG_X86_PAE set? If not, can you please test > if enabling this option still triggers the problem? Will check, but out of my memery there were 2 G3 HP Proliants that did not fit into the pattern (problem did not appear). I have more than 4G RAM in those and HIGHMEM_4G there, maybe that's it? -- Meelis Roos (mr...@linux.ee)
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
On Thu 30 Aug 20:57 PDT 2018, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
> > Attempt to acquire the APCS IPC through the mailbox framework and fall
> > back to the old syscon based approach, to allow us to move away from
> > using the syscon.
> >
> > Reviewed-by: Arun Kumar Neelakantam
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Changes since v2:
> > - Added comment about mbox_send_message() return value.
> >
> > .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++-
> > drivers/rpmsg/Kconfig | 1 +
> > drivers/rpmsg/qcom_smd.c | 67
> > --
> > 3 files changed, 56 insertions(+), 20 deletions(-)
>
> This patch in the mainline Linux kernel as commit
> ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4
> causes a problem with the APQ8074 Dragonboard. The mmc device is not set up
> with the patch applied, thus I do not have the block device my root file
> system
> is located on.
>
> Testing on v4.18, if I revert this commit the mmc device is available.
>
> I'll reply to this email with the console messages for 4.18 and for 4.18 with
> this commit reverted.
>
The mmc device would fail to come up if the regulators didn't come up,
which would be the result of smd not working. But it should fallback to
the old mechanism if no mailbox is specified.
Can you double check that CONFIG_RPMSG_QCOM_SMD is still set in your
.config after applying and building with this commit included? And if
not, try to enable CONFIG_MAILBOX.
Regards,
Bjorn
> -Frank
>
>
> >
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > index ea1dc75ec9ea..234ae2256501 100644
> > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > @@ -22,9 +22,15 @@ The edge is described by the following properties:
> > Definition: should specify the IRQ used by the remote processor to
> > signal this processor about communication related updates
> >
> > -- qcom,ipc:
> > +- mboxes:
> > Usage: required
> > Value type:
> > + Definition: reference to the associated doorbell in APCS, as described
> > + in mailbox/mailbox.txt
> > +
> > +- qcom,ipc:
> > + Usage: required, unless mboxes is specified
> > + Value type:
> > Definition: three entries specifying the outgoing ipc bit used for
> > signaling the remote processor:
> > - phandle to a syscon node representing the apcs registers
> > diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> > index 0fe6eac46512..2e4fb4ffd562 100644
> > --- a/drivers/rpmsg/Kconfig
> > +++ b/drivers/rpmsg/Kconfig
> > @@ -39,6 +39,7 @@ config RPMSG_QCOM_GLINK_SMEM
> >
> > config RPMSG_QCOM_SMD
> > tristate "Qualcomm Shared Memory Driver (SMD)"
> > + depends on MAILBOX
> > depends on QCOM_SMEM
> > select RPMSG
> > help
> > diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> > index bc0b30657230..3ff271a44bef 100644
> > --- a/drivers/rpmsg/qcom_smd.c
> > +++ b/drivers/rpmsg/qcom_smd.c
> > @@ -14,6 +14,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -107,6 +108,8 @@ static const struct {
> > * @ipc_regmap:regmap handle holding the outgoing ipc register
> > * @ipc_offset:offset within @ipc_regmap of the register for
> > ipc
> > * @ipc_bit: bit in the register at @ipc_offset of
> > @ipc_regmap
> > + * @mbox_client: mailbox client handle
> > + * @mbox_chan: apcs ipc mailbox channel handle
> > * @channels: list of all channels detected on this edge
> > * @channels_lock: guard for modifications of @channels
> > * @allocated: array of bitmaps representing already allocated
> > channels
> > @@ -129,6 +132,9 @@ struct qcom_smd_edge {
> > int ipc_offset;
> > int ipc_bit;
> >
> > + struct mbox_client mbox_client;
> > + struct mbox_chan *mbox_chan;
> > +
> > struct list_head channels;
> > spinlock_t channels_lock;
> >
> > @@ -366,7 +372,17 @@ static void qcom_smd_signal_channel(struct
> > qcom_smd_channel *channel)
> > {
> > struct qcom_smd_edge *edge = channel->edge;
> >
> > - regmap_write(edge->ipc_regmap, edge->ipc_offset, BIT(edge->ipc_bit));
> > + if (edge->mbox_chan) {
> > + /*
> > +* We can ignore a failing mbox_send_message() as the only
> > +* possible cause is that the FIFO in the framework is full of
> > +* other writes to the same bit.
> > +*/
> > + mbox_send_message(edge->mbox_chan, NULL);
> > + mbox_client_txdone(edge->mbox_chan, 0);
> > + } else {
> > + regmap_write(edge->ipc_regmap, edge->ipc_offset,
> > BIT(edge->ipc_bit));
> > + }
>
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
On Thu 30 Aug 20:57 PDT 2018, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
> > Attempt to acquire the APCS IPC through the mailbox framework and fall
> > back to the old syscon based approach, to allow us to move away from
> > using the syscon.
> >
> > Reviewed-by: Arun Kumar Neelakantam
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Changes since v2:
> > - Added comment about mbox_send_message() return value.
> >
> > .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++-
> > drivers/rpmsg/Kconfig | 1 +
> > drivers/rpmsg/qcom_smd.c | 67
> > --
> > 3 files changed, 56 insertions(+), 20 deletions(-)
>
> This patch in the mainline Linux kernel as commit
> ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4
> causes a problem with the APQ8074 Dragonboard. The mmc device is not set up
> with the patch applied, thus I do not have the block device my root file
> system
> is located on.
>
> Testing on v4.18, if I revert this commit the mmc device is available.
>
> I'll reply to this email with the console messages for 4.18 and for 4.18 with
> this commit reverted.
>
The mmc device would fail to come up if the regulators didn't come up,
which would be the result of smd not working. But it should fallback to
the old mechanism if no mailbox is specified.
Can you double check that CONFIG_RPMSG_QCOM_SMD is still set in your
.config after applying and building with this commit included? And if
not, try to enable CONFIG_MAILBOX.
Regards,
Bjorn
> -Frank
>
>
> >
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > index ea1dc75ec9ea..234ae2256501 100644
> > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> > @@ -22,9 +22,15 @@ The edge is described by the following properties:
> > Definition: should specify the IRQ used by the remote processor to
> > signal this processor about communication related updates
> >
> > -- qcom,ipc:
> > +- mboxes:
> > Usage: required
> > Value type:
> > + Definition: reference to the associated doorbell in APCS, as described
> > + in mailbox/mailbox.txt
> > +
> > +- qcom,ipc:
> > + Usage: required, unless mboxes is specified
> > + Value type:
> > Definition: three entries specifying the outgoing ipc bit used for
> > signaling the remote processor:
> > - phandle to a syscon node representing the apcs registers
> > diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> > index 0fe6eac46512..2e4fb4ffd562 100644
> > --- a/drivers/rpmsg/Kconfig
> > +++ b/drivers/rpmsg/Kconfig
> > @@ -39,6 +39,7 @@ config RPMSG_QCOM_GLINK_SMEM
> >
> > config RPMSG_QCOM_SMD
> > tristate "Qualcomm Shared Memory Driver (SMD)"
> > + depends on MAILBOX
> > depends on QCOM_SMEM
> > select RPMSG
> > help
> > diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> > index bc0b30657230..3ff271a44bef 100644
> > --- a/drivers/rpmsg/qcom_smd.c
> > +++ b/drivers/rpmsg/qcom_smd.c
> > @@ -14,6 +14,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -107,6 +108,8 @@ static const struct {
> > * @ipc_regmap:regmap handle holding the outgoing ipc register
> > * @ipc_offset:offset within @ipc_regmap of the register for
> > ipc
> > * @ipc_bit: bit in the register at @ipc_offset of
> > @ipc_regmap
> > + * @mbox_client: mailbox client handle
> > + * @mbox_chan: apcs ipc mailbox channel handle
> > * @channels: list of all channels detected on this edge
> > * @channels_lock: guard for modifications of @channels
> > * @allocated: array of bitmaps representing already allocated
> > channels
> > @@ -129,6 +132,9 @@ struct qcom_smd_edge {
> > int ipc_offset;
> > int ipc_bit;
> >
> > + struct mbox_client mbox_client;
> > + struct mbox_chan *mbox_chan;
> > +
> > struct list_head channels;
> > spinlock_t channels_lock;
> >
> > @@ -366,7 +372,17 @@ static void qcom_smd_signal_channel(struct
> > qcom_smd_channel *channel)
> > {
> > struct qcom_smd_edge *edge = channel->edge;
> >
> > - regmap_write(edge->ipc_regmap, edge->ipc_offset, BIT(edge->ipc_bit));
> > + if (edge->mbox_chan) {
> > + /*
> > +* We can ignore a failing mbox_send_message() as the only
> > +* possible cause is that the FIFO in the framework is full of
> > +* other writes to the same bit.
> > +*/
> > + mbox_send_message(edge->mbox_chan, NULL);
> > + mbox_client_txdone(edge->mbox_chan, 0);
> > + } else {
> > + regmap_write(edge->ipc_regmap, edge->ipc_offset,
> > BIT(edge->ipc_bit));
> > + }
>
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
On 08/30/18 20:57, Frank Rowand wrote: > Hi Bjorn, > > > On 04/19/18 18:17, Bjorn Andersson wrote: >> Attempt to acquire the APCS IPC through the mailbox framework and fall >> back to the old syscon based approach, to allow us to move away from >> using the syscon. >> >> Reviewed-by: Arun Kumar Neelakantam >> Signed-off-by: Bjorn Andersson >> --- >> >> Changes since v2: >> - Added comment about mbox_send_message() return value. >> >> .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++- >> drivers/rpmsg/Kconfig | 1 + >> drivers/rpmsg/qcom_smd.c | 67 >> -- >> 3 files changed, 56 insertions(+), 20 deletions(-) > > This patch in the mainline Linux kernel as commit > ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4 > causes a problem with the APQ8074 Dragonboard. The mmc device is not set up > with the patch applied, thus I do not have the block device my root file > system > is located on. > > Testing on v4.18, if I revert this commit the mmc device is available. > > I'll reply to this email with the console messages for 4.18 and for 4.18 with > this commit reverted. < snip > Note that I have commented out the WARN_ON() in gic_irq_domain_translate() at drivers/irqchip/irq-gic.c:1016 to remove a lot of noise from the boot messages. Here are the console messages for 4.18, with ab460a2e72da reverted: Android Bootloader - UART_DM Initialized!!! [0] welcome to lk [10] platform_init() [10] target_init() [10] Display Init: Start [10] display_init(),target_id=10. [30] Config MIPI_VIDEO_PANEL. [30] Turn on MIPI_VIDEO_PANEL. [50] Video lane tested successfully [50] Display Init: Done [80] Loading keystore failed status 5 [80] ERROR: scm_protect_keystore Failed[200] USB init ept @ 0xf96b000 [220] fastboot_init() [220] udc_start() [350] -- reset -- [350] -- portchange -- [460] -- reset -- [460] -- portchange -- [650] fastboot: processing commands [760] fastboot: download:00ed6000 [1250] fastboot: boot [1270] Found Appeneded Flattened Device tree [1270] cmdline: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyMSM0,115200 debug and roidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq [1290] Updating device tree: start [1300] Updating device tree: done [1300] booting linux @ 0x8000, ramdisk @ 0x200 (9533134), tags/device tree @ 0x1e0 [1310] Turn off MIPI_VIDEO_PANEL. [1310] Continuous splash enabled, keeping panel alive. Booting Linux on physical CPU 0x0 Linux version 4.18.0-dirty (frowand@xps8900) (gcc version 4.6.x-google 20120106 (prerelease) (GCC)) #2 SMP PREEMPT Thu Aug 30 20:26:18 PDT 2018 CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5787d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: Qualcomm APQ8074 Dragonboard Memory policy: Data cache writealloc On node 0 totalpages: 491776 Normal zone: 1536 pages used for memmap Normal zone: 0 pages reserved Normal zone: 164096 pages, LIFO batch:31 HighMem zone: 327680 pages, LIFO batch:31 random: get_random_bytes called from start_kernel+0x80/0x47c with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s39616 r8192 d21824 u69632 pcpu-alloc: s39616 r8192 d21824 u69632 alloc=17*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists, mobility grouping on. Total pages: 490240 Kernel command line: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyM SM0,115200 debug androidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1926832K/1967104K available (8192K kernel code, 793K rwdata, 3260K rodata, 1024K init, 267K bss, 40272K reserved, 0K cma-reserved, 13107 20K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xf080 - 0xff80 ( 240 MB) lowmem : 0xc000 - 0xf000 ( 768 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0x(ptrval) - 0x(ptrval) (9184 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 794 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 268 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Preemptible hierarchical RCU implementation. Tasks RCU enabled. NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns Switching to timer-based
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
On 08/30/18 20:57, Frank Rowand wrote: > Hi Bjorn, > > > On 04/19/18 18:17, Bjorn Andersson wrote: >> Attempt to acquire the APCS IPC through the mailbox framework and fall >> back to the old syscon based approach, to allow us to move away from >> using the syscon. >> >> Reviewed-by: Arun Kumar Neelakantam >> Signed-off-by: Bjorn Andersson >> --- >> >> Changes since v2: >> - Added comment about mbox_send_message() return value. >> >> .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++- >> drivers/rpmsg/Kconfig | 1 + >> drivers/rpmsg/qcom_smd.c | 67 >> -- >> 3 files changed, 56 insertions(+), 20 deletions(-) > > This patch in the mainline Linux kernel as commit > ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4 > causes a problem with the APQ8074 Dragonboard. The mmc device is not set up > with the patch applied, thus I do not have the block device my root file > system > is located on. > > Testing on v4.18, if I revert this commit the mmc device is available. > > I'll reply to this email with the console messages for 4.18 and for 4.18 with > this commit reverted. < snip > Note that I have commented out the WARN_ON() in gic_irq_domain_translate() at drivers/irqchip/irq-gic.c:1016 to remove a lot of noise from the boot messages. Here are the console messages for 4.18, with ab460a2e72da reverted: Android Bootloader - UART_DM Initialized!!! [0] welcome to lk [10] platform_init() [10] target_init() [10] Display Init: Start [10] display_init(),target_id=10. [30] Config MIPI_VIDEO_PANEL. [30] Turn on MIPI_VIDEO_PANEL. [50] Video lane tested successfully [50] Display Init: Done [80] Loading keystore failed status 5 [80] ERROR: scm_protect_keystore Failed[200] USB init ept @ 0xf96b000 [220] fastboot_init() [220] udc_start() [350] -- reset -- [350] -- portchange -- [460] -- reset -- [460] -- portchange -- [650] fastboot: processing commands [760] fastboot: download:00ed6000 [1250] fastboot: boot [1270] Found Appeneded Flattened Device tree [1270] cmdline: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyMSM0,115200 debug and roidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq [1290] Updating device tree: start [1300] Updating device tree: done [1300] booting linux @ 0x8000, ramdisk @ 0x200 (9533134), tags/device tree @ 0x1e0 [1310] Turn off MIPI_VIDEO_PANEL. [1310] Continuous splash enabled, keeping panel alive. Booting Linux on physical CPU 0x0 Linux version 4.18.0-dirty (frowand@xps8900) (gcc version 4.6.x-google 20120106 (prerelease) (GCC)) #2 SMP PREEMPT Thu Aug 30 20:26:18 PDT 2018 CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5787d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: Qualcomm APQ8074 Dragonboard Memory policy: Data cache writealloc On node 0 totalpages: 491776 Normal zone: 1536 pages used for memmap Normal zone: 0 pages reserved Normal zone: 164096 pages, LIFO batch:31 HighMem zone: 327680 pages, LIFO batch:31 random: get_random_bytes called from start_kernel+0x80/0x47c with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s39616 r8192 d21824 u69632 pcpu-alloc: s39616 r8192 d21824 u69632 alloc=17*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists, mobility grouping on. Total pages: 490240 Kernel command line: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyM SM0,115200 debug androidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1926832K/1967104K available (8192K kernel code, 793K rwdata, 3260K rodata, 1024K init, 267K bss, 40272K reserved, 0K cma-reserved, 13107 20K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xf080 - 0xff80 ( 240 MB) lowmem : 0xc000 - 0xf000 ( 768 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0x(ptrval) - 0x(ptrval) (9184 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 794 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 268 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Preemptible hierarchical RCU implementation. Tasks RCU enabled. NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns Switching to timer-based
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
On 08/30/18 20:57, Frank Rowand wrote: > Hi Bjorn, > > > On 04/19/18 18:17, Bjorn Andersson wrote: >> Attempt to acquire the APCS IPC through the mailbox framework and fall >> back to the old syscon based approach, to allow us to move away from >> using the syscon. >> >> Reviewed-by: Arun Kumar Neelakantam >> Signed-off-by: Bjorn Andersson >> --- >> >> Changes since v2: >> - Added comment about mbox_send_message() return value. >> >> .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++- >> drivers/rpmsg/Kconfig | 1 + >> drivers/rpmsg/qcom_smd.c | 67 >> -- >> 3 files changed, 56 insertions(+), 20 deletions(-) > > This patch in the mainline Linux kernel as commit > ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4 > causes a problem with the APQ8074 Dragonboard. The mmc device is not set up > with the patch applied, thus I do not have the block device my root file > system > is located on. > > Testing on v4.18, if I revert this commit the mmc device is available. > > I'll reply to this email with the console messages for 4.18 and for 4.18 with > this commit reverted. < snip > Note that I have commented out the WARN_ON() in gic_irq_domain_translate() at drivers/irqchip/irq-gic.c:1016 to remove a lot of noise from the boot messages. Here are the console messages for 4.18: Android Bootloader - UART_DM Initialized!!! [0] welcome to lk [10] platform_init() [10] target_init() [10] Display Init: Start [10] display_init(),target_id=10. [30] Config MIPI_VIDEO_PANEL. [30] Turn on MIPI_VIDEO_PANEL. [50] Video lane tested successfully [50] Display Init: Done [80] Loading keystore failed status 5 [80] ERROR: scm_protect_keystore Failed[200] USB init ept @ 0xf96b000 [220] fastboot_init() [220] udc_start() [350] -- reset -- [350] -- portchange -- [460] -- reset -- [460] -- portchange -- [650] fastboot: processing commands [750] fastboot: download:00ece000 [1220] fastboot: boot [1240] Found Appeneded Flattened Device tree [1240] cmdline: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyMSM0,115200 debug and roidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq [1270] Updating device tree: start [1270] Updating device tree: done [1270] booting linux @ 0x8000, ramdisk @ 0x200 (9533134), tags/device tree @ 0x1e0 [1280] Turn off MIPI_VIDEO_PANEL. [1280] Continuous splash enabled, keeping panel alive. Booting Linux on physical CPU 0x0 Linux version 4.18.0-dirty (frowand@xps8900) (gcc version 4.6.x-google 20120106 (prerelease) (GCC)) #3 SMP PREEMPT Thu Aug 30 20:32:21 PDT 2018 CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5787d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: Qualcomm APQ8074 Dragonboard Memory policy: Data cache writealloc On node 0 totalpages: 491776 Normal zone: 1536 pages used for memmap Normal zone: 0 pages reserved Normal zone: 164096 pages, LIFO batch:31 HighMem zone: 327680 pages, LIFO batch:31 random: get_random_bytes called from start_kernel+0x80/0x47c with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s39616 r8192 d21824 u69632 pcpu-alloc: s39616 r8192 d21824 u69632 alloc=17*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists, mobility grouping on. Total pages: 490240 Kernel command line: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyM SM0,115200 debug androidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1926844K/1967104K available (8192K kernel code, 782K rwdata, 3212K rodata, 1024K init, 267K bss, 40260K reserved, 0K cma-reserved, 13107 20K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xf080 - 0xff80 ( 240 MB) lowmem : 0xc000 - 0xf000 ( 768 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0x(ptrval) - 0x(ptrval) (9184 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 783 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 268 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Preemptible hierarchical RCU implementation. Tasks RCU enabled. NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns Switching to timer-based delay loop, resolution 52ns
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
On 08/30/18 20:57, Frank Rowand wrote: > Hi Bjorn, > > > On 04/19/18 18:17, Bjorn Andersson wrote: >> Attempt to acquire the APCS IPC through the mailbox framework and fall >> back to the old syscon based approach, to allow us to move away from >> using the syscon. >> >> Reviewed-by: Arun Kumar Neelakantam >> Signed-off-by: Bjorn Andersson >> --- >> >> Changes since v2: >> - Added comment about mbox_send_message() return value. >> >> .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++- >> drivers/rpmsg/Kconfig | 1 + >> drivers/rpmsg/qcom_smd.c | 67 >> -- >> 3 files changed, 56 insertions(+), 20 deletions(-) > > This patch in the mainline Linux kernel as commit > ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4 > causes a problem with the APQ8074 Dragonboard. The mmc device is not set up > with the patch applied, thus I do not have the block device my root file > system > is located on. > > Testing on v4.18, if I revert this commit the mmc device is available. > > I'll reply to this email with the console messages for 4.18 and for 4.18 with > this commit reverted. < snip > Note that I have commented out the WARN_ON() in gic_irq_domain_translate() at drivers/irqchip/irq-gic.c:1016 to remove a lot of noise from the boot messages. Here are the console messages for 4.18: Android Bootloader - UART_DM Initialized!!! [0] welcome to lk [10] platform_init() [10] target_init() [10] Display Init: Start [10] display_init(),target_id=10. [30] Config MIPI_VIDEO_PANEL. [30] Turn on MIPI_VIDEO_PANEL. [50] Video lane tested successfully [50] Display Init: Done [80] Loading keystore failed status 5 [80] ERROR: scm_protect_keystore Failed[200] USB init ept @ 0xf96b000 [220] fastboot_init() [220] udc_start() [350] -- reset -- [350] -- portchange -- [460] -- reset -- [460] -- portchange -- [650] fastboot: processing commands [750] fastboot: download:00ece000 [1220] fastboot: boot [1240] Found Appeneded Flattened Device tree [1240] cmdline: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyMSM0,115200 debug and roidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq [1270] Updating device tree: start [1270] Updating device tree: done [1270] booting linux @ 0x8000, ramdisk @ 0x200 (9533134), tags/device tree @ 0x1e0 [1280] Turn off MIPI_VIDEO_PANEL. [1280] Continuous splash enabled, keeping panel alive. Booting Linux on physical CPU 0x0 Linux version 4.18.0-dirty (frowand@xps8900) (gcc version 4.6.x-google 20120106 (prerelease) (GCC)) #3 SMP PREEMPT Thu Aug 30 20:32:21 PDT 2018 CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5787d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: Qualcomm APQ8074 Dragonboard Memory policy: Data cache writealloc On node 0 totalpages: 491776 Normal zone: 1536 pages used for memmap Normal zone: 0 pages reserved Normal zone: 164096 pages, LIFO batch:31 HighMem zone: 327680 pages, LIFO batch:31 random: get_random_bytes called from start_kernel+0x80/0x47c with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s39616 r8192 d21824 u69632 pcpu-alloc: s39616 r8192 d21824 u69632 alloc=17*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists, mobility grouping on. Total pages: 490240 Kernel command line: console=ttyMSM0,115200,n8 androidboot.hardware=qcom user_debug=31 maxcpus=2 msm_rtb.filter=0x37 ehci-hcd.park=3 kgdboc=ttyM SM0,115200 debug androidboot.emmc=true androidboot.serialno=40081c41 androidboot.baseband=apq Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1926844K/1967104K available (8192K kernel code, 782K rwdata, 3212K rodata, 1024K init, 267K bss, 40260K reserved, 0K cma-reserved, 13107 20K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xf080 - 0xff80 ( 240 MB) lowmem : 0xc000 - 0xf000 ( 768 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0x(ptrval) - 0x(ptrval) (9184 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 783 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 268 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Preemptible hierarchical RCU implementation. Tasks RCU enabled. NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns Switching to timer-based delay loop, resolution 52ns
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
Hi Bjorn,
On 04/19/18 18:17, Bjorn Andersson wrote:
> Attempt to acquire the APCS IPC through the mailbox framework and fall
> back to the old syscon based approach, to allow us to move away from
> using the syscon.
>
> Reviewed-by: Arun Kumar Neelakantam
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v2:
> - Added comment about mbox_send_message() return value.
>
> .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++-
> drivers/rpmsg/Kconfig | 1 +
> drivers/rpmsg/qcom_smd.c | 67
> --
> 3 files changed, 56 insertions(+), 20 deletions(-)
This patch in the mainline Linux kernel as commit
ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4
causes a problem with the APQ8074 Dragonboard. The mmc device is not set up
with the patch applied, thus I do not have the block device my root file system
is located on.
Testing on v4.18, if I revert this commit the mmc device is available.
I'll reply to this email with the console messages for 4.18 and for 4.18 with
this commit reverted.
-Frank
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> index ea1dc75ec9ea..234ae2256501 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> @@ -22,9 +22,15 @@ The edge is described by the following properties:
> Definition: should specify the IRQ used by the remote processor to
> signal this processor about communication related updates
>
> -- qcom,ipc:
> +- mboxes:
> Usage: required
> Value type:
> + Definition: reference to the associated doorbell in APCS, as described
> + in mailbox/mailbox.txt
> +
> +- qcom,ipc:
> + Usage: required, unless mboxes is specified
> + Value type:
> Definition: three entries specifying the outgoing ipc bit used for
> signaling the remote processor:
> - phandle to a syscon node representing the apcs registers
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index 0fe6eac46512..2e4fb4ffd562 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -39,6 +39,7 @@ config RPMSG_QCOM_GLINK_SMEM
>
> config RPMSG_QCOM_SMD
> tristate "Qualcomm Shared Memory Driver (SMD)"
> + depends on MAILBOX
> depends on QCOM_SMEM
> select RPMSG
> help
> diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> index bc0b30657230..3ff271a44bef 100644
> --- a/drivers/rpmsg/qcom_smd.c
> +++ b/drivers/rpmsg/qcom_smd.c
> @@ -14,6 +14,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -107,6 +108,8 @@ static const struct {
> * @ipc_regmap: regmap handle holding the outgoing ipc register
> * @ipc_offset: offset within @ipc_regmap of the register for
> ipc
> * @ipc_bit: bit in the register at @ipc_offset of @ipc_regmap
> + * @mbox_client: mailbox client handle
> + * @mbox_chan: apcs ipc mailbox channel handle
> * @channels:list of all channels detected on this edge
> * @channels_lock: guard for modifications of @channels
> * @allocated: array of bitmaps representing already allocated
> channels
> @@ -129,6 +132,9 @@ struct qcom_smd_edge {
> int ipc_offset;
> int ipc_bit;
>
> + struct mbox_client mbox_client;
> + struct mbox_chan *mbox_chan;
> +
> struct list_head channels;
> spinlock_t channels_lock;
>
> @@ -366,7 +372,17 @@ static void qcom_smd_signal_channel(struct
> qcom_smd_channel *channel)
> {
> struct qcom_smd_edge *edge = channel->edge;
>
> - regmap_write(edge->ipc_regmap, edge->ipc_offset, BIT(edge->ipc_bit));
> + if (edge->mbox_chan) {
> + /*
> + * We can ignore a failing mbox_send_message() as the only
> + * possible cause is that the FIFO in the framework is full of
> + * other writes to the same bit.
> + */
> + mbox_send_message(edge->mbox_chan, NULL);
> + mbox_client_txdone(edge->mbox_chan, 0);
> + } else {
> + regmap_write(edge->ipc_regmap, edge->ipc_offset,
> BIT(edge->ipc_bit));
> + }
> }
>
> /*
> @@ -1326,27 +1342,37 @@ static int qcom_smd_parse_edge(struct device *dev,
> key = "qcom,remote-pid";
> of_property_read_u32(node, key, >remote_pid);
>
> - syscon_np = of_parse_phandle(node, "qcom,ipc", 0);
> - if (!syscon_np) {
> - dev_err(dev, "no qcom,ipc node\n");
> - return -ENODEV;
> - }
> + edge->mbox_client.dev = dev;
> + edge->mbox_client.knows_txdone = true;
> + edge->mbox_chan = mbox_request_channel(>mbox_client, 0);
> + if (IS_ERR(edge->mbox_chan)) {
> + if (PTR_ERR(edge->mbox_chan) != -ENODEV)
Re: [PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework
Hi Bjorn,
On 04/19/18 18:17, Bjorn Andersson wrote:
> Attempt to acquire the APCS IPC through the mailbox framework and fall
> back to the old syscon based approach, to allow us to move away from
> using the syscon.
>
> Reviewed-by: Arun Kumar Neelakantam
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v2:
> - Added comment about mbox_send_message() return value.
>
> .../devicetree/bindings/soc/qcom/qcom,smd.txt | 8 ++-
> drivers/rpmsg/Kconfig | 1 +
> drivers/rpmsg/qcom_smd.c | 67
> --
> 3 files changed, 56 insertions(+), 20 deletions(-)
This patch in the mainline Linux kernel as commit
ab460a2e72dabecfdabd45eb7e3ee2d73fc876d4
causes a problem with the APQ8074 Dragonboard. The mmc device is not set up
with the patch applied, thus I do not have the block device my root file system
is located on.
Testing on v4.18, if I revert this commit the mmc device is available.
I'll reply to this email with the console messages for 4.18 and for 4.18 with
this commit reverted.
-Frank
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> index ea1dc75ec9ea..234ae2256501 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> @@ -22,9 +22,15 @@ The edge is described by the following properties:
> Definition: should specify the IRQ used by the remote processor to
> signal this processor about communication related updates
>
> -- qcom,ipc:
> +- mboxes:
> Usage: required
> Value type:
> + Definition: reference to the associated doorbell in APCS, as described
> + in mailbox/mailbox.txt
> +
> +- qcom,ipc:
> + Usage: required, unless mboxes is specified
> + Value type:
> Definition: three entries specifying the outgoing ipc bit used for
> signaling the remote processor:
> - phandle to a syscon node representing the apcs registers
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index 0fe6eac46512..2e4fb4ffd562 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -39,6 +39,7 @@ config RPMSG_QCOM_GLINK_SMEM
>
> config RPMSG_QCOM_SMD
> tristate "Qualcomm Shared Memory Driver (SMD)"
> + depends on MAILBOX
> depends on QCOM_SMEM
> select RPMSG
> help
> diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> index bc0b30657230..3ff271a44bef 100644
> --- a/drivers/rpmsg/qcom_smd.c
> +++ b/drivers/rpmsg/qcom_smd.c
> @@ -14,6 +14,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -107,6 +108,8 @@ static const struct {
> * @ipc_regmap: regmap handle holding the outgoing ipc register
> * @ipc_offset: offset within @ipc_regmap of the register for
> ipc
> * @ipc_bit: bit in the register at @ipc_offset of @ipc_regmap
> + * @mbox_client: mailbox client handle
> + * @mbox_chan: apcs ipc mailbox channel handle
> * @channels:list of all channels detected on this edge
> * @channels_lock: guard for modifications of @channels
> * @allocated: array of bitmaps representing already allocated
> channels
> @@ -129,6 +132,9 @@ struct qcom_smd_edge {
> int ipc_offset;
> int ipc_bit;
>
> + struct mbox_client mbox_client;
> + struct mbox_chan *mbox_chan;
> +
> struct list_head channels;
> spinlock_t channels_lock;
>
> @@ -366,7 +372,17 @@ static void qcom_smd_signal_channel(struct
> qcom_smd_channel *channel)
> {
> struct qcom_smd_edge *edge = channel->edge;
>
> - regmap_write(edge->ipc_regmap, edge->ipc_offset, BIT(edge->ipc_bit));
> + if (edge->mbox_chan) {
> + /*
> + * We can ignore a failing mbox_send_message() as the only
> + * possible cause is that the FIFO in the framework is full of
> + * other writes to the same bit.
> + */
> + mbox_send_message(edge->mbox_chan, NULL);
> + mbox_client_txdone(edge->mbox_chan, 0);
> + } else {
> + regmap_write(edge->ipc_regmap, edge->ipc_offset,
> BIT(edge->ipc_bit));
> + }
> }
>
> /*
> @@ -1326,27 +1342,37 @@ static int qcom_smd_parse_edge(struct device *dev,
> key = "qcom,remote-pid";
> of_property_read_u32(node, key, >remote_pid);
>
> - syscon_np = of_parse_phandle(node, "qcom,ipc", 0);
> - if (!syscon_np) {
> - dev_err(dev, "no qcom,ipc node\n");
> - return -ENODEV;
> - }
> + edge->mbox_client.dev = dev;
> + edge->mbox_client.knows_txdone = true;
> + edge->mbox_chan = mbox_request_channel(>mbox_client, 0);
> + if (IS_ERR(edge->mbox_chan)) {
> + if (PTR_ERR(edge->mbox_chan) != -ENODEV)
Re: VirtIO console hangs
On Tue, 28 Aug 2018 15:00:14 +
Matteo Croce wrote:
> On Tue, Aug 28, 2018 at 2:35 PM Nicholas Piggin wrote:
> >
> > On Tue, 28 Aug 2018 12:54:08 +
> > Matteo Croce wrote:
> >
> > > With kernel 4.19.0-rc1 virtio_console hangs very often.
> > > I can always trigger the bug by pasting some characters in the
> > > terminal window, the console will stop receiving keypresses, but I can
> > > still see output from the console.
> > > Stangely, logging in the VM via SSH and sending lot of data to hvc0,
> > > like 'dmesg >/dev/hvc0' will fix the issue until the next paste.
> > >
> > > I did a git bisect and I've found that this is the offending commit,
> > > reverting it fixes it.
> > >
> > > Cheers,
> > >
> > > commit ec97eaad1383ab2500fcf9a07ade6044fbcc67f5
> > > Author: Nicholas Piggin
> > > Date: Tue May 1 00:55:54 2018 +1000
> > >
> > > tty: hvc: hvc_poll() break hv read loop
> >
> > Thanks for the report. I can't immediately see what the problem
> > is. Can you try get a stack trace of where it is stuck?
> >
>
> I tried but didn't get one.
>
> > Perhaps try this patch if you have time (it's a bit of a shot
> > in the dark).
> >
>
> Yes it seems to fix. Thanks!
Okay sorry for the delay, I can reproduce it here and found a better
fix, if I could trouble you to test again.
[PATCH] tty: hvc: hvc_poll() fix read loop hang
Patch ec97eaad1383 ("tty: hvc: hvc_poll() break hv read loop") causes
the virtio console to hang if you paste a bunch of characters to it.
The reason is that get_chars must return 0 before we can be sure the
driver will kick or poll input again, but this patch only scheduled a
poll if get_chars had returned a full count. Change this to poll on
> 0 count.
Fixes: ec97eaad1383 ("tty: hvc: hvc_poll() break hv read loop")
Reported-by: Matteo Croce
Signed-off-by: Nicholas Piggin
---
drivers/tty/hvc/hvc_console.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c
b/drivers/tty/hvc/hvc_console.c index 5414c4a87bea..219369aebb1f 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -717,10 +717,13 @@ static int __hvc_poll(struct hvc_struct *hp, bool
may_sleep) #endif /* CONFIG_MAGIC_SYSRQ */
tty_insert_flip_char(>port, buf[i], 0);
}
- if (n == count)
- poll_mask |= HVC_POLL_READ;
read_total = n;
+ /* Activity is occurring, so reset the polling backoff value to
+ a minimum for performance. */
+ timeout = MIN_TIMEOUT;
+ poll_mask |= HVC_POLL_READ;
+
out:
/* Wakeup write queue if necessary */
if (hp->do_wakeup) {
@@ -730,13 +733,8 @@ static int __hvc_poll(struct hvc_struct *hp, bool
may_sleep) bail:
spin_unlock_irqrestore(>lock, flags);
- if (read_total) {
- /* Activity is occurring, so reset the polling backoff
value to
- a minimum for performance. */
- timeout = MIN_TIMEOUT;
-
+ if (read_total)
tty_flip_buffer_push(>port);
- }
tty_kref_put(tty);
return poll_mask;
--
2.18.0
Re: VirtIO console hangs
On Tue, 28 Aug 2018 15:00:14 +
Matteo Croce wrote:
> On Tue, Aug 28, 2018 at 2:35 PM Nicholas Piggin wrote:
> >
> > On Tue, 28 Aug 2018 12:54:08 +
> > Matteo Croce wrote:
> >
> > > With kernel 4.19.0-rc1 virtio_console hangs very often.
> > > I can always trigger the bug by pasting some characters in the
> > > terminal window, the console will stop receiving keypresses, but I can
> > > still see output from the console.
> > > Stangely, logging in the VM via SSH and sending lot of data to hvc0,
> > > like 'dmesg >/dev/hvc0' will fix the issue until the next paste.
> > >
> > > I did a git bisect and I've found that this is the offending commit,
> > > reverting it fixes it.
> > >
> > > Cheers,
> > >
> > > commit ec97eaad1383ab2500fcf9a07ade6044fbcc67f5
> > > Author: Nicholas Piggin
> > > Date: Tue May 1 00:55:54 2018 +1000
> > >
> > > tty: hvc: hvc_poll() break hv read loop
> >
> > Thanks for the report. I can't immediately see what the problem
> > is. Can you try get a stack trace of where it is stuck?
> >
>
> I tried but didn't get one.
>
> > Perhaps try this patch if you have time (it's a bit of a shot
> > in the dark).
> >
>
> Yes it seems to fix. Thanks!
Okay sorry for the delay, I can reproduce it here and found a better
fix, if I could trouble you to test again.
[PATCH] tty: hvc: hvc_poll() fix read loop hang
Patch ec97eaad1383 ("tty: hvc: hvc_poll() break hv read loop") causes
the virtio console to hang if you paste a bunch of characters to it.
The reason is that get_chars must return 0 before we can be sure the
driver will kick or poll input again, but this patch only scheduled a
poll if get_chars had returned a full count. Change this to poll on
> 0 count.
Fixes: ec97eaad1383 ("tty: hvc: hvc_poll() break hv read loop")
Reported-by: Matteo Croce
Signed-off-by: Nicholas Piggin
---
drivers/tty/hvc/hvc_console.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c
b/drivers/tty/hvc/hvc_console.c index 5414c4a87bea..219369aebb1f 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -717,10 +717,13 @@ static int __hvc_poll(struct hvc_struct *hp, bool
may_sleep) #endif /* CONFIG_MAGIC_SYSRQ */
tty_insert_flip_char(>port, buf[i], 0);
}
- if (n == count)
- poll_mask |= HVC_POLL_READ;
read_total = n;
+ /* Activity is occurring, so reset the polling backoff value to
+ a minimum for performance. */
+ timeout = MIN_TIMEOUT;
+ poll_mask |= HVC_POLL_READ;
+
out:
/* Wakeup write queue if necessary */
if (hp->do_wakeup) {
@@ -730,13 +733,8 @@ static int __hvc_poll(struct hvc_struct *hp, bool
may_sleep) bail:
spin_unlock_irqrestore(>lock, flags);
- if (read_total) {
- /* Activity is occurring, so reset the polling backoff
value to
- a minimum for performance. */
- timeout = MIN_TIMEOUT;
-
+ if (read_total)
tty_flip_buffer_push(>port);
- }
tty_kref_put(tty);
return poll_mask;
--
2.18.0
linux-next: Signed-off-by missing for commit in the arc-current tree
Hi Vineet,
Commit
c0a7bc6e5585 ("ARC: atomics: unbork atomic_fetch_##op()")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp8axos1HTI4.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/2] ARM: dts: socfpga: Add support for PMU on Arria5/Cyclone5
On 03/08/2017 04:19 PM, Dinh Nguyen wrote: > > > On 02/28/2017 09:52 AM, Florian Vaussard wrote: >> Hi, >> >> These patches add suport for ARM Performance Monitor Units on Arria5 and >> Cyclone5 SoCFPGA. This was tested on a Cyclone 5 SoC DK board. >> >> Side note: the same change can be probably applied to Arria10 as well, >> but we do not have the hardware here to test. >> >> Regards, >> Florian >> >> Florian Vaussard (2): >> ARM: dts: socfpga: Add labels for CPU nodes >> ARM: dts: socfpga: Add support for PMU >> >> arch/arm/boot/dts/socfpga.dtsi | 13 +++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> > > Applied! I have to wonder how this was tested. I tried this on 4.14.y, but when I do "perf record -e cycles", I get no samples. Moreover, when I check the PMU interrupts, "grep pmu /proc/interrupts", it shows 0 interrupts from the ARM PMU all the time. Why am I not getting any PMU interrupts when using perf ? -- Best regards, Marek Vasut
linux-next: Signed-off-by missing for commit in the arc-current tree
Hi Vineet,
Commit
c0a7bc6e5585 ("ARC: atomics: unbork atomic_fetch_##op()")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp8axos1HTI4.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/2] ARM: dts: socfpga: Add support for PMU on Arria5/Cyclone5
On 03/08/2017 04:19 PM, Dinh Nguyen wrote: > > > On 02/28/2017 09:52 AM, Florian Vaussard wrote: >> Hi, >> >> These patches add suport for ARM Performance Monitor Units on Arria5 and >> Cyclone5 SoCFPGA. This was tested on a Cyclone 5 SoC DK board. >> >> Side note: the same change can be probably applied to Arria10 as well, >> but we do not have the hardware here to test. >> >> Regards, >> Florian >> >> Florian Vaussard (2): >> ARM: dts: socfpga: Add labels for CPU nodes >> ARM: dts: socfpga: Add support for PMU >> >> arch/arm/boot/dts/socfpga.dtsi | 13 +++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> > > Applied! I have to wonder how this was tested. I tried this on 4.14.y, but when I do "perf record -e cycles", I get no samples. Moreover, when I check the PMU interrupts, "grep pmu /proc/interrupts", it shows 0 interrupts from the ARM PMU all the time. Why am I not getting any PMU interrupts when using perf ? -- Best regards, Marek Vasut
Re: [PATCH] remoteproc: qcom: Rename Hexagon v5 PAS driver
On Wed 29 Aug 02:25 PDT 2018, Niklas Cassel wrote:
> On Mon, Aug 27, 2018 at 10:12:03PM -0700, Bjorn Andersson wrote:
> > The Hexagon v5 ADSP driver is used for more than only the ADSP and
> > there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to
> > qcom_q6v5_pas in order to better suite this.
>
> Hello Bjorn,
>
> so I'm a bit new to this, but after your rename we will have:
>
> QCOM_Q6V5_PIL
> and
> QCOM_Q6V5_PAS
>
> that both are PILs.
> I guess that the difference is that the latter uses TrustZone?
>
> The ADSP for some QCOM SoCs is a Hexagon v5, therefore the
> QCOM_Q6V5_PAS can also boot certain ADSPs?
>
> But we also have QCOM_Q6V5_WCSS
> "Qualcomm Hexagon based WCSS Peripheral Image Loader",
> which also appears to be Hexagon v5 based, but I assume that
> neither QCOM_Q6V5_PIL nor QCOM_Q6V5_PAS can boot the WCSS?
>
> There is also an upcoming non-PAS ADSP PIL loader for SDM845,
> but I guess that the ADSP there is not based on Hexagon v5,
> so the QCOM_Q6V5_PIL will not be able to boot it?
>
> This all seems to be quite confusing, perhaps the help texts
> could be improved to mitigate this confusion?
>
You're right, as proposed this is confusing.
The plan is to have QCOM_Q6V5_PAS, which deals with standard Hexagon
peripherals that relies on the PAS service in TrustZone and then rename
QCOM_Q6V5_PIL to QCOM_Q6V5_MSA to denote that this is the remoteproc
driver for the self-authenticating modem.
The QCOM_Q6V5_WCSS then fits into this pattern, of being the non-TZ
based WCSS remoteproc driver.
> >
> > Cc: Rohit kumar
> > Signed-off-by: Bjorn Andersson
> > ---
> > drivers/remoteproc/Kconfig| 22 +--
> > drivers/remoteproc/Makefile | 2 +-
> > .../{qcom_adsp_pil.c => qcom_q6v5_pas.c} | 4 ++--
>
> You should probably also edit the qcom_defconfig:
> arch/arm/configs/qcom_defconfig:CONFIG_QCOM_ADSP_PIL=y
>
Yes, this needs to be done as well. But needs to be done in a separate
patch.
> > 3 files changed, 14 insertions(+), 14 deletions(-)
> > rename drivers/remoteproc/{qcom_adsp_pil.c => qcom_q6v5_pas.c} (98%)
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 052d4dd347f9..c98c0b2a2237 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -84,8 +84,16 @@ config KEYSTONE_REMOTEPROC
> > It's safe to say N here if you're not interested in the Keystone
> > DSPs or just want to use a bare minimum kernel.
> >
> > -config QCOM_ADSP_PIL
> > - tristate "Qualcomm ADSP Peripheral Image Loader"
> > +config QCOM_RPROC_COMMON
> > + tristate
> > +
> > +config QCOM_Q6V5_COMMON
> > + tristate
> > + depends on ARCH_QCOM
> > + depends on QCOM_SMEM
> > +
> > +config QCOM_Q6V5_PAS
> > + tristate "Qualcomm Hexagon v5 Peripheral Authentication Service support"
> > depends on OF && ARCH_QCOM
> > depends on QCOM_SMEM
> > depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> > @@ -98,15 +106,7 @@ config QCOM_ADSP_PIL
> > select QCOM_SCM
> > help
> > Say y here to support the TrustZone based Peripherial Image Loader
>
> Since you are editing this help text, yoy may just as well
> s/Peripherial/Peripheral.
>
Thanks, will do.
Regards,
Bjorn
> Kind regards,
> Niklas
>
> > - for the Qualcomm ADSP remote processors.
> > -
> > -config QCOM_RPROC_COMMON
> > - tristate
> > -
> > -config QCOM_Q6V5_COMMON
> > - tristate
> > - depends on ARCH_QCOM
> > - depends on QCOM_SMEM
> > + for the Qualcomm Hexagon v5 based remote processors.
> >
> > config QCOM_Q6V5_PIL
> > tristate "Qualcomm Hexagon V5 Peripherial Image Loader"
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 03332fa7e2ee..eb86c8ba5a87 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,9 +14,9 @@ obj-$(CONFIG_OMAP_REMOTEPROC) +=
> > omap_remoteproc.o
> > obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
> > obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> > obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
> > -obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
> > obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
> > obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
> > +obj-$(CONFIG_QCOM_Q6V5_PAS)+= qcom_q6v5_pas.o
> > obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
> > obj-$(CONFIG_QCOM_Q6V5_WCSS) += qcom_q6v5_wcss.o
> > obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
> > diff --git a/drivers/remoteproc/qcom_adsp_pil.c
> > b/drivers/remoteproc/qcom_q6v5_pas.c
> > similarity index 98%
> > rename from drivers/remoteproc/qcom_adsp_pil.c
> > rename to drivers/remoteproc/qcom_q6v5_pas.c
> > index d4339a6da616..2478ef3cd519 100644
> > --- a/drivers/remoteproc/qcom_adsp_pil.c
> > +++
Re: [PATCH] remoteproc: qcom: Rename Hexagon v5 PAS driver
On Wed 29 Aug 02:25 PDT 2018, Niklas Cassel wrote:
> On Mon, Aug 27, 2018 at 10:12:03PM -0700, Bjorn Andersson wrote:
> > The Hexagon v5 ADSP driver is used for more than only the ADSP and
> > there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to
> > qcom_q6v5_pas in order to better suite this.
>
> Hello Bjorn,
>
> so I'm a bit new to this, but after your rename we will have:
>
> QCOM_Q6V5_PIL
> and
> QCOM_Q6V5_PAS
>
> that both are PILs.
> I guess that the difference is that the latter uses TrustZone?
>
> The ADSP for some QCOM SoCs is a Hexagon v5, therefore the
> QCOM_Q6V5_PAS can also boot certain ADSPs?
>
> But we also have QCOM_Q6V5_WCSS
> "Qualcomm Hexagon based WCSS Peripheral Image Loader",
> which also appears to be Hexagon v5 based, but I assume that
> neither QCOM_Q6V5_PIL nor QCOM_Q6V5_PAS can boot the WCSS?
>
> There is also an upcoming non-PAS ADSP PIL loader for SDM845,
> but I guess that the ADSP there is not based on Hexagon v5,
> so the QCOM_Q6V5_PIL will not be able to boot it?
>
> This all seems to be quite confusing, perhaps the help texts
> could be improved to mitigate this confusion?
>
You're right, as proposed this is confusing.
The plan is to have QCOM_Q6V5_PAS, which deals with standard Hexagon
peripherals that relies on the PAS service in TrustZone and then rename
QCOM_Q6V5_PIL to QCOM_Q6V5_MSA to denote that this is the remoteproc
driver for the self-authenticating modem.
The QCOM_Q6V5_WCSS then fits into this pattern, of being the non-TZ
based WCSS remoteproc driver.
> >
> > Cc: Rohit kumar
> > Signed-off-by: Bjorn Andersson
> > ---
> > drivers/remoteproc/Kconfig| 22 +--
> > drivers/remoteproc/Makefile | 2 +-
> > .../{qcom_adsp_pil.c => qcom_q6v5_pas.c} | 4 ++--
>
> You should probably also edit the qcom_defconfig:
> arch/arm/configs/qcom_defconfig:CONFIG_QCOM_ADSP_PIL=y
>
Yes, this needs to be done as well. But needs to be done in a separate
patch.
> > 3 files changed, 14 insertions(+), 14 deletions(-)
> > rename drivers/remoteproc/{qcom_adsp_pil.c => qcom_q6v5_pas.c} (98%)
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 052d4dd347f9..c98c0b2a2237 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -84,8 +84,16 @@ config KEYSTONE_REMOTEPROC
> > It's safe to say N here if you're not interested in the Keystone
> > DSPs or just want to use a bare minimum kernel.
> >
> > -config QCOM_ADSP_PIL
> > - tristate "Qualcomm ADSP Peripheral Image Loader"
> > +config QCOM_RPROC_COMMON
> > + tristate
> > +
> > +config QCOM_Q6V5_COMMON
> > + tristate
> > + depends on ARCH_QCOM
> > + depends on QCOM_SMEM
> > +
> > +config QCOM_Q6V5_PAS
> > + tristate "Qualcomm Hexagon v5 Peripheral Authentication Service support"
> > depends on OF && ARCH_QCOM
> > depends on QCOM_SMEM
> > depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> > @@ -98,15 +106,7 @@ config QCOM_ADSP_PIL
> > select QCOM_SCM
> > help
> > Say y here to support the TrustZone based Peripherial Image Loader
>
> Since you are editing this help text, yoy may just as well
> s/Peripherial/Peripheral.
>
Thanks, will do.
Regards,
Bjorn
> Kind regards,
> Niklas
>
> > - for the Qualcomm ADSP remote processors.
> > -
> > -config QCOM_RPROC_COMMON
> > - tristate
> > -
> > -config QCOM_Q6V5_COMMON
> > - tristate
> > - depends on ARCH_QCOM
> > - depends on QCOM_SMEM
> > + for the Qualcomm Hexagon v5 based remote processors.
> >
> > config QCOM_Q6V5_PIL
> > tristate "Qualcomm Hexagon V5 Peripherial Image Loader"
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 03332fa7e2ee..eb86c8ba5a87 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,9 +14,9 @@ obj-$(CONFIG_OMAP_REMOTEPROC) +=
> > omap_remoteproc.o
> > obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
> > obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> > obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
> > -obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
> > obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
> > obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
> > +obj-$(CONFIG_QCOM_Q6V5_PAS)+= qcom_q6v5_pas.o
> > obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
> > obj-$(CONFIG_QCOM_Q6V5_WCSS) += qcom_q6v5_wcss.o
> > obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
> > diff --git a/drivers/remoteproc/qcom_adsp_pil.c
> > b/drivers/remoteproc/qcom_q6v5_pas.c
> > similarity index 98%
> > rename from drivers/remoteproc/qcom_adsp_pil.c
> > rename to drivers/remoteproc/qcom_q6v5_pas.c
> > index d4339a6da616..2478ef3cd519 100644
> > --- a/drivers/remoteproc/qcom_adsp_pil.c
> > +++
Re: [PATCH] x86/pkeys: Explicitly treat PK #PF on kernel address as a bad area
> On Aug 30, 2018, at 7:38 PM, Jann Horn wrote:
>
>> On Tue, 7 Aug 2018 Dave Hansen wrote:
>>
>>> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
>>> if (unlikely(fault_in_kernel_space(address))) {
>>> + /*
>>> + * We should never encounter a protection keys fault on a
>>> + * kernel address as kernel address are always mapped with
>>> + * _PAGE_USER=0, i.e. PKRU isn't enforced.
>>> + */
>>> + if (WARN_ON_ONCE(error_code & X86_PF_PK))
>>> + goto bad_kernel_address;
>>
>> I just realized one more thing: the vsyscall page can bite us here.
>> It's at a fault_in_kernel_space() address and we *can* trigger a pkey
>> fault on it if we jump to an instruction that reads from a
>> pkey-protected area.
>>
>> We can make a gadget out of unaligned vsyscall instructions that does
>> that. See:
>>
>> 0xff62: shlb $0x0,0x0(%rax)
>>
>> Then, we turn off access to all pkeys, including pkey-0, then jump to
>> the unaligned vsyscall instruction, which reads %rax, which is a kernel
>> address:
>
> Andy got rid of the (native) vsyscall page in
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=076ca272a14cea558b1092ec85cea08510283f2a
> ('x86/vsyscall/64: Drop "native" vsyscalls') a few months ago, right?
> At this point, the vsyscall page should never be executable.
Indeed.
Can one of you cc me on the original patch?
Re: [PATCH] x86/pkeys: Explicitly treat PK #PF on kernel address as a bad area
> On Aug 30, 2018, at 7:38 PM, Jann Horn wrote:
>
>> On Tue, 7 Aug 2018 Dave Hansen wrote:
>>
>>> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
>>> if (unlikely(fault_in_kernel_space(address))) {
>>> + /*
>>> + * We should never encounter a protection keys fault on a
>>> + * kernel address as kernel address are always mapped with
>>> + * _PAGE_USER=0, i.e. PKRU isn't enforced.
>>> + */
>>> + if (WARN_ON_ONCE(error_code & X86_PF_PK))
>>> + goto bad_kernel_address;
>>
>> I just realized one more thing: the vsyscall page can bite us here.
>> It's at a fault_in_kernel_space() address and we *can* trigger a pkey
>> fault on it if we jump to an instruction that reads from a
>> pkey-protected area.
>>
>> We can make a gadget out of unaligned vsyscall instructions that does
>> that. See:
>>
>> 0xff62: shlb $0x0,0x0(%rax)
>>
>> Then, we turn off access to all pkeys, including pkey-0, then jump to
>> the unaligned vsyscall instruction, which reads %rax, which is a kernel
>> address:
>
> Andy got rid of the (native) vsyscall page in
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=076ca272a14cea558b1092ec85cea08510283f2a
> ('x86/vsyscall/64: Drop "native" vsyscalls') a few months ago, right?
> At this point, the vsyscall page should never be executable.
Indeed.
Can one of you cc me on the original patch?
linux-next: Tree for Aug 31
Hi all, Changes since 20180830: Dropped trees: xarray, ida (temporarily) Non-merge commits (relative to Linus' tree): 1248 1497 files changed, 48772 insertions(+), 16144 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (fb6463856658 Merge tag 'for-linus-20180830' of git://git.kernel.dk/linux-block) Merging fixes/master (4db250925b08 disable stringop truncation warnings for now) Merging kbuild-current/fixes (ad1d69735878 Merge tag 'fuse-update-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (755a8bf5579d arm/arm64: smccc-1.1: Handle function result as parameters) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (dc6417949297 Merge branch 'net_sched-reject-unknown-tcfa_action-values') Merging bpf/master (dc6417949297 Merge branch 'net_sched-reject-unknown-tcfa_action-values') Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (0434ccdcf883 netfilter: nf_tables: rework ct timeout set support) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging mac80211/master (aa58acf325b4 mac80211: always account for A-MSDU header changes) Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1) Merging sound-current/for-linus (16037643969e ALSA: hda - Fix cancel_work_sync() stall from jackpoll work) Merging sound-asoc-fixes/for-linus (c4305768a542 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (823f18f8b860 regulator: bd71837: Disable voltage monitoring for LDO3/4) Merging spi-fixes/for-linus (9a92a569272a Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1) Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for status lines) Merging staging.current/staging-linus (f86cf25a6091 Revert "staging: erofs: disable compiling temporarile") Mergi
linux-next: Tree for Aug 31
Hi all, Changes since 20180830: Dropped trees: xarray, ida (temporarily) Non-merge commits (relative to Linus' tree): 1248 1497 files changed, 48772 insertions(+), 16144 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (fb6463856658 Merge tag 'for-linus-20180830' of git://git.kernel.dk/linux-block) Merging fixes/master (4db250925b08 disable stringop truncation warnings for now) Merging kbuild-current/fixes (ad1d69735878 Merge tag 'fuse-update-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (755a8bf5579d arm/arm64: smccc-1.1: Handle function result as parameters) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (dc6417949297 Merge branch 'net_sched-reject-unknown-tcfa_action-values') Merging bpf/master (dc6417949297 Merge branch 'net_sched-reject-unknown-tcfa_action-values') Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (0434ccdcf883 netfilter: nf_tables: rework ct timeout set support) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging mac80211/master (aa58acf325b4 mac80211: always account for A-MSDU header changes) Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1) Merging sound-current/for-linus (16037643969e ALSA: hda - Fix cancel_work_sync() stall from jackpoll work) Merging sound-asoc-fixes/for-linus (c4305768a542 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (823f18f8b860 regulator: bd71837: Disable voltage monitoring for LDO3/4) Merging spi-fixes/for-linus (9a92a569272a Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1) Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for status lines) Merging staging.current/staging-linus (f86cf25a6091 Revert "staging: erofs: disable compiling temporarile") Mergi
Re: [PATCH 2/2] mm: zero remaining unavailable struct pages
On Wed, Aug 29, 2018 at 11:16:30AM -0400, Masayoshi Mizuma wrote:
> Hi Horiguchi-san and Pavel
>
> Thank you for your comments!
> The Pavel's additional patch looks good to me, so I will add it to this
> series.
>
> However, unfortunately, the movable_node option has something wrong yet...
> When I offline the memory which belongs to movable zone, I got the following
> warning. I'm trying to debug it.
>
> I try to describe the issue as following.
> If you have any comments, please let me know.
>
> WARNING: CPU: 156 PID: 25611 at mm/page_alloc.c:7730
> has_unmovable_pages+0x1bf/0x200
> RIP: 0010:has_unmovable_pages+0x1bf/0x200
> ...
> Call Trace:
> is_mem_section_removable+0xd3/0x160
> show_mem_removable+0x8e/0xb0
> dev_attr_show+0x1c/0x50
> sysfs_kf_seq_show+0xb3/0x110
> seq_read+0xee/0x480
> __vfs_read+0x36/0x190
> vfs_read+0x89/0x130
> ksys_read+0x52/0xc0
> do_syscall_64+0x5b/0x180
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7fe7b7823f70
> ...
>
> I added a printk to catch the unmovable page.
> ---
> @@ -7713,8 +7719,12 @@ bool has_unmovable_pages(struct zone *zone, struct
> page *page, int count,
> * is set to both of a memory hole page and a _used_ kernel
> * page at boot.
> */
> - if (found > count)
> + if (found > count) {
> + pr_info("DEBUG: %s zone: %lx page: %lx pfn: %lx
> flags: %lx found: %ld count: %ld \n",
> + __func__, zone, page, page_to_pfn(page),
> page->flags, found, count);
> goto unmovable;
> + }
> ---
>
> Then I got the following. The page (PFN: 0x1c0ff130d) flag is
> 0xdfc0040048 (uptodate|active|swapbacked)
>
> ---
> DEBUG: has_unmovable_pages zone: 0x8c080380 page: 0xea703fc4c340
> pfn: 0x1c0ff130d flags: 0xdfc0040048 found: 1 count: 0
> ---
>
> And I got the owner from /sys/kernel/debug/page_owner.
>
> Page allocated via order 0, mask 0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO)
> PFN 7532909325 type Movable Block 14712713 type Movable Flags
> 0xdfc0040048(uptodate|active|swapbacked)
> __alloc_pages_nodemask+0xfc/0x270
> alloc_pages_vma+0x7c/0x1e0
> handle_pte_fault+0x399/0xe50
> __handle_mm_fault+0x38e/0x520
> handle_mm_fault+0xdc/0x210
> __do_page_fault+0x243/0x4c0
> do_page_fault+0x31/0x130
> page_fault+0x1e/0x30
>
> The page is allocated as anonymous page via page fault.
> I'm not sure, but lru flag should be added to the page...?
There is a small window of no PageLRU flag just after page allocation
until the page is linked to some LRU list.
This kind of unmovability is transient, so retrying can work.
I guess that this warning seems to be visible since commit 15c30bc09085
("mm, memory_hotplug: make has_unmovable_pages more robust")
which turned off the optimization based on the assumption that pages
under ZONE_MOVABLE are always movable.
I think that it helps developers find the issue that permanently
unmovable pages are accidentally located in ZONE_MOVABLE zone.
But even ZONE_MOVABLE zone could have transiently unmovable pages,
so the reported warning seems to me a false charge and should be avoided.
Doing lru_add_drain_all()/drain_all_pages() before has_unmovable_pages()
might be helpful?
Thanks,
Naoya Horiguchi
Re: [PATCH 2/2] mm: zero remaining unavailable struct pages
On Wed, Aug 29, 2018 at 11:16:30AM -0400, Masayoshi Mizuma wrote:
> Hi Horiguchi-san and Pavel
>
> Thank you for your comments!
> The Pavel's additional patch looks good to me, so I will add it to this
> series.
>
> However, unfortunately, the movable_node option has something wrong yet...
> When I offline the memory which belongs to movable zone, I got the following
> warning. I'm trying to debug it.
>
> I try to describe the issue as following.
> If you have any comments, please let me know.
>
> WARNING: CPU: 156 PID: 25611 at mm/page_alloc.c:7730
> has_unmovable_pages+0x1bf/0x200
> RIP: 0010:has_unmovable_pages+0x1bf/0x200
> ...
> Call Trace:
> is_mem_section_removable+0xd3/0x160
> show_mem_removable+0x8e/0xb0
> dev_attr_show+0x1c/0x50
> sysfs_kf_seq_show+0xb3/0x110
> seq_read+0xee/0x480
> __vfs_read+0x36/0x190
> vfs_read+0x89/0x130
> ksys_read+0x52/0xc0
> do_syscall_64+0x5b/0x180
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7fe7b7823f70
> ...
>
> I added a printk to catch the unmovable page.
> ---
> @@ -7713,8 +7719,12 @@ bool has_unmovable_pages(struct zone *zone, struct
> page *page, int count,
> * is set to both of a memory hole page and a _used_ kernel
> * page at boot.
> */
> - if (found > count)
> + if (found > count) {
> + pr_info("DEBUG: %s zone: %lx page: %lx pfn: %lx
> flags: %lx found: %ld count: %ld \n",
> + __func__, zone, page, page_to_pfn(page),
> page->flags, found, count);
> goto unmovable;
> + }
> ---
>
> Then I got the following. The page (PFN: 0x1c0ff130d) flag is
> 0xdfc0040048 (uptodate|active|swapbacked)
>
> ---
> DEBUG: has_unmovable_pages zone: 0x8c080380 page: 0xea703fc4c340
> pfn: 0x1c0ff130d flags: 0xdfc0040048 found: 1 count: 0
> ---
>
> And I got the owner from /sys/kernel/debug/page_owner.
>
> Page allocated via order 0, mask 0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO)
> PFN 7532909325 type Movable Block 14712713 type Movable Flags
> 0xdfc0040048(uptodate|active|swapbacked)
> __alloc_pages_nodemask+0xfc/0x270
> alloc_pages_vma+0x7c/0x1e0
> handle_pte_fault+0x399/0xe50
> __handle_mm_fault+0x38e/0x520
> handle_mm_fault+0xdc/0x210
> __do_page_fault+0x243/0x4c0
> do_page_fault+0x31/0x130
> page_fault+0x1e/0x30
>
> The page is allocated as anonymous page via page fault.
> I'm not sure, but lru flag should be added to the page...?
There is a small window of no PageLRU flag just after page allocation
until the page is linked to some LRU list.
This kind of unmovability is transient, so retrying can work.
I guess that this warning seems to be visible since commit 15c30bc09085
("mm, memory_hotplug: make has_unmovable_pages more robust")
which turned off the optimization based on the assumption that pages
under ZONE_MOVABLE are always movable.
I think that it helps developers find the issue that permanently
unmovable pages are accidentally located in ZONE_MOVABLE zone.
But even ZONE_MOVABLE zone could have transiently unmovable pages,
so the reported warning seems to me a false charge and should be avoided.
Doing lru_add_drain_all()/drain_all_pages() before has_unmovable_pages()
might be helpful?
Thanks,
Naoya Horiguchi
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 217c3e0196758662aa0429863b09d1c13da1c5d6 commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from HOSTCC date: 3 months ago config: alpha-allmodconfig (attached as .config) compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 819dd92b9c0bc7bce9097d8c1f14240f471bb386 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=alpha All errors (new ones prefixed by >>): In file included from tools/include/uapi/asm/bitsperlong.h:17:0, from /usr/alpha-linux-gnu/include/asm-generic/int-l64.h:11, from /usr/alpha-linux-gnu/include/asm/types.h:12, from tools/include/linux/types.h:10, from ./include/uapi/linux/bpf.h:11, from net//bpfilter/main.c:9: >> tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent >> word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ vim +14 tools/include/asm-generic/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 12 2a00f026 Arnaldo Carvalho de Melo 2016-07-13 13 #if BITS_PER_LONG != __BITS_PER_LONG bb970707 Arnaldo Carvalho de Melo 2016-07-12 @14 #error Inconsistent word size. Check asm/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 15 #endif bb970707 Arnaldo Carvalho de Melo 2016-07-12 16 :: The code at line 14 was first introduced by commit :: bb9707077b4ee5f77bc9939b057ff8a0d410296f tools: Copy the bitsperlong.h files from the kernel :: TO: Arnaldo Carvalho de Melo :: CC: Arnaldo Carvalho de Melo --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 217c3e0196758662aa0429863b09d1c13da1c5d6 commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from HOSTCC date: 3 months ago config: alpha-allmodconfig (attached as .config) compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 819dd92b9c0bc7bce9097d8c1f14240f471bb386 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=alpha All errors (new ones prefixed by >>): In file included from tools/include/uapi/asm/bitsperlong.h:17:0, from /usr/alpha-linux-gnu/include/asm-generic/int-l64.h:11, from /usr/alpha-linux-gnu/include/asm/types.h:12, from tools/include/linux/types.h:10, from ./include/uapi/linux/bpf.h:11, from net//bpfilter/main.c:9: >> tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent >> word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ vim +14 tools/include/asm-generic/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 12 2a00f026 Arnaldo Carvalho de Melo 2016-07-13 13 #if BITS_PER_LONG != __BITS_PER_LONG bb970707 Arnaldo Carvalho de Melo 2016-07-12 @14 #error Inconsistent word size. Check asm/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 15 #endif bb970707 Arnaldo Carvalho de Melo 2016-07-12 16 :: The code at line 14 was first introduced by commit :: bb9707077b4ee5f77bc9939b057ff8a0d410296f tools: Copy the bitsperlong.h files from the kernel :: TO: Arnaldo Carvalho de Melo :: CC: Arnaldo Carvalho de Melo --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] x86/pkeys: Explicitly treat PK #PF on kernel address as a bad area
On Tue, 7 Aug 2018 Dave Hansen wrote:
>
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > + * We should never encounter a protection keys fault on a
> > + * kernel address as kernel address are always mapped with
> > + * _PAGE_USER=0, i.e. PKRU isn't enforced.
> > + */
> > + if (WARN_ON_ONCE(error_code & X86_PF_PK))
> > + goto bad_kernel_address;
>
> I just realized one more thing: the vsyscall page can bite us here.
> It's at a fault_in_kernel_space() address and we *can* trigger a pkey
> fault on it if we jump to an instruction that reads from a
> pkey-protected area.
>
> We can make a gadget out of unaligned vsyscall instructions that does
> that. See:
>
> 0xff62: shlb $0x0,0x0(%rax)
>
> Then, we turn off access to all pkeys, including pkey-0, then jump to
> the unaligned vsyscall instruction, which reads %rax, which is a kernel
> address:
Andy got rid of the (native) vsyscall page in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=076ca272a14cea558b1092ec85cea08510283f2a
('x86/vsyscall/64: Drop "native" vsyscalls') a few months ago, right?
At this point, the vsyscall page should never be executable.
Re: [PATCH] x86/pkeys: Explicitly treat PK #PF on kernel address as a bad area
On Tue, 7 Aug 2018 Dave Hansen wrote:
>
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > + * We should never encounter a protection keys fault on a
> > + * kernel address as kernel address are always mapped with
> > + * _PAGE_USER=0, i.e. PKRU isn't enforced.
> > + */
> > + if (WARN_ON_ONCE(error_code & X86_PF_PK))
> > + goto bad_kernel_address;
>
> I just realized one more thing: the vsyscall page can bite us here.
> It's at a fault_in_kernel_space() address and we *can* trigger a pkey
> fault on it if we jump to an instruction that reads from a
> pkey-protected area.
>
> We can make a gadget out of unaligned vsyscall instructions that does
> that. See:
>
> 0xff62: shlb $0x0,0x0(%rax)
>
> Then, we turn off access to all pkeys, including pkey-0, then jump to
> the unaligned vsyscall instruction, which reads %rax, which is a kernel
> address:
Andy got rid of the (native) vsyscall page in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=076ca272a14cea558b1092ec85cea08510283f2a
('x86/vsyscall/64: Drop "native" vsyscalls') a few months ago, right?
At this point, the vsyscall page should never be executable.
import from China/safe transport & good price
Dear Sir: Good day Simon greeting from Everbright international logistics co.,ltd,and we specialize in overseas international logistics for 15 years,our major core business scope cover: International sea freight International air freight International courier service Local logistics service such as trucking,customs clearance ,warehousing,consolidation service We can give you quotation directly for your shipment under ex-work,fob,ddu,and ddp terms,and this can reduce a lot of logistics cost between your and your shipper in china ,and also updated you the situation of your shipment quickly Should you have any interest,all the certificates and profile of our company will be sent to you for checking,and also you can advise your inquiry,latest rate will be updated to you weekly We may have no time,but we will make it We may have no answer,but we will find it we may be not the best,but we are the most commited to your success We carry,we care Everbright International Logistics Co., Ltd. Room 621, Yide Block B, Maoyecheng, Longgang district, Shenzhen, China Tel/ Fax: 0086-755-28758565 Mobile: 0086-18665946255 Email: sale...@szeverbright.com WhatsApp: 0086-18665946255
import from China/safe transport & good price
Dear Sir: Good day Simon greeting from Everbright international logistics co.,ltd,and we specialize in overseas international logistics for 15 years,our major core business scope cover: International sea freight International air freight International courier service Local logistics service such as trucking,customs clearance ,warehousing,consolidation service We can give you quotation directly for your shipment under ex-work,fob,ddu,and ddp terms,and this can reduce a lot of logistics cost between your and your shipper in china ,and also updated you the situation of your shipment quickly Should you have any interest,all the certificates and profile of our company will be sent to you for checking,and also you can advise your inquiry,latest rate will be updated to you weekly We may have no time,but we will make it We may have no answer,but we will find it we may be not the best,but we are the most commited to your success We carry,we care Everbright International Logistics Co., Ltd. Room 621, Yide Block B, Maoyecheng, Longgang district, Shenzhen, China Tel/ Fax: 0086-755-28758565 Mobile: 0086-18665946255 Email: sale...@szeverbright.com WhatsApp: 0086-18665946255
Re: [PATCH tip/core/rcu 01/19] rcu: Refactor rcu_{nmi,irq}_{enter,exit}()
On Thu, Aug 30, 2018 at 02:10:32PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 15:20:29 -0700
> "Paul E. McKenney" wrote:
>
> > This commit also changes order of execution from this:
> >
> > rcu_dynticks_task_exit();
> > rcu_dynticks_eqs_exit();
> > trace_rcu_dyntick();
> > rcu_cleanup_after_idle();
> >
> > To this:
> >
> > rcu_dynticks_task_exit();
> > rcu_dynticks_eqs_exit();
> > rcu_cleanup_after_idle();
> > trace_rcu_dyntick();
> >
> > In other words, the calls to trace_rcu_dyntick() and trace_rcu_dyntick()
>
> How is trace_rcu_dyntick() and trace_rcu_dyntick reversed ? ;-)
>
> > are reversed. This has no functional effect because the real
> > concern is whether a given call is before or after the call to
> > rcu_dynticks_eqs_exit(), and this patch does not change that. Before the
> > call to rcu_dynticks_eqs_exit(), RCU is not yet watching the current
> > CPU and after that call RCU is watching.
> >
> > A similar switch in calling order happens on the idle-entry path, with
> > similar lack of effect for the same reasons.
> >
> > Suggested-by: Paul E. McKenney
> > Signed-off-by: Byungchul Park
> > Signed-off-by: Paul E. McKenney
> > ---
> > kernel/rcu/tree.c | 61 +++
> > 1 file changed, 41 insertions(+), 20 deletions(-)
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 0b760c1369f7..0adf77923e8b 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -771,17 +771,18 @@ void rcu_user_enter(void)
> > #endif /* CONFIG_NO_HZ_FULL */
> >
> > /**
> > - * rcu_nmi_exit - inform RCU of exit from NMI context
> > + * rcu_nmi_exit_common - inform RCU of exit from NMI context
> > + * @irq: Is this call from rcu_irq_exit?
> > *
> > * If we are returning from the outermost NMI handler that interrupted an
> > * RCU-idle period, update rdtp->dynticks and rdtp->dynticks_nmi_nesting
> > * to let the RCU grace-period handling know that the CPU is back to
> > * being RCU-idle.
> > *
> > - * If you add or remove a call to rcu_nmi_exit(), be sure to test
> > + * If you add or remove a call to rcu_nmi_exit_common(), be sure to test
> > * with CONFIG_RCU_EQS_DEBUG=y.
>
> As this is a static function, this description doesn't make sense. You
> need to move the description down to the new rcu_nmi_exit() below.
Right.. I should've done that.
Thanks you Steve.
Byungchul
> Other than that...
>
> Reviewed-by: Steven Rostedt (VMware)
>
> -- Steve
>
>
> > */
> > -void rcu_nmi_exit(void)
> > +static __always_inline void rcu_nmi_exit_common(bool irq)
> > {
> > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> >
> > @@ -807,7 +808,22 @@ void rcu_nmi_exit(void)
> > /* This NMI interrupted an RCU-idle CPU, restore RCU-idleness. */
> > trace_rcu_dyntick(TPS("Startirq"), rdtp->dynticks_nmi_nesting, 0,
> > rdtp->dynticks);
> > WRITE_ONCE(rdtp->dynticks_nmi_nesting, 0); /* Avoid store tearing. */
> > +
> > + if (irq)
> > + rcu_prepare_for_idle();
> > +
> > rcu_dynticks_eqs_enter();
> > +
> > + if (irq)
> > + rcu_dynticks_task_enter();
> > +}
> > +
> > +/**
> > + * rcu_nmi_exit - inform RCU of exit from NMI context
> > + */
> > +void rcu_nmi_exit(void)
> > +{
> > + rcu_nmi_exit_common(false);
> > }
> >
> > /**
> > @@ -831,14 +847,8 @@ void rcu_nmi_exit(void)
> > */
> > void rcu_irq_exit(void)
> > {
> > - struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > -
> > lockdep_assert_irqs_disabled();
> > - if (rdtp->dynticks_nmi_nesting == 1)
> > - rcu_prepare_for_idle();
> > - rcu_nmi_exit();
> > - if (rdtp->dynticks_nmi_nesting == 0)
> > - rcu_dynticks_task_enter();
> > + rcu_nmi_exit_common(true);
> > }
> >
> > /*
> > @@ -921,7 +931,8 @@ void rcu_user_exit(void)
> > #endif /* CONFIG_NO_HZ_FULL */
> >
> > /**
> > - * rcu_nmi_enter - inform RCU of entry to NMI context
> > + * rcu_nmi_enter_common - inform RCU of entry to NMI context
> > + * @irq: Is this call from rcu_irq_enter?
> > *
> > * If the CPU was idle from RCU's viewpoint, update rdtp->dynticks and
> > * rdtp->dynticks_nmi_nesting to let the RCU grace-period handling know
> > @@ -929,10 +940,10 @@ void rcu_user_exit(void)
> > * long as the nesting level does not overflow an int. (You will probably
> > * run out of stack space first.)
> > *
> > - * If you add or remove a call to rcu_nmi_enter(), be sure to test
> > + * If you add or remove a call to rcu_nmi_enter_common(), be sure to test
> > * with CONFIG_RCU_EQS_DEBUG=y.
> > */
> > -void rcu_nmi_enter(void)
> > +static __always_inline void rcu_nmi_enter_common(bool irq)
> > {
> > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > long incby = 2;
> > @@ -949,7 +960,15 @@ void rcu_nmi_enter(void)
> > * period (observation due to Andy Lutomirski).
> > */
> > if (rcu_dynticks_curr_cpu_in_eqs()) {
> > +
> > + if (irq)
> >
Re: [PATCH tip/core/rcu 01/19] rcu: Refactor rcu_{nmi,irq}_{enter,exit}()
On Thu, Aug 30, 2018 at 02:10:32PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 15:20:29 -0700
> "Paul E. McKenney" wrote:
>
> > This commit also changes order of execution from this:
> >
> > rcu_dynticks_task_exit();
> > rcu_dynticks_eqs_exit();
> > trace_rcu_dyntick();
> > rcu_cleanup_after_idle();
> >
> > To this:
> >
> > rcu_dynticks_task_exit();
> > rcu_dynticks_eqs_exit();
> > rcu_cleanup_after_idle();
> > trace_rcu_dyntick();
> >
> > In other words, the calls to trace_rcu_dyntick() and trace_rcu_dyntick()
>
> How is trace_rcu_dyntick() and trace_rcu_dyntick reversed ? ;-)
>
> > are reversed. This has no functional effect because the real
> > concern is whether a given call is before or after the call to
> > rcu_dynticks_eqs_exit(), and this patch does not change that. Before the
> > call to rcu_dynticks_eqs_exit(), RCU is not yet watching the current
> > CPU and after that call RCU is watching.
> >
> > A similar switch in calling order happens on the idle-entry path, with
> > similar lack of effect for the same reasons.
> >
> > Suggested-by: Paul E. McKenney
> > Signed-off-by: Byungchul Park
> > Signed-off-by: Paul E. McKenney
> > ---
> > kernel/rcu/tree.c | 61 +++
> > 1 file changed, 41 insertions(+), 20 deletions(-)
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 0b760c1369f7..0adf77923e8b 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -771,17 +771,18 @@ void rcu_user_enter(void)
> > #endif /* CONFIG_NO_HZ_FULL */
> >
> > /**
> > - * rcu_nmi_exit - inform RCU of exit from NMI context
> > + * rcu_nmi_exit_common - inform RCU of exit from NMI context
> > + * @irq: Is this call from rcu_irq_exit?
> > *
> > * If we are returning from the outermost NMI handler that interrupted an
> > * RCU-idle period, update rdtp->dynticks and rdtp->dynticks_nmi_nesting
> > * to let the RCU grace-period handling know that the CPU is back to
> > * being RCU-idle.
> > *
> > - * If you add or remove a call to rcu_nmi_exit(), be sure to test
> > + * If you add or remove a call to rcu_nmi_exit_common(), be sure to test
> > * with CONFIG_RCU_EQS_DEBUG=y.
>
> As this is a static function, this description doesn't make sense. You
> need to move the description down to the new rcu_nmi_exit() below.
Right.. I should've done that.
Thanks you Steve.
Byungchul
> Other than that...
>
> Reviewed-by: Steven Rostedt (VMware)
>
> -- Steve
>
>
> > */
> > -void rcu_nmi_exit(void)
> > +static __always_inline void rcu_nmi_exit_common(bool irq)
> > {
> > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> >
> > @@ -807,7 +808,22 @@ void rcu_nmi_exit(void)
> > /* This NMI interrupted an RCU-idle CPU, restore RCU-idleness. */
> > trace_rcu_dyntick(TPS("Startirq"), rdtp->dynticks_nmi_nesting, 0,
> > rdtp->dynticks);
> > WRITE_ONCE(rdtp->dynticks_nmi_nesting, 0); /* Avoid store tearing. */
> > +
> > + if (irq)
> > + rcu_prepare_for_idle();
> > +
> > rcu_dynticks_eqs_enter();
> > +
> > + if (irq)
> > + rcu_dynticks_task_enter();
> > +}
> > +
> > +/**
> > + * rcu_nmi_exit - inform RCU of exit from NMI context
> > + */
> > +void rcu_nmi_exit(void)
> > +{
> > + rcu_nmi_exit_common(false);
> > }
> >
> > /**
> > @@ -831,14 +847,8 @@ void rcu_nmi_exit(void)
> > */
> > void rcu_irq_exit(void)
> > {
> > - struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > -
> > lockdep_assert_irqs_disabled();
> > - if (rdtp->dynticks_nmi_nesting == 1)
> > - rcu_prepare_for_idle();
> > - rcu_nmi_exit();
> > - if (rdtp->dynticks_nmi_nesting == 0)
> > - rcu_dynticks_task_enter();
> > + rcu_nmi_exit_common(true);
> > }
> >
> > /*
> > @@ -921,7 +931,8 @@ void rcu_user_exit(void)
> > #endif /* CONFIG_NO_HZ_FULL */
> >
> > /**
> > - * rcu_nmi_enter - inform RCU of entry to NMI context
> > + * rcu_nmi_enter_common - inform RCU of entry to NMI context
> > + * @irq: Is this call from rcu_irq_enter?
> > *
> > * If the CPU was idle from RCU's viewpoint, update rdtp->dynticks and
> > * rdtp->dynticks_nmi_nesting to let the RCU grace-period handling know
> > @@ -929,10 +940,10 @@ void rcu_user_exit(void)
> > * long as the nesting level does not overflow an int. (You will probably
> > * run out of stack space first.)
> > *
> > - * If you add or remove a call to rcu_nmi_enter(), be sure to test
> > + * If you add or remove a call to rcu_nmi_enter_common(), be sure to test
> > * with CONFIG_RCU_EQS_DEBUG=y.
> > */
> > -void rcu_nmi_enter(void)
> > +static __always_inline void rcu_nmi_enter_common(bool irq)
> > {
> > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > long incby = 2;
> > @@ -949,7 +960,15 @@ void rcu_nmi_enter(void)
> > * period (observation due to Andy Lutomirski).
> > */
> > if (rcu_dynticks_curr_cpu_in_eqs()) {
> > +
> > + if (irq)
> >
Re: [PATCH 20/23] mm: percpu: remove unnecessary unlikely()
On Fri, Aug 31, 2018 at 01:34:26AM +0300, Igor Stoppa wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to
> wrap it into another.
>
> Signed-off-by: Igor Stoppa
> Cc: zijun_hu
> Cc: Tejun Heo
> Cc: Christoph Lameter
> Cc: Dennis Zhou
> ---
> mm/percpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index a749d4d96e3e..f5c2796fe63e 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2588,7 +2588,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size,
> BUG_ON(ai->nr_groups != 1);
> upa = ai->alloc_size/ai->unit_size;
> nr_g0_units = roundup(num_possible_cpus(), upa);
> - if (unlikely(WARN_ON(ai->groups[0].nr_units != nr_g0_units))) {
> + if (WARN_ON(ai->groups[0].nr_units != nr_g0_units)) {
> pcpu_free_alloc_info(ai);
> return -EINVAL;
> }
> --
> 2.17.1
>
Acked-by: Dennis Zhou
Thanks,
Dennis
Re: [PATCH 20/23] mm: percpu: remove unnecessary unlikely()
On Fri, Aug 31, 2018 at 01:34:26AM +0300, Igor Stoppa wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to
> wrap it into another.
>
> Signed-off-by: Igor Stoppa
> Cc: zijun_hu
> Cc: Tejun Heo
> Cc: Christoph Lameter
> Cc: Dennis Zhou
> ---
> mm/percpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index a749d4d96e3e..f5c2796fe63e 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2588,7 +2588,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size,
> BUG_ON(ai->nr_groups != 1);
> upa = ai->alloc_size/ai->unit_size;
> nr_g0_units = roundup(num_possible_cpus(), upa);
> - if (unlikely(WARN_ON(ai->groups[0].nr_units != nr_g0_units))) {
> + if (WARN_ON(ai->groups[0].nr_units != nr_g0_units)) {
> pcpu_free_alloc_info(ai);
> return -EINVAL;
> }
> --
> 2.17.1
>
Acked-by: Dennis Zhou
Thanks,
Dennis
Re: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault
On Thu, Aug 30, 2018 at 6:30 PM Linus Torvalds wrote: > > On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote: > > > > Fix is to move one step at a time. First mark the page not present > > (using the decoy address). Then it is safe to use the actual address > > of the 1:1 mapping to mark it "uc", and finally as present. > > Can't we do it in one step, but make sure that he clflush gets the real > address? > I'd like to, but I'd need to have a way to mark the address as needing fixing as it gets passed from set_memory_uc() to _set_memory_uc() to change_page_attr_set() to change_page_attr_set_clear() Just checking "do we have a non-canonical address" at the bottom of that call stack and flipping bit 63 back on again seems like a bad idea. But adding extra flag arguments is majorly ugly too. -Tony
Re: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault
On Thu, Aug 30, 2018 at 6:30 PM Linus Torvalds wrote: > > On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote: > > > > Fix is to move one step at a time. First mark the page not present > > (using the decoy address). Then it is safe to use the actual address > > of the 1:1 mapping to mark it "uc", and finally as present. > > Can't we do it in one step, but make sure that he clflush gets the real > address? > I'd like to, but I'd need to have a way to mark the address as needing fixing as it gets passed from set_memory_uc() to _set_memory_uc() to change_page_attr_set() to change_page_attr_set_clear() Just checking "do we have a non-canonical address" at the bottom of that call stack and flipping bit 63 back on again seems like a bad idea. But adding extra flag arguments is majorly ugly too. -Tony
Re: [PATCH v2 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller
On 2018/8/30 21:59, Rob Herring wrote: > On Thu, Aug 30, 2018 at 2:37 AM Hanjie Lin wrote: >> >> >> >> On 2018/8/29 8:41, Rob Herring wrote: >>> On Mon, Aug 27, 2018 at 04:55:20PM +0800, Hanjie Lin wrote: On 2018/8/24 16:22, Jerome Brunet wrote: > On Fri, 2018-08-24 at 15:36 +0800, Hanjie Lin wrote: >> From: Yue Wang >> >> The Amlogic Meson PCIe host controller is based on the Synopsys >> DesignWare >> PCI core. This patch adds documentation for the DT bindings in Meson PCIe >> controller. >> >> Signed-off-by: Yue Wang >> Signed-off-by: Hanjie Lin >> --- >> .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 63 >> ++ >> 1 file changed, 63 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> >> diff --git >> a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> new file mode 100644 >> index 000..8a831d1 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> @@ -0,0 +1,63 @@ >> +Amlogic Meson AXG DWC PCIE SoC controller >> + >> +Amlogic Meson PCIe host controller is based on the Synopsys DesignWare >> PCI core. >> +It shares common functions with the PCIe DesignWare core driver and >> +inherits common properties defined in >> +Documentation/devicetree/bindings/pci/designware-pci.txt. >> + >> +Additional properties are described here: >> + >> +Required properties: >> +- compatible: >> + should contain "amlogic,axg-pcie" to identify the core. >> +- reg: >> + Should contain the configuration address space. >> +- reg-names: Must be >> + - "elbi"External local bus interface registers >> + - "cfg" Meson specific registers >> + - "config" PCIe configuration space >> +- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert >> signal. >> +- clocks: Must contain an entry for each entry in clock-names. >> +- clock-names: Must include the following entries: >> + - "pclk" PCIe GEN 100M PLL clock >> + - "port" PCIe_x(A or B) RC clock gate >> + - "general"PCIe Phy clock >> + - "mipi" PCIe_x(A or B) 100M ref clock gate >> +- resets: phandle to the reset lines. >> +- reset-names: must contain "phy" and "peripheral" >> + - "port" Port A or B reset >> + - "apb" APB reset > > The above description is not coherent (phy <=> port) > Yes, this should be port and apb here. We'll integrate phy driver into ctrl driver, and move phy reset to here also. >>> >>> Why? That's the wrong thing to do if they are separate h/w blocks. You >>> can do whatever you like in the drivers, but the DT should reflect the >>> h/w. >>> >>> Rob >>> >>> . >>> >> >> We have the dedicated phy driver which only process reset job, >> and we consider that it's too overkill to do just these things . >> So we will integrate phy reset job into the controller driver int the next >> version. > > What's in the separate register space you had for the phy? > > Rob > > . > As described with 'phy' reg in ctrl patch v3 thread [0] - reg-names: Must be - "elbi"External local bus interface registers - "cfg" Meson specific registers - "phy" Meson PCIE PHY registers - "config" PCIe configuration space When each controller driver probe, we powerup phy by write phy register like below: writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base); [0] https://lkml.kernel.org/r/1535616829-167936-1-git-send-email-hanjie@amlogic.com
Re: [PATCH v2 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller
On 2018/8/30 21:59, Rob Herring wrote: > On Thu, Aug 30, 2018 at 2:37 AM Hanjie Lin wrote: >> >> >> >> On 2018/8/29 8:41, Rob Herring wrote: >>> On Mon, Aug 27, 2018 at 04:55:20PM +0800, Hanjie Lin wrote: On 2018/8/24 16:22, Jerome Brunet wrote: > On Fri, 2018-08-24 at 15:36 +0800, Hanjie Lin wrote: >> From: Yue Wang >> >> The Amlogic Meson PCIe host controller is based on the Synopsys >> DesignWare >> PCI core. This patch adds documentation for the DT bindings in Meson PCIe >> controller. >> >> Signed-off-by: Yue Wang >> Signed-off-by: Hanjie Lin >> --- >> .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 63 >> ++ >> 1 file changed, 63 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> >> diff --git >> a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> new file mode 100644 >> index 000..8a831d1 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt >> @@ -0,0 +1,63 @@ >> +Amlogic Meson AXG DWC PCIE SoC controller >> + >> +Amlogic Meson PCIe host controller is based on the Synopsys DesignWare >> PCI core. >> +It shares common functions with the PCIe DesignWare core driver and >> +inherits common properties defined in >> +Documentation/devicetree/bindings/pci/designware-pci.txt. >> + >> +Additional properties are described here: >> + >> +Required properties: >> +- compatible: >> + should contain "amlogic,axg-pcie" to identify the core. >> +- reg: >> + Should contain the configuration address space. >> +- reg-names: Must be >> + - "elbi"External local bus interface registers >> + - "cfg" Meson specific registers >> + - "config" PCIe configuration space >> +- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert >> signal. >> +- clocks: Must contain an entry for each entry in clock-names. >> +- clock-names: Must include the following entries: >> + - "pclk" PCIe GEN 100M PLL clock >> + - "port" PCIe_x(A or B) RC clock gate >> + - "general"PCIe Phy clock >> + - "mipi" PCIe_x(A or B) 100M ref clock gate >> +- resets: phandle to the reset lines. >> +- reset-names: must contain "phy" and "peripheral" >> + - "port" Port A or B reset >> + - "apb" APB reset > > The above description is not coherent (phy <=> port) > Yes, this should be port and apb here. We'll integrate phy driver into ctrl driver, and move phy reset to here also. >>> >>> Why? That's the wrong thing to do if they are separate h/w blocks. You >>> can do whatever you like in the drivers, but the DT should reflect the >>> h/w. >>> >>> Rob >>> >>> . >>> >> >> We have the dedicated phy driver which only process reset job, >> and we consider that it's too overkill to do just these things . >> So we will integrate phy reset job into the controller driver int the next >> version. > > What's in the separate register space you had for the phy? > > Rob > > . > As described with 'phy' reg in ctrl patch v3 thread [0] - reg-names: Must be - "elbi"External local bus interface registers - "cfg" Meson specific registers - "phy" Meson PCIE PHY registers - "config" PCIe configuration space When each controller driver probe, we powerup phy by write phy register like below: writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base); [0] https://lkml.kernel.org/r/1535616829-167936-1-git-send-email-hanjie@amlogic.com
RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Hi, Stephen Anson Huang Best Regards! > -Original Message- > From: Stephen Boyd > Sent: Friday, August 31, 2018 9:29 AM > To: ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > mturque...@baylibre.com; s.ha...@pengutronix.de; shawn...@kernel.org; > Anson Huang ; Fabio Estevam > ; Peng Fan ; Rob Herring > > Cc: dl-linux-imx > Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > Quoting Peng Fan (2018-08-12 18:15:41) > > Hi Anson, > > > > > > > -Original Message- > > > > > From: Anson Huang > > > > > Sent: 2018年8月8日 12:39 > > > > > To: shawn...@kernel.org; s.ha...@pengutronix.de; > > > > > ker...@pengutronix.de; Fabio Estevam ; > > > > > mturque...@baylibre.com; sb...@kernel.org; > > > > > linux-arm-ker...@lists.infradead.org; > > > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > Cc: dl-linux-imx > > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > > > > > > > > > Clock framework will enable those clocks registered with > > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array > > > > > during clock > > > > initialization now. > > > > > > > > Will it be more flexible to parse dts saying "critical-clocks = " > > > > or "init-on-arrary=" > > > > and enable those clocks? > > > > > > Parsing the clocks arrays from dtb is another way of enabling > > > critical clocks, but for current i.MX6/7 platforms, we implement it > > > in same way as most of other SoCs, currently I did NOT see any > > > necessity of putting them in dtb, just adding flag during clock > > > registering is more simple, if there is any special requirement for > > > different clocks set to be enabled, then we can add support to enable the > method of parsing critical-clocks from dtb. Just my two cents. > > > > Thinking about OP-TEE want to use one device, but it's clocks are > > registered by Linux, because there is no module in Linux side use it, > > it will shutdown the clock, which cause OP-TEE could not access the device. > > > > Then people have to modify clk code to add CLK_IS_CRITICAL flag to > > make sure the clocks are not shutdown by Linux. > > > > However adding a new property in clk node and let driver code parse > > the dts, there is no need to modify clk driver code when OP-TEE needs > another device clock. > > > > If OP-TEE needs linux to keep things on then why can't the OP-TEE driver in > Linux probe, acquire clocks, and keep the clks enabled forever? Yes, I agree with you, OP-TEE should maintain its clocks when OP-TEE is enabled. This is ONLY a concern raised by Peng, all platforms' current clock driver does NOT consider this case, so I think this patch should be fine for now? Thanks. Anson.
RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Hi, Stephen Anson Huang Best Regards! > -Original Message- > From: Stephen Boyd > Sent: Friday, August 31, 2018 9:29 AM > To: ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > mturque...@baylibre.com; s.ha...@pengutronix.de; shawn...@kernel.org; > Anson Huang ; Fabio Estevam > ; Peng Fan ; Rob Herring > > Cc: dl-linux-imx > Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > Quoting Peng Fan (2018-08-12 18:15:41) > > Hi Anson, > > > > > > > -Original Message- > > > > > From: Anson Huang > > > > > Sent: 2018年8月8日 12:39 > > > > > To: shawn...@kernel.org; s.ha...@pengutronix.de; > > > > > ker...@pengutronix.de; Fabio Estevam ; > > > > > mturque...@baylibre.com; sb...@kernel.org; > > > > > linux-arm-ker...@lists.infradead.org; > > > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > Cc: dl-linux-imx > > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > > > > > > > > > Clock framework will enable those clocks registered with > > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array > > > > > during clock > > > > initialization now. > > > > > > > > Will it be more flexible to parse dts saying "critical-clocks = " > > > > or "init-on-arrary=" > > > > and enable those clocks? > > > > > > Parsing the clocks arrays from dtb is another way of enabling > > > critical clocks, but for current i.MX6/7 platforms, we implement it > > > in same way as most of other SoCs, currently I did NOT see any > > > necessity of putting them in dtb, just adding flag during clock > > > registering is more simple, if there is any special requirement for > > > different clocks set to be enabled, then we can add support to enable the > method of parsing critical-clocks from dtb. Just my two cents. > > > > Thinking about OP-TEE want to use one device, but it's clocks are > > registered by Linux, because there is no module in Linux side use it, > > it will shutdown the clock, which cause OP-TEE could not access the device. > > > > Then people have to modify clk code to add CLK_IS_CRITICAL flag to > > make sure the clocks are not shutdown by Linux. > > > > However adding a new property in clk node and let driver code parse > > the dts, there is no need to modify clk driver code when OP-TEE needs > another device clock. > > > > If OP-TEE needs linux to keep things on then why can't the OP-TEE driver in > Linux probe, acquire clocks, and keep the clks enabled forever? Yes, I agree with you, OP-TEE should maintain its clocks when OP-TEE is enabled. This is ONLY a concern raised by Peng, all platforms' current clock driver does NOT consider this case, so I think this patch should be fine for now? Thanks. Anson.
Re: [PATCH] staging: android: ion: check for kref overflow
On 08/30/2018 05:41 PM, Greg Kroah-Hartman wrote:
On Thu, Aug 30, 2018 at 04:09:46PM -0700, Daniel Rosenberg wrote:
This patch is against 4.9. It does not apply to master due to a large
rework of ion in 4.12 which removed the affected functions altogther.
4c23cbff073f3b9b ("staging: android: ion: Remove import interface")
Userspace can cause the kref to handles to increment
arbitrarily high. Ensure it does not overflow.
Signed-off-by: Daniel Rosenberg
Signed-off-by: Greg Kroah-Hartman
I signed off on this? Where? When? Are you sure?
greg k-h
The sign off was on the 4.4.y version that I cherry-picked this from.
There was a trivial conflict moving it to 4.9, but it did not modify any
changed lines, so I hadn't thought that was worth noting on the patch. I
apologise if leaving the signed-off-by was incorrect here.
-Daniel
Re: [PATCH] staging: android: ion: check for kref overflow
On 08/30/2018 05:41 PM, Greg Kroah-Hartman wrote:
On Thu, Aug 30, 2018 at 04:09:46PM -0700, Daniel Rosenberg wrote:
This patch is against 4.9. It does not apply to master due to a large
rework of ion in 4.12 which removed the affected functions altogther.
4c23cbff073f3b9b ("staging: android: ion: Remove import interface")
Userspace can cause the kref to handles to increment
arbitrarily high. Ensure it does not overflow.
Signed-off-by: Daniel Rosenberg
Signed-off-by: Greg Kroah-Hartman
I signed off on this? Where? When? Are you sure?
greg k-h
The sign off was on the 4.4.y version that I cherry-picked this from.
There was a trivial conflict moving it to 4.9, but it did not modify any
changed lines, so I hadn't thought that was worth noting on the patch. I
apologise if leaving the signed-off-by was incorrect here.
-Daniel
WARNING in enter_vmx_operation
Hello, syzbot found the following crash on: HEAD commit:3f16503b7d22 Merge branch 'fixes' of git://git.kernel.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c7df6a40 kernel config: https://syzkaller.appspot.com/x/.config?x=49927b422dcf0b29 dashboard link: https://syzkaller.appspot.com/bug?extid=ab5d7a5d0fc0c7518f6d compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=132365a640 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ab5d7a5d0fc0c7518...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details. WARNING: CPU: 1 PID: 4748 at arch/x86/kvm/vmx.c:8247 alloc_shadow_vmcs arch/x86/kvm/vmx.c:8247 [inline] WARNING: CPU: 1 PID: 4748 at arch/x86/kvm/vmx.c:8247 enter_vmx_operation+0x391/0x470 arch/x86/kvm/vmx.c:8274 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4748 Comm: syz-executor0 Not tainted 4.19.0-rc1+ #213 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:alloc_shadow_vmcs arch/x86/kvm/vmx.c:8247 [inline] RIP: 0010:enter_vmx_operation+0x391/0x470 arch/x86/kvm/vmx.c:8274 Code: 00 4c 89 ef bb f4 ff ff ff e8 7b ec ff ff e9 f2 fe ff ff e8 71 dc 5f 00 48 8b 4d d0 48 85 c9 0f 84 08 ff ff ff e8 5f dc 5f 00 <0f> 0b e9 0e fe ff ff e8 f3 d9 9e 00 e9 c1 fe ff ff e8 09 da 9e 00 RSP: 0018:8801aa826f48 EFLAGS: 00010293 RAX: 8801abbde080 RBX: 8801d3668040 RCX: 8801c366d000 RDX: RSI: 811ce421 RDI: 8801d366d820 RBP: 8801aa826f80 R08: 8801abbde080 R09: ed003b6246de R10: ed003b6246de R11: 8801db1236f3 R12: 8801d366dba8 R13: 8801d366dbb8 R14: 8801d366dba0 R15: 8801d366d7a8 vmx_set_nested_state+0x4d6/0xea0 arch/x86/kvm/vmx.c:13944 kvm_arch_vcpu_ioctl+0x790/0x3ac0 arch/x86/kvm/x86.c:4048 kvm_vcpu_ioctl+0x286/0x1280 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2742 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:501 [inline] do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 __do_sys_ioctl fs/ioctl.c:709 [inline] __se_sys_ioctl fs/ioctl.c:707 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f0ac2b1cc78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7f0ac2b1d6d4 RCX: 00457089 RDX: 2580 RSI: 4080aebf RDI: 0005 RBP: 00930140 R08: R09: R10: R11: 0246 R12: R13: 004cf070 R14: 004c56c3 R15: 0001 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
WARNING in enter_vmx_operation
Hello, syzbot found the following crash on: HEAD commit:3f16503b7d22 Merge branch 'fixes' of git://git.kernel.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c7df6a40 kernel config: https://syzkaller.appspot.com/x/.config?x=49927b422dcf0b29 dashboard link: https://syzkaller.appspot.com/bug?extid=ab5d7a5d0fc0c7518f6d compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=132365a640 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ab5d7a5d0fc0c7518...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details. WARNING: CPU: 1 PID: 4748 at arch/x86/kvm/vmx.c:8247 alloc_shadow_vmcs arch/x86/kvm/vmx.c:8247 [inline] WARNING: CPU: 1 PID: 4748 at arch/x86/kvm/vmx.c:8247 enter_vmx_operation+0x391/0x470 arch/x86/kvm/vmx.c:8274 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4748 Comm: syz-executor0 Not tainted 4.19.0-rc1+ #213 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:alloc_shadow_vmcs arch/x86/kvm/vmx.c:8247 [inline] RIP: 0010:enter_vmx_operation+0x391/0x470 arch/x86/kvm/vmx.c:8274 Code: 00 4c 89 ef bb f4 ff ff ff e8 7b ec ff ff e9 f2 fe ff ff e8 71 dc 5f 00 48 8b 4d d0 48 85 c9 0f 84 08 ff ff ff e8 5f dc 5f 00 <0f> 0b e9 0e fe ff ff e8 f3 d9 9e 00 e9 c1 fe ff ff e8 09 da 9e 00 RSP: 0018:8801aa826f48 EFLAGS: 00010293 RAX: 8801abbde080 RBX: 8801d3668040 RCX: 8801c366d000 RDX: RSI: 811ce421 RDI: 8801d366d820 RBP: 8801aa826f80 R08: 8801abbde080 R09: ed003b6246de R10: ed003b6246de R11: 8801db1236f3 R12: 8801d366dba8 R13: 8801d366dbb8 R14: 8801d366dba0 R15: 8801d366d7a8 vmx_set_nested_state+0x4d6/0xea0 arch/x86/kvm/vmx.c:13944 kvm_arch_vcpu_ioctl+0x790/0x3ac0 arch/x86/kvm/x86.c:4048 kvm_vcpu_ioctl+0x286/0x1280 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2742 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:501 [inline] do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 __do_sys_ioctl fs/ioctl.c:709 [inline] __se_sys_ioctl fs/ioctl.c:707 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f0ac2b1cc78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7f0ac2b1d6d4 RCX: 00457089 RDX: 2580 RSI: 4080aebf RDI: 0005 RBP: 00930140 R08: R09: R10: R11: 0246 R12: R13: 004cf070 R14: 004c56c3 R15: 0001 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] clk: mediatek: remove unused array audio_parents
Quoting Colin King (2018-08-06 06:44:02) > From: Colin Ian King > > Array audio_parents is declared but never used, hence it is redundant > and can be removed. > > Cleans up clang warning: > warning: 'audio_parents' defined but not used [-Wunused-const-variable=] > > Signed-off-by: Colin Ian King > --- Applied to clk-next
Re: [PATCH] clk: mediatek: remove unused array audio_parents
Quoting Colin King (2018-08-06 06:44:02) > From: Colin Ian King > > Array audio_parents is declared but never used, hence it is redundant > and can be removed. > > Cleans up clang warning: > warning: 'audio_parents' defined but not used [-Wunused-const-variable=] > > Signed-off-by: Colin Ian King > --- Applied to clk-next
RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Quoting Peng Fan (2018-08-12 18:15:41) > Hi Anson, > > > > > -Original Message- > > > > From: Anson Huang > > > > Sent: 2018年8月8日 12:39 > > > > To: shawn...@kernel.org; s.ha...@pengutronix.de; > > > > ker...@pengutronix.de; Fabio Estevam ; > > > > mturque...@baylibre.com; sb...@kernel.org; > > > > linux-arm-ker...@lists.infradead.org; > > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Cc: dl-linux-imx > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > > > > > > > Clock framework will enable those clocks registered with > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during > > > > clock > > > initialization now. > > > > > > Will it be more flexible to parse dts saying "critical-clocks = " > > > or "init-on-arrary=" > > > and enable those clocks? > > > > Parsing the clocks arrays from dtb is another way of enabling critical > > clocks, but > > for current i.MX6/7 platforms, we implement it in same way as most of other > > SoCs, currently I did NOT see any necessity of putting them in dtb, just > > adding > > flag during clock registering is more simple, if there is any special > > requirement > > for different clocks set to be enabled, then we can add support to enable > > the > > method of parsing critical-clocks from dtb. Just my two cents. > > Thinking about OP-TEE want to use one device, but it's clocks are registered > by Linux, because there is no module in Linux side use it, it will shutdown > the clock, > which cause OP-TEE could not access the device. > > Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure > the clocks are not shutdown by Linux. > > However adding a new property in clk node and let driver code parse the dts, > there is no need to modify clk driver code when OP-TEE needs another device > clock. > If OP-TEE needs linux to keep things on then why can't the OP-TEE driver in Linux probe, acquire clocks, and keep the clks enabled forever?
Re: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault
On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote: > > Fix is to move one step at a time. First mark the page not present > (using the decoy address). Then it is safe to use the actual address > of the 1:1 mapping to mark it "uc", and finally as present. Can't we do it in one step, but make sure that he clflush gets the real address? Linus
RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Quoting Peng Fan (2018-08-12 18:15:41) > Hi Anson, > > > > > -Original Message- > > > > From: Anson Huang > > > > Sent: 2018年8月8日 12:39 > > > > To: shawn...@kernel.org; s.ha...@pengutronix.de; > > > > ker...@pengutronix.de; Fabio Estevam ; > > > > mturque...@baylibre.com; sb...@kernel.org; > > > > linux-arm-ker...@lists.infradead.org; > > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Cc: dl-linux-imx > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > > > > > > > Clock framework will enable those clocks registered with > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during > > > > clock > > > initialization now. > > > > > > Will it be more flexible to parse dts saying "critical-clocks = " > > > or "init-on-arrary=" > > > and enable those clocks? > > > > Parsing the clocks arrays from dtb is another way of enabling critical > > clocks, but > > for current i.MX6/7 platforms, we implement it in same way as most of other > > SoCs, currently I did NOT see any necessity of putting them in dtb, just > > adding > > flag during clock registering is more simple, if there is any special > > requirement > > for different clocks set to be enabled, then we can add support to enable > > the > > method of parsing critical-clocks from dtb. Just my two cents. > > Thinking about OP-TEE want to use one device, but it's clocks are registered > by Linux, because there is no module in Linux side use it, it will shutdown > the clock, > which cause OP-TEE could not access the device. > > Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure > the clocks are not shutdown by Linux. > > However adding a new property in clk node and let driver code parse the dts, > there is no need to modify clk driver code when OP-TEE needs another device > clock. > If OP-TEE needs linux to keep things on then why can't the OP-TEE driver in Linux probe, acquire clocks, and keep the clks enabled forever?
Re: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault
On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote: > > Fix is to move one step at a time. First mark the page not present > (using the decoy address). Then it is safe to use the actual address > of the 1:1 mapping to mark it "uc", and finally as present. Can't we do it in one step, but make sure that he clflush gets the real address? Linus
Re: [PATCH v3] clk: qcom: Add camera clock controller driver for SDM845
Quoting Amit Nischal (2018-08-08 03:47:19) > Add support for the camera clock controller found on SDM845 > based devices. This would allow camera drivers to probe and > control their clocks. > > Signed-off-by: Amit Nischal > --- Applied to clk-next
Re: [PATCH v3] clk: qcom: Add camera clock controller driver for SDM845
Quoting Amit Nischal (2018-08-08 03:47:19) > Add support for the camera clock controller found on SDM845 > based devices. This would allow camera drivers to probe and > control their clocks. > > Signed-off-by: Amit Nischal > --- Applied to clk-next
Re: [PATCH 3/4] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE
On Mon, 2018-08-27 at 19:02 +1000, Nicholas Piggin wrote: > > More tlbies ? With the cost of the broadasts on the fabric ? I don't > > think so.. or I'm not understanding your point... > > More tlbies are no good, but there will be some places where it works > out much better (and fewer tlbies). Worst possible case for current code > is a big unmap with lots of scattered page sizes. We _should_ get that > with just a single PID flush at the end, but what we will get today is > a bunch of PID and VA flushes. > > I don't propose doing that though, I'd rather be explicit about > tracking start and end range of each page size. Still not "optimal" > but neither is existing single range for sparse mappings... anyway it > will need to be profiled, but my point is we don't really fit exactly > what x86/arm want. If we have an arch specific part, we could just remember up to N "large" pages there without actually flushing, and if that overflows, upgrade to a full flush. Cheers, Ben.
Re: [PATCH 3/4] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE
On Mon, 2018-08-27 at 19:02 +1000, Nicholas Piggin wrote: > > More tlbies ? With the cost of the broadasts on the fabric ? I don't > > think so.. or I'm not understanding your point... > > More tlbies are no good, but there will be some places where it works > out much better (and fewer tlbies). Worst possible case for current code > is a big unmap with lots of scattered page sizes. We _should_ get that > with just a single PID flush at the end, but what we will get today is > a bunch of PID and VA flushes. > > I don't propose doing that though, I'd rather be explicit about > tracking start and end range of each page size. Still not "optimal" > but neither is existing single range for sparse mappings... anyway it > will need to be profiled, but my point is we don't really fit exactly > what x86/arm want. If we have an arch specific part, we could just remember up to N "large" pages there without actually flushing, and if that overflows, upgrade to a full flush. Cheers, Ben.
Re: [PATCH 09/12] asm-generic/tlb: Track which levels of the page tables have been cleared
On Thu, 30 Aug 2018 17:15:43 +0100 Will Deacon wrote: > It is common for architectures with hugepage support to require only a > single TLB invalidation operation per hugepage during unmap(), rather than > iterating through the mapping at a PAGE_SIZE increment. Currently, > however, the level in the page table where the unmap() operation occurs > is not stored in the mmu_gather structure, therefore forcing > architectures to issue additional TLB invalidation operations or to give > up and over-invalidate by e.g. invalidating the entire TLB. > > Ideally, we could add an interval rbtree to the mmu_gather structure, > which would allow us to associate the correct mapping granule with the > various sub-mappings within the range being invalidated. However, this > is costly in terms of book-keeping and memory management, so instead we > approximate by keeping track of the page table levels that are cleared > and provide a means to query the smallest granule required for invalidation. Actually the generic patches are pretty simple, and they look okay to me. powerpc *should* be able to switch to Peter's patch with a few lines of code with unchanged functionality as far as I can see. These flags we may use as well, but even if not if x86 and arm64 are using it, it seems reasonable to go in generic code for now. For the 3 generic patches, Acked-by: Nicholas Piggin Thanks, Nick
Re: [PATCH 09/12] asm-generic/tlb: Track which levels of the page tables have been cleared
On Thu, 30 Aug 2018 17:15:43 +0100 Will Deacon wrote: > It is common for architectures with hugepage support to require only a > single TLB invalidation operation per hugepage during unmap(), rather than > iterating through the mapping at a PAGE_SIZE increment. Currently, > however, the level in the page table where the unmap() operation occurs > is not stored in the mmu_gather structure, therefore forcing > architectures to issue additional TLB invalidation operations or to give > up and over-invalidate by e.g. invalidating the entire TLB. > > Ideally, we could add an interval rbtree to the mmu_gather structure, > which would allow us to associate the correct mapping granule with the > various sub-mappings within the range being invalidated. However, this > is costly in terms of book-keeping and memory management, so instead we > approximate by keeping track of the page table levels that are cleared > and provide a means to query the smallest granule required for invalidation. Actually the generic patches are pretty simple, and they look okay to me. powerpc *should* be able to switch to Peter's patch with a few lines of code with unchanged functionality as far as I can see. These flags we may use as well, but even if not if x86 and arm64 are using it, it seems reasonable to go in generic code for now. For the 3 generic patches, Acked-by: Nicholas Piggin Thanks, Nick
Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
On Thu 30 Aug 18:07 PDT 2018, Stephen Boyd wrote: > Quoting Bjorn Andersson (2018-08-29 16:15:02) > > We're currently facing the issue that every new platform requires the > > addition > > of a compatible to the DT binding as well as the driver. > > > > The DT binding patch to allow us to use qcom,scm for all these new platforms > > that doesn't require any clocks and the driver is reworked to make the > > qcom,scm > > still pick up specified clocks in this case but won't require them. > > > > This makes it possible to add new platforms by simply add the new > > compatible to > > the list in the DT binding, but no changes needs to be done in the driver. > > Which is what is done in patch 3. > > > > I still think it may be even simpler to move to the "get all the clks" > API and then stop caring completely. Any reason to not do that? > I love working with drivers that tells me things like "hey you forgot to add the 'core' clock", rather than having to spend hours bisecting which register access it is that's causing that reboot and then try to drill that down to a particular clock. Apart from that, the "get-all-the-clocks" would work fine as well. Does this API exist yet? Regards, Bjorn
Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
On Thu 30 Aug 18:07 PDT 2018, Stephen Boyd wrote: > Quoting Bjorn Andersson (2018-08-29 16:15:02) > > We're currently facing the issue that every new platform requires the > > addition > > of a compatible to the DT binding as well as the driver. > > > > The DT binding patch to allow us to use qcom,scm for all these new platforms > > that doesn't require any clocks and the driver is reworked to make the > > qcom,scm > > still pick up specified clocks in this case but won't require them. > > > > This makes it possible to add new platforms by simply add the new > > compatible to > > the list in the DT binding, but no changes needs to be done in the driver. > > Which is what is done in patch 3. > > > > I still think it may be even simpler to move to the "get all the clks" > API and then stop caring completely. Any reason to not do that? > I love working with drivers that tells me things like "hey you forgot to add the 'core' clock", rather than having to spend hours bisecting which register access it is that's causing that reboot and then try to drill that down to a particular clock. Apart from that, the "get-all-the-clocks" would work fine as well. Does this API exist yet? Regards, Bjorn
Re: linux-next: disabling -Wstringop-truncation
On Thu, Aug 30, 2018 at 3:07 PM Stephen Rothwell wrote: > > I am now mainly using gcc v8.2 for my builds and -Wstringop-truncation > causes so many warnings that I am sure to miss others, so I have > applied the below to my fixes tree until the noise reduces. Applied. If people want the warning with W=xyz, then this is still the correct patch, and we should add a line to re-enable it in scripts/Makefile.extrawarn. Linus
Re: linux-next: disabling -Wstringop-truncation
On Thu, Aug 30, 2018 at 3:07 PM Stephen Rothwell wrote: > > I am now mainly using gcc v8.2 for my builds and -Wstringop-truncation > causes so many warnings that I am sure to miss others, so I have > applied the below to my fixes tree until the noise reduces. Applied. If people want the warning with W=xyz, then this is still the correct patch, and we should add a line to re-enable it in scripts/Makefile.extrawarn. Linus
Re: [PATCH v8 0/5] Support for Qualcomm UFS QMP PHY on SDM845
On Thu 30 Aug 03:44 PDT 2018, Vivek Gautam wrote: > On Thu, Aug 30, 2018 at 11:46 AM Bjorn Andersson > wrote: > > > > On Tue 31 Jul 03:09 PDT 2018, Can Guo wrote: > > > > > This patch series adds support for UFS QMP PHY on SDM845 and the > > > compatible string for it. This patch series depends on the current > > > proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on > > > the DT bindings for the QMP V3 USB3 PHYs based dirver [2], and also > > > rebased on updated pipe_clk initialization sequence [3]. This series > > > can only be merged once the dependent patches do. > > > [1] > > > http://lists-archives.com/linux-kernel/29071659-dt-bindings-phy-qcom-qmp-update-bindings-for-sdm845.html > > > [2] > > > http://lists-archives.com/linux-kernel/29071660-phy-qcom-qmp-add-qmp-v3-usb3-uni-phy-support-for-sdm845.html > > > [3] https://patchwork.kernel.org/patch/10376551/ > > > > > > > Hi Can, > > > > We still have the issue that the older non-QMP phy driver takes a direct > > call to ufs_qcom_phy_set_tx_lane_enable(), which means that pointing > > UFSHCD to this phy implementation results in a kernel panic. > > Hi Bjorn, > > I have a series that removes couple of these function calls - > ufs_qcom_phy_set_tx_lane_enable(), and > ufs_qcom_phy_save_controller_version() from ufs-qcom, and > make phy-qcom-ufs-qmp-20nm as broken. > I can post it out if that sounds okay. > That sounds really good, please do sent that out. Regards, Bjorn
Re: [PATCH v8 0/5] Support for Qualcomm UFS QMP PHY on SDM845
On Thu 30 Aug 03:44 PDT 2018, Vivek Gautam wrote: > On Thu, Aug 30, 2018 at 11:46 AM Bjorn Andersson > wrote: > > > > On Tue 31 Jul 03:09 PDT 2018, Can Guo wrote: > > > > > This patch series adds support for UFS QMP PHY on SDM845 and the > > > compatible string for it. This patch series depends on the current > > > proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on > > > the DT bindings for the QMP V3 USB3 PHYs based dirver [2], and also > > > rebased on updated pipe_clk initialization sequence [3]. This series > > > can only be merged once the dependent patches do. > > > [1] > > > http://lists-archives.com/linux-kernel/29071659-dt-bindings-phy-qcom-qmp-update-bindings-for-sdm845.html > > > [2] > > > http://lists-archives.com/linux-kernel/29071660-phy-qcom-qmp-add-qmp-v3-usb3-uni-phy-support-for-sdm845.html > > > [3] https://patchwork.kernel.org/patch/10376551/ > > > > > > > Hi Can, > > > > We still have the issue that the older non-QMP phy driver takes a direct > > call to ufs_qcom_phy_set_tx_lane_enable(), which means that pointing > > UFSHCD to this phy implementation results in a kernel panic. > > Hi Bjorn, > > I have a series that removes couple of these function calls - > ufs_qcom_phy_set_tx_lane_enable(), and > ufs_qcom_phy_save_controller_version() from ufs-qcom, and > make phy-qcom-ufs-qmp-20nm as broken. > I can post it out if that sounds okay. > That sounds really good, please do sent that out. Regards, Bjorn
Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
Quoting Bjorn Andersson (2018-08-29 16:15:02) > We're currently facing the issue that every new platform requires the addition > of a compatible to the DT binding as well as the driver. > > The DT binding patch to allow us to use qcom,scm for all these new platforms > that doesn't require any clocks and the driver is reworked to make the > qcom,scm > still pick up specified clocks in this case but won't require them. > > This makes it possible to add new platforms by simply add the new compatible > to > the list in the DT binding, but no changes needs to be done in the driver. > Which is what is done in patch 3. > I still think it may be even simpler to move to the "get all the clks" API and then stop caring completely. Any reason to not do that?
Re: [PATCH 0/3] firmware: qcom: scm: Improve clock handling
Quoting Bjorn Andersson (2018-08-29 16:15:02) > We're currently facing the issue that every new platform requires the addition > of a compatible to the DT binding as well as the driver. > > The DT binding patch to allow us to use qcom,scm for all these new platforms > that doesn't require any clocks and the driver is reworked to make the > qcom,scm > still pick up specified clocks in this case but won't require them. > > This makes it possible to add new platforms by simply add the new compatible > to > the list in the DT binding, but no changes needs to be done in the driver. > Which is what is done in patch 3. > I still think it may be even simpler to move to the "get all the clks" API and then stop caring completely. Any reason to not do that?
Re: [PATCH 3/3] dt-bindings: firmware: scm: Add MSM8998 and SDM845
Quoting Bjorn Andersson (2018-08-29 16:15:05) > Now that the compatible/clock handling is reworked add compatibles for > MSM8998 and SDM845 to the SCM binding. > > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd
Re: [PATCH 2/3] firmware: qcom: scm: Refactor clock handling
Quoting Bjorn Andersson (2018-08-29 16:15:04) > At one point in time all "future" platforms required three clocks, so > the binding and driver was written to treat this as the default case. > But new platforms has no clock requirements, which currently makes them > all a special case, causing the need for a patch in the binding and > driver for each new platform added. > > This patch reworks the driver logic so that it will attempt to acquire > all three clocks and fail based on the given compatible. This allow us > to drop the clock requirement from "qcom,scm", in a way that will remain > backwards compatible with existing DT files. > > Specific compatibles are added for apq8084, msm8916 and msm8974 to match > the updated binding and although equivalent to qcom,scm both ipq4019 and > msm8996 are kept as these have been used without fallback to qcom,scm. > > The result of this patch is that new platforms, that require no clocks, > can be use the fallback compatible of "qcom,scm". > > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd
Re: [PATCH 1/3] dt-bindings: firmware: scm: Refactor compatibles and clocks
Quoting Bjorn Andersson (2018-08-29 16:15:03) > When the binding was written all "future" platforms required three > clocks, so the default compatible (qcom,scm) was defined to require > this. But as history shows all "future" platforms actually lack required > clocks. Given how the binding is written these compatibles have to be > added as an exception to the default. > > Refactor the description of compatible to define that a platform > compatible should be given, followed by the fallback of qcom,scm. Also > refactor the description of the clocks in a way that this does not need > to be updated as new platform specific compatibles are added. > > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd
Re: [PATCH 3/3] dt-bindings: firmware: scm: Add MSM8998 and SDM845
Quoting Bjorn Andersson (2018-08-29 16:15:05) > Now that the compatible/clock handling is reworked add compatibles for > MSM8998 and SDM845 to the SCM binding. > > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd
Re: [PATCH 2/3] firmware: qcom: scm: Refactor clock handling
Quoting Bjorn Andersson (2018-08-29 16:15:04) > At one point in time all "future" platforms required three clocks, so > the binding and driver was written to treat this as the default case. > But new platforms has no clock requirements, which currently makes them > all a special case, causing the need for a patch in the binding and > driver for each new platform added. > > This patch reworks the driver logic so that it will attempt to acquire > all three clocks and fail based on the given compatible. This allow us > to drop the clock requirement from "qcom,scm", in a way that will remain > backwards compatible with existing DT files. > > Specific compatibles are added for apq8084, msm8916 and msm8974 to match > the updated binding and although equivalent to qcom,scm both ipq4019 and > msm8996 are kept as these have been used without fallback to qcom,scm. > > The result of this patch is that new platforms, that require no clocks, > can be use the fallback compatible of "qcom,scm". > > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd
Re: [PATCH 1/3] dt-bindings: firmware: scm: Refactor compatibles and clocks
Quoting Bjorn Andersson (2018-08-29 16:15:03) > When the binding was written all "future" platforms required three > clocks, so the default compatible (qcom,scm) was defined to require > this. But as history shows all "future" platforms actually lack required > clocks. Given how the binding is written these compatibles have to be > added as an exception to the default. > > Refactor the description of compatible to define that a platform > compatible should be given, followed by the fallback of qcom,scm. Also > refactor the description of the clocks in a way that this does not need > to be updated as new platform specific compatibles are added. > > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd
Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64
On Thu, Aug 30, 2018 at 6:01 PM Nicholas Piggin wrote: > > Well it would help if powerpc say wanted to start using them without a > merge cycle lag. Not a huge issue because powerpc already does > reasonably well here and there's other work that can be done. Sure. If somebody wants to send the generic changes I can just take them directly to make it easier for people to work on this. Linus
Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64
On Thu, Aug 30, 2018 at 6:01 PM Nicholas Piggin wrote: > > Well it would help if powerpc say wanted to start using them without a > merge cycle lag. Not a huge issue because powerpc already does > reasonably well here and there's other work that can be done. Sure. If somebody wants to send the generic changes I can just take them directly to make it easier for people to work on this. Linus
Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64
On Thu, 30 Aug 2018 09:39:38 -0700 Linus Torvalds wrote: > On Thu, Aug 30, 2018 at 9:15 AM Will Deacon wrote: > > > > It's also had a lot more testing, but has held up nicely so far on arm64. > > I haven't figured out how to merge this yet, but I'll probably end up > > pulling > > the core changes out onto a separate branch. > > This looks fine, and I'm actually ok getting the core changes through > the arm64 branch, since this has been discussed across architectures, > and I think "whoever does the work gets to drive the car". Well it would help if powerpc say wanted to start using them without a merge cycle lag. Not a huge issue because powerpc already does reasonably well here and there's other work that can be done. I will try to review the core changes carefully next week. Thanks, Nick
Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64
On Thu, 30 Aug 2018 09:39:38 -0700 Linus Torvalds wrote: > On Thu, Aug 30, 2018 at 9:15 AM Will Deacon wrote: > > > > It's also had a lot more testing, but has held up nicely so far on arm64. > > I haven't figured out how to merge this yet, but I'll probably end up > > pulling > > the core changes out onto a separate branch. > > This looks fine, and I'm actually ok getting the core changes through > the arm64 branch, since this has been discussed across architectures, > and I think "whoever does the work gets to drive the car". Well it would help if powerpc say wanted to start using them without a merge cycle lag. Not a huge issue because powerpc already does reasonably well here and there's other work that can be done. I will try to review the core changes carefully next week. Thanks, Nick
