Re: [PATCH RFC] driver core: ensure a device has valid node id in device_add()
On Thu, Sep 05, 2019 at 09:33:50AM +0800, Yunsheng Lin wrote:
> Currently a device does not belong to any of the numa nodes
> (dev->numa_node is NUMA_NO_NODE) when the FW does not provide
> the node id and the device has not no parent device.
>
> According to discussion in [1]:
> Even if a device's numa node is not set by fw, the device
> really does belong to a node.
>
> This patch sets the device node to node 0 in device_add() if
> the fw has not specified the node id and it either has no
> parent device, or the parent device also does not have a valid
> node id.
>
> There may be explicit handling out there relying on NUMA_NO_NODE,
> like in nvme_probe().
>
> [1] https://lkml.org/lkml/2019/9/2/466
>
> Signed-off-by: Yunsheng Lin
> ---
> drivers/base/core.c | 17 ++---
> include/linux/numa.h | 2 ++
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 1669d41..466b8ff 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2107,9 +2107,20 @@ int device_add(struct device *dev)
> if (kobj)
> dev->kobj.parent = kobj;
>
> - /* use parent numa_node */
> - if (parent && (dev_to_node(dev) == NUMA_NO_NODE))
> - set_dev_node(dev, dev_to_node(parent));
> + /* use parent numa_node or default node 0 */
> + if (!numa_node_valid(dev_to_node(dev))) {
> + int nid = parent ? dev_to_node(parent) : NUMA_NO_NODE;
Can you expand this to be a "real" if statement please?
> +
> + if (numa_node_valid(nid)) {
> + set_dev_node(dev, nid);
> + } else {
> + if (nr_node_ids > 1U)
> + pr_err("device: '%s': has invalid NUMA
> node(%d)\n",
> +dev_name(dev), dev_to_node(dev));
dev_err() will show you the exact device properly, instead of having to
rely on dev_name().
And what is a user to do if this message happens? How do they fix this?
If they can not, what good is this error message?
thanks,
greg k-h
Re: [PATCH v2] drm/amdgpu: Remove two redundant null pointer checks
On 2019/9/5 下午1:49, zhong jiang wrote:
> The functions "debugfs_remove" and "kfree" tolerate the passing
> of null pointers. Hence it is unnecessary to check such arguments
> around the calls. Thus remove the extra condition check at two places.
>
> Signed-off-by: zhong jiang
Reviewed-by: Chunming Zhou
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 5652cc7..cb94627 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -1077,8 +1077,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64
> val)
>
> ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
>
> - if (fences)
> - kfree(fences);
> + kfree(fences);
>
> return 0;
> }
> @@ -1103,8 +1102,7 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
>
> void amdgpu_debugfs_preempt_cleanup(struct amdgpu_device *adev)
> {
> - if (adev->debugfs_preempt)
> - debugfs_remove(adev->debugfs_preempt);
> + debugfs_remove(adev->debugfs_preempt);
> }
>
> #else
Re: [RFC PATCH 0/9] Task latency-nice
Hi Subhra, On 8/30/19 11:19 PM, subhra mazumdar wrote: > Introduce new per task property latency-nice for controlling scalability > in scheduler idle CPU search path. Valid latency-nice values are from 1 to > 100 indicating 1% to 100% search of the LLC domain in select_idle_cpu. New > CPU cgroup file cpu.latency-nice is added as an interface to set and get. > All tasks in the same cgroup share the same latency-nice value. Using a > lower latency-nice value can help latency intolerant tasks e.g very short > running OLTP threads where full LLC search cost can be significant compared > to run time of the threads. The default latency-nice value is 5. > > In addition to latency-nice, it also adds a new sched feature SIS_CORE to > be able to disable idle core search altogether which is costly and hurts > more than it helps in short running workloads. > > Finally it also introduces a new per-cpu variable next_cpu to track > the limit of search so that every time search starts from where it ended. > This rotating search window over cpus in LLC domain ensures that idle > cpus are eventually found in case of high load. > > Uperf pingpong on 2 socket, 44 core and 88 threads Intel x86 machine with > message size = 8k (higher is better): > threads baseline latency-nice=5,SIS_CORE latency-nice=5,NO_SIS_CORE > 8 64.66 64.38 (-0.43%) 64.79 (0.2%) > 16 123.34 122.88 (-0.37%) 125.87 (2.05%) > 32 215.18 215.55 (0.17%) 247.77 (15.15%) > 48 278.56 321.6 (15.45%) 321.2 (15.3%) > 64 259.99 319.45 (22.87%) 333.95 (28.44%) > 128 431.1 437.69 (1.53%) 431.09 (0%) > The result seems to be appealing with your experimental setup. BTW, do you have any plans of load balancing as well based on latency niceness of the tasks? It seems to be a more interesting case when we give pack the lower latency sensitive tasks on fewer CPUs. Also, do you see any workload results showing performance regression with NO_SIS_CORE? Thanks, Parth
Re: [PATCH] media: siano: Use the correct style for SPDX License Identifier
On Wed, Sep 04, 2019 at 04:00:10PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 4 Sep 2019 20:36:08 +0200
> Greg Kroah-Hartman escreveu:
>
> > On Wed, Sep 04, 2019 at 03:34:32PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Sat, 31 Aug 2019 20:41:51 +0530
> > > Nishad Kamdar escreveu:
> > >
> > > > This patch corrects the SPDX License Identifier style
> > > > in header file related to Siano Mobile Silicon Digital TV.
> > > > For C header files Documentation/process/license-rules.rst
> > > > mandates C-like comments (opposed to C source files where
> > > > C++ style should be used)
> > > >
> > > > Changes made by using a script provided by Joe Perches here:
> > > > https://lkml.org/lkml/2019/2/7/46
> > > >
> > > > Suggested-by: Joe Perches
> > > > Signed-off-by: Nishad Kamdar
> > > > ---
> > > > drivers/media/common/siano/smsir.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/media/common/siano/smsir.h
> > > > b/drivers/media/common/siano/smsir.h
> > > > index b2c54c256e86..ada41d5c4e83 100644
> > > > --- a/drivers/media/common/siano/smsir.h
> > > > +++ b/drivers/media/common/siano/smsir.h
> > > > @@ -1,5 +1,5 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > /*
> > > > - * SPDX-License-Identifier: GPL-2.0+
> > > > *
> > > > * Siano Mobile Silicon, Inc.
> > > > * MDTV receiver kernel modules.
> > >
> > > What's wrong with that? The above is a perfectly fine SPDX header.
> >
> > It is not the first line of the file :(
> >
>
> A requirement for having it at the first line is not realistic.
But it is "the rule" as Joe points out.
> I'd say more: some script that would check for SPDX only at the
> first line won't work.
>
> The reason is simple: we have some scripts at the Kernel tree.
This is not a script, for those, it is fine to use the second line,
again, this is documented.
This isn't new at all, been that way since December of 2017, see commit
aa19a176df95 ("Documentation: Add license-rules.rst to describe how to
properly identify file licenses")
thanks,
greg k-h
[PATCH v2 3/5] pinctrl: mediatek: Refine mtk_pinconf_get() and mtk_pinconf_set()
From: Light Hsieh
1.Refine mtk_pinconf_get():
1.1 Use only one occurrence of return at end of this function.
1.2 Correct cases for PIN_CONFIG_SLEW_RATE, PIN_CONFIG_INPUT_SCHMITT_ENABLE,
and PIN_CONFIG_OUTPUT_ENABLE -
Use variable ret to receive value in mtk_hw_get_value() (instead of
variable val) since pinconf_to_config_packed() at end of this function
use variable ret to pack config value.
2.Refine mtk_pinconf_set():
2.1 Use only one occurrence of return at end of this function.
2.2 Modify case of PIN_CONFIG_INPUT_ENABLE -
Remove check of ies_present flag and always invoke mtk_hw_set_value()
since mtk_hw_pin_field_lookup() invoked inside mtk_hw_set_value() has
the same effect of checking if ies control is supported.
[The rationale is that: available of a control is always checked
in mtk_hw_pin_field_lookup() and no need to add ies_present flag
specially for ies control.]
2.3 Simply code logic for case of PIN_CONFIG_INPUT_SCHMITT.
2.4 Add case for PIN_CONFIG_INPUT_SCHMITT_ENABLE and process it with the
same code for case of PIN_CONFIG_INPUT_SCHMITT.
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c | 1 -
drivers/pinctrl/mediatek/pinctrl-paris.c | 204 +++---
2 files changed, 75 insertions(+), 130 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index e024ebc..bada37f 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1070,7 +1070,6 @@
.ngrps = ARRAY_SIZE(mtk_pins_mt6765),
.eint_hw = _eint_hw,
.gpio_m = 0,
- .ies_present = true,
.base_names = mt6765_pinctrl_register_base_names,
.nbase_names = ARRAY_SIZE(mt6765_pinctrl_register_base_names),
.bias_disable_set = mtk_pinconf_bias_disable_set,
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 71c94b2..bbe3f8a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -78,93 +78,75 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
{
struct mtk_pinctrl *hw = pinctrl_dev_get_drvdata(pctldev);
u32 param = pinconf_to_config_param(*config);
- int val, val2, err, reg, ret = 1;
+ int err, reg, ret = 1;
const struct mtk_pin_desc *desc;
desc = (const struct mtk_pin_desc *)>soc->pins[pin];
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
- if (hw->soc->bias_disable_get) {
+ if (hw->soc->bias_disable_get)
err = hw->soc->bias_disable_get(hw, desc, );
- if (err)
- return err;
- } else {
- return -ENOTSUPP;
- }
+ else
+ err = -ENOTSUPP;
break;
case PIN_CONFIG_BIAS_PULL_UP:
- if (hw->soc->bias_get) {
+ if (hw->soc->bias_get)
err = hw->soc->bias_get(hw, desc, 1, );
- if (err)
- return err;
- } else {
- return -ENOTSUPP;
- }
+ else
+ err = -ENOTSUPP;
break;
case PIN_CONFIG_BIAS_PULL_DOWN:
- if (hw->soc->bias_get) {
+ if (hw->soc->bias_get)
err = hw->soc->bias_get(hw, desc, 0, );
- if (err)
- return err;
- } else {
- return -ENOTSUPP;
- }
+ else
+ err = -ENOTSUPP;
break;
case PIN_CONFIG_SLEW_RATE:
- err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_SR, );
- if (err)
- return err;
-
- if (!val)
- return -EINVAL;
-
+ err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_SR, );
break;
case PIN_CONFIG_INPUT_ENABLE:
case PIN_CONFIG_OUTPUT_ENABLE:
- err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
+ err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
if (err)
- return err;
-
- /* HW takes input mode as zero; output mode as non-zero */
- if ((val && param == PIN_CONFIG_INPUT_ENABLE) ||
- (!val && param == PIN_CONFIG_OUTPUT_ENABLE))
- return -EINVAL;
+ goto out;
+ /* CONFIG Current direction return value
+* - - --
+* OUTPUT_ENABLE output 1 (= HW value)
+* input0 (= HW value)
+*
[PATCH v2 1/5] pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()
From: Light Hsieh
1. Check if gpio pin number is in valid range to prevent from get invalid
pointer 'desc' in the following code:
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
2. Use binary search in mtk_hw_pin_field_lookup()
Modify mtk_hw_pin_field_lookup() to use binary search for accelerating
search.
---
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 24 +++-
drivers/pinctrl/mediatek/pinctrl-paris.c | 19 +++
2 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 20e1c89..4687f63 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -68,7 +68,7 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
{
const struct mtk_pin_field_calc *c, *e;
const struct mtk_pin_reg_calc *rc;
- u32 bits;
+ u32 bits, start = 0, end, found = 0, check;
if (hw->soc->reg_cal && hw->soc->reg_cal[field].range) {
rc = >soc->reg_cal[field];
@@ -79,21 +79,32 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
return -ENOTSUPP;
}
+ end = rc->nranges - 1;
c = rc->range;
e = c + rc->nranges;
- while (c < e) {
- if (desc->number >= c->s_pin && desc->number <= c->e_pin)
+ while (start <= end) {
+ check = (start + end) >> 1;
+ if (desc->number >= rc->range[check].s_pin
+&& desc->number <= rc->range[check].e_pin) {
+ found = 1;
break;
- c++;
+ } else if (start == end)
+ break;
+ else if (desc->number < rc->range[check].s_pin)
+ end = check - 1;
+ else
+ start = check + 1;
}
- if (c >= e) {
+ if (!found) {
dev_dbg(hw->dev, "Not support field %d for pin = %d (%s)\n",
field, desc->number, desc->name);
return -ENOTSUPP;
}
+ c = rc->range + check;
+
if (c->i_base > hw->nbase - 1) {
dev_err(hw->dev,
"Invalid base for field %d for pin = %d (%s)\n",
@@ -182,6 +193,9 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const struct
mtk_pin_desc *desc,
if (err)
return err;
+ if (value < 0 || value > pf.mask)
+ return -EINVAL;
+
if (!pf.next)
mtk_rmw(hw, pf.index, pf.offset, pf.mask << pf.bitpos,
(value & pf.mask) << pf.bitpos);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 923264d..28b4951 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -693,6 +693,9 @@ static int mtk_gpio_get_direction(struct gpio_chip *chip,
unsigned int gpio)
const struct mtk_pin_desc *desc;
int value, err;
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
@@ -708,6 +711,9 @@ static int mtk_gpio_get(struct gpio_chip *chip, unsigned
int gpio)
const struct mtk_pin_desc *desc;
int value, err;
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DI, );
@@ -722,6 +728,9 @@ static void mtk_gpio_set(struct gpio_chip *chip, unsigned
int gpio, int value)
struct mtk_pinctrl *hw = gpiochip_get_data(chip);
const struct mtk_pin_desc *desc;
+ if (gpio > hw->soc->npins)
+ return;
+
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DO, !!value);
@@ -729,12 +738,22 @@ static void mtk_gpio_set(struct gpio_chip *chip, unsigned
int gpio, int value)
static int mtk_gpio_direction_input(struct gpio_chip *chip, unsigned int gpio)
{
+ struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
return pinctrl_gpio_direction_input(chip->base + gpio);
}
static int mtk_gpio_direction_output(struct gpio_chip *chip, unsigned int gpio,
int value)
{
+ struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
mtk_gpio_set(chip, gpio, value);
return pinctrl_gpio_direction_output(chip->base + gpio);
--
1.8.1.1.dirty
[PATCH v2 4/5] pinctrl: mediatek: Backward compatible to previous Mediatek's bias-pull usage
From: Light Hsieh
Refine mtk_pinconf_set()/mtk_pinconf_get() for backward compatibility to
previous Mediatek's bias-pull usage.
In PINCTRL_MTK that use pinctrl-mtk-common.c, bias-pull setting for pins
with 2 pull resistors can be specified as value for bias-pull-up and
bias-pull-down. For example:
bias-pull-up = ;
bias-pull-up = ;
bias-pull-up = ;
bias-pull-up = ;
bias-pull-down = ;
bias-pull-down = ;
bias-pull-down = ;
bias-pull-down = ;
On the other hand, PINCTRL_MTK_PARIS use customized properties
"mediatek,pull-up-adv" and "mediatek,pull-down-adv" to specify bias-pull
setting for pins with 2 pull resistors.
This introduce in-compatibility in device tree and increatse porting
effort to Mediatek's customer that had already used PINCTRL_MTK version.
Besides, if customers are not awared of this change and still write devicetree
for PINCTRL_MTK version, they may encounter runtime failure with pinctrl and
spent time to debug.
This patch add backward compatible to previous Mediatek's bias-pull usage
so that Mediatek's customer need not use a new devicetree property name.
The rationale is that: changing driver implemenation had better leave
interface unchanged.
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c| 4 +-
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 285 +++
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 11 +
drivers/pinctrl/mediatek/pinctrl-paris.c | 49 ++--
4 files changed, 327 insertions(+), 22 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index bada37f..315aebd 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1074,8 +1074,8 @@
.nbase_names = ARRAY_SIZE(mt6765_pinctrl_register_base_names),
.bias_disable_set = mtk_pinconf_bias_disable_set,
.bias_disable_get = mtk_pinconf_bias_disable_get,
- .bias_set = mtk_pinconf_bias_set,
- .bias_get = mtk_pinconf_bias_get,
+ .bias_set = mtk_pinconf_bias_set_combo,
+ .bias_get = mtk_pinconf_bias_get_combo,
.drive_set = mtk_pinconf_drive_set_direct_val,
.drive_get = mtk_pinconf_drive_get_direct_val,
.adv_pull_get = mtk_pinconf_adv_pull_get,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 23a9529..dab8418 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -13,6 +13,8 @@
#include
#include
+#include
+
#include "mtk-eint.h"
#include "pinctrl-mtk-common-v2.h"
@@ -205,6 +207,20 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const struct
mtk_pin_desc *desc,
return 0;
}
+void mtk_hw_set_value_no_lookup(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc,
+ int value, struct mtk_pin_field *pf)
+{
+ if (value < 0 || value > pf->mask)
+ return;
+
+ if (!pf->next)
+ mtk_rmw(hw, pf->index, pf->offset, pf->mask << pf->bitpos,
+ (value & pf->mask) << pf->bitpos);
+ else
+ mtk_hw_write_cross_field(hw, pf, value);
+}
+
int mtk_hw_get_value(struct mtk_pinctrl *hw, const struct mtk_pin_desc *desc,
int field, int *value)
{
@@ -224,6 +240,17 @@ int mtk_hw_get_value(struct mtk_pinctrl *hw, const struct
mtk_pin_desc *desc,
return 0;
}
+void mtk_hw_get_value_no_lookup(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc,
+ int *value, struct mtk_pin_field *pf)
+{
+ if (!pf->next)
+ *value = (mtk_r32(hw, pf->index, pf->offset)
+ >> pf->bitpos) & pf->mask;
+ else
+ mtk_hw_read_cross_field(hw, pf, value);
+}
+
static int mtk_xt_find_eint_num(struct mtk_pinctrl *hw, unsigned long eint_n)
{
const struct mtk_pin_desc *desc;
@@ -516,6 +543,264 @@ int mtk_pinconf_bias_get_rev1(struct mtk_pinctrl *hw,
return 0;
}
+/* Combo for the following pull register type:
+ * 1. PU + PD
+ * 2. PULLSEL + PULLEN
+ * 3. PUPD + R0 + R1
+ */
+int mtk_pinconf_bias_set_pu_pd(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc,
+ u32 pullup, u32 arg)
+{
+ struct mtk_pin_field pf;
+ int err = -EINVAL;
+ int pu, pd;
+
+ err = mtk_hw_pin_field_lookup(hw, desc, PINCTRL_PIN_REG_PU, );
+ if (err)
+ goto out;
+
+ if (arg == MTK_DISABLE) {
+ pu = 0;
+ pd = 0;
+ } else if ((arg == MTK_ENABLE) && pullup) {
+ pu = 1;
+ pd = 0;
+ } else if ((arg == MTK_ENABLE) && !pullup) {
+ pu = 0;
+ pd = 1;
+ } else {
+ goto out;
+ }
+
+
[PATCH v2 2/5] pinctrl: mediatek: Supporting driving setting without mapping current to register value
From: Light Hsieh
Mediatek's smarphone project actual usage does need to know current value
(in mA) in procedure of finding the best driving setting.
The steps in the procedure is like as follow:
1. set driving setting field in setting register as 0, measure waveform,
perform test, and etc.
2. set driving setting field in setting register as 1, measure waveform,
perform test, and etc.
...
n. set driving setting field in setting register as n-1, measure
waveform, perform test, and etc.
Check the results of steps 1~n and adopt the setting that get best result.
This procedure does need to know the mapping between current to register
value.
Therefore, setting driving without mapping current is more pratical for
Mediatek's smartphone usage.
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c| 4 ++--
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 21 +
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 5 +
drivers/pinctrl/mediatek/pinctrl-paris.c | 1 +
4 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index 32451e8..e024ebc 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1077,8 +1077,8 @@
.bias_disable_get = mtk_pinconf_bias_disable_get,
.bias_set = mtk_pinconf_bias_set,
.bias_get = mtk_pinconf_bias_get,
- .drive_set = mtk_pinconf_drive_set_rev1,
- .drive_get = mtk_pinconf_drive_get_rev1,
+ .drive_set = mtk_pinconf_drive_set_direct_val,
+ .drive_get = mtk_pinconf_drive_get_direct_val,
.adv_pull_get = mtk_pinconf_adv_pull_get,
.adv_pull_set = mtk_pinconf_adv_pull_set,
};
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 4687f63..23a9529 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -607,6 +607,27 @@ int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
return 0;
}
+/* Revision direct value */
+int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, u32 arg)
+{
+ int err;
+
+ err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV, arg);
+
+ return err;
+}
+
+int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, int *val)
+{
+ int err;
+
+ err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV, val);
+
+ return err;
+}
+
int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
const struct mtk_pin_desc *desc, bool pullup,
u32 arg)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 1b7da42..b3bada0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -288,6 +288,11 @@ int mtk_pinconf_drive_set_rev1(struct mtk_pinctrl *hw,
int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
const struct mtk_pin_desc *desc, int *val);
+int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, int *val);
+
int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
const struct mtk_pin_desc *desc, bool pullup,
u32 arg);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 28b4951..71c94b2 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -964,3 +964,4 @@ static int mtk_paris_pinctrl_resume(struct device *device)
.suspend_noirq = mtk_paris_pinctrl_suspend,
.resume_noirq = mtk_paris_pinctrl_resume,
};
+
--
1.8.1.1.dirty
[PATCH v2 5/5] pinctrl: mediatek: Add support for pin configuration dump via debugfs.
From: Light Hsieh
Add support for pin configuration dump via catting
/sys/kernel/debug/pinctrl/$platform_dependent_path/pinconf-pins.
pinctrl framework had already support such dump. This patch implement the
operation function pointer to fullfill this dump.
---
drivers/pinctrl/mediatek/pinctrl-paris.c | 88
drivers/pinctrl/mediatek/pinctrl-paris.h | 30 +++
2 files changed, 118 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 0a9440a..91d6e72 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -531,12 +531,99 @@ static int mtk_pctrl_get_group_pins(struct pinctrl_dev
*pctldev,
return 0;
}
+int mtk_hw_get_value_wrap(struct mtk_pinctrl *hw, unsigned int gpio, int field)
+{
+ const struct mtk_pin_desc *desc;
+ int value, err;
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
+ desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
+
+ err = mtk_hw_get_value(hw, desc, field, );
+ if (err)
+ return err;
+
+ return value;
+}
+
+ssize_t mtk_pctrl_show_one_pin(struct mtk_pinctrl *hw,
+ unsigned int gpio, char *buf, unsigned int bufLen)
+{
+ const struct mtk_pin_desc *desc;
+ int pinmux, pullup, pullen, r1 = -1, r0 = -1, len = 0;
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
+ desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
+ pinmux = mtk_pctrl_get_pinmux(hw, gpio);
+ if (pinmux >= hw->soc->nfuncs)
+ pinmux -= hw->soc->nfuncs;
+
+ mtk_pinconf_bias_get_combo(hw, desc, , );
+ if (pullen == MTK_PUPD_SET_R1R0_00) {
+ pullen = 0;
+ r1 = 0;
+ r0 = 0;
+ } else if (pullen == MTK_PUPD_SET_R1R0_01) {
+ pullen = 1;
+ r1 = 0;
+ r0 = 1;
+ } else if (pullen == MTK_PUPD_SET_R1R0_10) {
+ pullen = 1;
+ r1 = 1;
+ r0 = 0;
+ } else if (pullen == MTK_PUPD_SET_R1R0_11) {
+ pullen = 1;
+ r1 = 1;
+ r0 = 1;
+ } else if (pullen != MTK_DISABLE && pullen != MTK_ENABLE) {
+ pullen = 0;
+ }
+ len += snprintf(buf + len, bufLen - len,
+ "%03d: %1d%1d%1d%1d%02d%1d%1d%1d%1d",
+ gpio,
+ pinmux,
+ mtk_pctrl_get_direction(hw, gpio),
+ mtk_pctrl_get_out(hw, gpio),
+ mtk_pctrl_get_in(hw, gpio),
+ mtk_pctrl_get_driving(hw, gpio),
+ mtk_pctrl_get_smt(hw, gpio),
+ mtk_pctrl_get_ies(hw, gpio),
+ pullen,
+ pullup);
+
+ if (r1 != -1) {
+ len += snprintf(buf + len, bufLen - len, " (%1d %1d)\n",
+ r1, r0);
+ } else {
+ len += snprintf(buf + len, bufLen - len, "\n");
+ }
+
+ return len;
+}
+
+#define PIN_DBG_BUF_SZ 96
+static void mtk_pctrl_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
+ unsigned int gpio)
+{
+ struct mtk_pinctrl *hw = pinctrl_dev_get_drvdata(pctldev);
+ char buf[PIN_DBG_BUF_SZ];
+
+ (void)mtk_pctrl_show_one_pin(hw, gpio, buf, PIN_DBG_BUF_SZ);
+
+ seq_printf(s, "%s", buf);
+}
+
static const struct pinctrl_ops mtk_pctlops = {
.dt_node_to_map = mtk_pctrl_dt_node_to_map,
.dt_free_map= pinctrl_utils_free_map,
.get_groups_count = mtk_pctrl_get_groups_count,
.get_group_name = mtk_pctrl_get_group_name,
.get_group_pins = mtk_pctrl_get_group_pins,
+ .pin_dbg_show = mtk_pctrl_dbg_show,
};
static int mtk_pmx_get_funcs_cnt(struct pinctrl_dev *pctldev)
@@ -633,6 +720,7 @@ static int mtk_pconf_group_set(struct pinctrl_dev *pctldev,
unsigned group,
.pin_config_get = mtk_pinconf_get,
.pin_config_group_get = mtk_pconf_group_get,
.pin_config_group_set = mtk_pconf_group_set,
+ .is_generic = true,
};
static struct pinctrl_desc mtk_desc = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.h
b/drivers/pinctrl/mediatek/pinctrl-paris.h
index 3d43771..d73f4b6 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.h
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.h
@@ -60,6 +60,36 @@
int mtk_paris_pinctrl_probe(struct platform_device *pdev,
const struct mtk_pin_soc *soc);
+int mtk_hw_get_value_wrap(struct mtk_pinctrl *hw, unsigned int gpio, int
field);
+
+#define mtk_pctrl_get_pinmux(hw, gpio) \
+ mtk_hw_get_value_wrap(hw, gpio, PINCTRL_PIN_REG_MODE)
+
+/* MTK HW use 0 as input, 1 for output
+ * This interface is for get direct register value,
+ * so don't
[PATCH v2] drm/amdgpu: Remove two redundant null pointer checks
The functions "debugfs_remove" and "kfree" tolerate the passing
of null pointers. Hence it is unnecessary to check such arguments
around the calls. Thus remove the extra condition check at two places.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 5652cc7..cb94627 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1077,8 +1077,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
- if (fences)
- kfree(fences);
+ kfree(fences);
return 0;
}
@@ -1103,8 +1102,7 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
void amdgpu_debugfs_preempt_cleanup(struct amdgpu_device *adev)
{
- if (adev->debugfs_preempt)
- debugfs_remove(adev->debugfs_preempt);
+ debugfs_remove(adev->debugfs_preempt);
}
#else
--
1.7.12.4
[PATCH] ARM: Add support for Realtek SOC
From: "james.tai"
This patch adds the basic machine file for
the Realtek RTD16XX platform.
Signed-off-by: james.tai
---
arch/arm/Kconfig| 2 +
arch/arm/Makefile | 2 +
arch/arm/mach-realtek/Kconfig | 32
arch/arm/mach-realtek/Makefile | 3 ++
arch/arm/mach-realtek/platsmp.c | 91 +
arch/arm/mach-realtek/platsmp.h | 7 +++
arch/arm/mach-realtek/realtek.c | 78
7 files changed, 215 insertions(+)
create mode 100644 arch/arm/mach-realtek/Kconfig
create mode 100644 arch/arm/mach-realtek/Makefile
create mode 100644 arch/arm/mach-realtek/platsmp.c
create mode 100644 arch/arm/mach-realtek/platsmp.h
create mode 100644 arch/arm/mach-realtek/realtek.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..c7c9a3662eb7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -836,6 +836,8 @@ source "arch/arm/mach-zx/Kconfig"
source "arch/arm/mach-zynq/Kconfig"
+source "arch/arm/mach-realtek/Kconfig"
+
# ARMv7-M architecture
config ARCH_EFM32
bool "Energy Micro efm32"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..1f0926449d47 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -148,6 +148,7 @@ endif
textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
textofs-$(CONFIG_ARCH_MESON) := 0x00208000
+textofs-$(CONFIG_ARCH_REALTEK) := 0x00208000
textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
# Machine directory name. This list is sorted alphanumerically
@@ -225,6 +226,7 @@ machine-$(CONFIG_ARCH_VT8500) += vt8500
machine-$(CONFIG_ARCH_W90X900) += w90x900
machine-$(CONFIG_ARCH_ZX) += zx
machine-$(CONFIG_ARCH_ZYNQ)+= zynq
+machine-$(CONFIG_ARCH_REALTEK) += realtek
machine-$(CONFIG_PLAT_SPEAR) += spear
# Platform directory name. This list is sorted alphanumerically
diff --git a/arch/arm/mach-realtek/Kconfig b/arch/arm/mach-realtek/Kconfig
new file mode 100644
index ..a8269964dbdb
--- /dev/null
+++ b/arch/arm/mach-realtek/Kconfig
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menuconfig ARCH_REALTEK
+ bool "Realtek SoCs"
+ select ARM_GLOBAL_TIMER
+ select CLKDEV_LOOKUP
+ select HAVE_SMP
+ select HAVE_MACH_CLKDEV
+ select GENERIC_CLOCKEVENTS
+ select HAVE_SCHED_CLOCK
+ select ARCH_HAS_CPUFREQ
+ select CLKSRC_OF
+ select ARCH_REQUIRE_GPIOLIB
+ select GENERIC_IRQ_CHIP
+ select IRQ_DOMAIN
+ select PINCTRL
+ select COMMON_CLK
+ select ARCH_HAS_BARRIERS
+ select SPARSE_IRQ
+ select PM_OPP
+ select ARM_HAS_SG_CHAIN
+ select ARM_PATCH_PHYS_VIRT
+ select AUTO_ZRELADDR
+ select MIGHT_HAVE_PCI
+ select MULTI_IRQ_HANDLER
+ select PCI_DOMAINS if PCI
+ select USE_OF
+
+config ARCH_RTD16XX
+ bool "Enable support for RTD1619"
+ depends on ARCH_REALTEK
+ select ARM_GIC_V3
+ select ARM_PSCI
diff --git a/arch/arm/mach-realtek/Makefile b/arch/arm/mach-realtek/Makefile
new file mode 100644
index ..9cdc1f1f2917
--- /dev/null
+++ b/arch/arm/mach-realtek/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ARCH_REALTEK) += realtek.o
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-realtek/platsmp.c b/arch/arm/mach-realtek/platsmp.c
new file mode 100644
index ..5c4368fe1520
--- /dev/null
+++ b/arch/arm/mach-realtek/platsmp.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BL31_CMD 0x8400ff04
+#define BL31_DAT 0x1619
+#define CPUID 28
+#define CORE_PWRDN_EN 0x1
+
+#define CPUPWRCTLR __ACCESS_CP15(c15, 0, c2, 7)
+
+static u32 __iomem *cpu_release_virt;
+
+static int rtk_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ unsigned long entry_pa = __pa_symbol(secondary_startup);
+
+ writel_relaxed(entry_pa | (cpu << CPUID), cpu_release_virt);
+
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ return 0;
+}
+
+void rtk_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *np;
+ u32 release_phys;
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+
+ np = of_get_cpu_node(cpu, NULL);
+ if (!np)
+ continue;
+
+ if (of_property_read_u32(np, "cpu-release-addr", _phys))
+ continue;
+
+ cpu_release_virt = ioremap(release_phys, sizeof(u32));
+
+ set_cpu_present(cpu, true);
+ }
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+
+static void rtk_cpu_die(unsigned int cpu)
+{
+ struct arm_smccc_res res;
+ unsigned int cpu_pwr_ctrl;
+
+
[PATCH] mips: sgi-ip27: switch from DISCONTIGMEM to SPARSEMEM
From: Mike Rapoport The memory initialization of SGI-IP27 is already half-way to support SPARSEMEM and only a call to sparse_init() was missing. Add it to prom_meminit() and adjust arch/mips/Kconfig to enable SPARSEMEM and SPARSEMEM_EXTREME for SGI-IP27 Signed-off-by: Mike Rapoport --- Thomas, could you please test this on your Origin machine? arch/mips/Kconfig| 12 ++-- arch/mips/sgi-ip27/ip27-memory.c | 2 ++ 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d50fafd..e4b02b5 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -669,6 +669,7 @@ config SGI_IP22 config SGI_IP27 bool "SGI IP27 (Origin200/2000)" select ARCH_HAS_PHYS_TO_DMA + select ARCH_SPARSEMEM_ENABLE select FW_ARC select FW_ARC64 select BOOT_ELF64 @@ -2633,18 +2634,9 @@ config ARCH_FLATMEM_ENABLE def_bool y depends on !NUMA && !CPU_LOONGSON2 -config ARCH_DISCONTIGMEM_ENABLE - bool - default y if SGI_IP27 - help - Say Y to support efficient handling of discontiguous physical memory, - for architectures which are either NUMA (Non-Uniform Memory Access) - or have huge holes in the physical address space for other reasons. - See for more. - config ARCH_SPARSEMEM_ENABLE bool - select SPARSEMEM_STATIC + select SPARSEMEM_STATIC if !SGI_IP27 config NUMA bool "NUMA Support" diff --git a/arch/mips/sgi-ip27/ip27-memory.c b/arch/mips/sgi-ip27/ip27-memory.c index fb077a9..a8ddebc 100644 --- a/arch/mips/sgi-ip27/ip27-memory.c +++ b/arch/mips/sgi-ip27/ip27-memory.c @@ -444,6 +444,8 @@ void __init prom_meminit(void) } __node_data[node] = _node; } + + sparse_init(); } void __init prom_free_prom_memory(void) -- 2.7.4
Re: drm/amdgpu: remove the redundant null check
On 2019/9/5 1:50, Markus Elfring wrote: >> debugfs_remove and kfree has taken the null check in account. >> hence it is unnecessary to check it. Just remove the condition. > How do you think about a wording like the following? > > The functions “debugfs_remove” and “kfree” tolerate the passing > of null pointers. Hence it is unnecessary to check such arguments > around the calls. Thus remove the extra condition check at two places. > It's better, Thanks >> No functional change. > I find this information questionable while it is partly reasonable > according to the shown software refactoring. > > Can a subject like “[PATCH] drm/amdgpu: Remove two redundant > null pointer checks” be nicer here? > It's more clearer, thanks, Will repost using above description in v2. > Were any source code analysis tools involved for finding > these update candidates? With the help of Coccinelle. You can find out some example in scripts/coccinelle/. Sincerely, zhong jiang > Regards, > Markus > > . >
Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition
> On Sep 4, 2019, at 5:18 PM, Nick Desaulniers wrote:
>
> On Fri, Aug 30, 2019 at 4:15 PM Rasmus Villemoes
> wrote:
>> This adds an asm_inline macro which expands to "asm inline" [1] when gcc
>> is new enough (>= 9.1), and just asm for older gccs and other
>> compilers.
>>
>> Using asm inline("foo") instead of asm("foo") overrules gcc's
>> heuristic estimate of the size of the code represented by the asm()
>> statement, and makes gcc use the minimum possible size instead. That
>> can in turn affect gcc's inlining decisions.
>>
>> I wasn't sure whether to make this a function-like macro or not - this
>> way, it can be combined with volatile as
>>
>> asm_inline volatile()
>>
>> but perhaps we'd prefer to spell that
>>
>> asm_inline_volatile()
>>
>> anyway.
>>
>> [1] Technically, asm __inline, since both inline and __inline__
>> are macros that attach various attributes, making gcc barf if one
>> literally does "asm inline()". However, the third spelling __inline is
>> available for referring to the bare keyword.
>>
>> Signed-off-by: Rasmus Villemoes
>> ---
>> include/linux/compiler-gcc.h | 4
>> include/linux/compiler_types.h | 4
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index d7ee4c6bad48..544b87b41b58 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/include/linux/compiler-gcc.h
>> @@ -172,3 +172,7 @@
>> #endif
>>
>> #define __no_fgcse __attribute__((optimize("-fno-gcse")))
>> +
>> +#if GCC_VERSION >= 90100
>
> Is it too late to ask for a feature test macro? Maybe one already
> exists? I was not able to find documentation or a bug on `asm
> inline`. I'm quite curious how you even found or heard of this
> feature. To the source we must go...
When I had some free time I wrote a detailed blog post about this issue:
https://nadav.amit.zone/linux/2018/10/10/newline.html
Which later Borislav took to gcc people:
https://lore.kernel.org/lkml/20181007091805.ga30...@zn.tnic/
Re: [PATCH 1/1] x86/purgatory: Change compiler flags to avoid relocation errors.
On Wed, Sep 4, 2019 at 3:19 PM Nick Desaulniers wrote:
>
> + (folks recommended by ./scripts/get_maintainer.pl )
> (See also, step 7:
> https://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/)
>
> On Wed, Sep 4, 2019 at 2:45 PM Steve Wahl wrote:
> >
> > The last change to this Makefile caused relocation errors when loading
>
> It's good to add a fixes tag like below when a patch fixes a
> regression, so that stable backports the fix as far back as the
> regression:
> Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than
> reset KBUILD_CFLAGS")
>
> > a kdump kernel. This change restores the appropriate flags, without
> > reverting to the former practice of resetting KBUILD_CFLAGS.
> >
> > Signed-off-by: Steve Wahl
> > ---
> > arch/x86/purgatory/Makefile | 35 +++
> > 1 file changed, 19 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> > index 8901a1f89cf5..9f0bfef1f5db 100644
> > --- a/arch/x86/purgatory/Makefile
> > +++ b/arch/x86/purgatory/Makefile
> > @@ -18,37 +18,40 @@ targets += purgatory.ro
> > KASAN_SANITIZE := n
> > KCOV_INSTRUMENT := n
> >
> > +# These are adjustments to the compiler flags used for objects that
> > +# make up the standalone porgatory.ro
> > +
> > +PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
> > +PURGATORY_CFLAGS := -mcmodel=large -ffreestanding
> > -fno-zero-initialized-in-bss
>
> Thanks for confirming the fix. While it sounds like -mcmodel=large is
> the only necessary change, I don't object to -ffreestanding of
> -fno-zero-initialized-in-bss being readded, especially since I think
> what you've done with PURGATORY_CFLAGS_REMOVE is more concise.
Without -ffreestanding this results in undefined symbols (as before this patch)
$ readelf -a arch/x86/purgatory/purgatory.ro|grep UND
0: 0 NOTYPE LOCAL DEFAULT UND
51: 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_fail
I just bumped into this issue as I discovered that kexec() no longer works after
the x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS -commit
was merged.
回收: [PATCH] Bluetooth: btrtl: Fix an issue that failing to download the FW which size is over 32K bytes
Max Chou 希望回收這封郵件 [[PATCH] Bluetooth: btrtl: Fix an issue that failing to download the FW which size is over 32K bytes]。
[PATCH v2] Bluetooth: btrtl: Fix an issue that failing to download the FW which size is over 32K bytes
From: Max Chou
Fix the issue that when the FW size is 32K+, it will fail for the download
process because of the incorrect index.
When firmware patch length is over 32K, "dl_cmd->index" may >= 0x80. It
will be thought as "data end" that download process will not complete.
However, driver should recount the index from 1.
Signed-off-by: Max Chou
---
Changes in v2:
- Added the comment for commit message
- Remove the extra variable
drivers/bluetooth/btrtl.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 0354e93e7a7c..bf3c02be6930 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -401,7 +401,11 @@ static int rtl_download_firmware(struct hci_dev *hdev,
BT_DBG("download fw (%d/%d)", i, frag_num);
- dl_cmd->index = i;
+ if (i > 0x7f)
+ dl_cmd->index = (i & 0x7f) + 1;
+ else
+ dl_cmd->index = i;
+
if (i == (frag_num - 1)) {
dl_cmd->index |= 0x80; /* data end */
frag_len = fw_len % RTL_FRAG_LEN;
--
2.17.1
Re: [PATCH -next 35/36] spi: zynq-qspi: use devm_platform_ioremap_resource() to simplify code
On 04. 09. 19 15:59, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> drivers/spi/spi-zynq-qspi.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
> index 4a5326c..5cf6993 100644
> --- a/drivers/spi/spi-zynq-qspi.c
> +++ b/drivers/spi/spi-zynq-qspi.c
> @@ -620,7 +620,6 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> struct device *dev = >dev;
> struct device_node *np = dev->of_node;
> struct zynq_qspi *xqspi;
> - struct resource *res;
> u32 num_cs;
>
> ctlr = spi_alloc_master(>dev, sizeof(*xqspi));
> @@ -630,8 +629,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> xqspi = spi_controller_get_devdata(ctlr);
> xqspi->dev = dev;
> platform_set_drvdata(pdev, xqspi);
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - xqspi->regs = devm_ioremap_resource(>dev, res);
> + xqspi->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(xqspi->regs)) {
> ret = PTR_ERR(xqspi->regs);
> goto remove_master;
>
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH -next 34/36] spi: zynqmp: use devm_platform_ioremap_resource() to simplify code
On 04. 09. 19 15:59, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> drivers/spi/spi-zynqmp-gqspi.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
> index 5e9ea8a..60c4de4 100644
> --- a/drivers/spi/spi-zynqmp-gqspi.c
> +++ b/drivers/spi/spi-zynqmp-gqspi.c
> @@ -1016,7 +1016,6 @@ static int zynqmp_qspi_probe(struct platform_device
> *pdev)
> int ret = 0;
> struct spi_master *master;
> struct zynqmp_qspi *xqspi;
> - struct resource *res;
> struct device *dev = >dev;
>
> eemi_ops = zynqmp_pm_get_eemi_ops();
> @@ -1031,8 +1030,7 @@ static int zynqmp_qspi_probe(struct platform_device
> *pdev)
> master->dev.of_node = pdev->dev.of_node;
> platform_set_drvdata(pdev, master);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - xqspi->regs = devm_ioremap_resource(>dev, res);
> + xqspi->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(xqspi->regs)) {
> ret = PTR_ERR(xqspi->regs);
> goto remove_master;
>
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH v2 5/5] misc: fastrpc: free dma buf scatter list
Quoting Srinivas Kandagatla (2019-08-29 02:29:26) > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > index eee2bb398947..47ae84afac2e 100644 > --- a/drivers/misc/fastrpc.c > +++ b/drivers/misc/fastrpc.c > @@ -550,6 +550,7 @@ static void fastrpc_dma_buf_detatch(struct dma_buf > *dmabuf, Is the function really called buf_detatch? Is it supposed to be buf_detach? > mutex_lock(>lock); > list_del(>node); > mutex_unlock(>lock); > + sg_free_table(>sgt); > kfree(a);
Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees
On Wed, 04 Sep 2019, Michel Lespinasse wrote: Hi Davidlohr, On Wed, Sep 4, 2019 at 5:52 PM Davidlohr Bueso wrote: Ok, so for that I've added the following helper which will make the conversion a bit more straightforward: #define vma_interval_tree_foreach_stab(vma, root, start) vma_interval_tree_foreach(vma, root, start, start) Yes, that should help with the conversion :) I think this also makes sense as it documents the nature of the lookup. Because this is a nice helper regardless of the interval tree stuff, I went ahead and sent a patch as well as the conversion, which is quite trivial, and hopefully akpm can pick it up for -next; which makes one less patch to carry when doing the interval tree conversion series. Thanks, Davidlohr
Re: [PATCH] gpiolib: acpi: make acpi_can_fallback_to_crs() static
On Wed, Sep 04, 2019 at 10:26:24AM -0700, Dmitry Torokhov wrote: > It is not used outside gpiolib-acpi.c module, so there is no need to > export it. > > Signed-off-by: Dmitry Torokhov Acked-by: Mika Westerberg
Re: [RFC v2 0/3] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
On 04-09-19, 10:53, H. Nikolaus Schaller wrote: > Changes V2: > * merge separate patch to remove opp-v1 table from n950-n9 into > the general omap3xxx.dtsi patch > * add legacy compatibility to ti,omap3430 and ti,omap3630 for > the ti-cpufreq driver > * make driver and omap3xxx.dtsi patches pass checkpatch > * add bulk patch to explicitly define compatibility to ti,omap3430 > and ti,omap36xx in addition to ti,omap3 of all in-tree boards > where it was missing > > RFC V1 2019-09-02 12:55:55: > > This patch set converts the opp tables to opp-v2 format > and extends the ti-cpufreq to support omap3. > > It adds 720 MHz (omap34xx) and 1 GHz (omap36xx) OPPs but > tells the ti-cpufreq driver to disable them if the speed > binned / 720MHz grade eFuse bits indicate that the chip > is not rated for that speed. > > It has been tested (for chip variant detection, not reliability > of the high speed OPPs) on: > > * BeagleBoard C2 (omap3430 600MHz) > * BeagleBoard XM B (dm3730 800MHz) > * GTA04A4 (dm3730 800MHz) > * GTA04A5 (dm3730 1GHz) > > > H. Nikolaus Schaller (3): > cpufreq: ti-cpufreq: add support for omap34xx and omap36xx > ARM: dts: replace opp-v1 tables by opp-v2 for omap34xx and omap36xx > ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 > or ti,omap36xx > > arch/arm/boot/dts/am3517_mt_ventoux.dts | 2 +- > .../boot/dts/logicpd-som-lv-35xx-devkit.dts | 2 +- > .../boot/dts/logicpd-som-lv-37xx-devkit.dts | 2 +- > .../boot/dts/logicpd-torpedo-35xx-devkit.dts | 2 +- > .../boot/dts/logicpd-torpedo-37xx-devkit.dts | 2 +- > arch/arm/boot/dts/omap3-beagle.dts| 2 +- > arch/arm/boot/dts/omap3-cm-t3530.dts | 2 +- > arch/arm/boot/dts/omap3-devkit8000-lcd43.dts | 2 +- > arch/arm/boot/dts/omap3-devkit8000-lcd70.dts | 2 +- > arch/arm/boot/dts/omap3-devkit8000.dts| 2 +- > arch/arm/boot/dts/omap3-evm-37xx.dts | 2 +- > arch/arm/boot/dts/omap3-ha-lcd.dts| 2 +- > arch/arm/boot/dts/omap3-ha.dts| 2 +- > arch/arm/boot/dts/omap3-ldp.dts | 2 +- > arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -- > arch/arm/boot/dts/omap3-sbc-t3530.dts | 2 +- > arch/arm/boot/dts/omap3-thunder.dts | 2 +- > arch/arm/boot/dts/omap3430-sdp.dts| 2 +- > arch/arm/boot/dts/omap34xx.dtsi | 65 -- > arch/arm/boot/dts/omap36xx.dtsi | 53 +-- > drivers/cpufreq/cpufreq-dt-platdev.c | 2 +- > drivers/cpufreq/ti-cpufreq.c | 87 ++- > 22 files changed, 204 insertions(+), 44 deletions(-) Most of the stuff looks fine to me here. I will pick the patches when the SoC maintainers provide an Ack. -- viresh
Re: [PATCH v2 0/9] Exynos Adaptive Supply Voltage support
On 04-09-19, 14:37, Sylwester Nawrocki wrote: > I have changed the code to use dev_pm_opp_adjust_voltage(). I was wondering > though, what did you mean by "triplet" when commenting on this patch > https://patchwork.kernel.org/patch/11092245 ? The voltage value in the OPP core is stored as a triplet, min/max/target kind of stuff. You can check DT binding for OPPs and see the details. That's called as triplet. -- viresh
[PATCH -next] mm: introduce vma_interval_tree_foreach_stab()
This documents better the nature of the stab lookup/query.
In addition, this is a step that will make the conversion
of interval tree nodes from [a,b] to [a,b[ easier to review.
For symmetry with vma_interval_tree, the anon equivalent is
also introduced, albeit a single user. This patch does not
change any semantics.
Signed-off-by: Davidlohr Bueso
---
arch/arm/mm/fault-armv.c | 2 +-
arch/arm/mm/flush.c| 2 +-
arch/nios2/mm/cacheflush.c | 2 +-
arch/parisc/kernel/cache.c | 2 +-
fs/dax.c | 2 +-
include/linux/mm.h | 6 ++
kernel/events/uprobes.c| 2 +-
mm/hugetlb.c | 4 ++--
mm/khugepaged.c| 2 +-
mm/memory-failure.c| 6 ++
10 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c
index ae857f41f68d..85bb69f1decb 100644
--- a/arch/arm/mm/fault-armv.c
+++ b/arch/arm/mm/fault-armv.c
@@ -143,7 +143,7 @@ make_coherent(struct address_space *mapping, struct
vm_area_struct *vma,
* cache coherency.
*/
flush_dcache_mmap_lock(mapping);
- vma_interval_tree_foreach(mpnt, >i_mmap, pgoff, pgoff) {
+ vma_interval_tree_foreach_stab(mpnt, >i_mmap, pgoff) {
/*
* If this VMA is not in our MM, we can ignore it.
* Note that we intentionally mask out the VMA
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 6d89db7895d1..b04384406c0f 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -249,7 +249,7 @@ static void __flush_dcache_aliases(struct address_space
*mapping, struct page *p
pgoff = page->index;
flush_dcache_mmap_lock(mapping);
- vma_interval_tree_foreach(mpnt, >i_mmap, pgoff, pgoff) {
+ vma_interval_tree_foreach_stab(mpnt, >i_mmap, pgoff) {
unsigned long offset;
/*
diff --git a/arch/nios2/mm/cacheflush.c b/arch/nios2/mm/cacheflush.c
index 65de1bd6a760..8abe26b8e29d 100644
--- a/arch/nios2/mm/cacheflush.c
+++ b/arch/nios2/mm/cacheflush.c
@@ -79,7 +79,7 @@ static void flush_aliases(struct address_space *mapping,
struct page *page)
pgoff = page->index;
flush_dcache_mmap_lock(mapping);
- vma_interval_tree_foreach(mpnt, >i_mmap, pgoff, pgoff) {
+ vma_interval_tree_foreach_stab(mpnt, >i_mmap, pgoff) {
unsigned long offset;
if (mpnt->vm_mm != mm)
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index a82b3eaa5398..c5f8aab749c1 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -348,7 +348,7 @@ void flush_dcache_page(struct page *page)
* to flush one address here for them all to become coherent */
flush_dcache_mmap_lock(mapping);
- vma_interval_tree_foreach(mpnt, >i_mmap, pgoff, pgoff) {
+ vma_interval_tree_foreach_stab(mpnt, >i_mmap, pgoff) {
offset = (pgoff - mpnt->vm_pgoff) << PAGE_SHIFT;
addr = mpnt->vm_start + offset;
diff --git a/fs/dax.c b/fs/dax.c
index 6bf81f931de3..f24c035defb7 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -781,7 +781,7 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
spinlock_t *ptl;
i_mmap_lock_read(mapping);
- vma_interval_tree_foreach(vma, >i_mmap, index, index) {
+ vma_interval_tree_foreach_stab(vma, >i_mmap, index) {
struct mmu_notifier_range range;
unsigned long address;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 66f296181bcc..14c5eb514bfe 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2244,6 +2244,9 @@ struct vm_area_struct *vma_interval_tree_iter_next(struct
vm_area_struct *node,
for (vma = vma_interval_tree_iter_first(root, start, last); \
vma; vma = vma_interval_tree_iter_next(vma, start, last))
+#define vma_interval_tree_foreach_stab(vma, root, start) \
+ vma_interval_tree_foreach(vma, root, start, start)
+
void anon_vma_interval_tree_insert(struct anon_vma_chain *node,
struct rb_root_cached *root);
void anon_vma_interval_tree_remove(struct anon_vma_chain *node,
@@ -2261,6 +2264,9 @@ void anon_vma_interval_tree_verify(struct anon_vma_chain
*node);
for (avc = anon_vma_interval_tree_iter_first(root, start, last); \
avc; avc = anon_vma_interval_tree_iter_next(avc, start, last))
+#define anon_vma_interval_tree_foreach_stab(vma, root, start) \
+ anon_vma_interval_tree_foreach(vma, root, start, start)
+
/* mmap.c */
extern int __vm_enough_memory(struct mm_struct *mm, long pages, int
cap_sys_admin);
extern int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 94d38a39d72e..6a70dbe0b4b2 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -975,7 +975,7 @@
Re: [PATCH v2 2/2] mtd: spi-nor: intel-spi: add support for Intel Cannon Lake SPI flash
On Wed, Sep 04, 2019 at 01:15:24AM +, Jethro Beekman wrote: > Now that SPI flash controllers without a software sequencer are > supported, it's trivial to add support for CNL and its PCI ID. > > Values from > https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/300-series-chipset-pch-datasheet-vol-2.pdf > > Signed-off-by: Jethro Beekman Reviewed-by: Mika Westerberg
[PATCH] i2c: uniphier(-f): remove all dev_dbg()
I have fixed various bugs, and these drivers are (I hope) pretty
stable now. Remove all dev_dbg() for code clean-up.
If I end up with debugging the drivers again, I will locally revert
this commit. I no longer need the debug code in upstream.
Signed-off-by: Masahiro Yamada
---
drivers/i2c/busses/i2c-uniphier-f.c | 22 +-
drivers/i2c/busses/i2c-uniphier.c | 18 +++---
2 files changed, 4 insertions(+), 36 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c
b/drivers/i2c/busses/i2c-uniphier-f.c
index fc5354845ffa..4241aac79e7e 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -108,7 +108,6 @@ static void uniphier_fi2c_fill_txfifo(struct
uniphier_fi2c_priv *priv,
if (fifo_space-- <= 0)
break;
- dev_dbg(>adap.dev, "write data: %02x\n", *priv->buf);
writel(*priv->buf++, priv->membase + UNIPHIER_FI2C_DTTX);
priv->len--;
}
@@ -124,7 +123,6 @@ static void uniphier_fi2c_drain_rxfifo(struct
uniphier_fi2c_priv *priv)
break;
*priv->buf++ = readl(priv->membase + UNIPHIER_FI2C_DTRX);
- dev_dbg(>adap.dev, "read data: %02x\n", priv->buf[-1]);
priv->len--;
}
}
@@ -142,8 +140,6 @@ static void uniphier_fi2c_clear_irqs(struct
uniphier_fi2c_priv *priv,
static void uniphier_fi2c_stop(struct uniphier_fi2c_priv *priv)
{
- dev_dbg(>adap.dev, "stop condition\n");
-
priv->enabled_irqs |= UNIPHIER_FI2C_INT_STOP;
uniphier_fi2c_set_irqs(priv);
writel(UNIPHIER_FI2C_CR_MST | UNIPHIER_FI2C_CR_STO,
@@ -160,21 +156,15 @@ static irqreturn_t uniphier_fi2c_interrupt(int irq, void
*dev_id)
irq_status = readl(priv->membase + UNIPHIER_FI2C_INT);
irq_status &= priv->enabled_irqs;
- dev_dbg(>adap.dev,
- "interrupt: enabled_irqs=%04x, irq_status=%04x\n",
- priv->enabled_irqs, irq_status);
-
if (irq_status & UNIPHIER_FI2C_INT_STOP)
goto complete;
if (unlikely(irq_status & UNIPHIER_FI2C_INT_AL)) {
- dev_dbg(>adap.dev, "arbitration lost\n");
priv->error = -EAGAIN;
goto complete;
}
if (unlikely(irq_status & UNIPHIER_FI2C_INT_NA)) {
- dev_dbg(>adap.dev, "could not get ACK\n");
priv->error = -ENXIO;
if (priv->flags & UNIPHIER_FI2C_RD) {
/*
@@ -215,18 +205,14 @@ static irqreturn_t uniphier_fi2c_interrupt(int irq, void
*dev_id)
if (unlikely(priv->flags & UNIPHIER_FI2C_MANUAL_NACK)) {
if (priv->len <= UNIPHIER_FI2C_FIFO_SIZE &&
!(priv->flags & UNIPHIER_FI2C_BYTE_WISE)) {
- dev_dbg(>adap.dev,
- "enable read byte count IRQ\n");
priv->enabled_irqs |= UNIPHIER_FI2C_INT_RB;
uniphier_fi2c_set_irqs(priv);
priv->flags |= UNIPHIER_FI2C_BYTE_WISE;
}
- if (priv->len <= 1) {
- dev_dbg(>adap.dev, "set NACK\n");
+ if (priv->len <= 1)
writel(UNIPHIER_FI2C_CR_MST |
UNIPHIER_FI2C_CR_NACK,
priv->membase + UNIPHIER_FI2C_CR);
- }
}
goto handled;
@@ -334,10 +320,6 @@ static int uniphier_fi2c_master_xfer_one(struct
i2c_adapter *adap,
bool is_read = msg->flags & I2C_M_RD;
unsigned long time_left, flags;
- dev_dbg(>dev, "%s: addr=0x%02x, len=%d, repeat=%d, stop=%d\n",
- is_read ? "receive" : "transmit", msg->addr, msg->len,
- repeat, stop);
-
priv->len = msg->len;
priv->buf = msg->buf;
priv->enabled_irqs = UNIPHIER_FI2C_INT_FAULTS;
@@ -359,7 +341,6 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter
*adap,
else
uniphier_fi2c_tx_init(priv, msg->addr, repeat);
- dev_dbg(>dev, "start condition\n");
/*
* For a repeated START condition, writing a slave address to the FIFO
* kicks the controller. So, the UNIPHIER_FI2C_CR register should be
@@ -383,7 +364,6 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter
*adap,
uniphier_fi2c_recover(priv);
return -ETIMEDOUT;
}
- dev_dbg(>dev, "complete\n");
if (unlikely(priv->flags & UNIPHIER_FI2C_DEFER_STOP_COMP)) {
u32 status;
diff --git a/drivers/i2c/busses/i2c-uniphier.c
b/drivers/i2c/busses/i2c-uniphier.c
index a6d7a3709051..0270090c0360 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++
[PATCH v18 5/5] arm64: dts: mt8183: add scp node
From: Eddie Huang
Add scp node to mt8183 and mt8183-evb
Signed-off-by: Erin Lo
Signed-off-by: Pi-Hsun Shih
Signed-off-by: Eddie Huang
---
Changes from v17, v16, v15, v14:
- No change.
Changes from v13:
- Change the size of the cfg register region.
Changes from v12, v11, v10:
- No change.
Changes from v9:
- Remove extra reserve-memory-vpu_share node.
Changes from v8:
- New patch.
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +++
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 12
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 1fb195c683c3..ddb7a7ac9655 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -24,6 +24,17 @@
chosen {
stdout-path = "serial0:921600n8";
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ scp_mem_reserved: scp_mem_region {
+ compatible = "shared-dma-pool";
+ reg = <0 0x5000 0 0x290>;
+ no-map;
+ };
+ };
};
{
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 97f84aa9fc6e..3dd1b76bbaf5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -269,6 +269,18 @@
clock-names = "spi", "wrap";
};
+ scp: scp@1050 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x1050 0 0x8>,
+ <0 0x105c 0 0x19080>;
+ reg-names = "sram", "cfg";
+ interrupts = ;
+ clocks = < CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ memory-region = <_mem_reserved>;
+ status = "disabled";
+ };
+
auxadc: auxadc@11001000 {
compatible = "mediatek,mt8183-auxadc",
"mediatek,mt8173-auxadc";
--
2.23.0.187.g17f5b7556c-goog
[PATCH v18 1/5] dt-bindings: Add a binding for Mediatek SCP
From: Erin Lo
Add a DT binding documentation of SCP for the
MT8183 SoC from Mediatek.
Signed-off-by: Erin Lo
Signed-off-by: Pi-Hsun Shih
Reviewed-by: Rob Herring
---
Changes from v17, v16, v15, v14, v13, v12, v11, v10, v9, v8, v7, v6:
- No change.
Changes from v5:
- Remove dependency on CONFIG_RPMSG_MTK_SCP.
Changes from v4:
- Add detail of more properties.
- Document the usage of mtk,rpmsg-name in subnode from the new design.
Changes from v3:
- No change.
Changes from v2:
- No change. I realized that for this patch series, there's no need to
add anything under the mt8183-scp node (neither the mt8183-rpmsg or
the cros-ec-rpmsg) for them to work, since mt8183-rpmsg is added
directly as a rproc_subdev by code, and cros-ec-rpmsg is dynamically
created by SCP name service.
Changes from v1:
- No change.
---
.../bindings/remoteproc/mtk,scp.txt | 36 +++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
new file mode 100644
index ..3ba668bab14b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
@@ -0,0 +1,36 @@
+Mediatek SCP Bindings
+
+
+This binding provides support for ARM Cortex M4 Co-processor found on some
+Mediatek SoCs.
+
+Required properties:
+- compatible Should be "mediatek,mt8183-scp"
+- reg Should contain the address ranges for the two memory
+ regions, SRAM and CFG.
+- reg-namesContains the corresponding names for the two memory
+ regions. These should be named "sram" & "cfg".
+- clocks Clock for co-processor (See:
../clock/clock-bindings.txt)
+- clock-names Contains the corresponding name for the clock. This
+ should be named "main".
+
+Subnodes
+
+
+Subnodes of the SCP represent rpmsg devices. The names of the devices are not
+important. The properties of these nodes are defined by the individual bindings
+for the rpmsg devices - but must contain the following property:
+
+- mtk,rpmsg-name Contains the name for the rpmsg device. Used to match
+ the subnode to rpmsg device announced by SCP.
+
+Example:
+
+ scp: scp@1050 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x1050 0 0x8>,
+ <0 0x105c 0 0x5000>;
+ reg-names = "sram", "cfg";
+ clocks = < CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ };
--
2.23.0.187.g17f5b7556c-goog
[PATCH v18 3/5] remoteproc: mt8183: add reserved memory manager API
From: Erin Lo
Add memory table mapping API for other driver to lookup
reserved physical and virtual memory
Signed-off-by: Erin Lo
Signed-off-by: Pi-Hsun Shih
---
Changes from v17, v16, v15:
- No change.
Changes from v14:
- Fix a typo in variable name in DEBUG section.
Changes from v13:
- Add one more reserved region.
- Rename scp_get_reserve_* to scp_get_reserved_*.
- Minor fixes addressing comment.
Changes from v12:
- Reformat a line to fit 80 character width.
Changes from v11:
- No change.
Changes from v10:
- Fix some type mismatch warnings when printing debug messages.
Changes from v9:
- No change.
Changes from v8:
- Add more reserved regions for camera ISP.
Changes from v7, v6, v5:
- No change.
Changes from v4:
- New patch.
---
drivers/remoteproc/mtk_scp.c | 145 +
include/linux/remoteproc/mtk_scp.h | 25 +
2 files changed, 170 insertions(+)
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index c7dcc385d6a7..abfcbdd0dd4d 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -375,11 +375,142 @@ void *scp_mapping_dm_addr(struct platform_device *pdev,
u32 mem_addr)
}
EXPORT_SYMBOL_GPL(scp_mapping_dm_addr);
+#if SCP_RESERVED_MEM
+static phys_addr_t scp_mem_base_phys;
+static phys_addr_t scp_mem_base_virt;
+static size_t scp_mem_size;
+
+static struct scp_reserve_mblock scp_reserve_mblock[] = {
+ {
+ .num = SCP_ISP_MEM_ID,
+ .start_phys = 0x0,
+ .start_virt = 0x0,
+ .size = 0x20, /*2MB*/
+ },
+ {
+ .num = SCP_ISP_MEM2_ID,
+ .start_phys = 0x0,
+ .start_virt = 0x0,
+ .size = 0x80, /*8MB*/
+ },
+ {
+ .num = SCP_MDP_MEM_ID,
+ .start_phys = 0x0,
+ .start_virt = 0x0,
+ .size = 0x60, /*6MB*/
+ },
+ {
+ .num = SCP_DIP_MEM_ID,
+ .start_phys = 0x0,
+ .start_virt = 0x0,
+ .size = 0x90, /*9MB*/
+ },
+ {
+ .num = SCP_FD_MEM_ID,
+ .start_phys = 0x0,
+ .start_virt = 0x0,
+ .size = 0x10, /*1MB*/
+ },
+ {
+ .num = SCP_FD_MEM2_ID,
+ .start_phys = 0x0,
+ .start_virt = 0x0,
+ .size = 0x10, /*1MB*/
+ },
+};
+
+static int scp_reserve_mem_init(struct mtk_scp *scp)
+{
+ enum scp_reserve_mem_id_t id;
+ phys_addr_t accumlate_memory_size = 0;
+
+ scp_mem_base_phys = (phys_addr_t) (scp->phys_addr + MAX_CODE_SIZE);
+ scp_mem_size = scp->dram_size - MAX_CODE_SIZE;
+
+ dev_info(scp->dev,
+"phys:0x%llx - 0x%llx (0x%llx)\n",
+(unsigned long long)scp_mem_base_phys,
+(unsigned long long)(scp_mem_base_phys + scp_mem_size),
+(unsigned long long)scp_mem_size);
+ accumlate_memory_size = 0;
+ for (id = 0; id < SCP_NUMS_MEM_ID; id++) {
+ scp_reserve_mblock[id].start_phys =
+ scp_mem_base_phys + accumlate_memory_size;
+ accumlate_memory_size += scp_reserve_mblock[id].size;
+ dev_info(
+ scp->dev,
+ "[reserve_mem:%d]: phys:0x%llx - 0x%llx (0x%llx)\n", id,
+ (unsigned long long)scp_reserve_mblock[id].start_phys,
+ (unsigned long long)(scp_reserve_mblock[id].start_phys +
+scp_reserve_mblock[id].size),
+ (unsigned long long)scp_reserve_mblock[id].size);
+ }
+ return 0;
+}
+
+static int scp_reserve_memory_ioremap(struct mtk_scp *scp)
+{
+ enum scp_reserve_mem_id_t id;
+ phys_addr_t accumlate_memory_size = 0;
+
+ scp_mem_base_virt = (phys_addr_t)(size_t)ioremap_wc(scp_mem_base_phys,
+ scp_mem_size);
+
+ dev_info(scp->dev,
+"virt:0x%llx - 0x%llx (0x%llx)\n",
+ (unsigned long long)scp_mem_base_virt,
+ (unsigned long long)(scp_mem_base_virt + scp_mem_size),
+ (unsigned long long)scp_mem_size);
+ for (id = 0; id < SCP_NUMS_MEM_ID; id++) {
+ scp_reserve_mblock[id].start_virt =
+ scp_mem_base_virt + accumlate_memory_size;
+ accumlate_memory_size += scp_reserve_mblock[id].size;
+ }
+ /* the reserved memory should be larger then expected memory
+* or scp_reserve_mblock does not match dts
+*/
+ WARN_ON(accumlate_memory_size > scp_mem_size);
+ return 0;
+}
+phys_addr_t scp_get_reserved_mem_phys(enum scp_reserve_mem_id_t id)
+{
+ if (id >= SCP_NUMS_MEM_ID) {
+ pr_err("[SCP] no reserve memory for %d", id);
+ return 0;
+
[PATCH v18 2/5] remoteproc/mediatek: add SCP support for mt8183
From: Erin Lo Provide a basic driver to control Cortex M4 co-processor Signed-off-by: Erin Lo Signed-off-by: Nicolas Boichat Signed-off-by: Pi-Hsun Shih --- Changes from v17: - Fix mixture use of __iomem found by sparse. - Change the ipi handler to take a u32 instead of enum scp_ipi_id. Changes from v16: - Change the desc_lock mutex to be a per-id lock. - Put the execution of handler inside the per-id lock, to prevent race between scp_ipi_unregister and handler being run. - Move the initialization of mutex to before scp_ipi_register. Changes from v15: - Fix a bug on incorrect usage of wait_event_timeout return value. Changes from v14: - No change. Changes from v13: - Move include/linux/platform_data/mtk_scp.h to include/linux/remoteproc/mtk_scp.h. - Add lock for access of scp->ipi_desc. - Lock the whole ipi_send function. - Move more setting of cache size from SCP firmware to kernel driver, to prevent problem while loading firmware onto DRAM. - Cleanup and remove unused branch in scp_da_to_va. - Minor fixes addressing comment. Changes from v12: - Initialize cache before firmware load, to avoid problem while loading large firmware. - Disable watchdog before stopping SCP, to avoid extra warning message. - Use strscpy instead of strncpy. Changes from v11: - No change. Changes from v10: - Add a clock reset before loading firmware. Changes from v9: - No change. Changes from v8: - Add a missing space. Changes from v7: - Moved the location of shared SCP buffer. - Fix clock enable/disable sequence. - Add more IPI ID that would be used. Changes from v6: - No change. Changes from v5: - Changed some space to tab. Changes from v4: - Rename most function from mtk_scp_* to scp_*. - Change the irq to threaded handler. - Load ELF file instead of plain binary file as firmware by default (Squashed patch 6 in v4 into this patch). Changes from v3: - Fix some issue found by checkpatch. - Make writes aligned in scp_ipi_send. Changes from v2: - Squash patch 3 from v2 (separate the ipi interface) into this patch. - Remove unused name argument from scp_ipi_register. - Add scp_ipi_unregister for proper cleanup. - Move IPI ids in sync with firmware. - Add mb() in proper place, and correctly clear the run->signaled. Changes from v1: - Extract functions and rename variables in mtk_scp.c. --- drivers/remoteproc/Kconfig | 9 + drivers/remoteproc/Makefile| 1 + drivers/remoteproc/mtk_common.h| 92 + drivers/remoteproc/mtk_scp.c | 548 + drivers/remoteproc/mtk_scp_ipi.c | 175 + include/linux/remoteproc/mtk_scp.h | 141 6 files changed, 966 insertions(+) create mode 100644 drivers/remoteproc/mtk_common.h create mode 100644 drivers/remoteproc/mtk_scp.c create mode 100644 drivers/remoteproc/mtk_scp_ipi.c create mode 100644 include/linux/remoteproc/mtk_scp.h diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 28ed306982f7..ea71cad399f7 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -23,6 +23,15 @@ config IMX_REMOTEPROC It's safe to say N here. +config MTK_SCP + tristate "Mediatek SCP support" + depends on ARCH_MEDIATEK + help + Say y here to support Mediatek's System Companion Processor (SCP) via + the remote processor framework. + + It's safe to say N here. + config OMAP_REMOTEPROC tristate "OMAP remoteproc support" depends on ARCH_OMAP4 || SOC_OMAP5 diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile index 00f09e658cb3..e30a1b15fbac 100644 --- a/drivers/remoteproc/Makefile +++ b/drivers/remoteproc/Makefile @@ -10,6 +10,7 @@ remoteproc-y += remoteproc_sysfs.o remoteproc-y += remoteproc_virtio.o remoteproc-y += remoteproc_elf_loader.o obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o +obj-$(CONFIG_MTK_SCP) += mtk_scp.o mtk_scp_ipi.o obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h new file mode 100644 index ..d8a05df6c6f3 --- /dev/null +++ b/drivers/remoteproc/mtk_common.h @@ -0,0 +1,92 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019 MediaTek Inc. + */ + +#ifndef __RPROC_MTK_COMMON_H +#define __RPROC_MTK_COMMON_H + +#include +#include +#include +#include + +#define MT8183_SW_RSTN 0x0 +#define MT8183_SW_RSTN_BIT BIT(0) +#define MT8183_SCP_TO_HOST 0x1C +#define MT8183_SCP_IPC_INT_BIT BIT(0) +#define MT8183_SCP_WDT_INT_BIT BIT(8) +#define MT8183_HOST_TO_SCP 0x28 +#define MT8183_HOST_IPC_INT_BITBIT(0) +#define
[PATCH v18 0/5] Add support for mt8183 SCP.
Add support for controlling and communicating with mt8183's system
control processor (SCP), using the remoteproc & rpmsg framework.
And also add a cros_ec driver for CrOS EC host command over rpmsg.
The overall structure of the series is:
* remoteproc/mtk_scp.c: Control the start / stop of SCP (Patch 2, 3).
* remoteproc/mtk_scp_ipi.c: Communicates to SCP using inter-processor
interrupt (IPI) and shared memory (Patch 2, 3).
* rpmsg/mtk_rpmsg.c: Wrapper to wrap the IPI communication into a rpmsg
device. Supports name service for SCP firmware to
announce channels (Patch 4).
* add scp dts node to mt8183 platform (Patch 5).
Changes from v17:
- Fix mixture use of __iomem found by sparse.
- Change the ipi handler to take a u32 instead of enum scp_ipi_id.
- Mark mtk_rpmsg_{prepare,unprepare,stop} as static.
Changes from v16:
- Change the desc_lock mutex to be a per-id lock.
- Put the execution of handler inside the per-id lock, to prevent race
between scp_ipi_unregister and handler being run.
- Move the initialization of mutex to before scp_ipi_register.
Changes from v15:
- Fix a bug on incorrect usage of wait_event_timeout return value.
Changes from v14:
- Fix a typo on variable in DEBUG section.
Changes from v13:
- Move include/linux/platform_data/mtk_scp.h to
include/linux/remoteproc/mtk_scp.h.
- Rename scp_get_reserve_* to scp_get_reserved_*.
- Add lock for access of scp->ipi_desc.
- Lock the whole ipi_send function.
- Move more setting of cache size from SCP firmware to kernel driver,
to prevent problem while loading firmware onto DRAM.
- Minor fixes addressing comment.
Changes from v12:
- Initialize cache before firmware load, to avoid problem while loading
large firmware.
- Disable watchdog before stopping SCP, to avoid extra warning message.
- Fix new warnings by checkpatch.
Changes from v11:
- Fixed a bug that mtk_rpmsg_endpoint is not properly cleaned up if
rproc_boot fails.
- Add missing documentation in comment.
Changes from v10:
- Drop applied cros_ec_rpmsg patches.
- Add clock reset before loading SCP firmware.
- Fix some type mismatch warnings when printing debug messages.
Changes from v9:
- Remove reserve-memory-vpu_share node.
- Remove change to cros_ec_commands.h (That is already in
https://lore.kernel.org/lkml/20190518063949.GY4319@dell/T/)
Changes from v8:
- Rebased onto https://patchwork.kernel.org/cover/10962385/.
- Drop merged cros_ec_rpmsg patch, and add scp dts node patch.
- Add more reserved memory region.
Changes from v7:
- Rebase onto https://lore.kernel.org/patchwork/patch/1059196/.
- Fix clock enable/disable timing for SCP driver.
- Add more SCP IPI ID.
Changes from v6:
- Decouple mtk_rpmsg from mtk_scp.
- Change data of EC response to be aligned to 4 bytes.
Changes from v5:
- Add device tree binding document for cros_ec_rpmsg.
- Better document in comments for cros_ec_rpmsg.
- Remove dependency on CONFIG_ in binding tree document.
Changes from v4:
- Merge patch 6 (Load ELF firmware) into patch 2, so the driver loads
ELF firmware by default, and no longer accept plain binary.
- rpmsg_device listed in device tree (as a child of the SCP node) would
have it's device tree node mapped to the rpmsg_device, so the rpmsg
driver can use the properties on device tree.
Changes from v3:
- Make writing to SCP SRAM aligned.
- Add a new patch (Patch 6) to load ELF instead of bin firmware.
- Add host event support for EC driver.
- Fix some bugs found in testing (missing spin_lock_init,
rproc_subdev_unprepare to rproc_subdev_stop).
- Fix some coding style issue found by checkpatch.pl.
Changes from v2:
- Fold patch 3 into patch 2 in v2.
- Move IPI id around to support cross-testing for old and new firmware.
- Finish more TODO items.
Changes from v1:
- Extract functions and rename variables in mtk_scp.c.
- Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
short-lived work items.
- Code format fix based on feedback for cros_ec_rpmsg.c.
- Extract feature detection for SCP into separate patch (Patch 6).
Eddie Huang (1):
arm64: dts: mt8183: add scp node
Erin Lo (3):
dt-bindings: Add a binding for Mediatek SCP
remoteproc/mediatek: add SCP support for mt8183
remoteproc: mt8183: add reserved memory manager API
Pi-Hsun Shih (1):
rpmsg: add rpmsg support for mt8183 SCP.
.../bindings/remoteproc/mtk,scp.txt | 36 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 +
drivers/remoteproc/Kconfig| 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/mtk_common.h | 94 +++
drivers/remoteproc/mtk_scp.c | 723 ++
drivers/remoteproc/mtk_scp_ipi.c | 176 +
drivers/rpmsg/Kconfig | 9 +
drivers/rpmsg/Makefile| 1 +
drivers/rpmsg/mtk_rpmsg.c
[PATCH v18 4/5] rpmsg: add rpmsg support for mt8183 SCP.
Add a simple rpmsg support for mt8183 SCP, that use IPI / IPC directly.
Signed-off-by: Pi-Hsun Shih
---
Changes from v17:
- Mark mtk_rpmsg_{prepare,unprepare,stop} as static.
Changes from v16:
- Change year on another Copyright header to 2019.
Changes from v15:
- No change.
Changes from v14:
- Change year on Copyright header to 2019.
Changes from v13:
- No change.
Changes from v12:
- Use strscpy instead of strncpy.
Changes from v11:
- Fix a bug that when rproc_boot fails, the ns_ept won't be properly
destroyed, causing memory leak.
- Add documentation for mtk_rpmsg_info.
Changes from v10, v9, v8, v7:
- No change.
Changes from v6:
- Decouple mtk_rpmsg from mtk_scp by putting all necessary informations
(name service IPI id, register/unregister/send functions) into a
struct, and pass it to the mtk_rpmsg_create_rproc_subdev function.
Changes from v5:
- CONFIG_MTK_SCP now selects CONFIG_RPMSG_MTK_SCP, and the dummy
implementation for mtk_rpmsg_{create,destroy}_rproc_subdev when
CONFIG_RPMSG_MTK_SCP is not defined is removed.
Changes from v4:
- Match and fill the device tree node to the created rpmsg subdevice,
so the rpmsg subdevice can utilize the properties and subnodes on
device tree (This is similar to what drivers/rpmsg/qcom_smd.c does).
Changes from v3:
- Change from unprepare to stop, to stop the rpmsg driver before the
rproc is stopped, avoiding problem that some rpmsg would fail after
rproc is stopped.
- Add missing spin_lock_init, and use destroy_ept instead of kref_put.
Changes from v2:
- Unregiser IPI handler on unprepare.
- Lock the channel list on operations.
- Move SCP_IPI_NS_SERVICE to 0xFF.
Changes from v1:
- Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
short-lived work items.
- Fix several issues checkpatch found.
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/mtk_common.h| 2 +
drivers/remoteproc/mtk_scp.c | 38 ++-
drivers/remoteproc/mtk_scp_ipi.c | 1 +
drivers/rpmsg/Kconfig | 9 +
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/mtk_rpmsg.c | 414 +
include/linux/remoteproc/mtk_scp.h | 4 +-
include/linux/rpmsg/mtk_rpmsg.h| 38 +++
9 files changed, 503 insertions(+), 5 deletions(-)
create mode 100644 drivers/rpmsg/mtk_rpmsg.c
create mode 100644 include/linux/rpmsg/mtk_rpmsg.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index ea71cad399f7..cff3a9fa817b 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -26,6 +26,7 @@ config IMX_REMOTEPROC
config MTK_SCP
tristate "Mediatek SCP support"
depends on ARCH_MEDIATEK
+ select RPMSG_MTK_SCP
help
Say y here to support Mediatek's System Companion Processor (SCP) via
the remote processor framework.
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index d8a05df6c6f3..cdddef0d53a4 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -69,6 +69,8 @@ struct mtk_scp {
void __iomem *cpu_addr;
phys_addr_t phys_addr;
size_t dram_size;
+
+ struct rproc_subdev *rpmsg_subdev;
};
/**
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index abfcbdd0dd4d..488989c22b39 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "mtk_common.h"
#include "remoteproc_internal.h"
@@ -550,6 +551,31 @@ static int scp_map_memory_region(struct mtk_scp *scp)
return 0;
}
+static struct mtk_rpmsg_info mtk_scp_rpmsg_info = {
+ .send_ipi = scp_ipi_send,
+ .register_ipi = scp_ipi_register,
+ .unregister_ipi = scp_ipi_unregister,
+ .ns_ipi_id = SCP_IPI_NS_SERVICE,
+};
+
+static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
+{
+ scp->rpmsg_subdev =
+ mtk_rpmsg_create_rproc_subdev(to_platform_device(scp->dev),
+ _scp_rpmsg_info);
+ if (scp->rpmsg_subdev)
+ rproc_add_subdev(scp->rproc, scp->rpmsg_subdev);
+}
+
+static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
+{
+ if (scp->rpmsg_subdev) {
+ rproc_remove_subdev(scp->rproc, scp->rpmsg_subdev);
+ mtk_rpmsg_destroy_rproc_subdev(scp->rpmsg_subdev);
+ scp->rpmsg_subdev = NULL;
+ }
+}
+
static int scp_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -633,22 +659,25 @@ static int scp_probe(struct platform_device *pdev)
init_waitqueue_head(>run.wq);
init_waitqueue_head(>ack_wq);
+ scp_add_rpmsg_subdev(scp);
+
ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
scp_irq_handler, IRQF_ONESHOT,
pdev->name, scp);
RE: [PATCH] ACPI: support for NXP i2c controller
> Hi, > > On 02.09.19 23:16, Andy Shevchenko wrote: > > On Mon, Sep 2, 2019 at 11:58 PM Rafael J. Wysocki > wrote: > >> > >> On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han > wrote: > >>> > >>> Enable NXP i2c controller to boot with ACPI > >>> > >>> Signed-off-by: Meenakshi Aggarwal > >>> Signed-off-by: Udit Kumar > >>> Signed-off-by: Chuanhua Han > >> > >> Wolfram, any objections to this from the i2c side? > > > > May I propose amendment(s)? > > > >>> @@ -44,6 +44,7 @@ > >>> #include > >>> #include > >>> #include > > > >>> +#include > > > > If it's kept in order, better to go with it. (Yes, it is as I have > > checked) However, property.h should be included instead, see below. > > > >>> const struct of_device_id *of_id = > of_match_device(i2c_imx_dt_ids, > >>> > >>> >dev); > >>> + const struct acpi_device_id *acpi_id = > >>> + acpi_match_device(i2c_imx_acpi_ids, > >>> + >dev); > > > > > >>> if (of_id) > >>> i2c_imx->hwdata = of_id->data; > >>> + else if (acpi_id) > >>> + i2c_imx->hwdata = (struct imx_i2c_hwdata *) > >>> + acpi_id->driver_data; > > > > > > The above altogher may be replaced with > > > > const struct imx_i2c_hwdata *match; > > ... > > match = device_get_match_data(>dev); > > if (match) > > i2c_imx->hwdata = match; > > else > > ... > > Instead of "may be replaced", I would say: it should be replaced :) > > >>> + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids), > > > > Since there is no #ifdef guard no need to use ACPI_PTR(). > > > > What iMX/(other NXP?) SoCs are with ACPI support? Where I can get one? I > would like to know more about it. - Nxp has variety Socs, include i.MX, Layerscape, etc. - You can get one from here https://www.nxp.com/design/qoriq-developer-resources/qoriq-lx2160a-development-board:LX2160A-RDB > > Kind regards, > Oleksij Rempel > > -- > Pengutronix e.K. | > | > Industrial Linux Solutions | > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pe > ngutronix.de%2Fdata=02%7C01%7Cmeenakshi.aggarwal%40nxp.com% > 7C640eb015a91f4959d3b508d7303168fb%7C686ea1d3bc2b4c6fa92cd99c5c > 301635%7C0%7C0%7C637030861076879938sdata=sPWtkVtHHDvoRR > ZmWJuipCO%2BEwG%2BcupgZvcIV1%2BrlEY%3Dreserved=0 | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 > | > Amtsgericht Hildesheim, HRA 2686 | Fax: > +49-5121-206917- |
Re: [Patch V8 6/8] arm64: tegra: Enable xudc on Jetson TX1
On 04-09-2019 15:17, Chunfeng Yun wrote:
> On Wed, 2019-09-04 at 13:53 +0530, Nagarjuna Kristam wrote:
>> Enable XUSB device mode driver for USB0 slot on Jetson TX1.
>>
>> Signed-off-by: Nagarjuna Kristam
>> Reviewed-by: JC Kuo
>> ---
>> arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 31
>> +-
>> 1 file changed, 30 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
>> b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
>> index a7dc319..6aba1ba 100644
>> --- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
>> +++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
>> @@ -1362,7 +1362,7 @@
>> status = "okay";
>>
>> lanes {
>> -usb2-0 {
>> +micro_b: usb2-0 {
>> nvidia,function = "xusb";
>> status = "okay";
>> };
>> @@ -1483,6 +1483,21 @@
>> vmmc-supply = <_3v3_sd>;
>> };
>>
>> +usb@700d {
>> +status = "okay";
>> +phys = <_b>;
>> +phy-names = "usb2";
>> +avddio-usb-supply = <_3v3_sys>;
>> +hvdd-usb-supply = <_1v8>;
>> +usb-role-switch;
>> +
>> +port {
>> +usb_role_switch: endpoint {
>> +remote-endpoint = <_b_conn_ep>;
>> +};
>> +};
>> +};
>> +
>> regulators {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> @@ -1641,4 +1656,18 @@
>> linux,code = ;
>> };
>> };
>> +
>> +usb_type_b: connector {
>> +compatible = "linux,usb-conn-gpio", "gpio-usb-b-connector";
> please use "gpio-usb-b-connector" and "usb-b-connector", due to
> "linux,usb-conn-gpio" is not supported now
>
>
Thanks for info, will update accordingly.
>> +label = "micro-USB";
>> +type = "micro";
>> +vbus-gpio = < TEGRA_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
>> +
>> +port {
>> +usb_b_conn_ep: endpoint {
>> +remote-endpoint = <_role_switch>;
>> +};
>> +};
>> +};
>> +
>> };
>
>
[PATCH] cfg80211: Do not compare with boolean in nl80211_common_reg_change_event
With the help of boolinit.cocci, we use !nl80211_reg_change_event_fill
instead of (nl80211_reg_change_event_fill == false). Meanwhile, Clean
up the code.
Signed-off-by: zhong jiang
---
net/wireless/nl80211.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 3e30e18..0c7fa60 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -14997,12 +14997,10 @@ void nl80211_common_reg_change_event(enum
nl80211_commands cmd_id,
return;
hdr = nl80211hdr_put(msg, 0, 0, 0, cmd_id);
- if (!hdr) {
- nlmsg_free(msg);
- return;
- }
+ if (!hdr)
+ goto nla_put_failure;
- if (nl80211_reg_change_event_fill(msg, request) == false)
+ if (!nl80211_reg_change_event_fill(msg, request))
goto nla_put_failure;
genlmsg_end(msg, hdr);
--
1.7.12.4
Re: [Patch V8 7/8] usb: gadget: Add UDC driver for tegra XUSB device mode controller
On 04-09-2019 16:00, Chunfeng Yun wrote: > On Wed, 2019-09-04 at 13:53 +0530, Nagarjuna Kristam wrote: >> This patch adds UDC driver for tegra XUSB 3.0 device mode controller. >> XUSB device mode controller supports SS, HS and FS modes >> >> Based on work by: >> Mark Kuo >> Hui Fu >> Andrew Bresticker >> >> Signed-off-by: Nagarjuna Kristam >> Acked-by: Thierry Reding >> --- >> drivers/usb/gadget/udc/Kconfig | 12 + >> drivers/usb/gadget/udc/Makefile |1 + >> drivers/usb/gadget/udc/tegra-xudc.c | 3791 >> +++ >> 3 files changed, 3804 insertions(+) >> create mode 100644 drivers/usb/gadget/udc/tegra-xudc.c >> >> diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig >> index d354036..0fe7577 100644 >> --- a/drivers/usb/gadget/udc/Kconfig >> +++ b/drivers/usb/gadget/udc/Kconfig >> @@ -441,6 +441,18 @@ config USB_GADGET_XILINX >>dynamically linked module called "udc-xilinx" and force all >>gadget drivers to also be dynamically linked. >> >> +config USB_TEGRA_XUDC >> +tristate "NVIDIA Tegra Superspeed USB 3.0 Device Controller" >> +depends on ARCH_TEGRA || COMPILE_TEST >> +depends on PHY_TEGRA_XUSB >> +select USB_CONN_GPIO > To me, needn't select this driver, without it, the driver still build > pass > Yes compilation passes with out this. Added select for getting USB_CONN_GPIO driver functionality. >> +help >> + Enables NVIDIA Tegra USB 3.0 device mode controller driver. >> + >> + Say "y" to link the driver statically, or "m" to build a >> + dynamically linked module called "tegra_xudc" and force all >> + gadget drivers to also be dynamically linked. >> + >> source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig" >> >> # >> diff --git a/drivers/usb/gadget/udc/Makefile >> b/drivers/usb/gadget/udc/Makefile >> index 897f648..f6777e6 100644 >> --- a/drivers/usb/gadget/udc/Makefile >> +++ b/drivers/usb/gadget/udc/Makefile >> @@ -24,6 +24,7 @@ obj-$(CONFIG_USB_BCM63XX_UDC) += bcm63xx_udc.o >> obj-$(CONFIG_USB_FSL_USB2) += fsl_usb2_udc.o >> fsl_usb2_udc-y := fsl_udc_core.o >> fsl_usb2_udc-$(CONFIG_ARCH_MXC) += fsl_mxc_udc.o >> +obj-$(CONFIG_USB_TEGRA_XUDC)+= tegra-xudc.o >> obj-$(CONFIG_USB_M66592)+= m66592-udc.o >> obj-$(CONFIG_USB_R8A66597) += r8a66597-udc.o >> obj-$(CONFIG_USB_RENESAS_USB3) += renesas_usb3.o >> diff --git a/drivers/usb/gadget/udc/tegra-xudc.c >> b/drivers/usb/gadget/udc/tegra-xudc.c >> new file mode 100644 >> index 000..75fa2e1 >> --- /dev/null >> +++ b/drivers/usb/gadget/udc/tegra-xudc.c >> @@ -0,0 +1,3791 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * NVIDIA Tegra XUSB device mode controller >> + * >> + * Copyright (c) 2013-2019, NVIDIA CORPORATION. All rights reserved. >> + * Copyright (c) 2015, Google Inc. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* XUSB_DEV registers */ >> +#define SPARAM 0x000 >> +#define SPARAM_ERSTMAX_MASK GENMASK(20, 16) >> +#define SPARAM_ERSTMAX(x) (((x) << 16) & SPARAM_ERSTMAX_MASK) >> +#define DB 0x004 >> +#define DB_TARGET_MASK GENMASK(15, 8) >> +#define DB_TARGET(x) (((x) << 8) & DB_TARGET_MASK) >> +#define DB_STREAMID_MASK GENMASK(31, 16) >> +#define DB_STREAMID(x) (((x) << 16) & DB_STREAMID_MASK) >> +#define ERSTSZ 0x008 >> +#define ERSTSZ_ERSTXSZ_SHIFT(x) ((x) * 16) >> +#define ERSTSZ_ERSTXSZ_MASK GENMASK(15, 0) >> +#define ERSTXBALO(x) (0x010 + 8 * (x)) >> +#define ERSTXBAHI(x) (0x014 + 8 * (x)) >> +#define ERDPLO 0x020 >> +#define ERDPLO_EHB BIT(3) >> +#define ERDPHI 0x024 >> +#define EREPLO 0x028 >> +#define EREPLO_ECS BIT(0) >> +#define EREPLO_SEGI BIT(1) >> +#define EREPHI 0x02c >> +#define CTRL 0x030 >> +#define CTRL_RUN BIT(0) >> +#define CTRL_LSE BIT(1) >> +#define CTRL_IE BIT(4) >> +#define CTRL_SMI_EVT BIT(5) >> +#define CTRL_SMI_DSE BIT(6) >> +#define CTRL_EWE BIT(7) >> +#define CTRL_DEVADDR_MASK GENMASK(30, 24) >> +#define CTRL_DEVADDR(x) (((x) << 24) & CTRL_DEVADDR_MASK) >> +#define CTRL_ENABLE BIT(31) >> +#define ST 0x034 >> +#define ST_RC BIT(0) >> +#define ST_IP BIT(4) >> +#define RT_IMOD 0x038 >> +#define RT_IMOD_IMODI_MASK GENMASK(15, 0) >> +#define RT_IMOD_IMODI(x) ((x) & RT_IMOD_IMODI_MASK) >> +#define RT_IMOD_IMODC_MASK GENMASK(31, 16) >> +#define RT_IMOD_IMODC(x) (((x) << 16) & RT_IMOD_IMODC_MASK) >> +#define PORTSC 0x03c >> +#define PORTSC_CCS BIT(0) >> +#define PORTSC_PED BIT(1) >> +#define PORTSC_PR BIT(4) >> +#define PORTSC_PLS_SHIFT 5 >> +#define PORTSC_PLS_MASK GENMASK(8, 5) >> +#define PORTSC_PLS_U0 0x0 >> +#define PORTSC_PLS_U2 0x2 >> +#define PORTSC_PLS_U3 0x3 >> +#define PORTSC_PLS_DISABLED 0x4 >>
Re: [PATCH V7 1/3] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()
On 09/04/2019 01:46 PM, David Hildenbrand wrote: > On 03.09.19 11:45, Anshuman Khandual wrote: >> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs >> entries between memory block and node. It first checks pfn validity with >> pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config >> (arm64 has this enabled) pfn_valid_within() calls pfn_valid(). >> >> pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID) >> which scans all mapped memblock regions with memblock_is_map_memory(). This >> creates a problem in memory hot remove path which has already removed given >> memory range from memory block with memblock_[remove|free] before arriving >> at unregister_mem_sect_under_nodes(). Hence get_nid_for_pfn() returns -1 >> skipping subsequent sysfs_remove_link() calls leaving node <-> memory block >> sysfs entries as is. Subsequent memory add operation hits BUG_ON() because >> of existing sysfs entries. > Since > > commit 60bb462fc7adb06ebee3beb5a4af6c7e6182e248 > Author: David Hildenbrand > Date: Wed Aug 28 13:57:15 2019 +1000 > > drivers/base/node.c: simplify unregister_memory_block_under_nodes() > > that problem should be gone. There is no get_nid_for_pfn() call anymore. Yes, the problem is gone. The above commit is still not present on arm64 tree against which this series was rebased and tested while posting. > > So this patch should no longer be necessary - but as I said during > earlier versions of this patch, the re-ordering might still make sense > for consistency (removing stuff in the reverse order they were added). > You'll have to rephrase the description then. Sure will reword the commit message on these lines.
RE: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode
Hi > Yes. Except that I think the name POWER_BUDGET_3_0 is a little odd. > It implies that this change is specific to USB 3.0 -- but it isn't. > USB 3.1 and 3.2 also have a 900 mA limit, right? > > So please consider changing the name to POWER_BUDGET_3. > > Alan Stern Thank you for your comment. I updated the name from POWER_BUDGET_3_0 to POWER_BUDGET_3 in PATCH v3 and submitted it just now. Regards Jacky
[PATCH v3] USB: dummy-hcd: fix power budget for SuperSpeed mode
The power budget for SuperSpeed mode should be 900 mA according to USB specification, so set the power budget to 900mA for dummy_start_ss which is only used for SuperSpeed mode. If the max power consumption of SuperSpeed device is larger than 500 mA, insufficient available bus power error happens in usb_choose_configuration function when the device connects to dummy hcd. Signed-off-by: Jacky Cao --- Changes in v3: - Rename POWER_BUDGET_3_0 to POWER_BUDGET_3 - Update commit message from USB3.0 specification to USB specification Changes in v2: - Fix whitespace damage drivers/usb/gadget/udc/dummy_hcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index 8414fac..3d499d9 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -48,6 +48,7 @@ #define DRIVER_VERSION "02 May 2005" #define POWER_BUDGET 500 /* in mA; use 8 for low-power port testing */ +#define POWER_BUDGET_3 900 /* in mA */ static const char driver_name[] = "dummy_hcd"; static const char driver_desc[] = "USB Host+Gadget Emulator"; @@ -2432,7 +2433,7 @@ static int dummy_start_ss(struct dummy_hcd *dum_hcd) dum_hcd->rh_state = DUMMY_RH_RUNNING; dum_hcd->stream_en_ep = 0; INIT_LIST_HEAD(_hcd->urbp_list); - dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET; + dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3; dummy_hcd_to_hcd(dum_hcd)->state = HC_STATE_RUNNING; dummy_hcd_to_hcd(dum_hcd)->uses_new_polling = 1; #ifdef CONFIG_USB_OTG -- 2.7.4
Re: [PATCH 1/3] ACPI: Remove acpi_has_method() call from acpi_adxl.c
On Mon, Sep 02, 2019 at 11:08:08PM +0200, Rafael J. Wysocki wrote:
> Sorry for the delayed reply.
>
> On Mon, Jul 22, 2019 at 8:29 PM Bjorn Helgaas wrote:
> >
> > [+cc Tony (original author), Borislav (merged original patch)]
> >
> > On Mon, Jul 22, 2019 at 10:31:11AM +0200, Rafael J. Wysocki wrote:
> > > On Mon, Jul 22, 2019 at 4:36 AM Kelsey Skunberg
> > > wrote:
> > > >
> > > > acpi_check_dsm() will already return an error if the DSM method does not
> > > > exist. Checking if the DSM method exists before the acpi_check_dsm()
> > > > call
> > > > is not needed. Remove acpi_has_method() call to avoid additional work.
> > > >
> > > > Signed-off-by: Kelsey Skunberg
> > > > ---
> > > > drivers/acpi/acpi_adxl.c | 5 -
> > > > 1 file changed, 5 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/acpi_adxl.c b/drivers/acpi/acpi_adxl.c
> > > > index 13c8f7b50c46..89aac15663fd 100644
> > > > --- a/drivers/acpi/acpi_adxl.c
> > > > +++ b/drivers/acpi/acpi_adxl.c
> > > > @@ -148,11 +148,6 @@ static int __init adxl_init(void)
> > > > return -ENODEV;
> > > > }
> > > >
> > > > - if (!acpi_has_method(handle, "_DSM")) {
> > > > - pr_info("No DSM method\n");
> > >
> > > And why is printing the message not useful?
> > >
> > > > - return -ENODEV;
> > > > - }
> > > > -
> > > > if (!acpi_check_dsm(handle, _guid, ADXL_REVISION,
> > > > ADXL_IDX_GET_ADDR_PARAMS |
> > > > ADXL_IDX_FORWARD_TRANSLATE)) {
> >
> > The next line of context (not included in the patch):
> >
> >pr_info("DSM method does not support forward translate\n");
> >
> > IMHO kernel messages that are just a constant string, with no context
> > or variable part (device ID, path, error code, etc) are questionable
> > in general. Is there any dev_printk()-like thing that takes an
> > acpi_handle? Seems like that would be useful for cases like this.
> >
> > This message *does* include an "ADXL: " prefix (from the pr_fmt
> > definition), and from reading the code you can see that the only
> > possible method is "\_SB.ADXL._DSM".
> >
> > There's nothing an end user can do with these messages, so I suspect
> > their value is for debugging during platform bringup, and it would be
> > sufficient to drop the first one (as Kelsey's patch does) and change
> > the second one like this:
> >
> > - pr_info("DSM method does not support forward translate\n");
> > + pr_info("%s DSM missing or does not support forward
> > translate\n",
> > + path);
>
> You have a point, but then I would expect the changelog to mention that.
>
> As it stands, the patch does more than the changelog says, which isn't nice.
You're right, the changelog should include this information. I'll get an
updated version made. Thank you for getting back.
-Kelsey
Re: [PATCH v4 02/16] powerpc/pseries: Introduce option to build secure virtual machines
Thiago Jung Bauermann writes: > Michael Ellerman writes: >> On Tue, 2019-08-20 at 02:13:12 UTC, Thiago Jung Bauermann wrote: >>> Introduce CONFIG_PPC_SVM to control support for secure guests and include >>> Ultravisor-related helpers when it is selected >>> >>> Signed-off-by: Thiago Jung Bauermann >> >> Patch 2-14 & 16 applied to powerpc next, thanks. >> >> https://git.kernel.org/powerpc/c/136bc0397ae21dbf63ca02e5775ad353a479cd2f > > Thank you very much! No worries. I meant to say, there were some minor differences between your patch 15 adding the documentation and Claudio's version. If you want those differences applied please send me an incremental patch. cheers
Re: [Linux-kernel-mentees] [PATCH v2 2/3] PCI: sysfs: Change permissions from symbolic to octal
On Wed, Sep 04, 2019 at 02:33:44PM -0400, Don Dutile wrote:
> On 09/04/2019 02:22 AM, Kelsey Skunberg wrote:
> > On Thu, Aug 15, 2019 at 10:37:13AM -0400, Don Dutile wrote:
> > > On 08/14/2019 01:38 AM, Bjorn Helgaas wrote:
> > > > [+cc Bodong, Don, Greg for permission question]
> > > >
> > > > On Tue, Aug 13, 2019 at 02:45:12PM -0600, Kelsey Skunberg wrote:
> > > > > Symbolic permissions such as "(S_IWUSR | S_IWGRP)" are not
> > > > > preferred and octal permissions should be used instead. Change all
> > > > > symbolic permissions to octal permissions.
> > > > >
> > > > > Example of old:
> > > > >
> > > > > "(S_IWUSR | S_IWGRP)"
> > > > >
> > > > > Example of new:
> > > > >
> > > > > "0220"
> > > >
> > > >
> > > > >static DEVICE_ATTR_RO(sriov_totalvfs);
> > > > > -static DEVICE_ATTR(sriov_numvfs, (S_IRUGO | S_IWUSR | S_IWGRP),
> > > > > - sriov_numvfs_show,
> > > > > sriov_numvfs_store);
> > > > > +static DEVICE_ATTR(sriov_numvfs, 0664, sriov_numvfs_show,
> > > > > sriov_numvfs_store);
> > > > >static DEVICE_ATTR_RO(sriov_offset);
> > > > >static DEVICE_ATTR_RO(sriov_stride);
> > > > >static DEVICE_ATTR_RO(sriov_vf_device);
> > > > > -static DEVICE_ATTR(sriov_drivers_autoprobe, (S_IRUGO | S_IWUSR |
> > > > > S_IWGRP),
> > > > > -sriov_drivers_autoprobe_show,
> > > > > sriov_drivers_autoprobe_store);
> > > > > +static DEVICE_ATTR(sriov_drivers_autoprobe, 0664,
> > > > > sriov_drivers_autoprobe_show,
> > > > > +sriov_drivers_autoprobe_store);
> > > >
> > > > Greg noticed that sriov_numvfs and sriov_drivers_autoprobe have
> > > > "unusual" permissions. These were added by:
> > > >
> > > > 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF
> > > > driver binding")
> > > > 1789382a72a5 ("PCI: SRIOV control and status via sysfs")
> > > >
> > > > Kelsey's patch correctly preserves the existing permissions, but we
> > > > should double-check that they are the permissions they want, and
> > > > possibly add a comment about why they're different from the rest.
> > > >
> > > > Bjorn
> > > >
> >
> > Hi Don,
> >
> > > The rest being? ... 0644 vs 0664 ?
> > > The file is read & written, thus the (first) 6; I'll have to dig through
> > > very old (7 yr) notes to see if the second 6 is needed for libvirt (so it
> > > doesn't have to be root to enable).
> > >
> > > -dd
> > >
> >
> > Were you able to see if the unusual permissions (0664) are needed for
> > libvirt? I appreciate your help!
> >
> > -Kelsey
> >
> Daniel Berrangé reported that libvirt runs as root when dealing with anything
> PCI, and chowns files for qemu needs, so there is no need for the 664
> permission.
> For all I know, it's a simple typo that was allowed to creep in. :-/
>
> Feel free to modify to 644.
>
> -dd
>
Thank you for checking into this and getting back so quick! I'll cc you in
the patch. :)
Thanks again!
-Kelsey
[PATCH] ASoC: qcom: common: Include link-name in error messages
Reading out the link-name earlier and including it in the various error
messages makes it much more convenient to figure out what links have
unmet dependencies.
Signed-off-by: Bjorn Andersson
---
sound/soc/qcom/common.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/sound/soc/qcom/common.c b/sound/soc/qcom/common.c
index 2c7348ddbbb3..6c20bdd850f3 100644
--- a/sound/soc/qcom/common.c
+++ b/sound/soc/qcom/common.c
@@ -53,12 +53,18 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
link->num_cpus = 1;
link->num_platforms = 1;
+ ret = of_property_read_string(np, "link-name", >name);
+ if (ret) {
+ dev_err(card->dev, "error getting codec dai_link
name\n");
+ goto err;
+ }
+
cpu = of_get_child_by_name(np, "cpu");
platform = of_get_child_by_name(np, "platform");
codec = of_get_child_by_name(np, "codec");
if (!cpu) {
- dev_err(dev, "Can't find cpu DT node\n");
+ dev_err(dev, "%s: Can't find cpu DT node\n",
link->name);
ret = -EINVAL;
goto err;
}
@@ -66,7 +72,7 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
ret = of_parse_phandle_with_args(cpu, "sound-dai",
"#sound-dai-cells", 0, );
if (ret) {
- dev_err(card->dev, "error getting cpu phandle\n");
+ dev_err(card->dev, "%s: error getting cpu phandle\n",
link->name);
goto err;
}
link->cpus->of_node = args.np;
@@ -74,7 +80,7 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
ret = snd_soc_of_get_dai_name(cpu, >cpus->dai_name);
if (ret) {
- dev_err(card->dev, "error getting cpu dai name\n");
+ dev_err(card->dev, "%s: error getting cpu dai name\n",
link->name);
goto err;
}
@@ -83,14 +89,14 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
"sound-dai",
0);
if (!link->platforms->of_node) {
- dev_err(card->dev, "platform dai not found\n");
+ dev_err(card->dev, "%s: platform dai not
found\n", link->name);
ret = -EINVAL;
goto err;
}
ret = snd_soc_of_get_dai_link_codecs(dev, codec, link);
if (ret < 0) {
- dev_err(card->dev, "codec dai not found\n");
+ dev_err(card->dev, "%s: codec dai not found\n",
link->name);
goto err;
}
link->no_pcm = 1;
@@ -110,12 +116,6 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
}
link->ignore_suspend = 1;
- ret = of_property_read_string(np, "link-name", >name);
- if (ret) {
- dev_err(card->dev, "error getting codec dai_link
name\n");
- goto err;
- }
-
link->nonatomic = 1;
link->dpcm_playback = 1;
link->dpcm_capture = 1;
--
2.18.0
Re: [PATCH v2 4/4] gpio: dt-bindings: Update documentation with ast2600 controllers
On Thu, 5 Sep 2019, at 10:48, Rashmica Gupta wrote: > The ast2600 is a new generation of SoC from ASPEED. Similarly to the > ast2400 and ast2500, it has a GPIO controller for it's 3.6V GPIO pins. > Additionally, it has a GPIO controller for 36 1.8V GPIO pins. These > voltages are fixed and cannot be configured via pinconf, so we have two > separate drivers for them. See 3/4 for discussion about the commit message. > > Signed-off-by: Rashmica Gupta > --- > Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > index 7e9b586770b0..cd388797e07c 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > @@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings > --- > > Required properties: > -- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio" > +- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio", > + "aspeed,ast2600-gpio", or > "aspeed,ast2600-1-8v-gpio" See the discussion on patch 3/4 about how we might eliminate the aspeed,ast2600-1-8v-gpio compatible string. Also, this patch should be the first in the series and start the subject with "dt-bindings: gpio: aspeed: ..." Cheers, Andrew
Re: [PATCH v2 3/4] gpio: Add in ast2600 details to Aspeed driver
On Thu, 5 Sep 2019, at 10:47, Rashmica Gupta wrote:
> The ast2600 is a new generation of SoC from ASPEED. Similarly to the
> ast2400 and ast2500, it has a GPIO controller for it's 3.6V GPIO pins.
> Additionally, it has a GPIO controller for 36 1.8V GPIO pins. These
> voltages are fixed and cannot be configured via pinconf, so we need two
> separate drivers for them.
Working backwards, we don't really have multiple drivers, just different
configurations for the same driver. So I think this should be reworded.
Also it's not really the voltage differences that are driving the different
configurations but rather that there are two separate sets of registers
in the 2600 with overlapping bank names (they happen to be split into
3.3V and 1.8V groups). The key point being that there aren't just more
GPIO registers tacked on the end of the original 3.3V group.
>
> Signed-off-by: Rashmica Gupta
> ---
> drivers/gpio/gpio-aspeed.c | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index 16c6eaf70857..4723b8780a8c 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -662,12 +662,14 @@ static void aspeed_gpio_irq_handler(struct irq_desc
> *desc)
> struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> struct irq_chip *ic = irq_desc_get_chip(desc);
> struct aspeed_gpio *data = gpiochip_get_data(gc);
> - unsigned int i, p, girq;
> + unsigned int i, p, girq, banks;
> unsigned long reg;
> + struct aspeed_gpio *gpio = gpiochip_get_data(gc);
>
> chained_irq_enter(ic, desc);
>
> - for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
> + banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
> + for (i = 0; i < banks; i++) {
> const struct aspeed_gpio_bank *bank = _gpio_banks[i];
>
> reg = ioread32(bank_reg(data, bank, reg_irq_status));
> @@ -1108,9 +1110,33 @@ static const struct aspeed_gpio_config ast2500_config =
> /* 232 for simplicity, actual number is 228 (4-GPIO hole in GPIOAB) */
> { .nr_gpios = 232, .props = ast2500_bank_props, };
>
> +static const struct aspeed_bank_props ast2600_bank_props[] = {
> + /* input output */
> + {5, 0x, 0x}, /* U/V/W/X */
> + {6, 0x, 0x0fff}, /* Y/Z */
> + { },
> +};
> +
> +static const struct aspeed_gpio_config ast2600_config =
> + /* 208 3.6V GPIOs */
> + { .nr_gpios = 208, .props = ast2600_bank_props, };
> +
> +static const struct aspeed_bank_props ast2600_1_8v_bank_props[] = {
> + /* input output */
> + {1, 0x000f, 0x000f}, /* E */
If there are 36 GPIOs then this configuration is suggesting that all of them
are capable of input and output. A handy observation here is that the first
36 GPIOs of the 3.3V GPIO controller in the 2600 also have both capabilities,
so we can re-use the 3.3V configuration if we can limit the number of GPIOs
somehow.
The devicetree binding already describes an `ngpios` property so perhaps
we could make use of this to use the same properties struct instance for both
controllers in the 2600: Require that the property be present for 2600-
compatible devicetree nodes and test for its presence in probe(), then fall
back to the hard-coded value in the config struct if it is not (this keeps
devicetree compatibility for the 2400 and 2500 drivers).
This way we can eliminate the aspeed,ast2600-1-8v-gpio compatible string
below (we just use aspeed,ast2600-gpio for both controllers).
Thoughts?
Andrew
> + { },
> +};
> +
> +static const struct aspeed_gpio_config ast2600_1_8v_config =
> + /* 36 1.8V GPIOs */
> + { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
> +
> static const struct of_device_id aspeed_gpio_of_table[] = {
> { .compatible = "aspeed,ast2400-gpio", .data = _config, },
> { .compatible = "aspeed,ast2500-gpio", .data = _config, },
> + { .compatible = "aspeed,ast2600-gpio", .data = _config, },
> + { .compatible = "aspeed,ast2600-1-8v-gpio",
> + .data = _1_8v_config, },
> {}
> };
> MODULE_DEVICE_TABLE(of, aspeed_gpio_of_table);
> --
> 2.20.1
>
>
Re: [PATCH v3 2/3] Powerpc64/Watchpoint: Don't ignore extraneous exceptions
On 9/4/19 8:12 PM, Naveen N. Rao wrote: Ravi Bangoria wrote: On Powerpc64, watchpoint match range is double-word granular. On a watchpoint hit, DAR is set to the first byte of overlap between actual access and watched range. And thus it's quite possible that DAR does not point inside user specified range. Ex, say user creates a watchpoint with address range 0x1004 to 0x1007. So hw would be configured to watch from 0x1000 to 0x1007. If there is a 4 byte access from 0x1002 to 0x1005, DAR will point to 0x1002 and thus interrupt handler considers it as extraneous, but it's actually not, because part of the access belongs to what user has asked. So, let kernel pass it on to user and let user decide what to do with it instead of silently ignoring it. The drawback is, it can generate false positive events. I think you should do the additional validation here, instead of generating false positives. You should be able to read the instruction, run it through analyse_instr(), and then use OP_IS_LOAD_STORE() and GETSIZE() to understand the access range. This can be used to then perform a better match against what the user asked for. Ok. Let me see how feasible that is. But patch 1 and 3 are independent of this and can still go in. mpe? -Ravi
Re: lockdep warning while booting POWER9 PowerNV
Bart Van Assche writes:
> On 8/30/19 2:13 PM, Qian Cai wrote:
>> https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
>>
>> Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would
>> generate
>> a warning in lockdep_register_key() at,
>>
>> if (WARN_ON_ONCE(static_obj(key)))
>>
>> because
>>
>> key = 0xc19ad118
>> &_stext = 0xc000
>> &_end = 0xc49d
>>
>> i.e., it will cause static_obj() returns 1.
>
> (back from a trip)
>
> Hi Qian,
>
> Does this mean that on POWER9 it can happen that a dynamically allocated
> object has an address that falls between &_stext and &_end?
I thought that was true on all arches due to initmem, but seems not.
I guess we have the same problem as s390 and we need to define
arch_is_kernel_initmem_freed().
Qian, can you try this:
diff --git a/arch/powerpc/include/asm/sections.h
b/arch/powerpc/include/asm/sections.h
index 4a1664a8658d..616b1b7b7e52 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -5,8 +5,22 @@
#include
#include
+
+#define arch_is_kernel_initmem_freed arch_is_kernel_initmem_freed
+
#include
+extern bool init_mem_is_free;
+
+static inline int arch_is_kernel_initmem_freed(unsigned long addr)
+{
+ if (!init_mem_is_free)
+ return 0;
+
+ return addr >= (unsigned long)__init_begin &&
+ addr < (unsigned long)__init_end;
+}
+
extern char __head_end[];
#ifdef __powerpc64__
cheers
[PATCH] irqchip: uniphier-aidet: use devm_platform_ioremap_resource()
Replace the chain of platform_get_resource() and devm_ioremap_resource() with devm_platform_ioremap_resource(). This allows to remove the local variable for (struct resource *), and have one function call less. Signed-off-by: Masahiro Yamada --- drivers/irqchip/irq-uniphier-aidet.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-uniphier-aidet.c b/drivers/irqchip/irq-uniphier-aidet.c index ed7b4f47ff3f..89121b39be26 100644 --- a/drivers/irqchip/irq-uniphier-aidet.c +++ b/drivers/irqchip/irq-uniphier-aidet.c @@ -166,7 +166,6 @@ static int uniphier_aidet_probe(struct platform_device *pdev) struct device_node *parent_np; struct irq_domain *parent_domain; struct uniphier_aidet_priv *priv; - struct resource *res; parent_np = of_irq_find_parent(dev->of_node); if (!parent_np) @@ -181,8 +180,7 @@ static int uniphier_aidet_probe(struct platform_device *pdev) if (!priv) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - priv->reg_base = devm_ioremap_resource(dev, res); + priv->reg_base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(priv->reg_base)) return PTR_ERR(priv->reg_base); -- 2.17.1
[PATCH] Bluetooth: btrtl: Fix an issue that failing to download the FW which size is over 32K bytes
From: Max Chou
Fix the issue that when the FW size is 32K+, it will fail for the download
process because of the incorrect index.
When firmware patch length is over 32K, "dl_cmd->index" may >= 0x80. It
will be thought as "data end" that download process will not complete.
However, driver should recount the index from 1.
Signed-off-by: Max Chou
---
drivers/bluetooth/btrtl.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 0354e93e7a7c..bf3c02be6930 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -401,7 +401,11 @@ static int rtl_download_firmware(struct hci_dev *hdev,
BT_DBG("download fw (%d/%d)", i, frag_num);
- dl_cmd->index = i;
+ if (i > 0x7f)
+ dl_cmd->index = (i & 0x7f) + 1;
+ else
+ dl_cmd->index = i;
+
if (i == (frag_num - 1)) {
dl_cmd->index |= 0x80; /* data end */
frag_len = fw_len % RTL_FRAG_LEN;
--
2.17.1
Re: [PATCH 4.14 00/57] 4.14.142-stable review
On 9/4/19 5:38 PM, Kevin Hilman wrote: "kernelci.org bot" writes: stable-rc/linux-4.14.y boot: 144 boots: 5 failed, 131 passed with 8 offline (v4.14.141-58-g39a17ab1edd4) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.141-58-g39a17ab1edd4/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.141-58-g39a17ab1edd4/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.141-58-g39a17ab1edd4 Git Commit: 39a17ab1edd4adb3fb732726a36cb54a21cc570d Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 68 unique boards, 23 SoC families, 14 builds out of 201 Boot Failures Detected: arm: vexpress_defconfig: gcc-8: qemu_arm-virt-gicv3: 5 failed labs All 5 failures are for this same QEMU target in multiple labs It is also failing in linux-next and on several other stable versions. linux-next is in bad shape due to some usb issues, but I am not sure otherwise. I ran a quick test on 4.14.y-queue, and all my (arm, arm64) qemu tests are fine. Is it possible that this is a new or modified test ? Guenter
[PATCH V7 2/2] riscv: Add support for libdw
This patch adds support for DWARF register mappings and libdw registers
initialization, which is used by perf callchain analyzing when
--call-graph=dwarf is given.
Signed-off-by: Mao Han
Cc: Paul Walmsley
Cc: Greentime Hu
Cc: Palmer Dabbelt
Cc: linux-riscv
Cc: Christoph Hellwig
Cc: Guo Ren
---
tools/arch/riscv/include/uapi/asm/perf_regs.h | 42
tools/perf/Makefile.config| 6 +-
tools/perf/arch/riscv/Build | 1 +
tools/perf/arch/riscv/Makefile| 4 ++
tools/perf/arch/riscv/include/perf_regs.h | 96 +++
tools/perf/arch/riscv/util/Build | 2 +
tools/perf/arch/riscv/util/dwarf-regs.c | 72
tools/perf/arch/riscv/util/unwind-libdw.c | 57
8 files changed, 279 insertions(+), 1 deletion(-)
create mode 100644 tools/arch/riscv/include/uapi/asm/perf_regs.h
create mode 100644 tools/perf/arch/riscv/Build
create mode 100644 tools/perf/arch/riscv/Makefile
create mode 100644 tools/perf/arch/riscv/include/perf_regs.h
create mode 100644 tools/perf/arch/riscv/util/Build
create mode 100644 tools/perf/arch/riscv/util/dwarf-regs.c
create mode 100644 tools/perf/arch/riscv/util/unwind-libdw.c
diff --git a/tools/arch/riscv/include/uapi/asm/perf_regs.h
b/tools/arch/riscv/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..196f964
--- /dev/null
+++ b/tools/arch/riscv/include/uapi/asm/perf_regs.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd. */
+
+#ifndef _ASM_RISCV_PERF_REGS_H
+#define _ASM_RISCV_PERF_REGS_H
+
+enum perf_event_riscv_regs {
+ PERF_REG_RISCV_PC,
+ PERF_REG_RISCV_RA,
+ PERF_REG_RISCV_SP,
+ PERF_REG_RISCV_GP,
+ PERF_REG_RISCV_TP,
+ PERF_REG_RISCV_T0,
+ PERF_REG_RISCV_T1,
+ PERF_REG_RISCV_T2,
+ PERF_REG_RISCV_S0,
+ PERF_REG_RISCV_S1,
+ PERF_REG_RISCV_A0,
+ PERF_REG_RISCV_A1,
+ PERF_REG_RISCV_A2,
+ PERF_REG_RISCV_A3,
+ PERF_REG_RISCV_A4,
+ PERF_REG_RISCV_A5,
+ PERF_REG_RISCV_A6,
+ PERF_REG_RISCV_A7,
+ PERF_REG_RISCV_S2,
+ PERF_REG_RISCV_S3,
+ PERF_REG_RISCV_S4,
+ PERF_REG_RISCV_S5,
+ PERF_REG_RISCV_S6,
+ PERF_REG_RISCV_S7,
+ PERF_REG_RISCV_S8,
+ PERF_REG_RISCV_S9,
+ PERF_REG_RISCV_S10,
+ PERF_REG_RISCV_S11,
+ PERF_REG_RISCV_T3,
+ PERF_REG_RISCV_T4,
+ PERF_REG_RISCV_T5,
+ PERF_REG_RISCV_T6,
+ PERF_REG_RISCV_MAX,
+};
+#endif /* _ASM_RISCV_PERF_REGS_H */
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 89ac5a1..eaf25ee 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -60,6 +60,10 @@ ifeq ($(SRCARCH),arm64)
LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
endif
+ifeq ($(SRCARCH),riscv)
+ NO_PERF_REGS := 0
+endif
+
ifeq ($(SRCARCH),csky)
NO_PERF_REGS := 0
endif
@@ -82,7 +86,7 @@ endif
# Disable it on all other architectures in case libdw unwind
# support is detected in system. Add supported architectures
# to the check.
-ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc s390 csky))
+ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc s390 csky riscv))
NO_LIBDW_DWARF_UNWIND := 1
endif
diff --git a/tools/perf/arch/riscv/Build b/tools/perf/arch/riscv/Build
new file mode 100644
index 000..e4e5f33
--- /dev/null
+++ b/tools/perf/arch/riscv/Build
@@ -0,0 +1 @@
+perf-y += util/
diff --git a/tools/perf/arch/riscv/Makefile b/tools/perf/arch/riscv/Makefile
new file mode 100644
index 000..1aa9dd7
--- /dev/null
+++ b/tools/perf/arch/riscv/Makefile
@@ -0,0 +1,4 @@
+ifndef NO_DWARF
+PERF_HAVE_DWARF_REGS := 1
+endif
+PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/riscv/include/perf_regs.h
b/tools/perf/arch/riscv/include/perf_regs.h
new file mode 100644
index 000..7a8bcde
--- /dev/null
+++ b/tools/perf/arch/riscv/include/perf_regs.h
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd. */
+
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include
+#include
+#include
+
+#define PERF_REGS_MASK ((1ULL << PERF_REG_RISCV_MAX) - 1)
+#define PERF_REGS_MAX PERF_REG_RISCV_MAX
+#if __riscv_xlen == 64
+#define PERF_SAMPLE_REGS_ABIPERF_SAMPLE_REGS_ABI_64
+#else
+#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_32
+#endif
+
+#define PERF_REG_IPPERF_REG_RISCV_PC
+#define PERF_REG_SPPERF_REG_RISCV_SP
+
+static inline const char *perf_reg_name(int id)
+{
+ switch (id) {
+ case PERF_REG_RISCV_PC:
+ return "pc";
+ case PERF_REG_RISCV_RA:
+ return "ra";
+ case PERF_REG_RISCV_SP:
+ return "sp";
+ case PERF_REG_RISCV_GP:
+ return "gp";
+ case PERF_REG_RISCV_TP:
+ return
[PATCH V7 1/2] riscv: Add support for perf registers sampling
This patch implements the perf registers sampling and validation API
for riscv arch. The valid registers and their register ID are defined in
perf_regs.h. Perf tool can backtrace in userspace with unwind library
and the registers/user stack dump support.
Signed-off-by: Mao Han
Cc: Paul Walmsley
Cc: Greentime Hu
Cc: Palmer Dabbelt
Cc: linux-riscv
Cc: Christoph Hellwig
Cc: Guo Ren
---
arch/riscv/Kconfig | 2 ++
arch/riscv/include/uapi/asm/perf_regs.h | 42 +++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/perf_regs.c | 44 +
4 files changed, 89 insertions(+)
create mode 100644 arch/riscv/include/uapi/asm/perf_regs.h
create mode 100644 arch/riscv/kernel/perf_regs.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 59a4727..4bc976d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -35,6 +35,8 @@ config RISCV
select HAVE_DMA_CONTIGUOUS
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_PERF_EVENTS
+ select HAVE_PERF_REGS
+ select HAVE_PERF_USER_STACK_DUMP
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
select SPARSE_IRQ
diff --git a/arch/riscv/include/uapi/asm/perf_regs.h
b/arch/riscv/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..196f964
--- /dev/null
+++ b/arch/riscv/include/uapi/asm/perf_regs.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd. */
+
+#ifndef _ASM_RISCV_PERF_REGS_H
+#define _ASM_RISCV_PERF_REGS_H
+
+enum perf_event_riscv_regs {
+ PERF_REG_RISCV_PC,
+ PERF_REG_RISCV_RA,
+ PERF_REG_RISCV_SP,
+ PERF_REG_RISCV_GP,
+ PERF_REG_RISCV_TP,
+ PERF_REG_RISCV_T0,
+ PERF_REG_RISCV_T1,
+ PERF_REG_RISCV_T2,
+ PERF_REG_RISCV_S0,
+ PERF_REG_RISCV_S1,
+ PERF_REG_RISCV_A0,
+ PERF_REG_RISCV_A1,
+ PERF_REG_RISCV_A2,
+ PERF_REG_RISCV_A3,
+ PERF_REG_RISCV_A4,
+ PERF_REG_RISCV_A5,
+ PERF_REG_RISCV_A6,
+ PERF_REG_RISCV_A7,
+ PERF_REG_RISCV_S2,
+ PERF_REG_RISCV_S3,
+ PERF_REG_RISCV_S4,
+ PERF_REG_RISCV_S5,
+ PERF_REG_RISCV_S6,
+ PERF_REG_RISCV_S7,
+ PERF_REG_RISCV_S8,
+ PERF_REG_RISCV_S9,
+ PERF_REG_RISCV_S10,
+ PERF_REG_RISCV_S11,
+ PERF_REG_RISCV_T3,
+ PERF_REG_RISCV_T4,
+ PERF_REG_RISCV_T5,
+ PERF_REG_RISCV_T6,
+ PERF_REG_RISCV_MAX,
+};
+#endif /* _ASM_RISCV_PERF_REGS_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index b1bea89..696020f 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -40,5 +40,6 @@ obj-$(CONFIG_DYNAMIC_FTRACE) += mcount-dyn.o
obj-$(CONFIG_PERF_EVENTS) += perf_event.o
obj-$(CONFIG_PERF_EVENTS) += perf_callchain.o
+obj-$(CONFIG_HAVE_PERF_REGS) += perf_regs.o
clean:
diff --git a/arch/riscv/kernel/perf_regs.c b/arch/riscv/kernel/perf_regs.c
new file mode 100644
index 000..04a38fb
--- /dev/null
+++ b/arch/riscv/kernel/perf_regs.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+u64 perf_reg_value(struct pt_regs *regs, int idx)
+{
+ if (WARN_ON_ONCE((u32)idx >= PERF_REG_RISCV_MAX))
+ return 0;
+
+ return ((unsigned long *)regs)[idx];
+}
+
+#define REG_RESERVED (~((1ULL << PERF_REG_RISCV_MAX) - 1))
+
+int perf_reg_validate(u64 mask)
+{
+ if (!mask || mask & REG_RESERVED)
+ return -EINVAL;
+
+ return 0;
+}
+
+u64 perf_reg_abi(struct task_struct *task)
+{
+#if __riscv_xlen == 64
+ return PERF_SAMPLE_REGS_ABI_64;
+#else
+ return PERF_SAMPLE_REGS_ABI_32;
+#endif
+}
+
+void perf_get_regs_user(struct perf_regs *regs_user,
+ struct pt_regs *regs,
+ struct pt_regs *regs_user_copy)
+{
+ regs_user->regs = task_pt_regs(current);
+ regs_user->abi = perf_reg_abi(current);
+}
--
2.7.4
Re: [PATCH v2 1/4] gpio/aspeed: Fix incorrect number of banks
On Thu, 5 Sep 2019, at 10:46, Rashmica Gupta wrote:
> The current calculation for the number of GPIO banks is only correct if
> the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would
> currently say there are 0 banks, which is incorrect).
>
> Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
>
> Signed-off-by: Rashmica Gupta
Reviewed-by: Andrew Jeffery
> ---
> drivers/gpio/gpio-aspeed.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index 9defe25d4721..b83e23aecd18 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct
> platform_device *pdev)
> gpio->chip.base = -1;
>
> /* Allocate a cache of the output registers */
> - banks = gpio->config->nr_gpios >> 5;
> + banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
> gpio->dcache = devm_kcalloc(>dev,
> banks, sizeof(u32), GFP_KERNEL);
> if (!gpio->dcache)
> --
> 2.20.1
>
>
[PATCH] i2c: uniphier(-f): use devm_platform_ioremap_resource()
Replace the chain of platform_get_resource() and devm_ioremap_resource()
with devm_platform_ioremap_resource().
This allows to remove the local variable for (struct resource *), and
have one function call less.
Signed-off-by: Masahiro Yamada
---
drivers/i2c/busses/i2c-uniphier-f.c | 4 +---
drivers/i2c/busses/i2c-uniphier.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c
b/drivers/i2c/busses/i2c-uniphier-f.c
index 7acca2599f04..fc5354845ffa 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -538,7 +538,6 @@ static int uniphier_fi2c_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct uniphier_fi2c_priv *priv;
- struct resource *regs;
u32 bus_speed;
unsigned long clk_rate;
int irq, ret;
@@ -547,8 +546,7 @@ static int uniphier_fi2c_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, regs);
+ priv->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->membase))
return PTR_ERR(priv->membase);
diff --git a/drivers/i2c/busses/i2c-uniphier.c
b/drivers/i2c/busses/i2c-uniphier.c
index 0173840c32af..a6d7a3709051 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -326,7 +326,6 @@ static int uniphier_i2c_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct uniphier_i2c_priv *priv;
- struct resource *regs;
u32 bus_speed;
unsigned long clk_rate;
int irq, ret;
@@ -335,8 +334,7 @@ static int uniphier_i2c_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, regs);
+ priv->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->membase))
return PTR_ERR(priv->membase);
--
2.17.1
[PATCH V7 0/2] riscv: Add perf callchain support
This patchset adds perf callchain(FP/DWARF) support for RISC-V. It comes from the csky version callchain support with some slight modifications. The patchset base on Linux 5.3-rc6. The patchset has some 'checkpatch.pl --strict' warnings: WARNING: Use #include instead of #141: FILE: tools/perf/arch/riscv/include/perf_regs.h:9: +#include CHECK: Avoid CamelCase: #329: FILE: tools/perf/arch/riscv/util/unwind-libdw.c:9: +bool libdw__arch_set_initial_registers(Dwfl_Thread *thread, void *arg) CHECK: Avoid CamelCase: #333: FILE: tools/perf/arch/riscv/util/unwind-libdw.c:13: + Dwarf_Word dwarf_regs[32]; As all the other Linux architectures use asm/perf_regs.h directly and get these camelcases, I didn't try to fix them. Changes since v6: - add "WITH Linux-syscall-note" for uapi headers. Changes since v5: - use walk_stackframe from stacktrace.c to handle kernel callchain unwinding(fix invalid mem access) Changes since v4: - Add missing PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET verified with extra CFLAGS(-Wall -Werror) Changes since v3: - Add more strict check for unwind_frame_kernel - update for kernel 5.3 Changes since v2: - fix inconsistent comment - force to build kernel with -fno-omit-frame-pointer if perf event is enabled Changes since v1: - simplify implementation and code convention Signed-off-by: Mao Han Cc: Paul Walmsley Cc: Greentime Hu Cc: Palmer Dabbelt Cc: linux-riscv Cc: Christoph Hellwig Cc: Guo Ren Mao Han (2): riscv: Add support for perf registers sampling riscv: Add support for libdw arch/riscv/Kconfig| 2 + arch/riscv/include/uapi/asm/perf_regs.h | 42 arch/riscv/kernel/Makefile| 1 + arch/riscv/kernel/perf_regs.c | 44 tools/arch/riscv/include/uapi/asm/perf_regs.h | 42 tools/perf/Makefile.config| 6 +- tools/perf/arch/riscv/Build | 1 + tools/perf/arch/riscv/Makefile| 4 ++ tools/perf/arch/riscv/include/perf_regs.h | 96 +++ tools/perf/arch/riscv/util/Build | 2 + tools/perf/arch/riscv/util/dwarf-regs.c | 72 tools/perf/arch/riscv/util/unwind-libdw.c | 57 12 files changed, 368 insertions(+), 1 deletion(-) create mode 100644 arch/riscv/include/uapi/asm/perf_regs.h create mode 100644 arch/riscv/kernel/perf_regs.c create mode 100644 tools/arch/riscv/include/uapi/asm/perf_regs.h create mode 100644 tools/perf/arch/riscv/Build create mode 100644 tools/perf/arch/riscv/Makefile create mode 100644 tools/perf/arch/riscv/include/perf_regs.h create mode 100644 tools/perf/arch/riscv/util/Build create mode 100644 tools/perf/arch/riscv/util/dwarf-regs.c create mode 100644 tools/perf/arch/riscv/util/unwind-libdw.c -- 2.7.4
Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees
On Wed, 04 Sep 2019, Michel Lespinasse wrote:
I do not have time for a full review right now, but I did have a quick
pass at it and it does seem to match the direction I'd like this to
take.
Thanks, and no worries, I consider all this v5.5 material anyway.
Please let me know if you'd like me to do a full review of this, or if
it'll be easier to do it on the individual steps once this gets broken
up.
If nothing else, I would appreciate you making sure I didn't do anything
stupid in the interval_tree_generic.h lookup changes.
BTW are you going to plumbers ? I am and I would love to talk to you
there, about this and about MM range locking, too.
No, not this year; perhaps lsfmm (although that's not for a while).
Things I noticed in my quick pass:
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index e0ad547786e8..dc9fad8ea84a 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -450,13 +450,14 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
{
uint64_t size = radeon_bo_size(bo_va->bo);
struct radeon_vm *vm = bo_va->vm;
- unsigned last_pfn, pt_idx;
+ unsigned pt_idx;
uint64_t eoffset;
int r;
if (soffset) {
+ unsigned last_pfn;
/* make sure object fit at this offset */
- eoffset = soffset + size - 1;
+ eoffset = soffset + size;
if (soffset >= eoffset) {
Should probably be if (soffset > eoffset) now (just checking for
arithmetic overflow).
r = -EINVAL;
goto error_unreserve;
@@ -471,7 +472,7 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
}
} else {
- eoffset = last_pfn = 0;
+ eoffset = 1; /* interval trees are [a,b[ */
Looks highly suspicious to me, and doesn't jive with the eoffset /=
RADEON_GPU_PAGE_SIZE below.
I did not look deep enough into this to figure out what would be correct though.
I think you're right, I will double check this. I think we only wanna do
the RADEON_GPU_PAGE_SIZE division when soffset is non-zero.
}
mutex_lock(>mutex);
diff --git a/drivers/infiniband/hw/hfi1/mmu_rb.c
b/drivers/infiniband/hw/hfi1/mmu_rb.c
index 14d2a90964c3..d708c45bfabf 100644
--- a/drivers/infiniband/hw/hfi1/mmu_rb.c
+++ b/drivers/infiniband/hw/hfi1/mmu_rb.c
@@ -195,13 +195,13 @@ static struct mmu_rb_node *__mmu_rb_search(struct
mmu_rb_handler *handler,
trace_hfi1_mmu_rb_search(addr, len);
if (!handler->ops->filter) {
node = __mmu_int_rb_iter_first(>root, addr,
- (addr + len) - 1);
+ (addr + len));
} else {
for (node = __mmu_int_rb_iter_first(>root, addr,
- (addr + len) - 1);
+ (addr + len));
node;
node = __mmu_int_rb_iter_next(node, addr,
- (addr + len) - 1)) {
+ (addr + len))) {
if (handler->ops->filter(node, addr, len))
return node;
}
Weird unnecessary parentheses through this block.
Yes, but I wanted to leave it with the least amount of changes. There are plenty
of places that could use interval_tree_foreach helpers, like the vma tree has.
@@ -787,7 +787,7 @@ static phys_addr_t viommu_iova_to_phys(struct iommu_domain
*domain,
struct viommu_domain *vdomain = to_viommu_domain(domain);
spin_lock_irqsave(>mappings_lock, flags);
- node = interval_tree_iter_first(>mappings, iova, iova);
+ node = interval_tree_iter_first(>mappings, iova, iova + 1);
I was gonna suggest a stab iterator for the generic interval tree, but
maybe not if it's only used here.
I considered it as well.
diff --git a/include/linux/interval_tree_generic.h
b/include/linux/interval_tree_generic.h
index aaa8a0767aa3..e714e67ebdb5 100644
--- a/include/linux/interval_tree_generic.h
+++ b/include/linux/interval_tree_generic.h
@@ -69,12 +69,12 @@ ITSTATIC void ITPREFIX ## _remove(ITSTRUCT *node,
\
}\
\
/* \
- * Iterate over intervals intersecting [start;last] \
+ * Iterate over intervals intersecting [start;last[ \
Maybe I'm extra nitpicky, but I would suggest to use 'end' instead of
'last' when the intervals are half open: [start;end[
To me 'last' implies that it's in the interval, while 'end'
linux-next: manual merge of the net-next tree with the arm-soc tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/nuvoton/w90p910_ether.c
between commit:
00d2fbf73d55 ("net: remove w90p910-ether driver")
from the arm-soc tree and commit:
d1a55841ab24 ("net: Remove dev_err() usage after platform_get_irq()")
from the net-next tree.
I fixed it up (I removed the file) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
pgpfTsWq324Om.pgp
Description: OpenPGP digital signature
[PATCH] dmaengine: uniphier-mdmac: use devm_platform_ioremap_resource()
Replace the chain of platform_get_resource() and devm_ioremap_resource() with devm_platform_ioremap_resource(). This allows to remove the local variable for (struct resource *), and have one function call less. Signed-off-by: Masahiro Yamada --- drivers/dma/uniphier-mdmac.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/dma/uniphier-mdmac.c b/drivers/dma/uniphier-mdmac.c index ec65a7430dc4..e42f2312b7a1 100644 --- a/drivers/dma/uniphier-mdmac.c +++ b/drivers/dma/uniphier-mdmac.c @@ -385,7 +385,6 @@ static int uniphier_mdmac_probe(struct platform_device *pdev) struct device *dev = >dev; struct uniphier_mdmac_device *mdev; struct dma_device *ddev; - struct resource *res; int nr_chans, ret, i; nr_chans = platform_irq_count(pdev); @@ -401,8 +400,7 @@ static int uniphier_mdmac_probe(struct platform_device *pdev) if (!mdev) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - mdev->reg_base = devm_ioremap_resource(dev, res); + mdev->reg_base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(mdev->reg_base)) return PTR_ERR(mdev->reg_base); -- 2.17.1
Re: [PATCH 4.9 00/83] 4.9.191-stable review
stable-rc/linux-4.9.y boot: 129 boots: 6 failed, 114 passed with 8 offline, 1 untried/unknown (v4.9.190-84-ga232f5b3e312) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.190-84-ga232f5b3e312/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.190-84-ga232f5b3e312/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.190-84-ga232f5b3e312 Git Commit: a232f5b3e31224799f7506f9e9d4257d3d357d1b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 57 unique boards, 22 SoC families, 15 builds out of 197 Boot Failures Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab vexpress_defconfig: gcc-8: qemu_arm-virt-gicv3: 5 failed labs Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab arm: multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sun5i-r8-chip: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab --- For more info write to
Re: [PATCH v5 07/13] dt-bindings: pwm: add a property "num-pwms"
On Mon, 2019-09-02 at 18:04 +0200, Uwe Kleine-König wrote: > On Tue, Aug 27, 2019 at 01:39:24PM -0500, Rob Herring wrote: > > On Thu, Aug 22, 2019 at 02:58:37PM +0800, Sam Shih wrote: > > > From: Ryder Lee > > > > The subject should indicate this is for Mediatek. > > > > > > > > This adds a property "num-pwms" in example so that we could > > > specify the number of PWM channels via device tree. > > > > > > Signed-off-by: Ryder Lee > > > Signed-off-by: Sam Shih > > > Reviewed-by: Matthias Brugger > > > Acked-by: Uwe Kleine-König > > > --- > > > Changes since v5: > > > - Add an Acked-by tag > > > - This file is original v4 patch 5/10 > > > (https://patchwork.kernel.org/patch/11102577/) > > > > > > Change-Id: I429048afeffa96f3f14533910efe242f88776043 > > > --- > > > Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 7 --- > > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > > > b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > > > index 991728cb46cb..ea95b490a913 100644 > > > --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > > > @@ -14,12 +14,12 @@ Required properties: > > > has no clocks > > > - "top": the top clock generator > > > - "main": clock used by the PWM core > > > - - "pwm1-8": the eight per PWM clocks for mt2712 > > > - - "pwm1-6": the six per PWM clocks for mt7622 > > > - - "pwm1-5": the five per PWM clocks for mt7623 > > > + - "pwm1-N": the PWM clocks for each channel > > > + where N starting from 1 to the maximum number of PWM channels > > > > Once converted to schema, you are going to be back to listing them out. > > > > > - pinctrl-names: Must contain a "default" entry. > > > - pinctrl-0: One property must exist for each entry in pinctrl-names. > > > See pinctrl/pinctrl-bindings.txt for details of the property values. > > > + - num-pwms: the number of PWM channels. > > > > You can't add new required properties without breaking compatibility. > > > > You already have to imply the number of channels from the compatible (or > > number of clocks) and you have to keep doing so to maintain > > compatibility, so why not just keep doing that for new chips? > > This was a suggestion by me. The driver still handles compatibility > (i.e. falls back to the number of PWMs that was implied by the > compatible before). Given that there are various drivers that all solve > the same problem (i.e. different variants with different number of PWMs) > I thought it would be a good idea to introduce a property in the device > tree that specifies this number. > Only for newly introduced compatibles the num-pwms property is really > required. Differentiating the ones that need it and the ones that don't > seems over-engineered to me. I'm fine with both. num-pwms and pwm1-N is required properties for new chip, but it still have backward compatibility for old dt without num-pwms properties. > (BTW, using the number of clks doesn't really work because there are > also some variants without clocks. It is still under discussion if in > this case dummy-clocks should be provided IIRC.) Yes, the dummy-clocks of "top", "main" is needed in old MIPS dt. We also need fixed-clock for period calculation. Best Regards, Sam
[PATCH] bus: uniphier-system-bus: use devm_platform_ioremap_resource()
Replace the chain of platform_get_resource() and devm_ioremap_resource()
with devm_platform_ioremap_resource().
This allows to remove the local variable for (struct resource *), and
have one function call less.
Signed-off-by: Masahiro Yamada
---
drivers/bus/uniphier-system-bus.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/bus/uniphier-system-bus.c
b/drivers/bus/uniphier-system-bus.c
index e845c1a93f21..f70dedace20b 100644
--- a/drivers/bus/uniphier-system-bus.c
+++ b/drivers/bus/uniphier-system-bus.c
@@ -176,7 +176,6 @@ static int uniphier_system_bus_probe(struct platform_device
*pdev)
{
struct device *dev = >dev;
struct uniphier_system_bus_priv *priv;
- struct resource *regs;
const __be32 *ranges;
u32 cells, addr, size;
u64 paddr;
@@ -186,8 +185,7 @@ static int uniphier_system_bus_probe(struct platform_device
*pdev)
if (!priv)
return -ENOMEM;
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, regs);
+ priv->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->membase))
return PTR_ERR(priv->membase);
--
2.17.1
Re: [PATCH v2] mm: Unsigned 'nr_pages' always larger than zero
On Thu, Sep 05, 2019 at 10:17:51AM +0800, zhong jiang wrote:
> With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages'
> compare with zero. And __gup_longterm_locked pass an long local variant
> 'rc' to check_and_migrate_cma_pages. Hence it is nicer to change the
> parameter to long to fix the issue.
I think this patch is right, but I have concerns about this cocci grep.
The code says:
if ((nr_pages > 0) && migrate_allow) {
There's nothing wrong with this (... other than the fact that nr_pages might
happen to be a negative errno). nr_pages might be 0, and this would be
exactly the right test for that situation. I suppose some might argue
that this should be != 0 instead of > 0, but it depends on the situation
which one would read better.
So please don't blindly make these changes; you're right this time.
[BACKPORT 4.14.y v2 6/6] serial: sprd: Modify the baud rate calculation formula
From: Lanqing Liu
[Upstream commit 5b9cea15a3de5d65000d49f626b71b00d42a0577]
When the source clock is not divisible by the expected baud rate and
the remainder is not less than half of the expected baud rate, the old
formular will round up the frequency division coefficient. This will
make the actual baud rate less than the expected value and can not meet
the external transmission requirements.
Thus this patch modifies the baud rate calculation formula to support
the serial controller output the maximum baud rate.
Signed-off-by: Lanqing Liu
Signed-off-by: Baolin Wang
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Baolin Wang
---
drivers/tty/serial/sprd_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index e902494..72e96ab8 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -380,7 +380,7 @@ static void sprd_set_termios(struct uart_port *port,
/* ask the core to calculate the divisor for us */
baud = uart_get_baud_rate(port, termios, old, 0, SPRD_BAUD_IO_LIMIT);
- quot = (unsigned int)((port->uartclk + baud / 2) / baud);
+ quot = port->uartclk / baud;
/* set data length */
switch (termios->c_cflag & CSIZE) {
--
1.7.9.5
[BACKPORT 4.14.y v2 5/6] ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
From: Eric Biggers
[Upstream commit 25a09ce79639a8775244808c17282c491cff89cf]
Commit 0e5a610b5ca5 ("ppp: mppe: switch to RC4 library interface"),
which was merged through the crypto tree for v5.3, changed ppp_mppe.c to
use the new arc4_crypt() library function rather than access RC4 through
the dynamic crypto_skcipher API.
Meanwhile commit aad1dcc4f011 ("ppp: mppe: Add softdep to arc4") was
merged through the net tree and added a module soft-dependency on "arc4".
The latter commit no longer makes sense because the code now uses the
"libarc4" module rather than "arc4", and also due to the direct use of
arc4_crypt(), no module soft-dependency is required.
So revert the latter commit.
Cc: Takashi Iwai
Cc: Ard Biesheuvel
Signed-off-by: Eric Biggers
Signed-off-by: David S. Miller
Signed-off-by: Baolin Wang
---
drivers/net/ppp/ppp_mppe.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ppp/ppp_mppe.c b/drivers/net/ppp/ppp_mppe.c
index d9eda7c..6c7fd98 100644
--- a/drivers/net/ppp/ppp_mppe.c
+++ b/drivers/net/ppp/ppp_mppe.c
@@ -63,7 +63,6 @@
MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point
Encryption support");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE));
-MODULE_SOFTDEP("pre: arc4");
MODULE_VERSION("1.0.2");
static unsigned int
--
1.7.9.5
[BACKPORT 4.14.y v2 4/6] power: supply: sysfs: ratelimit property read error message
From: David Lechner [Upstream commit 87a2b65fc855e6be50f791c2ebbb492541896827] This adds rate limiting to the message that is printed when reading a power supply property via sysfs returns an error. This will prevent userspace applications from unintentionally dDOSing the system by continuously reading a property that returns an error. Signed-off-by: David Lechner Signed-off-by: Sebastian Reichel Signed-off-by: Baolin Wang --- drivers/power/supply/power_supply_sysfs.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c index eb5dc74..2ccaf4f 100644 --- a/drivers/power/supply/power_supply_sysfs.c +++ b/drivers/power/supply/power_supply_sysfs.c @@ -91,7 +91,8 @@ static ssize_t power_supply_show_property(struct device *dev, dev_dbg(dev, "driver has no data for `%s' property\n", attr->attr.name); else if (ret != -ENODEV && ret != -EAGAIN) - dev_err(dev, "driver failed to report `%s' property: %zd\n", + dev_err_ratelimited(dev, + "driver failed to report `%s' property: %zd\n", attr->attr.name, ret); return ret; } -- 1.7.9.5
[BACKPORT 4.14.y v2 3/6] pinctrl: sprd: Use define directive for sprd_pinconf_params values
From: Nathan Chancellor
[Upstream commit 957063c924736d4341e5d588757b9f31e8f6fa24]
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/sprd/pinctrl-sprd.c:845:19: warning: implicit conversion
from enumeration type 'enum sprd_pinconf_params' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"sprd,control", SPRD_PIN_CONFIG_CONTROL, 0},
~^~~
drivers/pinctrl/sprd/pinctrl-sprd.c:846:22: warning: implicit conversion
from enumeration type 'enum sprd_pinconf_params' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"sprd,sleep-mode", SPRD_PIN_CONFIG_SLEEP_MODE, 0},
~ ^~
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/138
Signed-off-by: Nathan Chancellor
Reviewed-by: Baolin Wang
Signed-off-by: Linus Walleij
Signed-off-by: Baolin Wang
---
drivers/pinctrl/sprd/pinctrl-sprd.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c
b/drivers/pinctrl/sprd/pinctrl-sprd.c
index 6352991..83958bd 100644
--- a/drivers/pinctrl/sprd/pinctrl-sprd.c
+++ b/drivers/pinctrl/sprd/pinctrl-sprd.c
@@ -159,10 +159,8 @@ struct sprd_pinctrl {
struct sprd_pinctrl_soc_info *info;
};
-enum sprd_pinconf_params {
- SPRD_PIN_CONFIG_CONTROL = PIN_CONFIG_END + 1,
- SPRD_PIN_CONFIG_SLEEP_MODE = PIN_CONFIG_END + 2,
-};
+#define SPRD_PIN_CONFIG_CONTROL(PIN_CONFIG_END + 1)
+#define SPRD_PIN_CONFIG_SLEEP_MODE (PIN_CONFIG_END + 2)
static int sprd_pinctrl_get_id_by_name(struct sprd_pinctrl *sprd_pctl,
const char *name)
--
1.7.9.5
[BACKPORT 4.14.y v2 2/6] locking/lockdep: Add debug_locks check in __lock_downgrade()
From: Waiman Long [Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf] Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning. Fix that by add a check for debug_locks at the beginning of __lock_downgrade(). Reported-by: Tetsuo Handa Reported-by: syzbot+53383ae265fb161ef...@syzkaller.appspotmail.com Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-long...@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Baolin Wang --- kernel/locking/lockdep.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 565005a..5c370c6 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct *curr, unsigned int depth, unsigned int depth; int i; + if (unlikely(!debug_locks)) + return 0; + depth = curr->lockdep_depth; /* * This function is about (re)setting the class of a held lock, -- 1.7.9.5
[BACKPORT 4.14.y v2 1/6] ip6: fix skb leak in ip6frag_expire_frag_queue()
From: Eric Dumazet
[Upstream commit 47d3d7fdb10a21c223036b58bd70ffdc24a472c4]
Since ip6frag_expire_frag_queue() now pulls the head skb
from frag queue, we should no longer use skb_get(), since
this leads to an skb leak.
Stefan Bader initially reported a problem in 4.4.stable [1] caused
by the skb_get(), so this patch should also fix this issue.
296583.091021] kernel BUG at
/build/linux-6VmqmP/linux-4.4.0/net/core/skbuff.c:1207!
[296583.091734] Call Trace:
[296583.091749] [] __pskb_pull_tail+0x50/0x350
[296583.091764] [] _decode_session6+0x26a/0x400
[296583.091779] [] __xfrm_decode_session+0x39/0x50
[296583.091795] [] icmpv6_route_lookup+0xf0/0x1c0
[296583.091809] [] icmp6_send+0x5e1/0x940
[296583.091823] [] ? __netif_receive_skb+0x18/0x60
[296583.091838] [] ? netif_receive_skb_internal+0x32/0xa0
[296583.091858] [] ? ixgbe_clean_rx_irq+0x594/0xac0 [ixgbe]
[296583.091876] [] ? nf_ct_net_exit+0x50/0x50
[nf_defrag_ipv6]
[296583.091893] [] icmpv6_send+0x21/0x30
[296583.091906] [] ip6_expire_frag_queue+0xe0/0x120
[296583.091921] [] nf_ct_frag6_expire+0x1f/0x30
[nf_defrag_ipv6]
[296583.091938] [] call_timer_fn+0x37/0x140
[296583.091951] [] ? nf_ct_net_exit+0x50/0x50
[nf_defrag_ipv6]
[296583.091968] [] run_timer_softirq+0x234/0x330
[296583.091982] [] __do_softirq+0x109/0x2b0
Fixes: d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6 defrag")
Signed-off-by: Eric Dumazet
Reported-by: Stefan Bader
Cc: Peter Oskolkov
Cc: Florian Westphal
Signed-off-by: David S. Miller
Signed-off-by: Baolin Wang
---
include/net/ipv6_frag.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/net/ipv6_frag.h b/include/net/ipv6_frag.h
index 28aa9b3..1f77fb4 100644
--- a/include/net/ipv6_frag.h
+++ b/include/net/ipv6_frag.h
@@ -94,7 +94,6 @@ static inline u32 ip6frag_obj_hashfn(const void *data, u32
len, u32 seed)
goto out;
head->dev = dev;
- skb_get(head);
spin_unlock(>q.lock);
icmpv6_send(head, ICMPV6_TIME_EXCEED, ICMPV6_EXC_FRAGTIME, 0);
--
1.7.9.5
[BACKPORT 4.14.y v2 0/6] Candidates from Spreadtrum 4.14 product kernel
With Arnd's script [1] help, I found some bugfixes in Spreadtrum 4.14 product kernel, but missing in v4.14.141: 25a09ce79639 ppp: mppe: Revert "ppp: mppe: Add softdep to arc4" 47d3d7fdb10a ip6: fix skb leak in ip6frag_expire_frag_queue() 5b9cea15a3de serial: sprd: Modify the baud rate calculation formula 513e1073d52e locking/lockdep: Add debug_locks check in __lock_downgrade() 957063c92473 pinctrl: sprd: Use define directive for sprd_pinconf_params values 87a2b65fc855 power: supply: sysfs: ratelimit property read error message [1] https://lore.kernel.org/lkml/20190322154425.3852517-19-a...@arndb.de/T/ Changes from v1: - Drop 2 unnecessary patches (patch 1 and patch 4) from v1 patch set. - Add upstream commit id in change log for each stable patch. David Lechner (1): power: supply: sysfs: ratelimit property read error message Eric Biggers (1): ppp: mppe: Revert "ppp: mppe: Add softdep to arc4" Eric Dumazet (1): ip6: fix skb leak in ip6frag_expire_frag_queue() Lanqing Liu (1): serial: sprd: Modify the baud rate calculation formula Nathan Chancellor (1): pinctrl: sprd: Use define directive for sprd_pinconf_params values Waiman Long (1): locking/lockdep: Add debug_locks check in __lock_downgrade() drivers/net/ppp/ppp_mppe.c|1 - drivers/pinctrl/sprd/pinctrl-sprd.c |6 ++ drivers/power/supply/power_supply_sysfs.c |3 ++- drivers/tty/serial/sprd_serial.c |2 +- include/net/ipv6_frag.h |1 - kernel/locking/lockdep.c |3 +++ 6 files changed, 8 insertions(+), 8 deletions(-) -- 1.7.9.5
Re: [PATCH 2/2] mmc: block: add CMD13 polling for ioctl() cmd with R1B response
On Wed, 2019-09-04 at 14:11 +, Avri Altman wrote:
> > static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct
> > mmc_blk_data *md,
> >struct mmc_blk_ioc_data *idata)
> > {
> > @@ -623,6 +675,9 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card
> > *card, struct mmc_blk_data *md,
> > __func__, status, err);
> > }
> >
> > + if (!err && (cmd.flags & MMC_RSP_R1B))
> > + err = card_busy_detect(card, MMC_BLK_TIMEOUT_MS, NULL);
> > +
> > return err;
> > }
> You have both the R1B flag check, and status poll (for rpmb) few line above.
> Maybe you could re-use it.
> It will both simplify this patch, and save the tad optimization of your first
> patch.
>
> Thanks,
> Avri
So that we can drop the ioctl_rpmb_card_status_poll() as it do almost
the same thing with card_busy_detect().
Re: [PATCH RESEND] fs/epoll: fix the edge-triggered mode for nested epoll
Hi,
I created an epoll wakeup test project, listed some possible cases,
and any other corner cases needs to be added?
https://github.com/heiher/epoll-wakeup/blob/master/README.md
On Wed, Sep 4, 2019 at 10:02 PM Heiher wrote:
>
> Hi,
>
> On Wed, Sep 4, 2019 at 8:02 PM Jason Baron wrote:
> >
> >
> >
> > On 9/4/19 5:57 AM, Roman Penyaev wrote:
> > > On 2019-09-03 23:08, Jason Baron wrote:
> > >> On 9/2/19 11:36 AM, Roman Penyaev wrote:
> > >>> Hi,
> > >>>
> > >>> This is indeed a bug. (quick side note: could you please remove efd[1]
> > >>> from your test, because it is not related to the reproduction of a
> > >>> current bug).
> > >>>
> > >>> Your patch lacks a good description, what exactly you've fixed. Let
> > >>> me speak out loud and please correct me if I'm wrong, my understanding
> > >>> of epoll internals has become a bit rusty: when epoll fds are nested
> > >>> an attempt to harvest events (ep_scan_ready_list() call) produces a
> > >>> second (repeated) event from an internal fd up to an external fd:
> > >>>
> > >>> epoll_wait(efd[0], ...):
> > >>>ep_send_events():
> > >>> ep_scan_ready_list(depth=0):
> > >>> ep_send_events_proc():
> > >>> ep_item_poll():
> > >>> ep_scan_ready_list(depth=1):
> > >>> ep_poll_safewake():
> > >>> ep_poll_callback()
> > >>> list_add_tail(, >rdllist);
> > >>> ^^
> > >>> repeated event
> > >>>
> > >>>
> > >>> In your patch you forbid wakeup for the cases, where depth != 0, i.e.
> > >>> for all nested cases. That seems clear. But what if we can go further
> > >>> and remove the whole chunk, which seems excessive:
> > >>>
> > >>> @@ -885,26 +886,11 @@ static __poll_t ep_scan_ready_list(struct
> > >>> eventpoll *ep,
> > >>>
> > >>> -
> > >>> - if (!list_empty(>rdllist)) {
> > >>> - /*
> > >>> -* Wake up (if active) both the eventpoll wait list and
> > >>> -* the ->poll() wait list (delayed after we release the
> > >>> lock).
> > >>> -*/
> > >>> - if (waitqueue_active(>wq))
> > >>> - wake_up(>wq);
> > >>> - if (waitqueue_active(>poll_wait))
> > >>> - pwake++;
> > >>> - }
> > >>> write_unlock_irq(>lock);
> > >>>
> > >>> if (!ep_locked)
> > >>> mutex_unlock(>mtx);
> > >>>
> > >>> - /* We have to call this outside the lock */
> > >>> - if (pwake)
> > >>> - ep_poll_safewake(>poll_wait);
> > >>>
> > >>>
> > >>> I reason like that: by the time we've reached the point of scanning
> > >>> events
> > >>> for readiness all wakeups from ep_poll_callback have been already fired
> > >>> and
> > >>> new events have been already accounted in ready list (ep_poll_callback()
> > >>> calls
> > >>> the same ep_poll_safewake()). Here, frankly, I'm not 100% sure and
> > >>> probably
> > >>> missing some corner cases.
> > >>>
> > >>> Thoughts?
> > >>
> > >> So the: 'wake_up(>wq);' part, I think is about waking up other
> > >> threads that may be in waiting in epoll_wait(). For example, there may
> > >> be multiple threads doing epoll_wait() on the same epoll fd, and the
> > >> logic above seems to say thread 1 may have processed say N events and
> > >> now its going to to go off to work those, so let's wake up thread 2 now
> > >> to handle the next chunk.
> > >
> > > Not quite. Thread which calls ep_scan_ready_list() processes all the
> > > events, and while processing those, removes them one by one from the
> > > ready list. But if event mask is !0 and event belongs to
> > > Level Triggered Mode descriptor (let's say default mode) it tails event
> > > again back to the list (because we are in level mode, so event should
> > > be there). So at the end of this traversing loop ready list is likely
> > > not empty, and if so, wake up again is called for nested epoll fds.
> > > But, those nested epoll fds should get already all the notifications
> > > from the main event callback ep_poll_callback(), regardless any thread
> > > which traverses events.
> > >
> > > I suppose this logic exists for decades, when Davide (the author) was
> > > reshuffling the code here and there.
> > >
> > > But I do not feel confidence to state that this extra wakeup is bogus,
> > > I just have a gut feeling that it looks excessive.
> >
> > Note that I was talking about the wakeup done on ep->wq not ep->poll_wait.
> > The path that I'm concerned about is let's say that there are N events
> > queued on the ready list. A thread that was woken up in epoll_wait may
> > decide to only process say N/2 of then. Then it will call wakeup on ep->wq
> > and this will wakeup another thread to process the remaining N/2. Without
> > the wakeup, the original thread isn't going to process the events until
> > it finishes with the original N/2
Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote: > On Tue 2019-09-03 15:02:34, Miroslav Benes wrote: > > On Mon, 2 Sep 2019, Joe Lawrence wrote: > > > > > On 9/2/19 12:13 PM, Miroslav Benes wrote: > > > >> I can easily foresee more problems like those in the future. Going > > > >> forward we have to always keep track of which special sections are > > > >> needed for which architectures. Those special sections can change over > > > >> time, or can simply be overlooked for a given architecture. It's > > > >> fragile. > > > > > > > > Indeed. It bothers me a lot. Even x86 "port" is not feature complete in > > > > this regard (jump labels, alternatives,...) and who knows what lurks in > > > > the corners of the other architectures we support. > > > > > > > > So it is in itself reason enough to do something about late module > > > > patching. > > > > > > > > > > Hi Miroslav, > > > > > > I was tinkering with the "blue-sky" ideas that I mentioned to Josh the > > > other > > > day. > > > > > I dunno if you had a chance to look at what removing that code looks > > > like, but I can continue to flesh out that idea if it looks interesting: > > > > Unfortunately no and I don't think I'll come up with something useful > > before LPC, so anything is really welcome. > > > > > > > > https://github.com/joe-lawrence/linux/tree/blue-sky > > > > > > A full demo would require packaging up replacement .ko's with a > > > livepatch, as > > > well as "blacklisting" those deprecated .kos, etc. But that's all I had > > > time > > > to cook up last week before our holiday weekend here. > > > > Frankly, I'm not sure about this approach. I'm kind of torn. The current > > solution is far from ideal, but I'm not excited about the other options > > either. It seems like the choice is basically between "general but > > technically complicated fragile solution with nontrivial maintenance > > burden", or "something safer and maybe cleaner, but limiting for > > users/distros". Of course it depends on whether the limitation is even > > real and how big it is. Unfortunately we cannot quantify it much and that > > is probably why our opinions (in the email thread) differ. > > I wonder what is necessary for a productive discussion on Plumbers: > > + Josh would like to see what code can get removed when late > handling of modules gets removed. I think that it might be > partially visible from Joe's blue-sky patches. Yes, and I like what I see. Especially the removal of the .klp.arch nastiness! > + I would like to better understand the scope of the current > problems. It is about modifying code in the livepatch that > depends on position of the related code: > > + relocations are rather clear; we will need them anyway > to access non-public (static) API from the original code. > > + What are the other changes? I think the .klp.arch sections are the big ones: .klp.arch.altinstructions .klp.arch.parainstructions .klp.arch.jump_labels (doesn't exist yet) And that's just x86... And then of course there's the klp coming/going notifiers which have also been an additional source of complexity. > + Do we use them in livepatches? How often? I don't have a number, but it's very common to patch a function which uses jump labels or alternatives. > + How often new problematic features appear? I'm not exactly sure what you mean, but it seems that anytime we add a new feature, we have to try to wrap our heads around how it interacts with the weirdness of late module patching. > + Would be possible to detect potential problems, for example > by comparing the code in the binary and in memory when > the module is loaded the normal way? Perhaps, though I assume this would be some out-of-band testing thing. > + Would be possible to reset the livepatch code in memory > when the related module is unloaded and safe us half > of the troubles? Maybe, but I think that would solve a much lower percentage of our troubles than half :-/ > + It might be useful to prepare overview of the existing proposals > and agree on the positives and negatives. I am afraid that some > of them might depend on the customer base and > use cases. Sometimes we might not have enough information. > But it might be good to get on the same page where possible. I think we've already done that for the existing proposals. Maybe Miroslav can summarize them at the LPC session. > Anyway, it might rule out some variants so that we could better > concentrate on the acceptable ones. Or come with yet another > proposal that would avoid the real blockers. I'd like to hear more specific negatives about Joe's recent patches, which IMO, are the best option we've discussed so far. -- Josh
Re: [PATCH V6 3/3] riscv: Add support for libdw
On Wed, Sep 04, 2019 at 02:24:57PM -0700, Paul Walmsley wrote: > Hello Mao Han, > > On Thu, 29 Aug 2019, Mao Han wrote: > > > This patch add support for DWARF register mappings and libdw registers > > initialization, which is used by perf callchain analyzing when > > --call-graph=dwarf is given. > > > diff --git a/tools/arch/riscv/include/uapi/asm/perf_regs.h > > b/tools/arch/riscv/include/uapi/asm/perf_regs.h > > new file mode 100644 > > index 000..df1a581 > > --- /dev/null > > +++ b/tools/arch/riscv/include/uapi/asm/perf_regs.h > > @@ -0,0 +1,42 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > As with > > https://lore.kernel.org/linux-riscv/cajf2gtrxh_bx0rwstzmtnx+umzfvtl_ivnewptvm50slaqj...@mail.gmail.com/T/#t > > is it possible to change this license string to "GPL-2.0 WITH > Linux-syscall-note" to match the other Linux architectures? > Thanks for suggestion. I didn't notice the UAPI headers are supposed to have the exception notes. I'll update the license string and resend them. Thanks, Mao Han
Re: [LKP] [fs/namei.c] e013ec23b8: WARNING:at_fs/dcache.c:#dentry_free
On Wed, Sep 04, 2019 at 02:52:40PM +0800, Oliver Sang wrote:
> On Sat, Aug 31, 2019 at 04:42:46PM +0100, Al Viro wrote:
> > On Sat, Aug 31, 2019 at 09:09:17PM +0800, kernel test robot wrote:
> >
> > > [ 13.886602] WARNING: CPU: 0 PID: 541 at fs/dcache.c:338
> > > dentry_free+0x7f/0x90
> > > [ 13.889208] Modules linked in:
> > > [ 13.890276] CPU: 0 PID: 541 Comm: readlink Not tainted
> > > 5.3.0-rc1-8-ge013ec23b8231 #1
> > > [ 13.892699] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> > > BIOS 1.10.2-1 04/01/2014
> > > [ 13.895419] RIP: 0010:dentry_free+0x7f/0x90
> > > [ 13.896739] Code: f0 75 cb 48 8d be b0 00 00 00 48 83 c4 08 48 c7 c6
> > > 60 8d cd a5 e9 51 69 e4 ff 48 89 3c 24 48 c7 c7 f8 a9 cb a6 e8 7f 37 e3
> > > ff <0f> 0b 48 8b 34 24 eb 8f 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90
> > > [ 13.901957] RSP: 0018:b5524063fe38 EFLAGS: 00010282
> > > [ 13.903527] RAX: 0024 RBX: 9941878040c0 RCX:
> > > a706aa08
> > > [ 13.905566] RDX: RSI: 0096 RDI:
> > > 0246
> > > [ 13.907612] RBP: R08: 0280 R09:
> > > 0033
> > > [ 13.909664] R10: R11: b5524063fce8 R12:
> > > 994187804118
> > > [ 13.911711] R13: 99427a81 R14: 994187d7c8f0 R15:
> > > 99427a810b80
> > > [ 13.913753] FS: () GS:9942bfc0()
> > > knlGS:
> > > [ 13.916187] CS: 0010 DS: 002b ES: 002b CR0: 80050033
> > > [ 13.917892] CR2: 0937458b CR3: 6800a000 CR4:
> > > 06f0
> > > [ 13.919925] Call Trace:
> > > [ 13.920840] __dentry_kill+0x13c/0x1a0
> > > [ 13.922076] path_put+0x12/0x20
> > > [ 13.923148] free_fs_struct+0x1b/0x30
> > > [ 13.924346] do_exit+0x304/0xc40
> > > [ 13.925438] ? __schedule+0x25d/0x670
> > > [ 13.926642] do_group_exit+0x3a/0xa0
> > > [ 13.927817] __ia32_sys_exit_group+0x14/0x20
> > > [ 13.929160] do_fast_syscall_32+0xa9/0x340
> > > [ 13.930565] entry_SYSENTER_compat+0x7f/0x91
> > > [ 13.931924] ---[ end trace 02c6706eb2c2ebf2 ]---
> > >
> > >
> > > To reproduce:
> > >
> > > # build kernel
> > > cd linux
> > > cp config-5.3.0-rc1-8-ge013ec23b8231 .config
> > > make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig prepare
> > > modules_prepare bzImage
> > >
> > > git clone https://github.com/intel/lkp-tests.git
> > > cd lkp-tests
> > > bin/lkp qemu -k job-script # job-script is attached in
> > > this email
> >
> > Can't reproduce here...
>
> any detail failure by using this reproducer?
>
> >
> > I see one potential problem in there, but I would expect it to have the
> > opposite effect (I really don't believe that it's a ->d_count wraparound -
> > that would've taken much longer than a minute, if nothing else).
> >
> > How reliably is it reproduced on your setup and does the following have
> > any impact, one way or another?
>
> It is always reproduced. We noticed that your branch was rebased. If it's
> still with problem, will let you know.
by testing the below HEAD commit of current branch, the issue gone
commit 46c46f8df9aa425cc4d6bc89d57a6fedf83dc797 (HEAD -> work.namei,
origin/work.namei)
Author: Al Viro
Date: Sat Jul 27 16:29:22 2019 -0400
>
> >
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 412479e4c258..671c3c1a3425 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -643,10 +643,8 @@ static bool legitimize_root(struct nameidata *nd)
> > {
> > if (!nd->root.mnt || (nd->flags & LOOKUP_ROOT))
> > return true;
> > - if (unlikely(!legitimize_path(nd, >root, nd->root_seq)))
> > - return false;
> > nd->flags |= LOOKUP_ROOT_GRABBED;
> > - return true;
> > + return legitimize_path(nd, >root, nd->root_seq);
> > }
> >
> > /*
> > ___
> > LKP mailing list
> > l...@lists.01.org
> > https://lists.01.org/mailman/listinfo/lkp
> ___
> LKP mailing list
> l...@lists.01.org
> https://lists.01.org/mailman/listinfo/lkp
[PATCH net-next v2] r8152: adjust the settings of ups flags
The UPS feature only works for runtime suspend, so UPS flags only
need to be set before enabling runtime suspend. Therefore, I create
a struct to record relative information, and use it before runtime
suspend.
All chips could record such information, even though not all of
them support the feature of UPS. Then, some functions could be
combined.
Signed-off-by: Hayes Wang
---
v2:
Fix the conflicts after commit 771efeda3936 ("r8152: modify
rtl8152_set_speed function") is applied.
---
drivers/net/usb/r8152.c | 208 +++-
1 file changed, 120 insertions(+), 88 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ec23c166e67b..08726090570e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -445,18 +445,18 @@
#define UPS_FLAGS_250M_CKDIV BIT(2)
#define UPS_FLAGS_EN_ALDPS BIT(3)
#define UPS_FLAGS_CTAP_SHORT_DIS BIT(4)
-#define UPS_FLAGS_SPEED_MASK (0xf << 16)
#define ups_flags_speed(x) ((x) << 16)
#define UPS_FLAGS_EN_EEE BIT(20)
#define UPS_FLAGS_EN_500M_EEE BIT(21)
#define UPS_FLAGS_EN_EEE_CKDIV BIT(22)
+#define UPS_FLAGS_EEE_PLLOFF_100 BIT(23)
#define UPS_FLAGS_EEE_PLLOFF_GIGA BIT(24)
#define UPS_FLAGS_EEE_CMOD_LV_EN BIT(25)
#define UPS_FLAGS_EN_GREEN BIT(26)
#define UPS_FLAGS_EN_FLOW_CTR BIT(27)
enum spd_duplex {
- NWAY_10M_HALF = 1,
+ NWAY_10M_HALF,
NWAY_10M_FULL,
NWAY_100M_HALF,
NWAY_100M_FULL,
@@ -749,6 +749,23 @@ struct r8152 {
void (*autosuspend_en)(struct r8152 *tp, bool enable);
} rtl_ops;
+ struct ups_info {
+ u32 _10m_ckdiv:1;
+ u32 _250m_ckdiv:1;
+ u32 aldps:1;
+ u32 lite_mode:2;
+ u32 speed_duplex:4;
+ u32 eee:1;
+ u32 eee_lite:1;
+ u32 eee_ckdiv:1;
+ u32 eee_plloff_100:1;
+ u32 eee_plloff_giga:1;
+ u32 eee_cmod_lv:1;
+ u32 green:1;
+ u32 flow_control:1;
+ u32 ctap_short_off:1;
+ } ups_info;
+
atomic_t rx_count;
bool eee_en;
@@ -2865,14 +2882,76 @@ static void r8153_u2p3en(struct r8152 *tp, bool enable)
ocp_write_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL, ocp_data);
}
-static void r8153b_ups_flags_w1w0(struct r8152 *tp, u32 set, u32 clear)
+static void r8153b_ups_flags(struct r8152 *tp)
{
- u32 ocp_data;
+ u32 ups_flags = 0;
+
+ if (tp->ups_info.green)
+ ups_flags |= UPS_FLAGS_EN_GREEN;
+
+ if (tp->ups_info.aldps)
+ ups_flags |= UPS_FLAGS_EN_ALDPS;
+
+ if (tp->ups_info.eee)
+ ups_flags |= UPS_FLAGS_EN_EEE;
+
+ if (tp->ups_info.flow_control)
+ ups_flags |= UPS_FLAGS_EN_FLOW_CTR;
+
+ if (tp->ups_info.eee_ckdiv)
+ ups_flags |= UPS_FLAGS_EN_EEE_CKDIV;
+
+ if (tp->ups_info.eee_cmod_lv)
+ ups_flags |= UPS_FLAGS_EEE_CMOD_LV_EN;
+
+ if (tp->ups_info._10m_ckdiv)
+ ups_flags |= UPS_FLAGS_EN_10M_CKDIV;
+
+ if (tp->ups_info.eee_plloff_100)
+ ups_flags |= UPS_FLAGS_EEE_PLLOFF_100;
- ocp_data = ocp_read_dword(tp, MCU_TYPE_USB, USB_UPS_FLAGS);
- ocp_data &= ~clear;
- ocp_data |= set;
- ocp_write_dword(tp, MCU_TYPE_USB, USB_UPS_FLAGS, ocp_data);
+ if (tp->ups_info.eee_plloff_giga)
+ ups_flags |= UPS_FLAGS_EEE_PLLOFF_GIGA;
+
+ if (tp->ups_info._250m_ckdiv)
+ ups_flags |= UPS_FLAGS_250M_CKDIV;
+
+ if (tp->ups_info.ctap_short_off)
+ ups_flags |= UPS_FLAGS_CTAP_SHORT_DIS;
+
+ switch (tp->ups_info.speed_duplex) {
+ case NWAY_10M_HALF:
+ ups_flags |= ups_flags_speed(1);
+ break;
+ case NWAY_10M_FULL:
+ ups_flags |= ups_flags_speed(2);
+ break;
+ case NWAY_100M_HALF:
+ ups_flags |= ups_flags_speed(3);
+ break;
+ case NWAY_100M_FULL:
+ ups_flags |= ups_flags_speed(4);
+ break;
+ case NWAY_1000M_FULL:
+ ups_flags |= ups_flags_speed(5);
+ break;
+ case FORCE_10M_HALF:
+ ups_flags |= ups_flags_speed(6);
+ break;
+ case FORCE_10M_FULL:
+ ups_flags |= ups_flags_speed(7);
+ break;
+ case FORCE_100M_HALF:
+ ups_flags |= ups_flags_speed(8);
+ break;
+ case FORCE_100M_FULL:
+ ups_flags |= ups_flags_speed(9);
+ break;
+ default:
+ break;
+ }
+
+ ocp_write_dword(tp, MCU_TYPE_USB, USB_UPS_FLAGS, ups_flags);
}
static void r8153b_green_en(struct r8152 *tp, bool enable)
@@ -2893,7 +2972,7 @@ static void r8153b_green_en(struct r8152 *tp,
RE: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500
> -Original Message-
> From: Liviu Dudau
> Sent: 2019年9月5日 0:13
> To: Wen He
> Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
>
> Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface
> configuration for Mali DP500
>
> Caution: EXT Email
>
> On Thu, Aug 15, 2019 at 11:14:17AM +, Wen He wrote:
> >
> >
> > > -Original Message-
> > > From: Liviu Dudau
> > > Sent: 2019年7月22日 17:33
> > > To: Wen He
> > > Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org;
> > > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> > >
> > > Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS
> > > interface configuration for Mali DP500
> > >
> > > Caution: EXT Email
> > >
> > > On Mon, Jul 22, 2019 at 02:12:08AM +, Wen He wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Liviu Dudau
> > > > > Sent: 2019年7月19日 19:46
> > > > > To: Wen He
> > > > > Cc: dri-de...@lists.freedesktop.org;
> > > > > linux-kernel@vger.kernel.org; brian.star...@arm.com;
> > > > > airl...@linux.ie; dan...@ffwll.ch; Leo Li
> > > > > Subject: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS
> > > > > interface configuration for Mali DP500
> > > > >
> > > > > Caution: EXT Email
> > > > >
> > > > > On Fri, Jul 19, 2019 at 05:54:45PM +0800, Wen He wrote:
> > > > > > Configure the display Quality of service (QoS) levels priority
> > > > > > if the optional property node "arm,malidp-aqros-value" is
> > > > > > defined in DTS
> > > file.
> > > > > >
> > > > > > QoS signaling using AQROS and AWQOS AXI interface signals, the
> > > > > > AQROS is driven from the "RQOS" register, so needed to program
> > > > > > the RQOS register to avoid the 4k resolution flicker issue on
> > > > > > the LS1028A
> > > platform.
> > > > > >
> > > > > > Signed-off-by: Wen He
> > > > > > ---
> > > > > > change in v2:
> > > > > > - modify some content based on feedback from
> > > > > > maintainers
> > > > > >
> > > > > > drivers/gpu/drm/arm/malidp_drv.c | 6 ++
> > > > > > drivers/gpu/drm/arm/malidp_hw.c | 13 +
> > > > > > drivers/gpu/drm/arm/malidp_hw.h | 3 +++
> > > > > > drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> > > > > > 4 files changed, 32 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > index f25ec4382277..61c49a0668a7 100644
> > > > > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > @@ -818,6 +818,12 @@ static int malidp_bind(struct device
> > > > > > *dev)
> > > > > >
> > > > > > malidp->core_id = version;
> > > > > >
> > > > > > + ret = of_property_read_u32(dev->of_node,
> > > > > > +
> "arm,malidp-arqos-value",
> > > > > > + >arqos_value);
> > > > > > + if (ret)
> > > > > > + hwdev->arqos_value = 0x0;
> > > > >
> > > > > Is zero the default value that you want? I thought it was 0x00010001.
> > > >
> > > > Actually, the register default value always is 0x00010001(can be
> > > > found in RM
> > > document).
> > >
> > > Exactly, but with your code you are overwriting it to 0 if the DT
> > > doesn't have the arm,malidp-arqos-value property.
> > >
> > > >
> > > > >
> > > > > > +
> > > > > > /* set the number of lines used for output of RGB data */
> > > > > > ret = of_property_read_u8_array(dev->of_node,
> > > > > >
> > > > > > "arm,malidp-output-port-lines", diff --git
> > > > > > a/drivers/gpu/drm/arm/malidp_hw.c
> > > > > > b/drivers/gpu/drm/arm/malidp_hw.c index
> > > > > > 50af399d7f6f..323683b1e9f7
> > > > > > 100644
> > > > > > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > > > > > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > > > > > @@ -374,6 +374,19 @@ static void malidp500_modeset(struct
> > > > > malidp_hw_device *hwdev, struct videomode *
> > > > > > malidp_hw_setbits(hwdev,
> > > > > > MALIDP_DISP_FUNC_ILACED,
> > > > > MALIDP_DE_DISPLAY_FUNC);
> > > > > > else
> > > > > > malidp_hw_clearbits(hwdev,
> > > MALIDP_DISP_FUNC_ILACED,
> > > > > > MALIDP_DE_DISPLAY_FUNC);
> > > > > > +
> > > > > > + /*
> > > > > > + * Program the RQoS register to avoid 4k resolution flicker
> > > > > > + * on the LS1028A.
> > > > > > + */
> > > > > > + if (hwdev->arqos_value) {
> > > > > > + val = hwdev->arqos_value;
> > > > > > +
> > > > > > + if (mode->pixelclock == 59400)
> > > > >
> > > > > If I remember correctly, you declare the pixelclocks in the
> > > > > device tree, so I wonder if this is needed here. We should just
> > > > > set what value was in the DT regardless of the pixelclock, and
> > > > > then you manipulate the DT to choose one of your fixed
> > > > > resolutions and also set the
> > > QoS value.
> > > >
> > > > Yes, you
[PATCH -next] staging: exfat: Use kmemdup in exfat_symlink()
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing
---
drivers/staging/exfat/exfat_super.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/exfat/exfat_super.c
b/drivers/staging/exfat/exfat_super.c
index 5b5c2ca8c9aa..05fdecc3e9ea 100644
--- a/drivers/staging/exfat/exfat_super.c
+++ b/drivers/staging/exfat/exfat_super.c
@@ -2696,12 +2696,11 @@ static int exfat_symlink(struct inode *dir, struct
dentry *dentry,
inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode);
/* timestamp is already written, so mark_inode_dirty() is unneeded. */
- EXFAT_I(inode)->target = kmalloc(len+1, GFP_KERNEL);
+ EXFAT_I(inode)->target = kmemdup(target, len + 1, GFP_KERNEL);
if (!EXFAT_I(inode)->target) {
err = -ENOMEM;
goto out;
}
- memcpy(EXFAT_I(inode)->target, target, len+1);
dentry->d_time = GET_IVERSION(dentry->d_parent->d_inode);
d_instantiate(dentry, inode);
Re: [PATCH v6 0/7] Support dsi for mt8183
Hi, Jitao: For this series, applied to mediatek-drm-next-5.5 [1], and I break "[v6,2/7] drm/mediatek: fixes CMDQ reg address of mt8173 is different with mt2701" into two patches, thanks. [1] https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5 Regards, CK On Sun, 2019-08-11 at 18:40 +0800, Jitao Shi wrote: > Change since v5: > - fine tune dphy timing. > > Change since v4: > - move mipi_dsi_host_unregiter() to .remove() > - fine tune add frame size control coding style > - change the data type of data_rate as u32, and add DIV_ROUND_UP_ULL > - use div_u64 when 80ULL / dsi->data_rate. > > Changes since v3 > - add one more 'tab' for bitwise define. > - add Tested-by: Ryan Case > and Reviewed-by: CK Hu . > - remove compare da_hs_zero to da_hs_prepare. > > Changes since v2: > - change the video timing calc method > - fine the dsi and mipitx init sequence > - fine tune commit msg > > Changes since v1: > - separate frame size and reg commit control independent patches. > - fix some return values in probe > - remove DSI_CMDW0 in "CMDQ reg address of mt8173 is different with mt2701" > > Jitao Shi (7): > drm/mediatek: move mipi_dsi_host_register to probe > drm/mediatek: fixes CMDQ reg address of mt8173 is different with > mt2701 > drm/mediatek: add dsi reg commit disable control > drm/mediatek: add frame size control > drm/mediatek: add mt8183 dsi driver support > drm/mediatek: change the dsi phytiming calculate method > drm: mediatek: adjust dsi and mipi_tx probe sequence > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- > drivers/gpu/drm/mediatek/mtk_dsi.c | 224 ++--- > 2 files changed, 161 insertions(+), 65 deletions(-) >
Re: NFS: remove the redundant check when kfree an object in nfs_netns_client_release
On 2019/9/4 23:11, Markus Elfring wrote: >> kfree has taken the null check in account. > I suggest to take another look at a similar patch. How to fast find out the similar patch. Search the key word doesn't work well. Thanks, zhong jiang > NFS: fix ifnullfree.cocci warnings > https://lkml.org/lkml/2019/7/7/73 > https://lore.kernel.org/patchwork/patch/1098005/ > https://lore.kernel.org/r/alpine.DEB.2.21.1907071844310.2521@hadrien/ > > Regards, > Markus > > . >
[PATCH v2] Bluetooth: btusb: Use cmd_timeout to reset Realtek device
From: Alex Lu
Realtek Bluetooth controller provides a BT_DIS reset pin for hardware
reset of it. The cmd_timeout is helpful on Realtek bluetooth controller
where the firmware gets stuck.
Signed-off-by: Alex Lu
---
Changes in v2
- Provide a dedicated btusb_rtl_cmd_timeout in case of Realtek hardware
drivers/bluetooth/btusb.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 31d3febed187..4ac012df5666 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -524,6 +524,36 @@ static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
gpiod_set_value_cansleep(reset_gpio, 0);
}
+static void btusb_rtl_cmd_timeout(struct hci_dev *hdev)
+{
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct gpio_desc *reset_gpio = data->reset_gpio;
+
+ if (++data->cmd_timeout_cnt < 5)
+ return;
+
+ if (!reset_gpio) {
+ bt_dev_err(hdev, "No gpio to reset Realtek device, ignoring");
+ return;
+ }
+
+ /*
+* Toggle the hard reset line. The Realtek device is going to yank
+* itself off the USB and then replug. The cleanup is handled correctly
+* on the way out(standard USB disconnect), and the new device is
+* detected cleanly and bound to the driver again like it should be.
+*/
+ if (test_and_set_bit(BTUSB_HW_RESET_ACTIVE, >flags)) {
+ bt_dev_err(hdev, "last reset failed? Not resetting again");
+ return;
+ }
+
+ bt_dev_err(hdev, "Reset Realtek device via gpio");
+ gpiod_set_value_cansleep(reset_gpio, 0);
+ msleep(200);
+ gpiod_set_value_cansleep(reset_gpio, 1);
+}
+
static inline void btusb_free_frags(struct btusb_data *data)
{
unsigned long flags;
@@ -3783,6 +3813,7 @@ static int btusb_probe(struct usb_interface *intf,
if (id->driver_info & BTUSB_REALTEK) {
hdev->setup = btrtl_setup_realtek;
hdev->shutdown = btrtl_shutdown_realtek;
+ hdev->cmd_timeout = btusb_rtl_cmd_timeout;
/* Realtek devices lose their updated firmware over global
* suspend that means host doesn't send SET_FEATURE
--
2.21.0
Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC
Hi Martin, On 9/3/2019 6:04 AM, Martin Blumenstingl wrote: Hi, On Mon, Sep 2, 2019 at 11:45 AM Chuan Hua, Lei wrote: Hi Martin, On 9/2/2019 5:38 AM, Martin Blumenstingl wrote: Hi, On Fri, Aug 30, 2019 at 5:02 AM Chuan Hua, Lei wrote: Hi Martin, On 8/30/2019 5:40 AM, Martin Blumenstingl wrote: Hi, On Thu, Aug 29, 2019 at 4:51 AM Chuan Hua, Lei wrote: I'm not surprised that we got some of the IP block layout for the VRX200 RCU "wrong" - all "documentation" we have is the old Lantiq UGW (BSP). with proper documentation (as in a "public datasheet for the SoC") it would be easy to spot these mistakes (at least I assume that the quality of the Infineon / Lantiq datasheets is excellent). back to reset-intel-syscon: assigning only one job to the RCU hardware is a good idea (in my opinion). that brings up a question: why do we need the "syscon" compatible for the RCU node? this is typically used when registers are accessed by another IP block and the other driver has to access these registers as well. does this mean that there's more hidden in the RCU registers? As I mentioned, some other misc registers are put into RCU even they don't belong to reset functions. OK, just be aware that there are also rules for syscon compatible drivers, see for example: [0] if Rob (dt-bindings maintainer) is happy with the documentation in patch 1 then I'm fine with it as well. for my own education I would appreciate if you could describe these "other misc registers" with a few sentences (I assume that this can also help Rob) For LGM, RCU is clean. There would be no MISC register after software's feedback. These misc registers will be moved to chiptop/misc groups(implemented by syscon). For legacy SoC, we do have a lot MISC registers for different SoCs. OK, I think I understand now: chiptop != RCU so RCU really only has one purpose: handling resets while chiptop manages all the random bits does this means we don't need RCU to match "syscon"? If we don't support legacy SoC with the same driver, we don't need syscon, just regmap. Regmap is a must for us since we will use regmap proxy to implement secure rest via secure processor. I think we should drop the syscon compatible for LGM then even for the legacy SoCs the reset controller should not have a syscon compatible: instead it should have a syscon parent (as the current "lantiq,xrx200-reset" binding requires and as suggested by Rob for another IP block: [0]) I am not sure if syscon parent really matches hardware implementation. In all our Networking SoCs, chiptop is kind of misc register collection. Some registers can't belong to any particular group, or they need to work together with other modules(therefore, these misc registers would be accessed by two or more modules). However, chiptop is not a hardware module. keeping regmap is great in my opinion because it's a nice API and gets rid of some boilerplate even better if it makes things easier for accessing the secure processor [...] 4. Code not optimized and intel internal review not assessed. insights from you (like the issue with the reset callback) are very valuable - this shows that we should focus on having one driver. Based on the above findings, I would suggest reset-lantiq.c to move to reset-intel-syscon.c my concern with having two separate drivers is that it will be hard to migrate from reset-lantiq to the "optimized" reset-intel-syscon driver. I don't have access to the datasheets for the any Lantiq/Intel SoC (VRX200 and even older). so debugging issues after switching from one driver to another is tedious because I cannot tell which part of the driver is causing a problem (it's either "all code from driver A" vs "all code from driver B", meaning it's hard to narrow it down). with separate commits/patches that are improving the reset-lantiq driver I can do git bisect to find the cause of a problem on the older SoCs (VRX200 for example) Our internal version supports XRX350/XRX500/PRX300(MIPS based) and latest Lighting Mountain(X86 based). Migration to reset-intel-syscon.c should be straight forward. what about the _reset callback on the XRX350/XRX500/PRX300 SoCs - do they only use level resets (_assert and _deassert) or are some reset lines using reset pulses (_reset)? when we wanted to switch from reset-lantiq.c to reset-intel-syscon.c we still had to add support for the _reset callback as this is missing in reset-intel-syscon.c currently Yes. We have reset pulse(assert, then check the reset status). only now I realized that the reset-intel-syscon driver does not seem to use the status registers (instead it's looking at the reset registers when checking the status). what happened to the status registers - do they still exist in newer SoCs (like LGM)? why are they not used? Reset status check is there. regmap_read_poll_timeout to check status big. Status register offset <4) from request register. For legacy, there is one exception, we can add soc specific data to handle it.
[PATCH -next] staging: exfat: remove unused including
Remove including that don't need it. Signed-off-by: YueHaibing --- drivers/staging/exfat/exfat_super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/exfat/exfat_super.c b/drivers/staging/exfat/exfat_super.c index 5b5c2ca8c9aa..cb43a39864af 100644 --- a/drivers/staging/exfat/exfat_super.c +++ b/drivers/staging/exfat/exfat_super.c @@ -3,7 +3,6 @@ * Copyright (C) 2012-2013 Samsung Electronics Co., Ltd. */ -#include #include #include #include
Re: [PATCH v6 0/3] Support mipitx for mt8183
Hi, Jitao: For this series, applied to mediatek-drm-next-5.5 [1], thanks. [1] https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5 Regards, CK On Wed, 2019-08-07 at 16:46 +0800, Jitao Shi wrote: > Change since v5: > - remove mipi_tx->ref_clk > - remove mt8183 pll prepare unprepare > > Change since v4: > - fine tune the mipi_tx->ref_clk and mipi_tx->pll sequence >1. Prepare mipi_tx->ref_clk >2. Prepare mipi_tx->pll >3. Enable mipi_tx->ref_clk >4. Enable mipi_tx->pll > > Changes since v3: > - turn off PLL before setting PLL parameters. > > Changes since v2: > - update Acked-by: Rob Herring > - update mt8183 max bit rate support > > Changes since v1: > - update dt-bindings document for mt8183 mipitx. > - remove mtk_mipitx_clk_get_ops and assign clk_ops in probe. > - fix the lincence > - remove txdiv1 from mtk_mipi_tx_pll_prepare > > Jitao Shi (3): > dt-bindings: display: mediatek: update dsi supported chips > drm/mediatek: separate mipi_tx to different file > drm/mediatek: add mipi_tx driver for mt8183 > > .../display/mediatek/mediatek,dsi.txt | 4 +- > drivers/gpu/drm/mediatek/Makefile | 2 + > drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 338 ++ > drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 49 +++ > drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 289 +++ > drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 150 > 6 files changed, 515 insertions(+), 317 deletions(-) > create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c >
[PATCH -next] staging: exfat: remove duplicated include from exfat_super.c
Remove duplicated include. Signed-off-by: YueHaibing --- drivers/staging/exfat/exfat_super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/exfat/exfat_super.c b/drivers/staging/exfat/exfat_super.c index 5b5c2ca8c9aa..f202a6588dc3 100644 --- a/drivers/staging/exfat/exfat_super.c +++ b/drivers/staging/exfat/exfat_super.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include
Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
On Tue, Sep 03, 2019 at 03:02:34PM +0200, Miroslav Benes wrote: > On Mon, 2 Sep 2019, Joe Lawrence wrote: > > > On 9/2/19 12:13 PM, Miroslav Benes wrote: > > >> I can easily foresee more problems like those in the future. Going > > >> forward we have to always keep track of which special sections are > > >> needed for which architectures. Those special sections can change over > > >> time, or can simply be overlooked for a given architecture. It's > > >> fragile. > > > > > > Indeed. It bothers me a lot. Even x86 "port" is not feature complete in > > > this regard (jump labels, alternatives,...) and who knows what lurks in > > > the corners of the other architectures we support. > > > > > > So it is in itself reason enough to do something about late module > > > patching. > > > > > > > Hi Miroslav, > > > > I was tinkering with the "blue-sky" ideas that I mentioned to Josh the other > > day. > > > I dunno if you had a chance to look at what removing that code looks > > like, but I can continue to flesh out that idea if it looks interesting: > > Unfortunately no and I don't think I'll come up with something useful > before LPC, so anything is really welcome. > > > > > https://github.com/joe-lawrence/linux/tree/blue-sky I like this a lot. > > A full demo would require packaging up replacement .ko's with a livepatch, > > as > > well as "blacklisting" those deprecated .kos, etc. But that's all I had > > time > > to cook up last week before our holiday weekend here. > > Frankly, I'm not sure about this approach. I'm kind of torn. The current > solution is far from ideal, but I'm not excited about the other options > either. It seems like the choice is basically between "general but > technically complicated fragile solution with nontrivial maintenance > burden", or "something safer and maybe cleaner, but limiting for > users/distros". Of course it depends on whether the limitation is even > real and how big it is. Unfortunately we cannot quantify it much and that > is probably why our opinions (in the email thread) differ. How would this option be "limiting for users/distros"? If the packaging part of the solution is done correctly then I don't see how it would be limiting. -- Josh
Re: [PATCH v3 2/2] dwc: PCI: intel: Intel PCIe RC controller driver
Hi Dilip, On 9/4/2019 6:10 PM, Dilip Kota wrote: Add support to PCIe RC controller on Intel Universal Gateway SoC. PCIe controller is based of Synopsys Designware pci core. Signed-off-by: Dilip Kota --- changes on v3: Rename PCIe app logic registers with PCIE_APP prefix. PCIE_IOP_CTRL configuration is not required. Remove respective code. Remove wrapper functions for clk enable/disable APIs. Use platform_get_resource_byname() instead of devm_platform_ioremap_resource() to be similar with DWC framework. Rename phy name to "pciephy". Modify debug message in msi_init() callback to be more specific. Remove map_irq() callback. Enable the INTx interrupts at the time of PCIe initialization. Reduce memory fragmentation by using variable "struct dw_pcie pci" instead of allocating memory. Reduce the delay to 100us during enpoint initialization intel_pcie_ep_rst_init(). Call dw_pcie_host_deinit() during remove() instead of directly calling PCIe core APIs. Rename "intel,rst-interval" to "reset-assert-ms". Remove unused APP logic Interrupt bit macro definitions. Use dwc framework's dw_pcie_setup_rc() for PCIe host specific configuration instead of redefining the same functionality in the driver. Move the whole DT parsing specific code to intel_pcie_get_resources() drivers/pci/controller/dwc/Kconfig | 13 + drivers/pci/controller/dwc/Makefile | 1 + drivers/pci/controller/dwc/pcie-intel-axi.c | 840 3 files changed, 854 insertions(+) create mode 100644 drivers/pci/controller/dwc/pcie-intel-axi.c diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig index 6ea778ae4877..e44b9b6a6390 100644 --- a/drivers/pci/controller/dwc/Kconfig +++ b/drivers/pci/controller/dwc/Kconfig @@ -82,6 +82,19 @@ config PCIE_DW_PLAT_EP order to enable device-specific features PCI_DW_PLAT_EP must be selected. +config PCIE_INTEL_AXI +bool "Intel AHB/AXI PCIe host controller support" +depends on PCI_MSI +depends on PCI +depends on OF +select PCIE_DW_HOST +help + Say 'Y' here to enable support for Intel AHB/AXI PCIe Host + controller driver. + The Intel PCIe controller is based on the Synopsys Designware + pcie core and therefore uses the Designware core functions to + implement the driver. + config PCI_EXYNOS bool "Samsung Exynos PCIe controller" depends on SOC_EXYNOS5440 || COMPILE_TEST diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile index b085dfd4fab7..46e656ebdf90 100644 --- a/drivers/pci/controller/dwc/Makefile +++ b/drivers/pci/controller/dwc/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o +obj-$(CONFIG_PCIE_INTEL_AXI) += pcie-intel-axi.o obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o obj-$(CONFIG_PCI_IMX6) += pci-imx6.o diff --git a/drivers/pci/controller/dwc/pcie-intel-axi.c b/drivers/pci/controller/dwc/pcie-intel-axi.c new file mode 100644 index ..75607ce03ebf --- /dev/null +++ b/drivers/pci/controller/dwc/pcie-intel-axi.c @@ -0,0 +1,840 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * PCIe host controller driver for Intel AXI PCIe Bridge + * + * Copyright (c) 2019 Intel Corporation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../../pci.h" +#include "pcie-designware.h" + +#define PCIE_CCRID 0x8 + +#define PCIE_LCAP 0x7C +#define PCIE_LCAP_MAX_LINK_SPEED GENMASK(3, 0) +#define PCIE_LCAP_MAX_LENGTH_WIDTH GENMASK(9, 4) + +/* Link Control and Status Register */ +#define PCIE_LCTLSTS 0x80 +#define PCIE_LCTLSTS_ASPM_ENABLE GENMASK(1, 0) +#define PCIE_LCTLSTS_RCB128BIT(3) +#define PCIE_LCTLSTS_LINK_DISABLE BIT(4) +#define PCIE_LCTLSTS_COM_CLK_CFG BIT(6) +#define PCIE_LCTLSTS_HW_AW_DIS BIT(9) +#define PCIE_LCTLSTS_LINK_SPEEDGENMASK(19, 16) +#define PCIE_LCTLSTS_NEGOTIATED_LINK_WIDTH GENMASK(25, 20) +#define PCIE_LCTLSTS_SLOT_CLK_CFG BIT(28) + +#define PCIE_LCTLSTS2 0xA0 +#define PCIE_LCTLSTS2_TGT_LINK_SPEED GENMASK(3, 0) +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_25GT 0x1 +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_5GT 0x2 +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_8GT 0x3 +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_16GT 0x4
Re: [PATCH V6 1/3] riscv: Add perf callchain support
On Wed, Sep 04, 2019 at 12:54:41PM -0700, Paul Walmsley wrote: > Hello Mao Han, > > On Thu, 29 Aug 2019, Mao Han wrote: > > > This patch add support for perf callchain sampling on riscv platform. > > The return address of leaf function is retrieved from pt_regs as > > it is not saved in the outmost frame. > > > > Signed-off-by: Mao Han > > Cc: Paul Walmsley > > Cc: Greentime Hu > > Cc: Palmer Dabbelt > > Cc: linux-riscv > > Cc: Christoph Hellwig > > Cc: Guo Ren > > There are some 'checkpatch.pl --strict' warnings with this patch (below). > These have been fixed here. The following patch has been queued for > v5.4-rc1 with Greentime's Tested-by:. Thanks for your hard work following > up on the feedback with these patches - Thanks for the fixes. I'll check patches with --strict next time. Thanks, Mao Han
Re: [PATCH v3 1/2] dt-bindings: PCI: intel: Add YAML schemas for the PCIe RC controller
Hi Dilip,
On 9/4/2019 6:10 PM, Dilip Kota wrote:
The Intel PCIe RC controller is Synopsys Designware
based PCIe core. Add YAML schemas for PCIe in RC mode
present in Intel Universal Gateway soc.
Signed-off-by: Dilip Kota
---
changes on v3:
Add the appropriate License-Identifier
Rename intel,rst-interval to 'reset-assert-us'
rst->interval to reset-assert-ms(should be typo error)
Add additionalProperties: false
Rename phy-names to 'pciephy'
Remove the dtsi node split of SoC and board in the example
Add #interrupt-cells = <1>; or else interrupt parsing will fail
Name yaml file with compatible name
.../devicetree/bindings/pci/intel,lgm-pcie.yaml| 137 +
1 file changed, 137 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/intel,lgm-pcie.yaml
diff --git a/Documentation/devicetree/bindings/pci/intel,lgm-pcie.yaml
b/Documentation/devicetree/bindings/pci/intel,lgm-pcie.yaml
new file mode 100644
index ..5e5cc7fd66cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/intel,lgm-pcie.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/intel-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel AXI bus based PCI express root complex
+
+maintainers:
+ - Dilip Kota
+
+properties:
+ compatible:
+const: intel,lgm-pcie
+
+ device_type:
+const: pci
+
+ "#address-cells":
+const: 3
+
+ "#size-cells":
+const: 2
+
+ reg:
+items:
+ - description: Controller control and status registers.
+ - description: PCIe configuration registers.
+ - description: Controller application registers.
+
+ reg-names:
+items:
+ - const: dbi
+ - const: config
+ - const: app
+
+ ranges:
+description: Ranges for the PCI memory and I/O regions.
+
+ resets:
+maxItems: 1
+
+ clocks:
+description: PCIe registers interface clock.
+
+ phys:
+maxItems: 1
+
+ phy-names:
+const: pciephy
+
+ reset-gpios:
+maxItems: 1
+
+ num-lanes:
+description: Number of lanes to use for this port.
+
+ linux,pci-domain:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: PCI domain ID.
+
+ interrupts:
+description: PCIe core integrated miscellaneous interrupt.
+
+ '#interrupt-cells':
+const: 1
+
+ interrupt-map-mask:
+description: Standard PCI IRQ mapping properties.
+
+ interrupt-map:
+description: Standard PCI IRQ mapping properties.
+
+ max-link-speed:
+description: Specify PCI Gen for link capability.
+
+ bus-range:
+description: Range of bus numbers associated with this controller.
+
+ reset-assert-ms:
+description: |
+ Device reset interval in ms.
+ Some devices need an interval upto 500ms. By default it is 100ms.
+
+required:
+ - compatible
+ - device_type
+ - reg
+ - reg-names
+ - ranges
+ - resets
+ - clocks
+ - phys
+ - phy-names
+ - reset-gpios
+ - num-lanes
+ - linux,pci-domain
+ - interrupts
+ - interrupt-map
+ - interrupt-map-mask
+
+additionalProperties: false
+
+examples:
+ - |
+pcie10:pcie@d0e0 {
+ compatible = "intel,lgm-pcie";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <
+0xd0e0 0x1000
+0xd200 0x80
+0xd0a41000 0x1000
+>;
+ reg-names = "dbi", "config", "app";
+ linux,pci-domain = <0>;
+ max-link-speed = <4>;
+ bus-range = <0x00 0x08>;
+ interrupt-parent = <>;
+ interrupts = <67 1>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 27 1>,
+ <0 0 0 2 28 1>,
+ <0 0 0 3 29 1>,
+ <0 0 0 4 30 1>;
+ ranges = <0x0200 0 0xd400 0xd400 0 0x0400>;
+ resets = < 0x50 0>;
+ clocks = < LGM_GCLK_PCIE10>;
+ phys = <>;
+ phy-names = "pciephy";
+ status = "okay";
+ reset-assert-ms = <500>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ num-lanes = <2>;
+};
[PATCH v2] mm: Unsigned 'nr_pages' always larger than zero
With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages'
compare with zero. And __gup_longterm_locked pass an long local variant
'rc' to check_and_migrate_cma_pages. Hence it is nicer to change the
parameter to long to fix the issue.
Fixes: 932f4a630a69 ("mm/gup: replace get_user_pages_longterm() with
FOLL_LONGTERM")
Signed-off-by: zhong jiang
---
mm/gup.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 23a9f9c..ee0b71f 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1433,13 +1433,13 @@ static struct page *new_non_cma_page(struct page *page,
unsigned long private)
static long check_and_migrate_cma_pages(struct task_struct *tsk,
struct mm_struct *mm,
unsigned long start,
- unsigned long nr_pages,
+ long nr_pages,
struct page **pages,
struct vm_area_struct **vmas,
unsigned int gup_flags)
{
- unsigned long i;
- unsigned long step;
+ long i;
+ long step;
bool drain_allow = true;
bool migrate_allow = true;
LIST_HEAD(cma_page_list);
@@ -1520,7 +1520,7 @@ static long check_and_migrate_cma_pages(struct
task_struct *tsk,
static long check_and_migrate_cma_pages(struct task_struct *tsk,
struct mm_struct *mm,
unsigned long start,
- unsigned long nr_pages,
+ long nr_pages,
struct page **pages,
struct vm_area_struct **vmas,
unsigned int gup_flags)
--
1.7.12.4
Re: WARNING in hso_free_net_device
Can you guys have a look at the attached patch?
On 9/4/19 6:41 PM, Stephen Hemminger wrote:
> On Wed, 4 Sep 2019 16:27:50 -0400
> Hui Peng wrote:
>
>> Hi, all:
>>
>> I looked at the bug a little.
>>
>> The issue is that in the error handling code, hso_free_net_device
>> unregisters
>>
>> the net_device (hso_net->net) by calling unregister_netdev. In the
>> error handling code path,
>>
>> hso_net->net has not been registered yet.
>>
>> I think there are two ways to solve the issue:
>>
>> 1. fix it in drivers/net/usb/hso.c to avoiding unregistering the
>> net_device when it is still not registered
>>
>> 2. fix it in unregister_netdev. We can add a field in net_device to
>> record whether it is registered, and make unregister_netdev return if
>> the net_device is not registered yet.
>>
>> What do you guys think ?
> #1
From f3fdee8fc03aa2bc982f22da1d29bbf6bca72935 Mon Sep 17 00:00:00 2001
From: Hui Peng
Date: Wed, 4 Sep 2019 21:38:35 -0400
Subject: [PATCH] Fix a wrong unregistering bug in hso_free_net_device
As shown below, hso_create_net_device may call hso_free_net_device
before the net_device is registered. hso_free_net_device will
unregister the network device no matter it is registered or not,
unregister_netdev is not able to handle unregistered net_device,
resulting in the bug reported by the syzbot.
```
static struct hso_device *hso_create_net_device(struct usb_interface *interface,
int port_spec)
{
..
net = alloc_netdev(sizeof(struct hso_net), "hso%d", NET_NAME_UNKNOWN,
hso_net_init);
..
if (!hso_net->out_endp) {
dev_err(>dev, "Can't find BULK OUT endpoint\n");
goto exit;
}
..
result = register_netdev(net);
..
exit:
hso_free_net_device(hso_dev);
return NULL;
}
static void hso_free_net_device(struct hso_device *hso_dev)
{
..
if (hso_net->net)
unregister_netdev(hso_net->net);
..
}
```
This patch adds a net_registered field in struct hso_net to record whether
the containing net_device is registered or not, and avoid unregistering it
if it is not registered yet.
Reported-by: syzbot+44d53c7255bb1aea2...@syzkaller.appspotmail.com
Signed-off-by: Hui Peng
---
drivers/net/usb/hso.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index ce78714..5b3df33 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -128,6 +128,7 @@ struct hso_shared_int {
struct hso_net {
struct hso_device *parent;
struct net_device *net;
+ bool net_registered;
struct rfkill *rfkill;
char name[24];
@@ -2362,7 +2363,7 @@ static void hso_free_net_device(struct hso_device *hso_dev)
remove_net_device(hso_net->parent);
- if (hso_net->net)
+ if (hso_net->net && hso_net->net_registered)
unregister_netdev(hso_net->net);
/* start freeing */
@@ -2544,6 +2545,7 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,
dev_err(>dev, "Failed to register device\n");
goto exit;
}
+ hso_net->net_registered = true;
hso_log_port(hso_dev);
--
2.7.4
pEpkey.asc
Description: application/pgp-keys
RE: [EXT] Re: [PATCH v1] usb: dwc3: remove the call trace of USBx_GFLADJ
Hi Balbi,
If no other doubts, please help apply it.
Thanks,
Regards,
Yinbo Zhu.
-Original Message-
From: Felipe Balbi
Sent: 2019年8月27日 19:55
To: Ran Wang ; Yinbo Zhu ; Greg
Kroah-Hartman ; linux-...@vger.kernel.org; open
list
Cc: Xiaobo Xie ; Jiafei Pan
Subject: RE: [EXT] Re: [PATCH v1] usb: dwc3: remove the call trace of
USBx_GFLADJ
Hi,
Ran Wang writes:
>> Yinbo Zhu writes:
>> >> Yinbo Zhu writes:
>> >> >> > diff --git a/drivers/usb/dwc3/core.c
>> >> >> > b/drivers/usb/dwc3/core.c index
>> >> >> > 98bce85c29d0..a133d8490322 100644
>> >> >> > --- a/drivers/usb/dwc3/core.c
>> >> >> > +++ b/drivers/usb/dwc3/core.c
>> >> >> > @@ -300,8 +300,7 @@ static void
>> >> >> > dwc3_frame_length_adjustment(struct
>> >> >> > dwc3 *dwc)
>> >> >> >
>> >> >> > reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
>> >> >> > dft = reg & DWC3_GFLADJ_30MHZ_MASK;
>> >> >> > - if (!dev_WARN_ONCE(dwc->dev, dft == dwc->fladj,
>> >> >> > - "request value same as default, ignoring\n")) {
>> >> >> > + if (dft != dwc->fladj) {
>> >> >>
>> >> >> if the value isn't different, why do you want to change it?
>> >> >>
>> >> >> --
>> >> >> Balbi
>> >> > Hi Balbi,
>> >> >
>> >> > I don't change any value. I was remove that call trace.
>> >>
>> >> Sure you do. The splat only shows when you request a FLADJ value
>> >> that's the same as the one already in the register. The reason you
>> >> see the splat is because your requested value is what's already in the HW.
>> >>
>> >> So, again, why are you adding this device tree property if the
>> >> value is already the correct one?
>> >>
>> >> > In addition that GFLADJ_30MHZ value intial value is 0, and it's
>> >> > value must be 0x20, if not, usb will not work.
>> >>
>> >> it's not zero, otherwise the splat wouldn't trigger. You're
>> >> requesting the value that's already in your register by default.
>> >>
>> >> --
>> >> Balbi
>> >
>> > Hi Balbi,
>> >
>> > According that rm doc that GFLADJ_30MHZ has a default value is
>> > 0x20, when GFLADJ_30MHZ_REG_SEL is 0, this 0x20 is a hard-coded value.
>> >
>> > But in fact, that default value is 0, please you note!
>> >
>> > Then according that xhci spec 5.2.4, that register the sixth bit if
>> > is 0, then that can support Frame Lenth Timing value.
>> >
>> > So set GFLADJ_30MHZ_REG_SEL to 1 for use FLADJ, then I find that it
>> > must use 0x20 usb will work well, even thoug xhci can permit
>> > GFLADJ_30MHZ use other value
>>
>> You only get the splat because you try to sent GFLADJ to 0x20 and
>> it's ALREADY 0x20. This means that you don't need the property in DTS.
>>
>> > In addition about what you said is about dts patch, and that patch
>> > had merged by upstream, patch owner isn't me,
>>
>> Well, then remove the setting from DTS, since clearly it's not needed.
>
> Please considering below scenarios on the same board which needs GFLADJ
> property on kernel DTS:
>
> 1. Board boot to U-Boot first, then load kernel. In this case, we need kernel
> DTS
> help to get GFLADJ setting right, everything is as expected.
>
> 2. Board boot to U-Boot console, then execute 'usb start' under U-Boot
> console to init
> DWC3 controller, then load kernel. In this case, actually GFLADJ is
> correctly
> configured already, and the GFLADJ config double-checking is fine
> (because kernel
> cannot know if U-Boot has initialized it or not), but warning looks not
> necessary.
>
> 3. Board boot to kernel, GFLADJ get set from DTS, then system suspend &
> resume. In this case
> when resuming, GFLADJ setting has been restored correctly, so here we
> might not need
> send out the warning message (double-checking might be fine).
>
> So, what's your suggestion to remove this looks non-necessary warning message?
now this is well explained! So the value in the register is *NOT* 0x20 by
default, however, u-boot _can_ use dwc3 if we're flashing, then it'll result in
the splat.
Okay, this is a valid scenario that the kernel should consider. I agree that we
should remove the WARN() from there.
Thanks
--
balbi
[PATCH] cpuset: adjust the lock sequence when rebuilding the sched domains.
From: Vincent Wang A deadlock issue is found when executing a cpu hotplug stress test on android phones with cpuset and scheduil enabled. When CPUx is plugged out, the hotplug thread that calls cpu_down() will hold cpu_hotplug_lock and wait the thread cpuhp/x to finish hotplug. If the core is the last one in a cluster, cpuhp/x have to call cpuhp_cpufreq_offline() and the kernel thread sugov need to exit for schedutil governor. The exit of sugov need to hold cgroup_threadgroup_rwsem in exit_signals(). For example: PID: 150TASK: ffc0b9cad080 CPU: 0 COMMAND: "sprdhotplug" #0 [ff8009fcb9d0] __switch_to at ff80080858f0 #1 [ff8009fcb9f0] __schedule at ff80089f185c #2 [ff8009fcba80] schedule at ff80089f1b84 #3 [ff8009fcbaa0] schedule_timeout at ff80089f5124 #4 [ff8009fcbb40] wait_for_common at ff80089f2944 #5 [ff8009fcbbe0] wait_for_completion at ff80089f29a4 #6 [ff8009fcbc00] __cpuhp_kick_ap at ff80080ab030 #7 [ff8009fcbc20] cpuhp_kick_ap_work at ff80080ab154 #8 [ff8009fcbc70] _cpu_down at ff80089ee19c #9 [ff8009fcbcd0] cpu_down at ff80080ac144 PID: 26 TASK: ffc0bbe22080 CPU: 3 COMMAND: "cpuhp/3" #0 [ff8009693a30] __switch_to at ff80080858f0 #1 [ff8009693a50] __schedule at ff80089f185c #2 [ff8009693ae0] schedule at ff80089f1b84 #3 [ff8009693b00] schedule_timeout at ff80089f5124 #4 [ff8009693ba0] wait_for_common at ff80089f2944 #5 [ff8009693c40] wait_for_completion at ff80089f29a4 #6 [ff8009693c60] kthread_stop at ff80080ccd2c #7 [ff8009693c90] sugov_exit at ff8008102134 #8 [ff8009693cc0] cpufreq_exit_governor at ff80086c03bc #9 [ff8009693ce0] cpufreq_offline at ff80086c0634 PID: 13819 TASK: ffc0affb6080 CPU: 0 COMMAND: "sugov:3" #0 [ff800ee73c30] __switch_to at ff80080858f0 #1 [ff800ee73c50] __schedule at ff80089f185c #2 [ff800ee73ce0] schedule at ff80089f1b84 #3 [ff800ee73d00] rwsem_down_read_failed at ff80089f49d0 #4 [ff800ee73d80] __percpu_down_read at ff8008102ebc #5 [ff800ee73da0] exit_signals at ff80080bbd24 #6 [ff800ee73de0] do_exit at ff80080ae65c #7 [ff800ee73e60] kthread at ff80080cc550 Sometimes cgroup_threadgroup_rwsem is hold by another thread, for example Binder:681_2 on android, it wants to hold cpuset_mutex: PID: 732TASK: ffc09668b080 CPU: 2 COMMAND: "Binder:681_2" #0 [ff800cb7b8c0] __switch_to at ff80080858f0 #1 [ff800cb7b8e0] __schedule at ff80089f185c #2 [ff800cb7b970] schedule at ff80089f1b84 #3 [ff800cb7b990] schedule_preempt_disabled at ff80089f205c #4 [ff800cb7b9a0] __mutex_lock at ff80089f3118 #5 [ff800cb7ba40] __mutex_lock_slowpath at ff80089f3230 #6 [ff800cb7ba60] mutex_lock at ff80089f3278 #7 [ff800cb7ba80] cpuset_can_attach at ff8008152f84 #8 [ff800cb7bae0] cgroup_migrate_execute at ff800814ada8 On android, a thread kworker/3:0 will hold cpuset_mutex in rebuild_sched_domains() and want to hold cpu_hotplug_lock which is already hold by the hotplug thread. PID: 4847 TASK: ffc031a6a080 CPU: 3 COMMAND: "kworker/3:0" #0 [ff8016fd3ad0] __switch_to at ff80080858f0 #1 [ff8016fd3af0] __schedule at ff80089f185c #2 [ff8016fd3b80] schedule at ff80089f1b84 #3 [ff8016fd3ba0] rwsem_down_read_failed at ff80089f49d0 #4 [ff8016fd3c20] __percpu_down_read at ff8008102ebc #5 [ff8016fd3c40] cpus_read_lock at ff80080aa59c #6 [ff8016fd3c50] rebuild_sched_domains_locked at ff80081522a8 In order to fix the deadlock, this patch will adjust the lock sequence when rebuilding sched domains. After stress tests, it works well. Signed-off-by: Vincent Wang Signed-off-by: Chunyan Zhang --- kernel/cgroup/cpuset.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 5aa37531ce76..ef10d276da22 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -912,7 +912,6 @@ static void rebuild_sched_domains_locked(void) int ndoms; lockdep_assert_held(_mutex); - get_online_cpus(); /* * We have raced with CPU hotplug. Don't do anything to avoid @@ -921,19 +920,17 @@ static void rebuild_sched_domains_locked(void) */ if (!top_cpuset.nr_subparts_cpus && !cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask)) - goto out; + return; if (top_cpuset.nr_subparts_cpus && !cpumask_subset(top_cpuset.effective_cpus, cpu_active_mask)) - goto out; + return; /* Generate domain masks and attrs */ ndoms = generate_sched_domains(, ); /* Have scheduler rebuild the domains */ partition_sched_domains(ndoms, doms, attr); -out: -
[PATCH] net/mlx5: Fix addr's type in mlx5dr_icm_dm
clang errors when CONFIG_PHYS_ADDR_T_64BIT is not set:
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c:121:8:
error: incompatible pointer types passing 'u64 *' (aka 'unsigned long
long *') to parameter of type 'phys_addr_t *' (aka 'unsigned int *')
[-Werror,-Wincompatible-pointer-types]
_mr->dm.addr, _mr->dm.obj_id);
^~~~
include/linux/mlx5/driver.h:1092:39: note: passing argument to parameter
'addr' here
u64 length, u16 uid, phys_addr_t *addr, u32 *obj_id);
^
1 error generated.
Use phys_addr_t for addr's type in mlx5dr_icm_dm, which won't change
anything with 64-bit builds because phys_addr_t is u64 when
CONFIG_PHYS_ADDR_T_64BIT is set, which is always when CONFIG_64BIT is
set.
Fixes: 29cf8febd185 ("net/mlx5: DR, ICM pool memory allocator")
Link: https://github.com/ClangBuiltLinux/linux/issues/653
Signed-off-by: Nathan Chancellor
---
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c
b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c
index e76f61e7555e..913f1e5aaaf2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c
@@ -53,7 +53,7 @@ struct mlx5dr_icm_pool {
struct mlx5dr_icm_dm {
u32 obj_id;
enum mlx5_sw_icm_type type;
- u64 addr;
+ phys_addr_t addr;
size_t length;
};
--
2.23.0
Re: [PATCH] mm: Unsigned 'nr_pages' always larger than zero
On 2019/9/4 19:24, Vlastimil Babka wrote:
> On 9/4/19 12:26 PM, zhong jiang wrote:
>> With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages"'
>> compare with zero. And __get_user_pages_locked will return an long value.
>> Hence, Convert the long to compare with zero is feasible.
> It would be nicer if the parameter nr_pages was long again instead of unsigned
> long (note there are two variants of the function, so both should be changed).
Yep, the parameter 'nr_pages' was changed to long. and the variants ‘i、step’
should
be changed accordingly.
>> Signed-off-by: zhong jiang
> Fixes: 932f4a630a69 ("mm/gup: replace get_user_pages_longterm() with
> FOLL_LONGTERM")
>
> (which changed long to unsigned long)
>
> AFAICS... stable shouldn't be needed as the only "risk" is that we goto
> check_again even when we fail, which should be harmless.
Agreed, Thanks.
Sincerely,
zhong jiang
> Vlastimil
>
>> ---
>> mm/gup.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index 23a9f9c..956d5a1 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -1508,7 +1508,7 @@ static long check_and_migrate_cma_pages(struct
>> task_struct *tsk,
>> pages, vmas, NULL,
>> gup_flags);
>>
>> -if ((nr_pages > 0) && migrate_allow) {
>> +if (((long)nr_pages > 0) && migrate_allow) {
>> drain_allow = true;
>> goto check_again;
>> }
>>
>
> .
>
Re: [PATCH] gpio: Move gpiochip_.*lock_as_irq() to the proper ifdef
On 2019/9/4 23:46, Sebastian Andrzej Siewior wrote:
> In a recent commit the gpiochip_.*lock_as_irq() were moved and ended up
> in the wrong `ifdef' section. Now for !CONFIG_GPIOLIB the function is
> defined twice leading to an compile error.
>
> Move the extern function declaration under CONFIG_GPIOLIB, the "static
> inline" version is already under !CONFIG_GPIOLIB.
>
> Fixes: c7663fa2a6631 ("gpio: Move gpiochip_lock/unlock_as_irq to
> gpio/driver.h")
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> include/linux/gpio/driver.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index b74a3bee85e5d..fb134ff20f6b2 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -702,14 +702,14 @@ void gpiochip_free_own_desc(struct gpio_desc *desc);
> void devprop_gpiochip_set_names(struct gpio_chip *chip,
> const struct fwnode_handle *fwnode);
>
> -/* lock/unlock as IRQ */
> -int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
> -void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
> -
> #ifdef CONFIG_GPIOLIB
>
> struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc);
>
> +/* lock/unlock as IRQ */
> +int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
> +void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
> +
> #else /* CONFIG_GPIOLIB */
Interesting, my patch indeed do the correct thing：
+/* lock/unlock as IRQ */
+int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
+void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
+
#else /* CONFIG_GPIOLIB */
however, now in include/linux/gpio/driver.h, it is:
/* lock/unlock as IRQ */
int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
#ifdef CONFIG_GPIOLIB
struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc);
#else /* CONFIG_GPIOLIB */
Maybe this caused by the fuzzing? Anyway, this fix the issue, so
Reviewed-by: YueHaibing
>
> static inline struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc)
>
Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees
Hi Davidlohr,
On Wed, Sep 4, 2019 at 5:52 PM Davidlohr Bueso wrote:
> Ok, so for that I've added the following helper which will make the
> conversion a bit more straightforward:
>
> #define vma_interval_tree_foreach_stab(vma, root, start)
>vma_interval_tree_foreach(vma, root, start, start)
Yes, that should help with the conversion :)
> I think this also makes sense as it documents the nature of the lookup.
>
> Now for the interval-tree conversion to [a,b[ , how does the following
> look to you? Note that this should be the end result; we can discuss
> how to get there later, but I wanna make sure that it was more or less
> what you were picturing.
I do not have time for a full review right now, but I did have a quick
pass at it and it does seem to match the direction I'd like this to
take.
Please let me know if you'd like me to do a full review of this, or if
it'll be easier to do it on the individual steps once this gets broken
up.
BTW are you going to plumbers ? I am and I would love to talk to you
there, about this and about MM range locking, too.
Things I noticed in my quick pass:
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index e0ad547786e8..dc9fad8ea84a 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -450,13 +450,14 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
> {
> uint64_t size = radeon_bo_size(bo_va->bo);
> struct radeon_vm *vm = bo_va->vm;
> - unsigned last_pfn, pt_idx;
> + unsigned pt_idx;
> uint64_t eoffset;
> int r;
>
> if (soffset) {
> + unsigned last_pfn;
> /* make sure object fit at this offset */
> - eoffset = soffset + size - 1;
> + eoffset = soffset + size;
> if (soffset >= eoffset) {
Should probably be if (soffset > eoffset) now (just checking for
arithmetic overflow).
> r = -EINVAL;
> goto error_unreserve;
> @@ -471,7 +472,7 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
> }
>
> } else {
> - eoffset = last_pfn = 0;
> + eoffset = 1; /* interval trees are [a,b[ */
Looks highly suspicious to me, and doesn't jive with the eoffset /=
RADEON_GPU_PAGE_SIZE below.
I did not look deep enough into this to figure out what would be correct though.
> }
>
> mutex_lock(>mutex);
> diff --git a/drivers/infiniband/hw/hfi1/mmu_rb.c
> b/drivers/infiniband/hw/hfi1/mmu_rb.c
> index 14d2a90964c3..d708c45bfabf 100644
> --- a/drivers/infiniband/hw/hfi1/mmu_rb.c
> +++ b/drivers/infiniband/hw/hfi1/mmu_rb.c
> @@ -195,13 +195,13 @@ static struct mmu_rb_node *__mmu_rb_search(struct
> mmu_rb_handler *handler,
> trace_hfi1_mmu_rb_search(addr, len);
> if (!handler->ops->filter) {
> node = __mmu_int_rb_iter_first(>root, addr,
> - (addr + len) - 1);
> + (addr + len));
> } else {
> for (node = __mmu_int_rb_iter_first(>root, addr,
> - (addr + len) - 1);
> + (addr + len));
> node;
> node = __mmu_int_rb_iter_next(node, addr,
> - (addr + len) - 1)) {
> + (addr + len))) {
> if (handler->ops->filter(node, addr, len))
> return node;
> }
Weird unnecessary parentheses through this block.
> @@ -787,7 +787,7 @@ static phys_addr_t viommu_iova_to_phys(struct
> iommu_domain *domain,
> struct viommu_domain *vdomain = to_viommu_domain(domain);
>
> spin_lock_irqsave(>mappings_lock, flags);
> - node = interval_tree_iter_first(>mappings, iova, iova);
> + node = interval_tree_iter_first(>mappings, iova, iova + 1);
I was gonna suggest a stab iterator for the generic interval tree, but
maybe not if it's only used here.
> diff --git a/include/linux/interval_tree_generic.h
> b/include/linux/interval_tree_generic.h
> index aaa8a0767aa3..e714e67ebdb5 100644
> --- a/include/linux/interval_tree_generic.h
> +++ b/include/linux/interval_tree_generic.h
> @@ -69,12 +69,12 @@ ITSTATIC void ITPREFIX ## _remove(ITSTRUCT *node,
> \
> }
> \
>
> \
> /*
> \
> - * Iterate over intervals intersecting [start;last]
> \
> + * Iterate over intervals intersecting [start;last[
> \
Maybe I'm extra
Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
On Wed, 2019-09-04 at 10:37 -0400, Qian Cai wrote: > On Wed, 2019-09-04 at 22:16 +0800, Walter Wu wrote: > > On Wed, 2019-09-04 at 15:44 +0200, Andrey Konovalov wrote: > > > On Wed, Sep 4, 2019 at 8:51 AM Walter Wu > > > wrote: > > > > +config KASAN_DUMP_PAGE > > > > + bool "Dump the page last stack information" > > > > + depends on KASAN && PAGE_OWNER > > > > + help > > > > + By default, KASAN doesn't record alloc/free stack for page > > > > allocator. > > > > + It is difficult to fix up page use-after-free issue. > > > > + This feature depends on page owner to record the last stack of > > > > page. > > > > + It is very helpful for solving the page use-after-free or out- > > > > of-bound. > > > > > > I'm not sure if we need a separate config for this. Is there any > > > reason to not have this enabled by default? > > > > PAGE_OWNER need some memory usage, it is not allowed to enable by > > default in low RAM device. so I create new feature option and the person > > who wants to use it to enable it. > > Or you can try to look into reducing the memory footprint of PAGE_OWNER to fit > your needs. It does not always need to be that way. Thanks your suggestion. We can try to think what can be slimmed. Thanks. Walter
[PATCH v2] drm/vkms: Use alpha value to blend values.
Use alpha value to blend source value and destination value Instead of
just overwrite with source value.
Signed-off-by: Sidong Yang
---
v1 -> v2:
* Move variables to tighter scope.
drivers/gpu/drm/vkms/vkms_composer.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index d5585695c64d..181472efa08c 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -77,6 +77,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
+ u8 *src, *dst;
+ u32 alpha, inv_alpha;
+
offset_dst = dest_composer->offset
+ (i_dst * dest_composer->pitch)
+ (j_dst++ * dest_composer->cpp);
@@ -84,8 +87,14 @@ static void blend(void *vaddr_dst, void *vaddr_src,
+ (i * src_composer->pitch)
+ (j * src_composer->cpp);
- memcpy(vaddr_dst + offset_dst,
- vaddr_src + offset_src, sizeof(u32));
+ src = vaddr_src + offset_src;
+ dst = vaddr_dst + offset_dst;
+ alpha = src[3] + 1;
+ inv_alpha = 256 - src[3];
+ dst[0] = (alpha * src[0] + inv_alpha * dst[0]) >> 8;
+ dst[1] = (alpha * src[1] + inv_alpha * dst[1]) >> 8;
+ dst[2] = (alpha * src[2] + inv_alpha * dst[2]) >> 8;
+ dst[3] = 0xff;
}
i_dst++;
}
--
2.20.1
Re: [PATCH v1 1/3] perf cs-etm: Refactor instruction size handling
Hi Mathieu,
On Wed, Sep 04, 2019 at 11:06:10AM -0600, Mathieu Poirier wrote:
> On Wed, 4 Sep 2019 at 03:19, Leo Yan wrote:
> >
> > Hi Mathieu,
> >
> > On Tue, Sep 03, 2019 at 04:22:15PM -0600, Mathieu Poirier wrote:
> > > On Fri, Aug 30, 2019 at 02:24:19PM +0800, Leo Yan wrote:
> > > > There has several code pieces need to know the instruction size, but
> > > > now every place calculates the instruction size separately.
> > > >
> > > > This patch refactors to create a new function cs_etm__instr_size() as
> > > > a central place to analyze the instruction length based on ISA type
> > > > and instruction value.
> > > >
> > > > Signed-off-by: Leo Yan
> > > > ---
> > > > tools/perf/util/cs-etm.c | 44 +++-
> > > > 1 file changed, 30 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > > > index b3a5daaf1a8f..882a0718033d 100644
> > > > --- a/tools/perf/util/cs-etm.c
> > > > +++ b/tools/perf/util/cs-etm.c
> > > > @@ -914,6 +914,26 @@ static inline int cs_etm__t32_instr_size(struct
> > > > cs_etm_queue *etmq,
> > > > return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
> > > > }
> > > >
> > > > +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> > > > +u8 trace_chan_id,
> > > > +enum cs_etm_isa isa,
> > > > +u64 addr)
> > > > +{
> > > > + int insn_len;
> > > > +
> > > > + /*
> > > > +* T32 instruction size might be 32-bit or 16-bit, decide by calling
> > > > +* cs_etm__t32_instr_size().
> > > > +*/
> > > > + if (isa == CS_ETM_ISA_T32)
> > > > + insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
> > > > addr);
> > > > + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > > > + else
> > > > + insn_len = 4;
> > > > +
> > > > + return insn_len;
> > > > +}
> > > > +
> > > > static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet
> > > > *packet)
> > > > {
> > > > /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> > > > @@ -938,19 +958,23 @@ static inline u64 cs_etm__instr_addr(struct
> > > > cs_etm_queue *etmq,
> > > > const struct cs_etm_packet *packet,
> > > > u64 offset)
> > > > {
> > > > + int insn_len;
> > > > +
> > > > if (packet->isa == CS_ETM_ISA_T32) {
> > > > u64 addr = packet->start_addr;
> > > >
> > > > while (offset > 0) {
> > > > - addr += cs_etm__t32_instr_size(etmq,
> > > > - trace_chan_id, addr);
> > > > + addr += cs_etm__instr_size(etmq, trace_chan_id,
> > > > + packet->isa, addr);
> > > > offset--;
> > > > }
> > > > return addr;
> > > > }
> > > >
> > > > - /* Assume a 4 byte instruction size (A32/A64) */
> > > > - return packet->start_addr + offset * 4;
> > > > + /* Return instruction size for A32/A64 */
> > > > + insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> > > > + packet->isa, packet->start_addr);
> > > > + return packet->start_addr + offset * insn_len;
> > >
> > > This patch will work but from where I stand it makes things difficult to
> > > understand more than anything else. It is also adding coupling between
> > > function
> > > cs_etm__instr_addr() and cs_etm__instr_size(), meaning the code needs to
> > > be
> > > carefully inspected in order to make changes to either one.
> >
> > My purpose is to use a same place to calculate the instruction
> > size, rather than to spread the duplicate codes in several different
> > functions.
> >
> > > Last but not least function cs_etm__instr_size() isn't used in the
> > > upcoming
> > > patches. I really don't see what is gained here.
> >
> > Sorry that I forgot to commit my final change into patch 02.
> >
> > I planed to use cs_etm__instr_size() in patch 02; patch 02 has
> > function cs_etm__add_stack_event(), which also needs to get the
> > instruction size when it sends stack event.
> >
> > After apply patch 02, tools/perf/util/cs-etm.c will have below three
> > functions to caculate instruction size; this is the main reason I want
> > to refactor the code for instruction size.
> >
> > cs_etm__instr_addr()
> > cs_etm__copy_insn()
> > cs_etm__add_stack_event()
> >
> > If this lets code more difficult to understand, will drop it.
> >
>
> I agree with the consolidation but for that to work function
> cs_etm__instr_addr() needs to be refactored. Since
> cs_etm__instr_size() is already taking care of checking the ISA type
> the while() loop in cs_etm__instr_addr() can be done regardless of the
> operation mode. That way cs_etm__instr_size() can be changed at will
> without breaking anything.
>
> The downside is that we
