Re: [RFC PATCH] mmc: core: Optimize case for exactly one erase-group budget TRIM
Dear Ulf, On Thu, 4 Jun 2015 10:31:59 +0200 Ulf Hansson wrote: > On 3 June 2015 at 10:34, David Jander wrote: > > In the (not so unlikely) case that the mmc controller timeout budget is > > enough for exactly one erase-group, the simplification of allowing one > > sector has an enormous performance penalty. We optimize this special case > > by introducing a flag that prohibits erase-group boundary crossing, so > > that we can allow trimming more than one sector at a time. > > > > Signed-off-by: David Jander > > Hi David, > > Thanks for working on this! I have since sent an updated patch that includes more comment. It would be great if you could find the time to review it. I hope the comments are clear enough. Best regards, -- David Jander Protonic Holland. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] gpu/drm: remove unnecessary check before kfree
Hi, >The shortlog prefix of both your patches should be "drm/amdgpu:" instead >of "gpu/drm:". With that fixed, both are Do i need to send V2 of patch with that change or you have fixed that? >Reviewed-by: Michel Dänzer Thanks. ..
Re: [PATCH 1/1] gpu/drm: remove unnecessary check before kfree
On 26.06.2015 15:25, Maninder Singh wrote: > kfree(NULL) is safe and this check is probably not required > > Signed-off-by: Maninder Singh > Reviewed-by: Vaneet Narang > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > index fec487d..a85cd08 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > @@ -1575,8 +1575,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev) > amdgpu_fence_driver_fini(adev); > amdgpu_fbdev_fini(adev); > r = amdgpu_fini(adev); > - if (adev->ip_block_enabled) > - kfree(adev->ip_block_enabled); > + kfree(adev->ip_block_enabled); > adev->ip_block_enabled = NULL; > adev->accel_working = false; > /* free i2c buses */ > The shortlog prefix of both your patches should be "drm/amdgpu:" instead of "gpu/drm:". With that fixed, both are Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 08/17] perf tools: Add Intel PT support
On 26/06/15 03:09, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 25, 2015 at 08:56:34PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Will do the same tests with intel_pt as well, on a remote machine, add
>> examples
>> to the changeset logs and everything going well, aim for pushing for Ingo
>> soon,
>
> So, I asked for callchains, with:
>
> perf record -g -e intel_bts// ls
>
> And it got stuck somewhere, then I did a perf top to see where it was,
> and got to:
>
> 96.24% perf[.] intel_bts_process_queue
>
> Annotating I get to:
>
> 1.17 │1a0:┌─→mov0x8(%r13),%rdx
>││ test %rdx,%rdx
> 98.83 │└──je 1a0
>
>
> Which is an endless loop! Source code for intel_bts_process_buffer(),
> inlined there:
>
> while (sz > sizeof(struct branch)) {
> if (!branch->from && !branch->to)
> continue;
> err = intel_bts_synth_branch_sample(btsq, branch);
> if (err)
> break;
> branch += 1;
> sz -= sizeof(struct branch);
> }
>
> Can you fix this, please, so that I can fold it into where it was
> introduced, namely:
>
> commit 439ad895a2aecea09416206f023336297cc72efe
> Author: Adrian Hunter
> Date: Fri May 29 16:33:39 2015 +0300
>
> perf tools: Add Intel BTS support
It is fixed as an unexpected side-effect of a following patch (which is
probably why I didn't notice it - or perhaps I rolled the fix into the wrong
patch O_o). The fix is in:
perf tools: Output sample flags and insn_len from intel_bts
intel_bts synthesizes samples. Fill in the new flags and insn_len
members with instruction information.
Signed-off-by: Adrian Hunter
So what you want is:
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index 48bcbd607ef7..68bb6fede55b 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -304,7 +304,7 @@ static int intel_bts_process_buffer(struct intel_bts_queue
*btsq,
struct auxtrace_buffer *buffer)
{
struct branch *branch;
- size_t sz;
+ size_t sz, bsz = sizeof(struct branch);
int err = 0;
if (buffer->use_data) {
@@ -318,14 +318,12 @@ static int intel_bts_process_buffer(struct
intel_bts_queue *btsq,
if (!btsq->bts->sample_branches)
return 0;
- while (sz > sizeof(struct branch)) {
+ for (; sz > bsz; branch += 1, sz -= bsz) {
if (!branch->from && !branch->to)
continue;
err = intel_bts_synth_branch_sample(btsq, branch);
if (err)
break;
- branch += 1;
- sz -= sizeof(struct branch);
}
return err;
}
But obviously that will conflict with "perf tools: Output sample flags and
insn_len from intel_bts"
Another thing, the intel_bts implementation does not support
"instructions" samples because there is no timing information to
use to create periodic samples. But callchains are added only
to "instructions" samples so there are no callchains in 'perf report'
for intel_bts. The call information is still available for
db-export and the example call-graph, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path
Hi Anton/Michael, Nikunj A Dadhania writes: > Hi Anton, > > Anton Blanchard writes: >> Hi Nikunj, >> >>> From: Nikunj A Dadhania >>> >>> powerpc/numa: initialize distance lookup table from drconf path >>> >>> In some situations, a NUMA guest that supports >>> ibm,dynamic-memory-reconfiguration node will end up having flat NUMA >>> distances between nodes. This is because of two problems in the >>> current code. >> >> Thanks for the patch. Have we tested that this doesn't regress the >> non dynamic representation? > > Yes, that is tested. And works as expected. If the patch looks fine, can this be pushed upstream ? Regards, Nikunj -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lib/bitmap.c: add some check to correct the parse result
Sometimes the input from user may cause an unexpected result.
for example, echo "1-3," > /proc/irq//smp_affinity_list.
The correct result should be 1-3, however we got 0-4.
To avoid this issue, we check if there is a ready digit.
If no valid digit is set, we just continue to the next parse.
Signed-off-by: Pan Xinhui
---
lib/bitmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 64c0926..3c489c1 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -561,6 +561,8 @@ static int __bitmap_parselist(const char *buf, unsigned int
buflen,
return -EINVAL;
if (b >= nmaskbits)
return -ERANGE;
+ if (unlikely(exp_digit))
+ continue;
while (a <= b) {
set_bit(a, maskp);
a++;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v4 1/3] mfd: 88pm800: Add device tree support
2015-06-26 14:59 GMT+09:00 Vaibhav Hiremath :
>
>
> On Friday 26 June 2015 11:23 AM, Yi Zhang wrote:
>>
>> On Thu, Jun 25, 2015 at 08:57:49PM +0530, Vaibhav Hiremath wrote:
>>>
>>>
>>>
>>> On Thursday 25 June 2015 08:18 PM, Lee Jones wrote:
On Thu, 25 Jun 2015, Vaibhav Hiremath wrote:
>
> On Thursday 25 June 2015 03:49 PM, Lee Jones wrote:
>>
>> On Thu, 25 Jun 2015, Vaibhav Hiremath wrote:
>>
>>> Add DT support to the 88pm800 driver, along with compatible
>>> field for it's sub-devices (rtc, onkey and regulator)
>>>
>>> Signed-off-by: Chao Xie
>>> Signed-off-by: Vaibhav Hiremath
>>> ---
>>> drivers/mfd/88pm800.c | 23 +++
>>> 1 file changed, 23 insertions(+)
>>>
>>> diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
>>> index 841717a..40fd014 100644
>>> --- a/drivers/mfd/88pm800.c
>>> +++ b/drivers/mfd/88pm800.c
>>> @@ -27,6 +27,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> /* Interrupt Registers */
>>> #define PM800_INT_STATUS1 (0x05)
>>> @@ -121,6 +122,11 @@ static const struct i2c_device_id
>>> pm80x_id_table[] = {
>>> };
>>> MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
>>>
>>> +static const struct of_device_id pm80x_of_match_table[] = {
>>> + { .compatible = "marvell,88pm800", },
>>> + {},
>>> +};
>>> +
>>> static struct resource rtc_resources[] = {
>>> {
>>> .name = "88pm80x-rtc",
>>> @@ -133,6 +139,7 @@ static struct resource rtc_resources[] = {
>>> static struct mfd_cell rtc_devs[] = {
>>> {
>>> .name = "88pm80x-rtc",
>>> +.of_compatible = "marvell,88pm80x-rtc",
>>> .num_resources = ARRAY_SIZE(rtc_resources),
>>> .resources = &rtc_resources[0],
>>> .id = -1,
>>> @@ -151,6 +158,7 @@ static struct resource onkey_resources[] = {
>>> static const struct mfd_cell onkey_devs[] = {
>>> {
>>> .name = "88pm80x-onkey",
>>> +.of_compatible = "marvell,88pm80x-onkey",
>>> .num_resources = 1,
>>> .resources = &onkey_resources[0],
>>> .id = -1,
>>> @@ -160,6 +168,7 @@ static const struct mfd_cell onkey_devs[] = {
>>> static const struct mfd_cell regulator_devs[] = {
>>> {
>>> .name = "88pm80x-regulator",
>>> +.of_compatible = "marvell,88pm80x-regulator",
>>> .id = -1,
>>> },
>>> };
>>> @@ -544,8 +553,21 @@ static int pm800_probe(struct i2c_client
>>> *client,
>>> int ret = 0;
>>> struct pm80x_chip *chip;
>>> struct pm80x_platform_data *pdata =
>>> dev_get_platdata(&client->dev);
>>> + struct device_node *np = client->dev.of_node;
>>> struct pm80x_subchip *subchip;
>>>
>>> + if (!pdata && !np) {
>>> + dev_err(&client->dev,
>>> + "pm80x requires platform data or of_node\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (!pdata) {
>>> + pdata = devm_kzalloc(&client->dev, sizeof(*pdata),
>>> GFP_KERNEL);
>>> + if (!pdata)
>>> + return -ENOMEM;
>>> + }
>>
>>
>> Why have you allocated data for pdata, then done nothing with it?
>>
>
> Not in this patch, but subsequent patches would use it.
Only provide it when you start using it please.
>>>
>>> I will take back my earlier comment of "not using in this patch, but
>>> subsequent patches".
>>>
>>> pdata is being used, couple of places in the driver,
>>>
>>>
>>> @line-751
>>>
>>> ret = device_800_init(chip, pdata);
>>> if (ret) {
>>> dev_err(chip->dev, "Failed to initialize 88pm800
>>> devices\n");
>>> goto err_device_init;
>>> }
>>>
>>> if (pdata && pdata->plat_config)
>>> pdata->plat_config(chip, pdata);
>>
>>
>>this plat_config() is used in legacy non-device-tree code, it's used
>>to implement fixup for chip or board level, it exists in
>>the board configuration file
>>
>>just curious, do you think we still need to keep it?
>>considering device-tree has been used. thanks;
>>
>
> I do not see it anywhere in mainline kernel tree, is it part of some
> internal tree?
>
> If we know that it is being used, then lets not remove it now.
There aren't many board files in mainline but still downstream may use
it. Do you know who could be the downstream for this device?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Re: [PATCH v2 2/3] IRQ/Gic-V3: Change arm-gic-its to support the Mbigen interrupt
Hi Thomas:
在 2015/6/12 10:49, Ma Jun 写道:
> +static int its_mbigen_prepare(struct irq_domain *domain, struct mbi_desc
> *desc,
> + int hwirq,
> struct mbi_alloc_info *arg)
> +{
> + struct its_node *its = domain->parent->host_data;
> + struct its_device *its_dev;
> + u32 dev_id;
> +
> + dev_id = desc->msg_id;
> +
> + its_dev = its_find_device(its, dev_id);
> + if (!its_dev) {
> + its_dev = its_create_device(its, dev_id, desc->lines);
> + if (!its_dev)
> + return -ENOMEM;
> + }
> +
> + arg->scratchpad[0].ptr = its_dev;
> + arg->scratchpad[1].ptr = NULL;
> +
> + arg->desc = desc;
> + arg->hwirq = hwirq;
> + return 0;
> +}
> +
> +static struct mbigen_domain_ops its_mbigen_ops = {
> + .mbigen_prepare = its_mbigen_prepare,
> +};
> +
> +static struct mbigen_domain_info its_mbigen_domain_info = {
> + .ops= &its_mbigen_ops,
> +};
> +
what's you opinion about the function 'its_mbigen_prepare' ?
put this function in irq-gic-v3-its.c or move to mbigen driver ?
If I move this function to mbigen driver, some its fuctions
(ex. its_find_device, its_create_device) and struct data (ex its_node)
would be used in mbigen driver.
Now, all these functions and data structure are defined as static.
to use them, I have to remove the 'static' definition and put them
in a head file （ create a new head file).
I'm not sure which way is better .
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] gpu/drm: remove unnecessary check before kfree
kfree(NULL) is safe and this check is probably not required Signed-off-by: Maninder Singh Reviewed-by: Vaneet Narang --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index fec487d..a85cd08 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -1575,8 +1575,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev) amdgpu_fence_driver_fini(adev); amdgpu_fbdev_fini(adev); r = amdgpu_fini(adev); - if (adev->ip_block_enabled) - kfree(adev->ip_block_enabled); + kfree(adev->ip_block_enabled); adev->ip_block_enabled = NULL; adev->accel_working = false; /* free i2c buses */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] gpu/drm: use kzalloc for allocating one thing
Use kzalloc rather than kcalloc(1.. for allocating
one thing.
Signed-off-by: Maninder Singh
Reviewed-by: Vaneet Narang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d3706a4..dd3415d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -674,7 +674,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
return 0;
if (gtt && gtt->userptr) {
- ttm->sg = kcalloc(1, sizeof(struct sg_table), GFP_KERNEL);
+ ttm->sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!ttm->sg)
return -ENOMEM;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] perf tools: Check access permission when reading symbol files
ping ?
On 2015年06月19日 16:57, Li Zhang wrote:
There 2 problems when reading symbols files:
* It doesn't report any errors even if when users specify symbol
files which don't exist with --kallsyms or --vmlinux. The result
just shows the address without symbols, which is not what is expected.
So it's better to report errors and exit the program.
* When using command perf report --kallsyms=/proc/kallsyms with a
non-root user, symbols are resolved. Then select one symbol and
annotate it, it reports the error as the following:
Can't annotate __clear_user: No vmlinux file with build id xxx was
found.
The problem is caused by reading /proc/kcore without access permission.
/proc/kcore requires CAP_SYS_RAWIO capability to access, so it needs to
change access permission to allow a specific user to read /proc/kcore or
use root to execute the perf command.
This patch is to report errors when symbol files specified by users
don't exist. And check access permission of /proc/kcore when reading it.
Signed-off-by: Li Zhang
---
v3 -> v2:
* Add checking symbol files when user specify these files.
* Report an error to users when open fails. Suggested by Sukar
v2 -> v1:
* Report one useful message to users about the access permision,
then go back to the tools. Suggested by Arnaldo Carvalho de Melo.
tools/perf/builtin-report.c | 11 +++
tools/perf/util/symbol.c| 5 -
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 476cdf7..1c353b1 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -731,6 +731,17 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
argc = parse_options(argc, argv, options, report_usage, 0);
+ if (symbol_conf.vmlinux_name &&
+ access(symbol_conf.vmlinux_name, R_OK)) {
+ pr_err("Invalid file: %s\n", symbol_conf.vmlinux_name);
+ return -EINVAL;
+ }
+ if (symbol_conf.kallsyms_name &&
+ access(symbol_conf.kallsyms_name, R_OK)) {
+ pr_err("Invalid file: %s\n", symbol_conf.kallsyms_name);
+ return -EINVAL;
+ }
+
if (report.use_stdio)
use_browser = 0;
else if (report.use_tui)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 201f6c4c..46aa93d 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1126,8 +1126,11 @@ static int dso__load_kcore(struct dso *dso, struct map
*map,
INIT_LIST_HEAD(&md.maps);
fd = open(kcore_filename, O_RDONLY);
- if (fd < 0)
+ if (fd < 0) {
+ pr_err("%s requires CAP_SYS_RAWIO capability to access.\n",
+ kcore_filename);
return -EINVAL;
+ }
/* Read new maps into temporary lists */
err = file__read_maps(fd, md.type == MAP__FUNCTION, kcore_mapfn, &md,
--
Li Zhang
IBM China Linux Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] arm: dts: am43xx-clock: Add qspi clock node.
On Wednesday 24 June 2015 11:15 PM, Mugunthan V N wrote:
From: Sourav Poddar
Add clock node for qspi controller driver on am437x.
Cc: Keerthy
Cc: Tero Kristo
Signed-off-by: Sourav Poddar
Signed-off-by: Mugunthan V N
---
arch/arm/boot/dts/am4372.dtsi| 2 ++
arch/arm/boot/dts/am43xx-clocks.dtsi | 8
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 649e7b9..8ab7831 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -903,6 +903,8 @@
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
+ clocks = <&qspi_fclk>;
+ clock-names = "fck";
interrupts = <0 138 0x4>;
num-cs = <4>;
status = "disabled";
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index cc88728..1506585 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -763,4 +763,12 @@
ti,bit-shift = <8>;
reg = <0x8a68>;
};
+
+ qspi_fclk: qspi_fclk {
+ #clock-cells = <0>;
+ compatible = "ti,fixed-factor-clock";
+ clocks = <&dpll_per_m2_div4_ck>;
From the clock tree this does not seem to be sourced from dpll_per_m2.
I guess this needs to be changed.
-Keerthy
+ clock-mult = <1>;
+ clock-div = <1>;
+ };
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] selftests/exec: Fix build on older distros.
On Fri, Jun 26, 2015 at 12:29 AM, Vinson Lee wrote:
> From: Vinson Lee
>
> This patch fixes this build error on CentOS 5.
>
> execveat.c: In function ‘check_execveat_pathmax’:
> execveat.c:185: error: ‘AT_EMPTY_PATH’ undeclared (first use in this function)
> execveat.c:185: error: (Each undeclared identifier is reported only once
> execveat.c:185: error: for each function it appears in.)
> execveat.c: In function ‘run_tests’:
> execveat.c:221: error: ‘O_PATH’ undeclared (first use in this function)
> execveat.c:222: error: ‘O_CLOEXEC’ undeclared (first use in this function)
> execveat.c:258: error: ‘AT_EMPTY_PATH’ undeclared (first use in this function)
>
> Cc: sta...@vger.kernel.org # 3.19+
> Signed-off-by: Vinson Lee
> ---
> tools/testing/selftests/exec/execveat.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/testing/selftests/exec/execveat.c
> b/tools/testing/selftests/exec/execveat.c
> index 8d5d1d2..170148d 100644
> --- a/tools/testing/selftests/exec/execveat.c
> +++ b/tools/testing/selftests/exec/execveat.c
> @@ -20,6 +20,16 @@
> #include
> #include
>
> +#ifndef AT_EMPTY_PATH
> +# define AT_EMPTY_PATH 0x1000
> +#endif
> +#ifndef O_PATH
> +# define O_PATH 01000
> +#endif
> +#ifndef O_CLOEXEC
> +# define O_CLOEXEC 0200
> +#endif
> +
Won't those definitions affect the arch-independence of the test?
(The O_* constants are sadly arch-specific:
http://lxr.free-electrons.com/ident?i=O_PATH)
> static char longpath[2 * PATH_MAX] = "";
> static char *envp[] = { "IN_TEST=yes", NULL, NULL };
> static char *argv[] = { "execveat", "99", NULL };
> --
> 1.8.2.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Core block IO bits for 4.2
Hi Jens, On 06/25/15 23:37, Jens Axboe wrote: > block, dm: don't copy bios for request clones this change should not be pushed to mainline yet. Firstly, Christoph has a newer version of the patch that fixes silent data corruption problem: https://www.redhat.com/archives/dm-devel/2015-May/msg00229.html And the new version still depends on LLDDs to always complete requests to the end when error happens, while block API doesn't enforce such a requirement. If the assumption is ever broken, the inconsistency between request and bio (e.g. rq->__sector and rq->bio) will cause silent data corruption: https://www.redhat.com/archives/dm-devel/2015-June/msg00022.html -- Jun'ichi Nomura, NEC Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v4 3/3] mfd: devicetree: bindings: Add new 88pm800 mfd binding
On Friday 26 June 2015 11:35 AM, Yi Zhang wrote: On Thu, Jun 25, 2015 at 03:26:29PM +0800, Vaibhav Hiremath wrote: With addition of DT support to 88pm800 mfd driver, this patch adds new DT binding documentation along with respective properties. Signed-off-by: Vaibhav Hiremath --- Documentation/devicetree/bindings/mfd/88pm800.txt | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/88pm800.txt diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt b/Documentation/devicetree/bindings/mfd/88pm800.txt new file mode 100644 index 000..f56b751 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/88pm800.txt @@ -0,0 +1,54 @@ +* Marvell 88PM8xx Power Management IC + +Required parent device properties: +- compatible : "marvell,88pm800", "marvell,88pm805", "marvell,88pm860" +- reg : the I2C slave address for the 88pm8xx chip +- interrupts : IRQ line for the 88pm8xx chip +- interrupt-controller: describes the 88pm8xx as an interrupt controller +- #interrupt-cells : should be 1. + - The cell is the 88pm8xx local IRQ number + +88pm8xx family of devices consists of varied group of sub-devices: what about using "88pm80x family of devices..."? for we also have another series of chip, with the name of 88pm88x.. I renamed it after Rob's suggestion, but at that time we didn't see 88pm88x coming. But I think now, I should stick to 88pm800 only, as it doesn't make match with both 88pm822 and 88pm860. Rob, let me know if you think otherwise. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] usb: storage : Remove c99 style commenting
This patch fixes checkpatch.pl warning c99 style commenting. Signed-off-by: Sunny Kumar --- drivers/usb/storage/sddr55.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/usb/storage/sddr55.c b/drivers/usb/storage/sddr55.c index aacedef..54d0a59 100644 --- a/drivers/usb/storage/sddr55.c +++ b/drivers/usb/storage/sddr55.c @@ -209,10 +209,10 @@ static int sddr55_read_data(struct us_data *us, unsigned int len, offset; struct scatterlist *sg; - // Since we only read in one block at a time, we have to create - // a bounce buffer and move the data a piece at a time between the - // bounce buffer and the actual transfer buffer. - + /* Since we only read in one block at a time, we have to create +* a bounce buffer and move the data a piece at a time between the +* bounce buffer and the actual transfer buffer. +*/ len = min((unsigned int) sectors, (unsigned int) info->blocksize >> info->smallpageshift) * PAGESIZE; buffer = kmalloc(len, GFP_NOIO); @@ -336,10 +336,10 @@ static int sddr55_write_data(struct us_data *us, return USB_STOR_TRANSPORT_FAILED; } - // Since we only write one block at a time, we have to create - // a bounce buffer and move the data a piece at a time between the - // bounce buffer and the actual transfer buffer. - + /* Since we only write one block at a time, we have to create +* a bounce buffer and move the data a piece at a time between the +* bounce buffer and the actual transfer buffer. +*/ len = min((unsigned int) sectors, (unsigned int) info->blocksize >> info->smallpageshift) * PAGESIZE; buffer = kmalloc(len, GFP_NOIO); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v4 3/3] mfd: devicetree: bindings: Add new 88pm800 mfd binding
On Thu, Jun 25, 2015 at 03:26:29PM +0800, Vaibhav Hiremath wrote:
> With addition of DT support to 88pm800 mfd driver, this patch
> adds new DT binding documentation along with respective properties.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> Documentation/devicetree/bindings/mfd/88pm800.txt | 54
> +++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/88pm800.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt
> b/Documentation/devicetree/bindings/mfd/88pm800.txt
> new file mode 100644
> index 000..f56b751
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/88pm800.txt
> @@ -0,0 +1,54 @@
> +* Marvell 88PM8xx Power Management IC
> +
> +Required parent device properties:
> +- compatible : "marvell,88pm800", "marvell,88pm805", "marvell,88pm860"
> +- reg : the I2C slave address for the 88pm8xx chip
> +- interrupts : IRQ line for the 88pm8xx chip
> +- interrupt-controller: describes the 88pm8xx as an interrupt controller
> +- #interrupt-cells : should be 1.
> + - The cell is the 88pm8xx local IRQ number
> +
> +88pm8xx family of devices consists of varied group of sub-devices:
what about using "88pm80x family of devices..."?
for we also have another series of chip, with the name of 88pm88x..
> +
> +Device Supply Names Description
> +-- ---
> +88pm80x-onkey: : On key
> +88pm80x-rtc : : RTC
> +88pm80x-regulator: : Regulators
> +
> +Note: More device list will follow
> +
> +Example:
> +
> + pmic: 88pm800@30 {
> + compatible = "marvell,88pm800";
> + reg = <0x30>;
> + interrupts = ;
> + interrupt-parent = <&gic>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + regulators {
> + compatible = "marvell,88pm80x-regulator";
> +
> + buck1a: BUCK1A {
> + regulator-name = "BUCK1A";
> + regulator-min-microvolt = <60>;
> + regulator-max-microvolt = <180>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo1: LDO1 {
> + regulator-name = "LDO1";
> + regulator-min-microvolt = <170>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> +
> + rtc {
> + compatible = "marvell,88pm80x-rtc";
> + };
> + };
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] HID: microsoft: Add quirk for MS Surface Type/Touch cover
The newer frimware on MS Surface 2 tablets causes the type and touch cover
keyboards to timeout when waiting for reports.
Signed-off-by: Reyad Attiyat
---
drivers/hid/usbhid/hid-quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 4696895e..19c6f74 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -87,6 +87,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C05A,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3_JP,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v4 1/3] mfd: 88pm800: Add device tree support
On Friday 26 June 2015 11:23 AM, Yi Zhang wrote:
On Thu, Jun 25, 2015 at 08:57:49PM +0530, Vaibhav Hiremath wrote:
On Thursday 25 June 2015 08:18 PM, Lee Jones wrote:
On Thu, 25 Jun 2015, Vaibhav Hiremath wrote:
On Thursday 25 June 2015 03:49 PM, Lee Jones wrote:
On Thu, 25 Jun 2015, Vaibhav Hiremath wrote:
Add DT support to the 88pm800 driver, along with compatible
field for it's sub-devices (rtc, onkey and regulator)
Signed-off-by: Chao Xie
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 841717a..40fd014 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
/* Interrupt Registers */
#define PM800_INT_STATUS1 (0x05)
@@ -121,6 +122,11 @@ static const struct i2c_device_id pm80x_id_table[] = {
};
MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
+static const struct of_device_id pm80x_of_match_table[] = {
+ { .compatible = "marvell,88pm800", },
+ {},
+};
+
static struct resource rtc_resources[] = {
{
.name = "88pm80x-rtc",
@@ -133,6 +139,7 @@ static struct resource rtc_resources[] = {
static struct mfd_cell rtc_devs[] = {
{
.name = "88pm80x-rtc",
+.of_compatible = "marvell,88pm80x-rtc",
.num_resources = ARRAY_SIZE(rtc_resources),
.resources = &rtc_resources[0],
.id = -1,
@@ -151,6 +158,7 @@ static struct resource onkey_resources[] = {
static const struct mfd_cell onkey_devs[] = {
{
.name = "88pm80x-onkey",
+.of_compatible = "marvell,88pm80x-onkey",
.num_resources = 1,
.resources = &onkey_resources[0],
.id = -1,
@@ -160,6 +168,7 @@ static const struct mfd_cell onkey_devs[] = {
static const struct mfd_cell regulator_devs[] = {
{
.name = "88pm80x-regulator",
+.of_compatible = "marvell,88pm80x-regulator",
.id = -1,
},
};
@@ -544,8 +553,21 @@ static int pm800_probe(struct i2c_client *client,
int ret = 0;
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = dev_get_platdata(&client->dev);
+ struct device_node *np = client->dev.of_node;
struct pm80x_subchip *subchip;
+ if (!pdata && !np) {
+ dev_err(&client->dev,
+ "pm80x requires platform data or of_node\n");
+ return -EINVAL;
+ }
+
+ if (!pdata) {
+ pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ }
Why have you allocated data for pdata, then done nothing with it?
Not in this patch, but subsequent patches would use it.
Only provide it when you start using it please.
I will take back my earlier comment of "not using in this patch, but
subsequent patches".
pdata is being used, couple of places in the driver,
@line-751
ret = device_800_init(chip, pdata);
if (ret) {
dev_err(chip->dev, "Failed to initialize 88pm800
devices\n");
goto err_device_init;
}
if (pdata && pdata->plat_config)
pdata->plat_config(chip, pdata);
this plat_config() is used in legacy non-device-tree code, it's used
to implement fixup for chip or board level, it exists in
the board configuration file
just curious, do you think we still need to keep it?
considering device-tree has been used. thanks;
I do not see it anywhere in mainline kernel tree, is it part of some
internal tree?
If we know that it is being used, then lets not remove it now.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v4 1/3] mfd: 88pm800: Add device tree support
On Thu, Jun 25, 2015 at 08:57:49PM +0530, Vaibhav Hiremath wrote:
>
>
> On Thursday 25 June 2015 08:18 PM, Lee Jones wrote:
> >On Thu, 25 Jun 2015, Vaibhav Hiremath wrote:
> >>On Thursday 25 June 2015 03:49 PM, Lee Jones wrote:
> >>>On Thu, 25 Jun 2015, Vaibhav Hiremath wrote:
> >>>
> Add DT support to the 88pm800 driver, along with compatible
> field for it's sub-devices (rtc, onkey and regulator)
>
> Signed-off-by: Chao Xie
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/mfd/88pm800.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> index 841717a..40fd014 100644
> --- a/drivers/mfd/88pm800.c
> +++ b/drivers/mfd/88pm800.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> /* Interrupt Registers */
> #define PM800_INT_STATUS1 (0x05)
> @@ -121,6 +122,11 @@ static const struct i2c_device_id pm80x_id_table[] =
> {
> };
> MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
>
> +static const struct of_device_id pm80x_of_match_table[] = {
> + { .compatible = "marvell,88pm800", },
> + {},
> +};
> +
> static struct resource rtc_resources[] = {
> {
> .name = "88pm80x-rtc",
> @@ -133,6 +139,7 @@ static struct resource rtc_resources[] = {
> static struct mfd_cell rtc_devs[] = {
> {
> .name = "88pm80x-rtc",
> + .of_compatible = "marvell,88pm80x-rtc",
> .num_resources = ARRAY_SIZE(rtc_resources),
> .resources = &rtc_resources[0],
> .id = -1,
> @@ -151,6 +158,7 @@ static struct resource onkey_resources[] = {
> static const struct mfd_cell onkey_devs[] = {
> {
> .name = "88pm80x-onkey",
> + .of_compatible = "marvell,88pm80x-onkey",
> .num_resources = 1,
> .resources = &onkey_resources[0],
> .id = -1,
> @@ -160,6 +168,7 @@ static const struct mfd_cell onkey_devs[] = {
> static const struct mfd_cell regulator_devs[] = {
> {
> .name = "88pm80x-regulator",
> + .of_compatible = "marvell,88pm80x-regulator",
> .id = -1,
> },
> };
> @@ -544,8 +553,21 @@ static int pm800_probe(struct i2c_client *client,
> int ret = 0;
> struct pm80x_chip *chip;
> struct pm80x_platform_data *pdata =
> dev_get_platdata(&client->dev);
> + struct device_node *np = client->dev.of_node;
> struct pm80x_subchip *subchip;
>
> + if (!pdata && !np) {
> + dev_err(&client->dev,
> + "pm80x requires platform data or of_node\n");
> + return -EINVAL;
> + }
> +
> + if (!pdata) {
> + pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> + }
> >>>
> >>>Why have you allocated data for pdata, then done nothing with it?
> >>>
> >>
> >>Not in this patch, but subsequent patches would use it.
> >
> >Only provide it when you start using it please.
> >
>
> I will take back my earlier comment of "not using in this patch, but
> subsequent patches".
>
> pdata is being used, couple of places in the driver,
>
>
> @line-751
>
> ret = device_800_init(chip, pdata);
> if (ret) {
> dev_err(chip->dev, "Failed to initialize 88pm800
> devices\n");
> goto err_device_init;
> }
>
> if (pdata && pdata->plat_config)
> pdata->plat_config(chip, pdata);
this plat_config() is used in legacy non-device-tree code, it's used
to implement fixup for chip or board level, it exists in
the board configuration file
just curious, do you think we still need to keep it?
considering device-tree has been used. thanks;
>
> Thanks,
> Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/19] staging: sm750fb: consistent spacing around operators
On Thu, Jun 25, 2015 at 9:05 PM, Sudip Mukherjee wrote: > Usually I use the checkpatch which is in linux-next. That will be the > latest version. If you compare, last commit on checkpatch of staging > tree was on April 16th, where as last commit in linux-next is on > June 19th. And if you use this checkpatch you will see these warnings > also. :) Just wanted to clarify. So even with the linux-next checkpatch.pl, no errors/warnings show for me. Only when I run checkpatch.pl with the '--strict' option does it give the following checks for various operators: CHECK: space preferred before that '|' (ctx:VxE) Are these the warnings you are referring too? Do you want me to fix all of these for this patch? Regards Juston -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] mtd: nand_bbt: separate struct nand_chip from nand_bbt.c
Hi Kamil, First of all, thanks for your great contribution. On Jun 25, 2015 at 20:44 PM, Kamil Debski wrote: > > Hi Peter, > > Thank you for work on this. I have applied this patch to the latest > kernel and it had some minor merge conflicts that needed to be resolved. > But apart from this it compiled and worked in my setup. > > My testing procedure was following: > 1) I applied your patch to the NAND core > 2) I applied old SPI NAND patches by Ezequiel Garcia. His patches use > the NAND core as a bridge between the SPI NAND core and MTD core. Hence > it was possible to test changes in the NAND core. > 3) The kernel compiled and booted. I then run nandtest and it finished > successfully. > > I know that you have prepared a patch that adds the SPI NAND core and > that uses common BBT. I think that it is a good idea to send it along > with a v2 of this patch rebased to the 4.1 or the next branch of Brain > Norris. I would really like to test it :) I will send the new SPI NAND patch and v2 BBT patch out soon. Your effort will be a great help! > > I have read the patch code and I have this one minor comment. Please > find it below. > > Best wishes, > Kamil Debski > > From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On > Behalf > Of Peter Pan ?? (peterpandong) > Sent: 15 May 2015 08:32 > > > Currently nand_bbt.c is tied with struct nand_chip, and it makes > other > > NAND family chips hard to use nand_bbt.c. Maybe it's the reason why > > onenand has own bbt(onenand_bbt.c). > > > > Parameterize a few relevant device detail information into a new > > nand_bbt struct, and set some hooks for chip specified part. Allocate > > and initialize struct nand_bbt in nand_base.c. > > > > Most of the patch is borrowed from Brian Norris > > . > > http://git.infradead.org/users/norris/linux- > > mtd.git/shortlog/refs/heads/nand-bbt > > > > Signed-off-by: Peter Pan > > Signed-off-by: Brian Norris > > Tested-by: Kamil Debski > > > --- > > drivers/mtd/nand/docg4.c | 8 +- > > drivers/mtd/nand/nand_base.c | 145 +++- > > drivers/mtd/nand/nand_bbt.c | 518 + > - > > - > > include/linux/mtd/bbm.h | 96 +--- > > include/linux/mtd/nand.h | 11 +- > > include/linux/mtd/nand_bbt.h | 160 + > > 6 files changed, 516 insertions(+), 422 deletions(-) > > create mode 100644 include/linux/mtd/nand_bbt.h > > > > [ snip] > > > diff --git a/include/linux/mtd/nand_bbt.h > b/include/linux/mtd/nand_bbt.h > > new file mode 100644 > > index 000..03ee0eb > > --- /dev/null > > +++ b/include/linux/mtd/nand_bbt.h > > @@ -0,0 +1,160 @@ > > +/* > > + * NAND family Bad Block Table support > > + * > > + * Copyright © 2015 Broadcom Corporation > > + * Brian Norris > > + * > > + * This program is free software; you can redistribute it and/or > modify > > + * it under the terms of the GNU General Public License as published > by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + */ > > +#ifndef __LINUX_MTD_NAND_BBT_H > > +#define __LINUX_MTD_NAND_BBT_H > > + > > +struct mtd_info; > > + > > +/* The maximum number of NAND chips in an array */ > > +#define NAND_MAX_CHIPS 8 > > + > > +/** > > + * struct nand_bbt_descr - bad block table descriptor > > + * @options: options for this descriptor > > + * @pages: the page(s) where we find the bbt, used with option > > BBT_ABSPAGE > > + * when bbt is searched, then we store the found bbts pages > > here. > > + * Its an array and supports up to 8 chips now > > + * @offs: offset of the pattern in the oob area of the page > > + * @veroffs: offset of the bbt version counter in the oob are of > the page > > + * @version: version read from the bbt page during scan > > + * @len: length of the pattern, if 0 no pattern check is performed > > + * @maxblocks: maximum number of blocks to search for a bbt. This > > number of > > + * blocks is reserved at the end of the device where the > tables > > are > > + * written. > > + * @reserved_block_code: if non-0, this pattern denotes a reserved > (rather > > than > > + * bad) block in the stored bbt > > + * @pattern: pattern to identify bad block table or factory marked > good / > > + * bad blocks, can be NULL, if len = 0 > > + * > > + * Descriptor for the bad block table marker and the descriptor for > the > > + * pattern which identifies good and bad blocks. The assumption is > made > > + * that the pattern and the version count are always located in the > oob area > > + * of the first block. > > + */ > > +struct nand_bbt_
Re: linux-next: manual merge of the arc tree with Linus' tree
On Friday 26 June 2015 05:17 AM, Stephen Rothwell wrote:
> Hi Vineet,
>
> Today's linux-next merge of the arc tree got a conflict in:
>
> include/asm-generic/barrier.h
>
> between commits:
>
> ab3f02fc2372 ("locking/arch: Add WRITE_ONCE() to set_mb()")
> b92b8b35a2e3 ("locking/arch: Rename set_mb() to smp_store_mb()")
>
> from Linus' tree and commit:
>
> 470c27e4695a ("arch: conditionally define smp_{mb,rmb,wmb}")
>
> from the arc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
LGTM.
Thx Stephan.
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8188eu: don't duplicate ieee80211 WLAN_CAPABILITY_* constants
linux/ieee80211.h already defines constants for capability bits.
Include it where needed, resolve discrepancies in naming, and remove the
duplicated definitions.
Also, make use of WLAN_CAPABILITY_IS_STA_BSS() macro to check if neither
ESS nor IBSS capability bits are set.
Signed-off-by: Jakub Sitnicki
---
This patch depends on commit 04fbf979b39b ("rtl8188eu: don't duplicate
ieee80211 constants for status/reason") in staging-next branch.
drivers/staging/rtl8188eu/core/rtw_ap.c| 2 +-
drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 2 ++
drivers/staging/rtl8188eu/core/rtw_mlme.c | 5 +++--
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 2 ++
drivers/staging/rtl8188eu/include/ieee80211.h | 10 --
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 4 ++--
6 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 1d3f728..f4376d5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -1564,7 +1564,7 @@ void bss_cap_update_on_sta_join(struct adapter *padapter,
struct sta_info *psta)
}
}
- if (!(psta->capability & WLAN_CAPABILITY_SHORT_SLOT)) {
+ if (!(psta->capability & WLAN_CAPABILITY_SHORT_SLOT_TIME)) {
if (!psta->no_short_slot_time_set) {
psta->no_short_slot_time_set = 1;
diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 11b780d..d43e867 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -19,6 +19,8 @@
**/
#define _IEEE80211_C
+#include
+
#include
#include
#include
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 6c91aa5..d398151 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -19,6 +19,7 @@
**/
#define _RTW_MLME_C_
+#include
#include
#include
@@ -352,8 +353,8 @@ int is_same_network(struct wlan_bssid_ex *src, struct
wlan_bssid_ex *dst)
((!memcmp(src->Ssid.Ssid, dst->Ssid.Ssid,
src->Ssid.SsidLength)) == true) &&
((s_cap & WLAN_CAPABILITY_IBSS) ==
(d_cap & WLAN_CAPABILITY_IBSS)) &&
- ((s_cap & WLAN_CAPABILITY_BSS) ==
- (d_cap & WLAN_CAPABILITY_BSS)));
+ ((s_cap & WLAN_CAPABILITY_ESS) ==
+ (d_cap & WLAN_CAPABILITY_ESS)));
}
struct wlan_network*rtw_get_oldest_wlan_network(struct __queue
*scanned_queue)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 2b37175..c0e4751 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -19,6 +19,8 @@
**/
#define _RTW_WLAN_UTIL_C_
+#include
+
#include
#include
#include
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h
b/drivers/staging/rtl8188eu/include/ieee80211.h
index b129ad1..fabb959 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -483,16 +483,6 @@ struct ieee80211_snap_hdr {
#define WLAN_AUTH_CHALLENGE_LEN 128
-#define WLAN_CAPABILITY_BSS (1<<0)
-#define WLAN_CAPABILITY_IBSS (1<<1)
-#define WLAN_CAPABILITY_CF_POLLABLE (1<<2)
-#define WLAN_CAPABILITY_CF_POLL_REQUEST (1<<3)
-#define WLAN_CAPABILITY_PRIVACY (1<<4)
-#define WLAN_CAPABILITY_SHORT_PREAMBLE (1<<5)
-#define WLAN_CAPABILITY_PBCC (1<<6)
-#define WLAN_CAPABILITY_CHANNEL_AGILITY (1<<7)
-#define WLAN_CAPABILITY_SHORT_SLOT (1<<10)
-
/* Non standard? Not in */
#define WLAN_REASON_EXPIRATION_CHK 65535
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 0bde2887..a80cf31 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -179,8 +179,8 @@ static char *translate_scan(struct adapter *padapter,
cap = le16_to_cpu(le_tmp);
- if (cap & (WLAN_CAPABILITY_IBSS | WLAN_CAPABILITY_BSS)) {
- if (cap & WLAN_CAPABILITY_BSS)
+ if (!WLAN_CAPABILITY_IS_STA_BSS(cap)) {
+ if (cap & WLAN_CAPABILITY_ESS)
iwe.u.mode = IW_MODE_MASTER;
else
iwe.u.mode = IW_MODE_ADHOC;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] arm: add call to CPU idle quirks handler
Hi Nicolas,
Thanks for your proposal, however, I have some trouble with it.
That would look lovely:
#include
#include
/*
* cpu_kinetis_do_idle()
*
* Idle the processor (wait for interrupt).
*
* IRQs are already disabled.
*/
ENTRY(cpu_kinetis_do_idle)
wfi
movwr3, #:lower16:0xe0082000
movtr3, #:upper16:0xe0082000
ldr r0, [r3, #0]
orr r2, r0, #0x8500
str r2, [r3, #0]
ret lr
ENDPROC(cpu_kinetis_do_idle)
But... what about the rest of this hypothetical proc_kinetis.S file?
It would be a lot of code duplication with proc-v7m.S I think.
I could define CPU_KINETIS as such:
config CPU_KINETIS
bool
select CPU_V7M
But there's no such thing like customize_processor_functions that would be
called after proc-v7m.S define_processor_functions specified things like
idle routine.
Finally, while I was searching for suitable arm_pm_idle-based solution, I
found idle.c in mach-gemini that encouraged me to write my own idle.c for
Kinetis:
/*
* arch/arm/mach-kinetis/idle.c
*/
#include
#include
#include
#include
static void kinetis_idle(void)
{
asm volatile ("wfi");
/*
* This is a dirty hack that invalidates the I/D bus cache
* on Kinetis K70. This must be done after idle.
*/
writel(readl(IOMEM(0xe0082000)) | 0x8500, IOMEM(0xe0082000));
}
static int __init kinetis_idle_init(void)
{
arm_pm_idle = kinetis_idle;
return 0;
}
arch_initcall(kinetis_idle_init);
Et voila:
(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
kinetis_idle () at ../arch/arm/mach-kinetis/idle.c:18
18 writel(readl(IOMEM(0xe0082000)) | 0x8500,
IOMEM(0xe0082000));
(gdb) bt
#0 kinetis_idle () at ../arch/arm/mach-kinetis/idle.c:18
#1 0x0800a91e in arch_cpu_idle () at ../arch/arm/kernel/process.c:70
#2 0x08025402 in cpuidle_idle_call (state=)
at ../kernel/sched/idle.c:157
#3 cpu_idle_loop (state=) at
../kernel/sched/idle.c:253
#4 cpu_startup_entry (state=) at
../kernel/sched/idle.c:301
#5 0x081bf816 in start_kernel () at ../init/main.c:683
#6 0x08008024 in stext () at ../arch/arm/kernel/head-nommu.S:85
(gdb)
On Thu, 25 Jun 2015, Nicolas Pitre wrote:
On Tue, 23 Jun 2015, Arnd Bergmann wrote:
On Tuesday 23 June 2015 23:19:41 Paul Osmialowski wrote:
Some SoCs need additional actions to be performed after arch idle,
e.g. Kinetis requires invalidation of the I/D bus cache.
Such handler could be held in provided header file.
Signed-off-by: Paul Osmialowski
---
arch/arm/Kconfig | 7 +++
arch/arm/kernel/process.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8e3a833..8ef8f8f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -98,6 +98,13 @@ config ARM_HAS_SG_CHAIN
config NEED_SG_DMA_LENGTH
bool
+config NEED_MACH_IDLE_H
+ bool
+
+config ARM_CPU_IDLE_QUIRKS
+ bool
+ select NEED_MACH_IDLE_H
+
We're not adding header files like this, please come up
with another solution. How about a cpuidle driver, or
possibly just overriding arm_pm_idle()?
If the WFI instruction always requires I and D flushing, then it might
be a better idea to provide a replacement for the corresponding
cpu_*_do_idle function. Plenty of examples exist for other cpu_*
functions.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hugetlb:Make the function vma_shareable bool
On Thu, Jun 25, 2015 at 09:19:28PM -0400, Nicholas Krause wrote: > This makes the function vma_shareable bool now due to this > particular function only ever returning either one or zero > as its return value. > > Signed-off-by: Nicholas Krause Acked-by: Naoya Horiguchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clockevents: return error from tick_broadcast_oneshot_control if !GENERIC_CLOCKEVENTS_BROADCAST
On 06/25/2015 09:00 PM, Sudeep Holla wrote: > > > On 25/06/15 14:55, Thomas Gleixner wrote: >> On Thu, 25 Jun 2015, Sudeep Holla wrote: >> >>> tick_broadcast_enter returns 0 when CPU can switch to broadcast >>> timer and non-zero otherwise. However when GENERIC_CLOCKEVENTS_BROADCAST >>> and TICK_ONESHOT are disabled, tick_broadcast_oneshot_control returns 0 >>> which indicates to the CPUIdle framework that the CPU can enter deeper >>> idle states even when the CPU local timer will be shutdown. If the >>> target state needs broadcast but not broadcast timer is available, then >>> the CPU can not resume back from that idle state. >>> >>> This patch returns error when there's no broadcast timer support >>> available so that CPUIdle framework prevents the CPU from entering any >>> idle states losing the local timer. >> >> That's wrong and breaks stuff which does not require the broadcast >> nonsense. >> > > OK, sorry for not considering that case. > >> If TICK_ONESHOT is disabled, then everything is in periodic mode and >> tick_broadcast_enter() rightfully returns 0. Ditto for 'highres=off' >> on the command line. >> >> But there is a case which is not correctly handled right now. That's >> what you are trying to solve in the wrong way. >> > > Correct I was trying to solve exactly the case mentioned below. > >> If >> GENERIC_CLOCKEVENTS_BROADCAST=n >> >> or >> >> GENERIC_CLOCKEVENTS_BROADCAST=y and no broadcast device is available, >> >> AND cpu local tick device has the C3STOP flag set, >> >> then we have no way to tell the idle code that going deep is not >> allowed. >> >> So we need to be smarter than blindly changing a return >> value. Completely untested patch below. >> > > Agreed, thanks for the quick patch, I have tested it and it works fine. > You can add > > Tested-by: Sudeep Holla What about the case where GENERIC_CLOCKEVENTS_BROADCAST=y and TICK_ONESHOT=n (HZ_PERIODIC=y) ? Have you tested this ? This will hang the kernel at boot if you are using the hrtimer mode of broadcast. This is because the local timers of all cpus are shutdown when the cpuidle driver registers itself, on finding out that there are idle states where local tick devices stop. The broadcast tick device is then in charge of waking up the cpus at every period. In hrtimer mode of broadcast, there is no such real device and we hang. There was a patch sent out recently to fix this on powerpc. https://lkml.org/lkml/2015/6/24/42 Regards Preeti U Murthy > > Regards, > Sudeep > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clockevents: return error from tick_broadcast_oneshot_control if !GENERIC_CLOCKEVENTS_BROADCAST
On 06/25/2015 07:25 PM, Thomas Gleixner wrote:
> But there is a case which is not correctly handled right now. That's
> what you are trying to solve in the wrong way.
>
> If
>GENERIC_CLOCKEVENTS_BROADCAST=n
>
> or
>
>GENERIC_CLOCKEVENTS_BROADCAST=y and no broadcast device is available,
>
> AND cpu local tick device has the C3STOP flag set,
>
> then we have no way to tell the idle code that going deep is not
> allowed.
>
> So we need to be smarter than blindly changing a return
> value. Completely untested patch below.
>
> Thanks,
>
> tglx
> ---
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 4191b5623a28..8731a58dd747 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -63,11 +63,7 @@ extern void tick_broadcast_control(enum
> tick_broadcast_mode mode);
> static inline void tick_broadcast_control(enum tick_broadcast_mode mode) { }
> #endif /* BROADCAST */
>
> -#if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) &&
> defined(CONFIG_TICK_ONESHOT)
> extern int tick_broadcast_oneshot_control(enum tick_broadcast_state state);
> -#else
> -static inline int tick_broadcast_oneshot_control(enum tick_broadcast_state
> state) { return 0; }
> -#endif
>
> static inline void tick_broadcast_enable(void)
> {
> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> index d39f32cdd1b5..52c8d01b956b 100644
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -662,24 +662,15 @@ static void broadcast_shutdown_local(struct
> clock_event_device *bc,
> clockevents_switch_state(dev, CLOCK_EVT_STATE_SHUTDOWN);
> }
>
> -/**
> - * tick_broadcast_oneshot_control - Enter/exit broadcast oneshot mode
> - * @state: The target state (enter/exit)
> - *
> - * The system enters/leaves a state, where affected devices might stop
> - * Returns 0 on success, -EBUSY if the cpu is used to broadcast wakeups.
> - *
> - * Called with interrupts disabled, so clockevents_lock is not
> - * required here because the local clock event device cannot go away
> - * under us.
> - */
> -int tick_broadcast_oneshot_control(enum tick_broadcast_state state)
> +int __tick_broadcast_oneshot_control(enum tick_broadcast_state state)
> {
> struct clock_event_device *bc, *dev;
> - struct tick_device *td;
> int cpu, ret = 0;
> ktime_t now;
>
> + if (!tick_broadcast_device.evtdev)
> + return -EBUSY;
> +
> /*
>* Periodic mode does not care about the enter/exit of power
>* states
> @@ -687,15 +678,7 @@ int tick_broadcast_oneshot_control(enum
> tick_broadcast_state state)
> if (tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC)
> return 0;
>
> - /*
> - * We are called with preemtion disabled from the depth of the
> - * idle code, so we can't be moved away.
> - */
> - td = this_cpu_ptr(&tick_cpu_device);
> - dev = td->evtdev;
> -
> - if (!(dev->features & CLOCK_EVT_FEAT_C3STOP))
> - return 0;
> + dev = this_cpu_ptr(&tick_cpu_device)->evtdev;
>
> raw_spin_lock(&tick_broadcast_lock);
> bc = tick_broadcast_device.evtdev;
> @@ -938,6 +921,13 @@ bool tick_broadcast_oneshot_available(void)
> return bc ? bc->features & CLOCK_EVT_FEAT_ONESHOT : false;
> }
>
> +#else
> +int __tick_broadcast_oneshot_control(enum tick_broadcast_state state)
> +{
> + if (!tick_broadcast_device.evtdev)
> + return -EBUSY;
> + return 0;
> +}
> #endif
>
> void __init tick_broadcast_init(void)
> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index 17f144450050..f66c11a30348 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -342,6 +342,27 @@ out_bc:
> tick_install_broadcast_device(newdev);
> }
>
> +/**
> + * tick_broadcast_oneshot_control - Enter/exit broadcast oneshot mode
> + * @state: The target state (enter/exit)
> + *
> + * The system enters/leaves a state, where affected devices might stop
> + * Returns 0 on success, -EBUSY if the cpu is used to broadcast wakeups.
> + *
> + * Called with interrupts disabled, so clockevents_lock is not
> + * required here because the local clock event device cannot go away
> + * under us.
> + */
> +int tick_broadcast_oneshot_control(enum tick_broadcast_state state)
> +{
> + struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
> +
> + if (!(td->evtdev->features & CLOCK_EVT_FEAT_C3STOP))
> + return 0;
> +
> + return __tick_broadcast_oneshot_control(state);
> +}
> +
> #ifdef CONFIG_HOTPLUG_CPU
> /*
> * Transfer the do_timer job away from a dying cpu.
> diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
> index 42fdf4958bcc..a4a8d4e9baa1 100644
> --- a/kernel/time/tick-sched.h
> +++ b/kernel/time/tick-sched.h
> @@ -71,4 +71,14 @@ extern void tick_cancel_sched_timer(int cpu);
> static inline void tick_cancel_sched_timer(int cpu) { }
> #endif
>
> +#ifdef CONFIG_GENERIC_CLOCKE
Re: [PATCH v5 3/3] usb: xhci: remove stop device and ring doorbell in hub control and bus suspend
On 06/25/2015 10:53 PM, Mathias Nyman wrote: On 09.05.2015 04:15, Lu Baolu wrote: There is no need to call xhci_stop_device() and xhci_ring_device() in hub control and bus suspend functions since all device suspend and resume have been notified through device_suspend/device_resume interfaces. I was looking through this code again before sending it forward, and it occurred to me that this might be breaking the PORT_SUSPEND and PORT_SET_LINK_STATE port features for xhci root hub. In normal use these requests are called by usb core in usb_port_suspend(), which also now notifies xhci, which makes sure xhci_stop_device() is called. But I don't think there is anything preventing an URB to be sent to the xhci roothub with a PORT_SUSPEND or PORT_SET_LINK_STATE port feature request. In this case the usb_port_suspend() is not called, and no notify will stop the device. For example hub validation tests might do this. If that, we can drop this patch. It doesn't impact the other two patches in this patch series. Thanks, Baolu -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] ttpci: Replace memset with eth_zero_addr
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.
Note that the 6 in the third argument of memset appears to represent
an ethernet address size (ETH_ALEN).
The Coccinelle semantic patch that makes this change is as follows:
//
@eth_zero_addr@
expression e;
@@
-memset(e,0x00,6);
+eth_zero_addr(e);
//
Signed-off-by: Vaishali Thakkar
---
drivers/media/pci/ttpci/budget-av.c| 2 +-
drivers/media/pci/ttpci/ttpci-eeprom.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/ttpci/budget-av.c
b/drivers/media/pci/ttpci/budget-av.c
index 54c9910..3e469d4 100644
--- a/drivers/media/pci/ttpci/budget-av.c
+++ b/drivers/media/pci/ttpci/budget-av.c
@@ -1508,7 +1508,7 @@ static int budget_av_attach(struct saa7146_dev *dev,
struct saa7146_pci_extensio
if (i2c_readregs(&budget_av->budget.i2c_adap, 0xa0, 0x30, mac, 6)) {
pr_err("KNC1-%d: Could not read MAC from KNC1 card\n",
budget_av->budget.dvb_adapter.num);
- memset(mac, 0, 6);
+ eth_zero_addr(mac);
} else {
pr_info("KNC1-%d: MAC addr = %pM\n",
budget_av->budget.dvb_adapter.num, mac);
diff --git a/drivers/media/pci/ttpci/ttpci-eeprom.c
b/drivers/media/pci/ttpci/ttpci-eeprom.c
index 32d4315..01e13c4 100644
--- a/drivers/media/pci/ttpci/ttpci-eeprom.c
+++ b/drivers/media/pci/ttpci/ttpci-eeprom.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "ttpci-eeprom.h"
@@ -145,7 +146,7 @@ int ttpci_eeprom_parse_mac(struct i2c_adapter *adapter, u8
*proposed_mac)
if (ret != 0) { /* Will only be -ENODEV */
dprintk("Couldn't read from EEPROM: not there?\n");
- memset(proposed_mac, 0, 6);
+ eth_zero_addr(proposed_mac);
return ret;
}
@@ -157,7 +158,7 @@ int ttpci_eeprom_parse_mac(struct i2c_adapter *adapter, u8
*proposed_mac)
dprintk( "%.2x:", encodedMAC[i]);
}
dprintk("%.2x\n", encodedMAC[19]);
- memset(proposed_mac, 0, 6);
+ eth_zero_addr(proposed_mac);
return ret;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] pctv452e: Replace memset with eth_zero_addr
Use eth_zero_addr to assign the zero address to the given address array instead of memset when second argument is address of zero. Note that the 6 in the third argument of memset appears to represent an ethernet address size (ETH_ALEN). The Coccinelle semantic patch that makes this change is as follows: // @eth_zero_addr@ expression e; @@ -memset(e,0x00,6); +eth_zero_addr(e); // Signed-off-by: Vaishali Thakkar --- drivers/media/usb/dvb-usb/pctv452e.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb/pctv452e.c b/drivers/media/usb/dvb-usb/pctv452e.c index d17618f..ec397c4 100644 --- a/drivers/media/usb/dvb-usb/pctv452e.c +++ b/drivers/media/usb/dvb-usb/pctv452e.c @@ -611,7 +611,7 @@ static int pctv452e_read_mac_address(struct dvb_usb_device *d, u8 mac[6]) return 0; failed: - memset(mac, 0, 6); + eth_zero_addr(mac); return ret; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] powerpc/rcpm: add RCPM driver
On Tue, 2015-06-23 at 16:07 +0800, yuantian.t...@freescale.com wrote: > From: Tang Yuantian > > There is a RCPM (Run Control/Power Management) in Freescale QorIQ > series processors. The device performs tasks associated with device > run control and power management. > > The driver implements some features: mask/unmask irq, enter/exit low > power states, freeze time base, etc. > > Signed-off-by: Chenhui Zhao > Signed-off-by: Tang Yuantian > --- > v4: > - refine bindings document > v3: > - added static and __init modifier to fsl_rcpm_init > v2: > - fix code style issues > - refine compatible string match part > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 42 +++ > arch/powerpc/include/asm/fsl_guts.h| 105 +++ > arch/powerpc/include/asm/fsl_pm.h | 48 +++ > arch/powerpc/platforms/85xx/Kconfig| 1 + > arch/powerpc/sysdev/Kconfig| 5 + > arch/powerpc/sysdev/Makefile | 1 + > arch/powerpc/sysdev/fsl_rcpm.c | 338 > + > 7 files changed, 540 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt > create mode 100644 arch/powerpc/include/asm/fsl_pm.h > create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt > new file mode 100644 > index 000..1f58018 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt > @@ -0,0 +1,42 @@ > +* Run Control and Power Management > + > +The RCPM performs all device-level tasks associated with device run control > +and power management. > + > +Required properites: > + - reg : Offset and length of the register set of RCPM block. > + - compatible : Sould contain a chip-specific RCPM block compatible string > + and (if applicable) may contain a chassis-version RCPM compatible > string. > + Chip-specific strings are of the form "fsl,-rcpm", such as: > + * "fsl,p2041-rcpm" > + * "fsl,p3041-rcpm" > + * "fsl,p4080-rcpm" > + * "fsl,p5020-rcpm" > + * "fsl,p5040-rcpm" > + * "fsl,t4240-rcpm" > + * "fsl,b4420-rcpm" > + * "fsl,b4860-rcpm" > + > + Chassis-version RCPM strings include: > + * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm > + * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm > + > +All references to "1.0" and "2.0" refer to the QorIQ chassis version to > +which the chip complies. > +Chassis Version Example Chips > +--- --- > +1.0 p4080, p5020, p5040, p2041, p3041 > +2.0 t4240, b4860, t1040, b4420 I don't think it's accurate to call t1040 chassis 2.0. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v8 46/49] perf tools: Add prologue for BPF programs for fetching arguments
On 2015/6/24 20:31, Wang Nan wrote:
[SNIP]
diff --git a/tools/perf/util/bpf-prologue.h b/tools/perf/util/bpf-prologue.h
new file mode 100644
index 000..3f77606
--- /dev/null
+++ b/tools/perf/util/bpf-prologue.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2015, He Kuang
+ * Copyright (C) 2015, Huawei Inc.
+ */
+#ifndef __BPF_PROLOGUE_H
+#define __BPF_PROLOGUE_H
+
+#include
+#include "probe-event.h"
+
+#define BPF_PROLOGUE_MAX_ARGS 3
+#define BPF_PROLOGUE_START_ARG_REG BPF_REG_3
+#define BPF_PROLOGUE_FETCH_RESULT_REG BPF_REG_2
+
+int bpf__gen_prologue(struct probe_trace_arg *args, int nargs,
+ struct bpf_insn *new_prog, size_t *new_cnt,
+ size_t cnt_space);
+
Here is a problem: if CONFIG_BPF_PROLOGUE is not set, a missing symbol
problem will be triggered.
I have updated this part in my patchset:
+/*
+ * Copyright (C) 2015, He Kuang
+ * Copyright (C) 2015, Huawei Inc.
+ */
+#ifndef __BPF_PROLOGUE_H
+#define __BPF_PROLOGUE_H
+
+#include
+#include
+#include "probe-event.h"
+
+#define BPF_PROLOGUE_MAX_ARGS 3
+#define BPF_PROLOGUE_START_ARG_REG BPF_REG_3
+#define BPF_PROLOGUE_FETCH_RESULT_REG BPF_REG_2
+
+#ifdef HAVE_BPF_PROLOGUE
+int bpf__gen_prologue(struct probe_trace_arg *args, int nargs,
+ struct bpf_insn *new_prog, size_t *new_cnt,
+ size_t cnt_space);
+#else
+static inline int
+bpf__gen_prologue(struct probe_trace_arg *args __maybe_unused,
+ int nargs __maybe_unused,
+ struct bpf_insn *new_prog __maybe_unused,
+ size_t *new_cnt,
+ size_t cnt_space __maybe_unused)
+{
+ if (!new_cnt)
+ return -EINVAL;
+ *new_cnt = 0;
+ return 0;
+}
+#endif
+#endif /* __BPF_PROLOGUE_H */
+#endif /* __BPF_PROLOGUE_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: rtl8192u: Replace memset with eth_zero_addr
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.
Note that the 6 in the third argument of memset appears to represent
an ethernet address size (ETH_ALEN).
The Coccinelle semantic patch that makes this change is as follows:
//
@eth_zero_addr@
expression e;
@@
-memset(e,0x00,6);
+eth_zero_addr(e);
//
Signed-off-by: Vaishali Thakkar
---
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index ea92fde..b89105d 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
@@ -112,7 +112,7 @@ static void TsAddBaProcess(unsigned long data)
static void ResetTsCommonInfo(PTS_COMMON_INFO pTsCommonInfo)
{
- memset(pTsCommonInfo->Addr, 0, 6);
+ eth_zero_addr(pTsCommonInfo->Addr);
memset(&pTsCommonInfo->TSpec, 0, sizeof(TSPEC_BODY));
memset(&pTsCommonInfo->TClass, 0, sizeof(QOS_TCLAS)*TCLAS_NUM);
pTsCommonInfo->TClasProc = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hugetlb:Make the function vma_shareable bool
On 06/25/2015 06:19 PM, Nicholas Krause wrote:
This makes the function vma_shareable bool now due to this
particular function only ever returning either one or zero
as its return value.
Signed-off-by: Nicholas Krause
---
mm/hugetlb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 75c0eef..c1be0d1 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3789,7 +3789,7 @@ static unsigned long page_table_shareable(struct
vm_area_struct *svma,
return saddr;
}
-static int vma_shareable(struct vm_area_struct *vma, unsigned long addr)
+static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
{
unsigned long base = addr & PUD_MASK;
unsigned long end = base + PUD_SIZE;
@@ -3799,8 +3799,8 @@ static int vma_shareable(struct vm_area_struct *vma,
unsigned long addr)
*/
if (vma->vm_flags & VM_MAYSHARE &&
vma->vm_start <= base && end <= vma->vm_end)
- return 1;
- return 0;
+ return true;
+ return false;
}
/*
I was looking at the page table sharing code just last week.
Acked-by: Mike Kravetz
--
Mike Kravetz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/19] staging: sm750fb: consistent spacing around operators
On Thu, Jun 25, 2015 at 9:05 PM, Sudip Mukherjee wrote: > Usually I use the checkpatch which is in linux-next. That will be the > latest version. If you compare, last commit on checkpatch of staging > tree was on April 16th, where as last commit in linux-next is on > June 19th. And if you use this checkpatch you will see these warnings > also. :) Thanks for the tip, I'll use the latest checkpatch and fix the warnings. Your help has been much appreciated Regards Juston -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] scripts/spelling.txt: Adding misspelled word for check.
misspelled words for check:- chcek chck cehck I myself did these spell mistakes in changelog for patches, Thus suggesting to add in spelling.txt, so that checkpatch.pl warns it earlier. References:- ./arch/powerpc/kernel/exceptions-64e.S:456: . . . make sure you chcek https://lkml.org/lkml/2015/6/25/289 ./arch/x86/mm/pageattr.c:1368: * No need to cehck in that case Signed-off-by: Maninder Singh --- scripts/spelling.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index bb8e4d0..958d054 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -187,6 +187,7 @@ capatibilities||capabilities carefuly||carefully cariage||carriage catagory||category +cehck||check challange||challenge challanges||challenges chanell||channel @@ -199,6 +200,8 @@ charactor||character charater||character charaters||characters charcter||character +chcek||check +chck||check checksuming||checksumming childern||children childs||children -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: rtl8192e: Replace memset with eth_zero_addr
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.
Note that the 6 in the third argument of memset appears to represent
an ethernet address size (ETH_ALEN).
The Coccinelle semantic patch that makes this change is as follows:
//
@eth_zero_addr@
expression e;
@@
-memset(e,0x00,6);
+eth_zero_addr(e);
//
Signed-off-by: Vaishali Thakkar
---
drivers/staging/rtl8192e/rtl819x_TSProc.c | 2 +-
drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c
b/drivers/staging/rtl8192e/rtl819x_TSProc.c
index 05aea43..70879594 100644
--- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
@@ -113,7 +113,7 @@ static void TsAddBaProcess(unsigned long data)
static void ResetTsCommonInfo(struct ts_common_info *pTsCommonInfo)
{
- memset(pTsCommonInfo->Addr, 0, 6);
+ eth_zero_addr(pTsCommonInfo->Addr);
memset(&pTsCommonInfo->TSpec, 0, sizeof(union tspec_body));
memset(&pTsCommonInfo->TClass, 0, sizeof(union qos_tclas)*TCLAS_NUM);
pTsCommonInfo->TClasProc = 0;
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index d320c31..1e8b109 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -3084,7 +3084,7 @@ static int rtllib_wpa_enable(struct rtllib_device *ieee,
int value)
*/
netdev_info(ieee->dev, "%s WPA\n", value ? "enabling" : "disabling");
ieee->wpa_enabled = value;
- memset(ieee->ap_mac_addr, 0, 6);
+ eth_zero_addr(ieee->ap_mac_addr);
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
On 2015-06-26 04:22, Hui Wang wrote:
> On 06/25/2015 07:02 PM, Jan Kiszka wrote:
>> On 2015-06-24 10:46, Hui Wang wrote:
>>> On 06/24/2015 01:37 PM, Jan Kiszka wrote:
On 2015-05-23 18:22, Jan Kiszka wrote:
> On 2015-05-23 18:06, Raymond Yau wrote:
>> 2015-5-23 下午4:50 於 "Jan Kiszka" 寫道：
>> Most Thinkpad Edge series laptops use conexant codec, so
>> far
>> although
>>> Is there anything I can debug or any information I can
>>> collect
>>> from my
>>> box to examine this?
>> What is the linux distribution on your machine? And use
>> showkey to
>> catch
>> the keycode of that button.
> I'm running OpenSUSE 13.1. The reported keycode of the power
> button is
> 116.
It seems the keycode is correct, it is power keycode rather
the mute
keycode.
Could you please do some debug, let us find which line of
code is
>> the
root cause for this problem. for example:
after running the line, the problem shows up:
1. if (ACPI_SUCCESS(acpi_get_devices("LEN0068",
acpi_check_cb,
&found, NULL)) && found) // in the
sound/pci/hda/thinkpad_helper.c,
is_thinkpad()
>>> This evaluates to true
>>>
2. return ACPI_SUCCESS(acpi_get_devices("IBM0068",
>> acpi_check_cb,
&found, NULL)) && found; // same as above
3. if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
//in the
sound/pci/hda/thinkpad_helper.c, hda_fixup_thinkpad_acpi()
>>> ...and this
>>>
4. if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0) { //
same as
above
>>> ...and this as well. spec->num_adc_nids is 1.
>> If we change the code like below, does the power button can work
>> well?
>>
>> in the thinkpad_helper.c, hda_fixup_thinkpad_acpi()
>>
>>
>>if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
>>/*
>>old_vmaster_hook = spec->vmaster_mute.hook;
>>spec->vmaster_mute.hook = update_tpacpi_mute_led;
>>removefunc = false;
>> */
> Disabling only this block resolves the issue.
So Below two lines make the power button change to the reset
button.
drivers/platform/x86/thinkpad_acpi.c mute_led_on_off():
acpi_get_handle(hkey_handle, "SSMS", &temp);
acpi_evalf(hkey_handle, &output, "SSMS", "dd", 1);
@alexhung,
Do you have any idea why this can affect the power button behavior?
>>> I think we all lost track of this issue, but it unfortunately still
>>> exists in the latest kernel, requiring custom builds here. How
>>> can we
>>> proceed?
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-May/091561.html
>>
>>
>>
>> If you cannot find "SSMS" in your T520 ACPI dump, this mean mute LED
>> cannot be turn on/off similar to T510
> There is an entry (see attached disassembly), but this device has at
> least no physical LED to drive.
>>> Some hotkey leds are embedded on button. Through the pictures I found
>>> on the internet (thinkpad t520), it looks like there is a led at the
>>> center of the mute button.
>> Again, I'm on a X121e, and that has only a single physical LED for
>> signaling the power state. The mute button is behind key combination of
>> the keyboard.
>>
>> Jan
> There is no reason to change a power button to a reset button after
> accessing the acpi device "SSMS", the "SSMS" is for the mute led instead
> of the power management.
>
> I think it is better you login to the lenovo website and look for the
> latest BIOS image, then upgrade the BIOS on your machine to see if it
> can solve the problem or not.
There is no more update since 2013, and I'm using the latest one. The
real bug is likely in the BIOS (it also has some other oddities), but
the trigger was this patch.
I suggested to have a quirk installed for my model - it cannot benefit
from this change anyway. Now I'm waiting for feedback on how to address
this best *in Linux* (because this is what we have under control).
Thanks,
Jan
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 11/19] staging: sm750fb: consistent spacing around operators
On Thu, Jun 25, 2015 at 09:26:00AM -0700, Juston Li wrote: > On Thu, Jun 25, 2015 at 4:56 AM, Sudip Mukherjee > wrote: > > On Wed, Jun 24, 2015 at 09:25:12AM -0700, Juston Li wrote: > > > 2) Considering that you are giving consitent space around operators, then > > i think you have missed few operators like '|','&',':' in this > > patch. > > > > These were the only instances the checkpatch.pl error came up. This patch > only fixes even spacing around a specific operator. Other operators either > have even or no spacing around them with PATCH 11/19 fixing any operators > with spacing around required. This leaves operators that checkpatch deems > spacing as optional which I left as a separate issue to be addressed of making > optional spacing of operators consistent with each other. Usually I use the checkpatch which is in linux-next. That will be the latest version. If you compare, last commit on checkpatch of staging tree was on April 16th, where as last commit in linux-next is on June 19th. And if you use this checkpatch you will see these warnings also. :) regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Mailbox changes for v4.2
On Fri, Jun 26, 2015 at 7:10 AM, Linus Torvalds wrote: > On Thu, Jun 25, 2015 at 8:58 AM, Jassi Brar wrote: >> >> http://git.linaro.org/landing-teams/working/fujitsu/integration.git >> mailbox-for-next > > So just looking at this pull request (and my previous merges from you) > it does strike me that you seem to be one of the few people who never > explain your pull requests.. > > Mind starting to write a small blurb every time you ask me to pull to > explain what's new and what's going on? That will improve my merge > logs.. > Sorry, the changes have been few and I thought patch names were suggestive enough. Will write a small para from next pull request. Thanks for accepting this request as such. -Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 16/19] staging: sm750fb: fix brace placement
On Thu, Jun 25, 2015 at 02:27:02PM -0700, Juston Li wrote: > On Thu, Jun 25, 2015 at 1:31 PM, Dan Carpenter > wrote: > Patchset was responded by Greg's patch bot, I'll resend when I figure out > why. Greg will not apply any patch since the merge window is open. That patchbot will respond when anyone send patch to Greg during this time. Just send the updated patch as a reply to the original patch with proper version number and Greg will pick it up later. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio: altera: use of_mm_gpiochip_remove() to fix memory leak
Acked-by: Tien Hock Loh
On Wed, 2015-06-17 at 20:59 +0900, Masahiro Yamada wrote:
> This driver calls of_mm_gpiochip_add() to add a memory mapped gpio
> chip. So, of_mm_gpiochip_remove() should be used when removing it.
>
> The direct call of gpiochip_remove() misses unmapping the register
> and freeing the label.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/gpio/gpio-altera.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
> index 449fb46..c653c83 100644
> --- a/drivers/gpio/gpio-altera.c
> +++ b/drivers/gpio/gpio-altera.c
> @@ -337,7 +337,7 @@ static int altera_gpio_remove(struct platform_device
> *pdev)
> {
> struct altera_gpio_chip *altera_gc = platform_get_drvdata(pdev);
>
> - gpiochip_remove(&altera_gc->mmchip.gc);
> + of_mm_gpiochip_remove(&altera_gc->mmchip);
>
> return -EIO;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio: altera: kill bogus dependency on GPIO_GENERIC
Acked-by: Tien Hock Loh On Sun, 2015-06-21 at 08:48 +0900, Masahiro Yamada wrote: > Adding Tien. > > > 2015-06-19 20:31 GMT+09:00 Masahiro Yamada : > > The driver gpio-altera.c does not depend on gpio-generic.c at all. > > Drop unneeded "select GPIO_GENERIC". > > > > Signed-off-by: Masahiro Yamada > > --- > > > > drivers/gpio/Kconfig | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > > index caefe80..25c232e 100644 > > --- a/drivers/gpio/Kconfig > > +++ b/drivers/gpio/Kconfig > > @@ -113,7 +113,6 @@ config GPIO_74XX_MMIO > > config GPIO_ALTERA > > tristate "Altera GPIO" > > depends on OF_GPIO > > - select GPIO_GENERIC > > select GPIOLIB_IRQCHIP > > help > > Say Y or M here to build support for the Altera PIO device. > > -- > > 1.9.1 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > Please read the FAQ at http://www.tux.org/lkml/ > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] mfd: add Marvell 88pm88x description
On Tue, Jun 23, 2015 at 08:16:01PM +0530, Vaibhav Hiremath wrote: > > > On Tuesday 23 June 2015 08:01 PM, Rob Herring wrote: > >On Fri, Jun 12, 2015 at 3:43 AM, Yi Zhang wrote: > >>88pm880 and 88pm886 are two combo PMIC chips, most of the function and the > >>register mapping are the same > > > >How do they compare to 80x/822/860 PMICs? > > > > Zhang, > > Sorry, I missed this patch-series. > > Is there any way we can get access to datahsheets of all these devices? Hi, Vaibhav: https://extranet.marvell.com/ is a useful place to access to them > > >> > >>Signed-off-by: Yi Zhang > >>--- > >> Documentation/devicetree/bindings/mfd/88pm88x.txt | 33 > >> +++ > >> 1 file changed, 33 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/mfd/88pm88x.txt > >> > >>diff --git a/Documentation/devicetree/bindings/mfd/88pm88x.txt > >>b/Documentation/devicetree/bindings/mfd/88pm88x.txt > >>new file mode 100644 > >>index 000..72e741c > >>--- /dev/null > >>+++ b/Documentation/devicetree/bindings/mfd/88pm88x.txt > >>@@ -0,0 +1,33 @@ > >>+Marvell 88pm88x combo PMIC chip > >>+ > >>+This series of chip integrates regulator, rtc, onkey, switch charger, > >>+fuelgauge, gpadc and a range of I/O pins. > >>+ > >>+88pm886 and 88pm880 are two very similar chips, most of the registers > >>mapping > >>+and functions are the same, the main difference is the latter has a > >>separate > >>+i2c slave address to cover BUCK related setting > >>+ > >>+Required properties: > >>+- compatible: one of the strings for a specific chip: > >>+ "marvell,88pm886" > >>+ "marvell,88pm880" > >>+- reg: the i2c address > >>+- interrupt-controller: it works as an interrupt controller managing its > >>irqs > >>+- interrupt-cells: this value is 1 > >>+ > >>+Optional properties: > >>+- marvell,88pm88x-irq-write-clear: the interrupt ack method > > > >The 80x/860 binding needs the same property. Please coordinate this > >with Vaibhav. > > > > Please refer to the patch > > https://lkml.org/lkml/2015/6/17/545 Thanks; > > Thanks, > Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] mfd: add Marvell 88pm88x description
On Tue, Jun 23, 2015 at 09:31:00AM -0500, Rob Herring wrote: > On Fri, Jun 12, 2015 at 3:43 AM, Yi Zhang wrote: > > 88pm880 and 88pm886 are two combo PMIC chips, most of the function and the > > register mapping are the same > > How do they compare to 80x/822/860 PMICs? Hi, Rob: 88pm80x/822/860 and 88pm886/88pm880 are two different series: - the register mapping is totally different, it's hard to reuse the existed code for 88pm80x - the latter is a chip which integrates the charger/fuelgauge/camera flash which doesn't exist in 88pm80x > > > > > Signed-off-by: Yi Zhang > > --- > > Documentation/devicetree/bindings/mfd/88pm88x.txt | 33 > > +++ > > 1 file changed, 33 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/88pm88x.txt > > > > diff --git a/Documentation/devicetree/bindings/mfd/88pm88x.txt > > b/Documentation/devicetree/bindings/mfd/88pm88x.txt > > new file mode 100644 > > index 000..72e741c > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/88pm88x.txt > > @@ -0,0 +1,33 @@ > > +Marvell 88pm88x combo PMIC chip > > + > > +This series of chip integrates regulator, rtc, onkey, switch charger, > > +fuelgauge, gpadc and a range of I/O pins. > > + > > +88pm886 and 88pm880 are two very similar chips, most of the registers > > mapping > > +and functions are the same, the main difference is the latter has a > > separate > > +i2c slave address to cover BUCK related setting > > + > > +Required properties: > > +- compatible: one of the strings for a specific chip: > > + "marvell,88pm886" > > + "marvell,88pm880" > > +- reg: the i2c address > > +- interrupt-controller: it works as an interrupt controller managing its > > irqs > > +- interrupt-cells: this value is 1 > > + > > +Optional properties: > > +- marvell,88pm88x-irq-write-clear: the interrupt ack method > > The 80x/860 binding needs the same property. Please coordinate this > with Vaibhav. Thanks for your reminder, got it > > Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [overlayfs] lockdep splat after mounting overlayfs over overlayfs
> On Thu, Jun 25, 2015 at 10:24 AM, Xu Wang wrote: > >> I've accidentally mounted one overlayfs over another and got obvious > >> warning from lockdep: i_mutex lockdep classes are per-fs-type. > >> > >> # mount -t overlay overlay 1 -o > >> upperdir=1_upper,workdir=1_work,lowerdir=1_lower > >> # mount -t overlay overlay 2 -o upperdir=2_upper,workdir=2_work,lowerdir=1 > >> # ls 2 > > > > This reporting is positive, we are not in deadlock situation actually. The > > "2" dir > > of overlayfs will call iterate_dir->"1" dir of overlayfs->iterate_dir, and > > the nest > > iterate_dir happened on the same file system, so the warning came out. > > > > We'd better make the lower and upper in different fs instance, and this > > warning > > will disappear. > > > > And this lockdep warning happened when the nest iterate_dir call of same > > fs(I > > mean the same super block). The function check_deadlock in lockdep.c will > > report the nest lock of same process. If we make the 2_upper and 2_work in > > a different fs, no warning comes out. > > Yep, it's not a deadlock. As I mentioned lockdep classes are per-fs-type so > lockdep cannot see difference between i_mutexes on different sb of the > same type. > But anyway this looks messy. > yes, you are right. The i_mutex_class is file_system_tye scale. I was puzzled by the debug_locks mechanism during my quick tests. The nest iterate_dir is overlay dir, neither upper nor lower. > Probably it's safer to forbid overlayfs as lower or upper mount for overlayfs > because this have no sense. Nesting anyway is limited by the depth of kernel > stack and sb->s_stack_depth. > > Or overlayfs could detect this situation and substitute layers of underlying > overlayfs into its own lower layers in appropriate place. > Can we add the lockdep_off/lockdep_on in this situation? For we know this is just the false positive reporting of lockdep. Thanks, Xu Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] gpio: altera: fix return value of altera_gpio_remove()
Acked-by: Tien Hock Loh
On Wed, 2015-06-17 at 20:59 +0900, Masahiro Yamada wrote:
> The remove callback never succeeds, which seems odd.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> I wonder why nobody has pointed this out before me.
> I am suspecting -EIO might be intentional.
> I hope some Altera guys will give me comments.
>
>
> drivers/gpio/gpio-altera.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
> index c653c83..5861550 100644
> --- a/drivers/gpio/gpio-altera.c
> +++ b/drivers/gpio/gpio-altera.c
> @@ -339,7 +339,7 @@ static int altera_gpio_remove(struct platform_device
> *pdev)
>
> of_mm_gpiochip_remove(&altera_gc->mmchip);
>
> - return -EIO;
> + return 0;
> }
>
> static const struct of_device_id altera_gpio_of_match[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] regmap: add configurable lock class key for lockdep
On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown wrote: [...] >> >As far as I can tell we're likely to end up needing a key per regmap or >> >something similar. > >> Since the number of lockdep classes itself is also limited we should avoid >> creating extra lockdep classes when we can. I think the approach which >> having the option of specifying a lockdep class in the regmap config will be >> ok. The only case it can't handle if we nest instances with the same config, >> but I don't really see valid use scases for that at the moment. > > Oh, ffs. This just keeps getting better. I hadn't been aware of that > limitation. We still have the problem that this needs to be something > users can understand rather than something that's just "define something > here in one of your drivers if you're running into problems with > spurious warnings" here. That's always been the biggest problem here > (once we got past the "what is this supposed to do in the first place?" > issues). I found that V4L2 uses separate lockdep classes for each of their v4l2_ctrl. This was introduced in 6cd247ef22e "[media] v4l2-ctrls: eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock" (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd247ef22e), so we could possibly take that approach. On my system, I have: # cat /proc/lockdep_stats lock-classes: 1241 [max: 8191] direct dependencies: 7364 [max: 32768] indirect dependencies: 27686 all direct dependencies:158097 dependency chains: 10011 [max: 65536] dependency chain hlocks: 38887 [max: 327680] in-hardirq chains: 92 in-softirq chains: 372 in-process chains:9547 stack-trace entries:107703 [max: 524288] So, at least on that platform, there is some room to grow... I'm just afraid that implementing this may require creating a bunch of macros to wrap all regmap_init_[i2c/spi/...] functions, as the lockdep classes need to be statically allocated... Unless we find a different solution than what V4L2 does. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v1 0/7] input: cyapa: instruction of cyapa patches.patch
Hi Dmitry, Jmmahler, All, Is there any review points or comments on the v1 patches? Thanks in advance, Dudley V1 patches mainly have following updates compared with V0 patches: 1) This patch series is generated base on code base linux-next 20150612, so fix the patch v0 6/7 failed to apply on linux-next 20150611 issue. 1) Fix spelling errors, space and black line format errors in patch v1 1/7. 2) Add detail description of the new interrupt and proximity interfaces in patch v1 5/7. This patch series is mainly aimed to add new gen6 trackpad devices support, and also new function to report proximity data/vent for Gen5 and Gen6 trackpad devices. Dudley Du (7): input: cyapa: change strings of gen5 to pip in the name when they are shared input: cyapa: add gen6 device module support in driver input: cyapa: add proximity function support for gen5 and gen6 modules input: cyapa: fully support runtime suspend power management input: cyapa: add proximity and interrupt sysfs interfaces support input: cyapa: add of match device support and description document input: cyapa: add CYAP0002 Gen6 device for ACPI configuration .../devicetree/bindings/input/cypress,cyapa.txt| 44 + .../devicetree/bindings/vendor-prefixes.txt|1 + drivers/input/mouse/Makefile |2 +- drivers/input/mouse/cyapa.c| 266 - drivers/input/mouse/cyapa.h| 161 ++- drivers/input/mouse/cyapa_gen3.c | 11 +- drivers/input/mouse/cyapa_gen5.c | 1254 +++- drivers/input/mouse/cyapa_gen6.c | 760 8 files changed, 1854 insertions(+), 645 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt create mode 100644 drivers/input/mouse/cyapa_gen6.c History patch series modifications list: V0 patches mainly have following updates: 1) Add Gen6 trackpad device support; 2) Add report proximity data function support for Gen5 and Gen6 devices; 3) Fully support runtime suspend/resume power management; 4) Add of_match_table mechanism support. -- 1.9.1 This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/scsi: fix macro in sg
This patch fix the macro transport_class_to_sdev to the resonable name
and use the macro.
Signed-off-by: vonnyfly
---
drivers/scsi/sg.c |6 +++---
include/scsi/scsi_device.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 9d7b7db..be7f132 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1454,10 +1454,10 @@ out_unlock:
static int
sg_add_device(struct device *cl_dev, struct class_interface *cl_intf)
{
- struct scsi_device *scsidp = to_scsi_device(cl_dev->parent);
- struct gendisk *disk;
+ struct scsi_device *scsidp = transport_class_to_scsi_device(cl_dev);
+ struct gendisk *disk = NULL;
Sg_device *sdp = NULL;
- struct cdev * cdev = NULL;
+ struct cdev *cdev = NULL;
int error;
unsigned long iflags;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index ae84b22..f6a5473 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -227,7 +227,7 @@ struct scsi_dh_data {
container_of(d, struct scsi_device, sdev_gendev)
#define class_to_sdev(d) \
container_of(d, struct scsi_device, sdev_dev)
-#define transport_class_to_sdev(class_dev) \
+#define transport_class_to_scsi_device(class_dev) \
to_scsi_device(class_dev->parent)
#define sdev_dbg(sdev, fmt, a...) \
--
1.7.10.4
--
Thanks and Best Regards,
Feng Li(Alex)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: lzo: check for length overrun in variable length encoding backport
Le 06/24/15 22:30, Willy Tarreau a écrit :
> Hi Florian,
>
> On Wed, Jun 24, 2015 at 09:48:46PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> Could you backport this commit:
>> 72cf90124e87d975d0b2114d930808c58b4c05e4 ("lzo: check for length overrun
>> in variable length encoding.") into stable kernels older than 3.18?
>>
>> It should apply cleanly to anything that contains
>> 8b975bd3f9089f8ee5d7bbfd798537b992bbc7e7 ("lib/lzo: Update LZO
>> compression to current upstream version") which goes as far as 3.9.
>
> Well, it was merged into 3.10.59 as commit 9689415259, 3.12.32 as 4277fc42,
> 3.14.23 as 7f5f71a92.
>
> Are you sure you didn't mean something else and confused it with another id ?
I just got confused with searching the original commit it and did not
search by subject, thanks for the confirmation and sorry for the noise.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Call for Topics and Sponsors
* Call for Topics and Sponsors Workshop on Open Source Development Tools 2015 Beijing, China Sep. 12, 2015 (TBD) HelloGCC Work Group (www.hellogcc.org) * Open Source Development Tools Workshop is a meeting for open source software developers. You can share your work, study and learning experience of open source software development here. Our main topics is open source development tools. The content of topics can be: * GNU toolchain (gcc, binutils, gdb, etc) * Clang/LLVM toolchain * Other tools of open source development, debug and simulation The form of topics can be: * the introduction of your own work * the introduction of your work did in the past * tutorial, experience and etc * other forms of presentation, such as lightning talk If you have some topics, please contact us: * send email to hello...@freelists.org (need to subscribe http://www.freelists.org/list/hellogcc first) * login into freenode IRC #hellogcc room Important Date: * the deadline of topics and sponsors solicitation: Aug 1st, 2015 Previous Meetings: * OSDT 2014: http://www.hellogcc.org/?p=33910 * HelloGCC 2013: http://www.hellogcc.org/?p=33518 * HelloGCC 2012: http://linux.chinaunix.net/hellogcc2012 * HelloGCC 2011: http://linux.chinaunix.net/hellogcc2011 * HelloGCC 2010: http://linux.chinaunix.net/hellogcc2010 * HelloGCC 2009: http://www.aka-kernel.org/news/hellogcc/index.html If you want to sponsor us, we will very appreciate and please contact us via hellogcc.workgr...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote: > > Ah, thanks. I see now that the __raw_*() APIs don't do any of the > Endian Swizzling. Unfortunately the *_relaxed() APIs on PowerPC > are just defined as the normal *() routines. From > arch/powerpc/include/asm/io.h: > > /* > * We don't do relaxed operations yet, at least not with this > semantic > */ Yes so I was looking at this but there are some difficulties. Architecturally, even with I=1 G=1 mappings (normal ioremap), we have no guarantee of ordering of load vs. store unless I misunderstood something. I think all current implementations provide some of that but without barriers in the accessors, we aren't architecturally correct. However, having those barriers will cause issues with G=0 (write combine). It's unclear whether eieio() will provide the required ordering for I=1 G=0 mappings and it will probably break write combine. I'm looking into it with our HW guys and will try to come up with a solution for power, but it doesn't help that our memory model conflates write combining with other relaxations and that all our barriers also prevent write combine. Maybe we can bias the relaxed accessors toward write, by having no barriers in it, and putting extra ones in reads. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
On Wed, 2015-06-24 at 18:22 -0700, Luis R. Rodriguez wrote: > Although I had test compiled this before just to be safe I went ahead and > successfully test-compiled this set with allmodconfig, specially since I've > now > removed the exports for the devres routines. Please let me know if these > might > be able to go through you or if there are any questions. I will note the > recent > discussion with Benjamin over the v7 series concluded that the ideas we both > were alluding to, on automating instead the WC effects for devices seems a bit > too idealistic for PCI / PCIE for now, but perhaps we should at least consider > this in the future for userspace mmap() calls [4]. So I've been trying to figure out how to make this practically work for us (powerpc). writel() will never write combine for us, it uses too heavy barriers. writel_relaxed() today is identical to writel() but we can change it. The problem is that switching to G=0 mappings (which is what provides us with write combining) also architecturally enables prefetch and speculative loads... and again architecturally (the implementations may differ), kills the effect of the lightweight io barrier eieio which we would have to use in readl_relaxed() and writel_relaxed() to provide their normal semantics. So it boils down to: Can we modify the documentation of readl_relaxed() and writel_relaxed() to define them as being even further relaxed when using a "wc" mapping ? Otherwise, the only way out I see for us on powerpc is to bias massively writel_relaxed() against real_relaxed() by putting heavy barriers around the load in the latter so we can keep them completely out of the former and still enable wc. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] regmap: add configurable lock class key for lockdep
On Thu, Jun 25, 2015 at 11:59 PM, Lars-Peter Clausen wrote: > [...] >> >> diff --git a/include/linux/regmap.h b/include/linux/regmap.h >> index 116655d..09aaaf5 100644 >> --- a/include/linux/regmap.h >> +++ b/include/linux/regmap.h >> @@ -135,6 +135,12 @@ typedef void (*regmap_unlock)(void *); >>* @lock_arg: this field is passed as the only argument of lock/unlock >>* functions (ignored in case regular lock/unlock functions >>* are not overridden). >> + * @lock_class_key: Custom lock class key for lockdep validator. Use that >> to >> + * silence false lockdep nested locking warning, when >> this >> + * regmap needs to access another regmap during >> read/write >> + * operations (directly in read/write functions, or >> + * indirectly, e.g. through bus accesses). > > > The recommendation when to use this is the wrong way around. The presented > criteria is true for all devices since the bus master might be using regmap > to implements its IO. Any regmap instance that might be used from within > another regmap instance needs a custom lock class. This includes bus masters > as well as resource providers like clock chips or regulators. I would have thought that it is easier to figure out that a regmap is going to access another one, instead of figuring out all possible uses of a regmap... As it stands, I could only see 2 cases where this kind of warning happens (I did not find any other recursive locking warning involving regmaps...): 1. rt5677: The "master" regmap is a "virtual" regmap, that, depending on the device mode (DSP or not), either directly access the register on a physical regmap on i2c bus, or does it indirectly, by doing a number of read/write on that same physical regmap. 2. drivers/media/dvb-frontends/rtl2832.c: That's Antti's case. If I understand correctly, regmap access require transfers on a private i2c bus, which, itself, uses a regmap. I think both cases are _fairly_ clear, but of course that may not cover everything (and I'm not sure if anyone would figure it out before the warning shows up...), and I'm not sure if there are cases that look similar but don't require a lockdep class. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] stop_machine: kill stop_cpus_mutex and stop_cpus_lock
As always, forgot to mention...
Also. We can turn these stop_work_alloc/stop_work_free into the generic
helpers which (I think) can have more users.
On 06/26, Oleg Nesterov wrote:
>
> On 06/25, Peter Zijlstra wrote:
> >
> > On Tue, Jun 23, 2015 at 07:24:16PM +0200, Oleg Nesterov wrote:
> > >
> > > lock_stop_cpus_works(cpumask)
> > > {
> > > for_each_cpu(cpu, cpumask)
> > > mutex_lock(per_cpu(cpu_stopper_task, cpu).work_mutex);
> > > }
> > >
> > > unlock_stop_cpus_works(cpumask)
> > > {
> > > for_each_cpu(cpu, cpumask)
> > > mutex_lock(...);
> > > }
> > >
> > > which should be used instead of stop_cpus_mutex. After this change
> > > stop_two_cpus() can just use stop_cpus().
> >
> > Right, lockdep annotating that will be 'interesting' though.
>
> Sure, and this is too inefficient, this is only to explain what
> I mean.
>
> How about this series? Untested. For review.
>
> > And
> > stop_two_cpus() then has the problem of allocating a cpumask.
>
> Yes, but we can avoid this, see the changelog in 5/6.
>
> > Simpler to
> > let it keep 'abuse' the queueing spinlock in there.
>
> Not sure.
>
> And note that this series kills stop_cpus_mutex, so that multiple
> stop_cpus()'s / stop_machine()'s can run in parallel if cpumask's
> do not overlap.
>
> Note also the changelog in 6/6, we can simplify + optimize this code
> a bit more.
>
> What do you think?
>
> Oleg.
>
> include/linux/lglock.h |5 -
> kernel/locking/lglock.c | 22 -
> kernel/stop_machine.c | 197
> ---
> 3 files changed, 119 insertions(+), 105 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[lkp] [usb] 56aa45adcc5: Fixed: WARNING: at kernel/mutex.c:199 mutex_lock_nested+0x121/0x349()
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 56aa45adcc5b793369e535a4b7177f1c7314b577 ("usb: gadget: make usb
functions to load before gadget driver")
This commit fixed an warning as below:
[8.571726] [ cut here ]
[8.572786] WARNING: at kernel/mutex.c:199 mutex_lock_nested+0x121/0x349()
[8.572786] Hardware name: Standard PC (i440FX + PIIX, 1996)
[8.572786] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1-6-gfe2a429 #884
[8.572786] Call Trace:
[8.572786] [] warn_slowpath_common+0x77/0x91
[8.572786] [] warn_slowpath_null+0x15/0x17
[8.572786] [] mutex_lock_nested+0x121/0x349
[8.572786] [] ? sched_clock+0x9/0xd
[8.572786] [] ? sched_clock_local+0x11/0x78
[8.572786] [] ? gserial_alloc_line+0x2a/0x1c0
[8.572786] [] gserial_alloc_line+0x2a/0x1c0
[8.572786] [] ? gserial_alloc_line+0x2a/0x1c0
[8.572786] [] acm_ms_bind+0x2d/0x7ab
[8.572786] [] ? mutex_unlock+0x9/0xb
[8.572786] [] ? sysfs_addrm_finish+0x16/0x52
[8.572786] [] ? sysfs_add_file_mode+0xa8/0xdc
[8.572786] [] ? sysfs_add_file+0xd/0xf
[8.572786] [] ? sysfs_create_file+0x23/0x25
[8.572786] [] ? device_create_file+0x14/0x16
[8.572786] [] ? composite_dev_prepare+0xb0/0xe9
[8.572786] [] composite_bind+0x9c/0x166
[8.572786] [] ? m66592_probe+0x418/0x418
[8.572786] [] udc_bind_to_driver+0x25/0xa6
[8.572786] [] ? m66592_probe+0x418/0x418
[8.572786] [] usb_gadget_probe_driver+0x75/0x88
[8.572786] [] usb_composite_probe+0x8d/0x8f
[8.572786] [] init+0x10/0x12
[8.572786] [] do_one_initcall+0x7a/0x13d
[8.572786] [] kernel_init_freeable+0x178/0x1fb
[8.572786] [] ? rest_init+0xb7/0xb7
[8.572786] [] kernel_init+0x9/0xd1
[8.572786] [] ret_from_fork+0x7c/0xb0
[8.572786] [] ? rest_init+0xb7/0xb7
[8.572786] ---[ end trace 220a440ac161c663 ]---
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.9.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ALWAYS_USE_PERSISTENT_CLOCK=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XA
[PATCH 3/3] ARM: socfpga: dts: Fix adxl345 compatible string
This patch fixes the compatible string for adxl345 digital accelerometer
after the deprecation of compatible string adxl345x.
Signed-off-by: Walter Lozano
---
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index d343e03..5e17fd1 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -68,7 +68,7 @@
status = "okay";
accel1: accelerometer@53 {
- compatible = "adxl34x";
+ compatible = "adi,adxl345";
reg = <0x53>;
interrupt-parent = <&portc>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: socfpga: dts: Fix entries order
This patch reorders the nodes alphabetically
Signed-off-by: Walter Lozano
---
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 5b60692..d343e03 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -60,15 +60,6 @@
rxc-skew-ps = <2000>;
};
-&mmc0 {
- vmmc-supply = <®ulator_3_3v>;
- vqmmc-supply = <®ulator_3_3v>;
-};
-
-&usb1 {
- status = "okay";
-};
-
&gpio2 {
status = "okay";
};
@@ -84,3 +75,12 @@
interrupts = <3 2>;
};
};
+
+&mmc0 {
+ vmmc-supply = <®ulator_3_3v>;
+ vqmmc-supply = <®ulator_3_3v>;
+};
+
+&usb1 {
+ status = "okay";
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: socfpga: dts: Fix adxl34x formating
This patch fixes the formating of DTS bindings for the adxl34x digital
accelerometer.
Signed-off-by: Walter Lozano
---
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 71468a7..5b60692 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -73,14 +73,14 @@
status = "okay";
};
-&i2c1{
+&i2c1 {
status = "okay";
- accel1: accel1@53{
+ accel1: accelerometer@53 {
compatible = "adxl34x";
reg = <0x53>;
- interrupt-parent = < &portc >;
+ interrupt-parent = <&portc>;
interrupts = <3 2>;
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
On 06/25/2015 07:02 PM, Jan Kiszka wrote:
On 2015-06-24 10:46, Hui Wang wrote:
On 06/24/2015 01:37 PM, Jan Kiszka wrote:
On 2015-05-23 18:22, Jan Kiszka wrote:
On 2015-05-23 18:06, Raymond Yau wrote:
2015-5-23 下午4:50 於 "Jan Kiszka" 寫道：
Most Thinkpad Edge series laptops use conexant codec, so
far
although
Is there anything I can debug or any information I can collect
from my
box to examine this?
What is the linux distribution on your machine? And use
showkey to
catch
the keycode of that button.
I'm running OpenSUSE 13.1. The reported keycode of the power
button is
116.
It seems the keycode is correct, it is power keycode rather
the mute
keycode.
Could you please do some debug, let us find which line of code is
the
root cause for this problem. for example:
after running the line, the problem shows up:
1. if (ACPI_SUCCESS(acpi_get_devices("LEN0068",
acpi_check_cb,
&found, NULL)) && found) // in the
sound/pci/hda/thinkpad_helper.c,
is_thinkpad()
This evaluates to true
2. return ACPI_SUCCESS(acpi_get_devices("IBM0068",
acpi_check_cb,
&found, NULL)) && found; // same as above
3. if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
//in the
sound/pci/hda/thinkpad_helper.c, hda_fixup_thinkpad_acpi()
...and this
4. if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0) { // same as
above
...and this as well. spec->num_adc_nids is 1.
If we change the code like below, does the power button can work
well?
in the thinkpad_helper.c, hda_fixup_thinkpad_acpi()
if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
/*
old_vmaster_hook = spec->vmaster_mute.hook;
spec->vmaster_mute.hook = update_tpacpi_mute_led;
removefunc = false;
*/
Disabling only this block resolves the issue.
So Below two lines make the power button change to the reset button.
drivers/platform/x86/thinkpad_acpi.c mute_led_on_off():
acpi_get_handle(hkey_handle, "SSMS", &temp);
acpi_evalf(hkey_handle, &output, "SSMS", "dd", 1);
@alexhung,
Do you have any idea why this can affect the power button behavior?
I think we all lost track of this issue, but it unfortunately still
exists in the latest kernel, requiring custom builds here. How can we
proceed?
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-May/091561.html
If you cannot find "SSMS" in your T520 ACPI dump, this mean mute LED
cannot be turn on/off similar to T510
There is an entry (see attached disassembly), but this device has at
least no physical LED to drive.
Some hotkey leds are embedded on button. Through the pictures I found
on the internet (thinkpad t520), it looks like there is a led at the
center of the mute button.
Again, I'm on a X121e, and that has only a single physical LED for
signaling the power state. The mute button is behind key combination of
the keyboard.
Jan
There is no reason to change a power button to a reset button after
accessing the acpi device "SSMS", the "SSMS" is for the mute led instead
of the power management.
I think it is better you login to the lenovo website and look for the
latest BIOS image, then upgrade the BIOS on your machine to see if it
can solve the problem or not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 16/17] libnvdimm: Add sysfs numa_node to NVDIMM devices
On Thu, 2015-06-25 at 05:37 -0400, Dan Williams wrote: > From: Toshi Kani > > Add support of sysfs 'numa_node' to I/O-related NVDIMM devices > under /sys/bus/nd/devices, regionN, namespaceN.0, and bttN. > When bttN is not set up, its numa_node returns -1 (NUMA_NO_NODE). > > An example of numa_node values on a 2-socket system with a single > NVDIMM range on each socket is shown below. > /sys/bus/nd/devices > |-- btt0/numa_node:-1 > |-- btt1/numa_node:0 > |-- namespace0.0/numa_node:0 > |-- namespace1.0/numa_node:1 > |-- region0/numa_node:0 > |-- region1/numa_node:1 > > These numa_node files are then linked under the block class of > their device names. > /sys/class/block/pmem0/device/numa_node:0 > /sys/class/block/pmem0s/device/numa_node:0 > /sys/class/block/pmem1/device/numa_node:1 > > This enables numactl(8) to accept 'block:' and 'file:' paths of > pmem and btt devices as shown in the examples below. > numactl --preferred block:pmem0 --show > numactl --preferred file:/dev/pmem0s --show > > Signed-off-by: Toshi Kani > Signed-off-by: Dan Williams Can you please update the commit log with the following? It reflects the changes in sysfs btt files. Thanks, -Toshi = From: Toshi Kani Add support of sysfs 'numa_node' to I/O-related NVDIMM devices under /sys/bus/nd/devices, regionN, namespaceN.0, and bttN.x. An example of numa_node values on a 2-socket system with a single NVDIMM range on each socket is shown below. /sys/bus/nd/devices |-- btt0.0/numa_node:0 |-- btt1.0/numa_node:1 |-- btt1.1/numa_node:1 |-- namespace0.0/numa_node:0 |-- namespace1.0/numa_node:1 |-- region0/numa_node:0 |-- region1/numa_node:1 These numa_node files are then linked under the block class of their device names. /sys/class/block/pmem0/device/numa_node:0 /sys/class/block/pmem1s/device/numa_node:1 This enables numactl(8) to accept 'block:' and 'file:' paths of pmem and btt devices as shown in the examples below. numactl --preferred block:pmem0 --show numactl --preferred file:/dev/pmem1s --show Signed-off-by: Toshi Kani Signed-off-by: Dan Williams -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] ext4 changes for 4.2-rc1
[ I renamed "ext4_follow_link()" to "ext4_encrypted_follow_link()" in the merge resolution, to make it clear that that function is _only_ used for encrypted symlinks. The function doesn't actually work for non-encrypted symlinks at all, and they use the generic helpers - Linus ] Thanks, that was on my todo list as a cleanup patch after the merge window closed... :-) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 5/6] stop_machine: change stop_two_cpus() just use stop_cpu(), kill lg_double_lock/unlock
Now that stop_cpus() is not "exclusive" if cpumask's don't overlap, we
can turn stop_two_cpus() into a trivial wrapper on top of stop_cpus().
Note: if zalloc_cpumask_var(cpumask, GFP_KERNEL) is not an option, we
can reimplement this function using stop_work_{alloc,free}_one().
Signed-off-by: Oleg Nesterov
---
include/linux/lglock.h |5 ---
kernel/locking/lglock.c | 22
kernel/stop_machine.c | 64 --
3 files changed, 11 insertions(+), 80 deletions(-)
diff --git a/include/linux/lglock.h b/include/linux/lglock.h
index c92ebd1..0081f00 100644
--- a/include/linux/lglock.h
+++ b/include/linux/lglock.h
@@ -52,15 +52,10 @@ struct lglock {
static struct lglock name = { .lock = &name ## _lock }
void lg_lock_init(struct lglock *lg, char *name);
-
void lg_local_lock(struct lglock *lg);
void lg_local_unlock(struct lglock *lg);
void lg_local_lock_cpu(struct lglock *lg, int cpu);
void lg_local_unlock_cpu(struct lglock *lg, int cpu);
-
-void lg_double_lock(struct lglock *lg, int cpu1, int cpu2);
-void lg_double_unlock(struct lglock *lg, int cpu1, int cpu2);
-
void lg_global_lock(struct lglock *lg);
void lg_global_unlock(struct lglock *lg);
diff --git a/kernel/locking/lglock.c b/kernel/locking/lglock.c
index 951cfcd..86ae2ae 100644
--- a/kernel/locking/lglock.c
+++ b/kernel/locking/lglock.c
@@ -60,28 +60,6 @@ void lg_local_unlock_cpu(struct lglock *lg, int cpu)
}
EXPORT_SYMBOL(lg_local_unlock_cpu);
-void lg_double_lock(struct lglock *lg, int cpu1, int cpu2)
-{
- BUG_ON(cpu1 == cpu2);
-
- /* lock in cpu order, just like lg_global_lock */
- if (cpu2 < cpu1)
- swap(cpu1, cpu2);
-
- preempt_disable();
- lock_acquire_shared(&lg->lock_dep_map, 0, 0, NULL, _RET_IP_);
- arch_spin_lock(per_cpu_ptr(lg->lock, cpu1));
- arch_spin_lock(per_cpu_ptr(lg->lock, cpu2));
-}
-
-void lg_double_unlock(struct lglock *lg, int cpu1, int cpu2)
-{
- lock_release(&lg->lock_dep_map, 1, _RET_IP_);
- arch_spin_unlock(per_cpu_ptr(lg->lock, cpu1));
- arch_spin_unlock(per_cpu_ptr(lg->lock, cpu2));
- preempt_enable();
-}
-
void lg_global_lock(struct lglock *lg)
{
int i;
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 4b23875..572abc9 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
/*
* Structure to determine completion condition and record errors. May
@@ -97,14 +96,6 @@ static bool stop_work_alloc(const struct cpumask *cpumask,
bool wait)
return true;
}
-/*
- * Avoids a race between stop_two_cpus and global stop_cpus, where
- * the stoppers could get queued up in reverse order, leading to
- * system deadlock. Using an lglock means stop_two_cpus remains
- * relatively cheap.
- */
-DEFINE_STATIC_LGLOCK(stop_cpus_lock);
-
static void cpu_stop_init_done(struct cpu_stop_done *done, unsigned int
nr_todo)
{
memset(done, 0, sizeof(*done));
@@ -276,50 +267,17 @@ static int multi_cpu_stop(void *data)
*/
int stop_two_cpus(unsigned int cpu1, unsigned int cpu2, cpu_stop_fn_t fn, void
*arg)
{
- struct cpu_stop_done done;
- struct cpu_stop_work work1, work2;
- struct multi_stop_data msdata;
-
- preempt_disable();
- msdata = (struct multi_stop_data){
- .fn = fn,
- .data = arg,
- .num_threads = 2,
- .active_cpus = cpumask_of(cpu1),
- };
-
- work1 = work2 = (struct cpu_stop_work){
- .fn = multi_cpu_stop,
- .arg = &msdata,
- .done = &done
- };
-
- cpu_stop_init_done(&done, 2);
- set_state(&msdata, MULTI_STOP_PREPARE);
-
- /*
-* If we observe both CPUs active we know _cpu_down() cannot yet have
-* queued its stop_machine works and therefore ours will get executed
-* first. Or its not either one of our CPUs that's getting unplugged,
-* in which case we don't care.
-*
-* This relies on the stopper workqueues to be FIFO.
-*/
- if (!cpu_active(cpu1) || !cpu_active(cpu2)) {
- preempt_enable();
- return -ENOENT;
- }
-
- lg_double_lock(&stop_cpus_lock, cpu1, cpu2);
- cpu_stop_queue_work(cpu1, &work1);
- cpu_stop_queue_work(cpu2, &work2);
- lg_double_unlock(&stop_cpus_lock, cpu1, cpu2);
-
- preempt_enable();
+ cpumask_var_t cpumask;
+ int ret;
- wait_for_completion(&done.completion);
+ if (!zalloc_cpumask_var(&cpumask, GFP_KERNEL))
+ return -ENOMEM;
- return done.executed ? done.ret : -ENOENT;
+ cpumask_set_cpu(cpu1, cpumask);
+ cpumask_set_cpu(cpu2, cpumask);
+ ret = stop_cpus(cpumask, fn, arg);
+ free_cpumask_var(cpumask);
+ return ret;
}
/**
@@ -355,7 +313,7 @@ static void queue_stop_cpus_work(const struc
[RFC PATCH 6/6] stop_machine: optimize stop_work_alloc()
wait_event()/wake_up_all() in stop_work_alloc/stop_work_free logic
is very suboptimal because of non-exclusive wakeups. So we add the
wait_queue_func_t alloc_wake() helper which wakes the waiter up only
a) if it actually waits for a stop_work in the "freed" cpumask, and
b) only after we already set ->stop_owner = waiter.
So if 2 stop_machine()'s race with each other, the loser will likely
call schedule() only once and we will have a single wakeup.
TODO: we can optimize (and simplify!) this code more. We can remove
stop_work_alloc_one() and fold it into stop_work_alloc(), so that
prepare_to_wait() will be the outer loop. Lets do this later.
TODO: the init_waitqueue_func_entry() code in stop_work_alloc_one()
is really annoying, we need the trivial new __init_wait(wait, func)
helper.
Signed-off-by: Oleg Nesterov
---
kernel/stop_machine.c | 47 +++
1 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 572abc9..bbfc670 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -63,21 +63,60 @@ static void stop_work_free(const struct cpumask *cpumask)
for_each_cpu(cpu, cpumask)
stop_work_free_one(cpu);
- wake_up_all(&stop_work_wq);
+ __wake_up(&stop_work_wq, TASK_ALL, 0, (void *)cpumask);
+}
+
+struct alloc_wait {
+ wait_queue_twait;
+ int cpu;
+};
+
+static int alloc_wake(wait_queue_t *wait, unsigned int mode, int sync, void
*key)
+{
+ struct alloc_wait *aw = container_of(wait, struct alloc_wait, wait);
+ struct cpu_stopper *stopper = &per_cpu(cpu_stopper, aw->cpu);
+ const struct cpumask *cpumask = key;
+
+ if (!cpumask_test_cpu(aw->cpu, cpumask))
+ return 0;
+ if (cmpxchg(&stopper->stop_owner, NULL, aw->wait.private) != NULL)
+ return 0;
+
+ return autoremove_wake_function(wait, mode, sync, key);
}
static struct cpu_stop_work *stop_work_alloc_one(int cpu, bool wait)
{
struct cpu_stopper *stopper = &per_cpu(cpu_stopper, cpu);
+ struct task_struct *me = current;
+ struct alloc_wait aw;
- if (cmpxchg(&stopper->stop_owner, NULL, current) == NULL)
+ if (cmpxchg(&stopper->stop_owner, NULL, me) == NULL)
goto done;
if (!wait)
return NULL;
- __wait_event(stop_work_wq,
- cmpxchg(&stopper->stop_owner, NULL, current) == NULL);
+ /* TODO: add __init_wait(wait, func) helper! */
+ INIT_LIST_HEAD(&aw.wait.task_list);
+ init_waitqueue_func_entry(&aw.wait, alloc_wake);
+ aw.wait.private = me;
+ aw.cpu = cpu;
+ for (;;) {
+ prepare_to_wait(&stop_work_wq, &aw.wait, TASK_UNINTERRUPTIBLE);
+ /*
+* This can "falsely" fail if we race with alloc_wake() and
+* stopper->stop_owner is already me, in this case schedule()
+* won't block and the check below will notice this change.
+*/
+ if (cmpxchg(&stopper->stop_owner, NULL, me) == NULL)
+ break;
+
+ schedule();
+ if (likely(stopper->stop_owner == me))
+ break;
+ }
+ finish_wait(&stop_work_wq, &aw.wait);
done:
return &stopper->stop_work;
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/6] stop_machine: introduce stop_work_alloc() and stop_work_free()
A separate and intentionally suboptimal patch to simplify the review of
this and the next changes.
And the new helpers, stop_work_alloc(cpumask) and stop_work_free(cpumask),
should be called if the caller is going to use cpu_stopper->stop_work's.
Note that 2 callers can never deadlock even if their cpumask's overlap,
they always "lock" cpu_stopper->stop_owner's in the same order as if we
had another per-cpu mutex.
This is obviously greatly inefficient, this will be fixed later.
Signed-off-by: Oleg Nesterov
---
kernel/stop_machine.c | 50 +
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 6212208..3d5d810 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -42,11 +42,61 @@ struct cpu_stopper {
struct list_headworks; /* list of pending works */
struct cpu_stop_workstop_work; /* for stop_cpus */
+ struct task_struct *stop_owner;
};
static DEFINE_PER_CPU(struct cpu_stopper, cpu_stopper);
static bool stop_machine_initialized = false;
+static DECLARE_WAIT_QUEUE_HEAD(stop_work_wq);
+
+static void stop_work_free_one(int cpu)
+{
+ struct cpu_stopper *stopper = &per_cpu(cpu_stopper, cpu);
+ /* Can be NULL if stop_work_alloc(wait => false) fails */
+ if (likely(stopper->stop_owner == current))
+ stopper->stop_owner = NULL;
+}
+
+static void stop_work_free(const struct cpumask *cpumask)
+{
+ int cpu;
+
+ for_each_cpu(cpu, cpumask)
+ stop_work_free_one(cpu);
+ wake_up_all(&stop_work_wq);
+}
+
+static struct cpu_stop_work *stop_work_alloc_one(int cpu, bool wait)
+{
+ struct cpu_stopper *stopper = &per_cpu(cpu_stopper, cpu);
+
+ if (cmpxchg(&stopper->stop_owner, NULL, current) == NULL)
+ goto done;
+
+ if (!wait)
+ return NULL;
+
+ __wait_event(stop_work_wq,
+ cmpxchg(&stopper->stop_owner, NULL, current) == NULL);
+done:
+ return &stopper->stop_work;
+}
+
+static bool stop_work_alloc(const struct cpumask *cpumask, bool wait)
+{
+ int cpu;
+
+ for_each_cpu(cpu, cpumask) {
+ if (stop_work_alloc_one(cpu, wait))
+ continue;
+ stop_work_free(cpumask);
+ return false;
+ }
+
+ return true;
+}
+
/*
* Avoids a race between stop_two_cpus and global stop_cpus, where
* the stoppers could get queued up in reverse order, leading to
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 4/6] stop_machine: kill stop_cpus_mutex
Change the users of stop_cpus_mutex to rely on stop_work_alloc() and
stop_work_free(). This means that 2 stop_cpus() can run in parallel
as long a their cpumask's do not overlap.
Signed-off-by: Oleg Nesterov
---
kernel/stop_machine.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 3d5d810..4b23875 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -343,9 +343,6 @@ void stop_one_cpu_nowait(unsigned int cpu, cpu_stop_fn_t
fn, void *arg,
cpu_stop_queue_work(cpu, work_buf);
}
-/* static data for stop_cpus */
-static DEFINE_MUTEX(stop_cpus_mutex);
-
static void queue_stop_cpus_work(const struct cpumask *cpumask,
cpu_stop_fn_t fn, void *arg,
struct cpu_stop_done *done)
@@ -412,10 +409,9 @@ int stop_cpus(const struct cpumask *cpumask, cpu_stop_fn_t
fn, void *arg)
{
int ret;
- /* static works are used, process one request at a time */
- mutex_lock(&stop_cpus_mutex);
+ stop_work_alloc(cpumask, true);
ret = __stop_cpus(cpumask, fn, arg);
- mutex_unlock(&stop_cpus_mutex);
+ stop_work_free(cpumask);
return ret;
}
@@ -442,10 +438,10 @@ int try_stop_cpus(const struct cpumask *cpumask,
cpu_stop_fn_t fn, void *arg)
int ret;
/* static works are used, process one request at a time */
- if (!mutex_trylock(&stop_cpus_mutex))
+ if (!stop_work_alloc(cpumask, false))
return -EAGAIN;
ret = __stop_cpus(cpumask, fn, arg);
- mutex_unlock(&stop_cpus_mutex);
+ stop_work_free(cpumask);
return ret;
}
@@ -643,7 +639,7 @@ int stop_machine_from_inactive_cpu(int (*fn)(void *), void
*data,
msdata.num_threads = num_active_cpus() + 1; /* +1 for local */
/* No proper task established and can't sleep - busy wait for lock. */
- while (!mutex_trylock(&stop_cpus_mutex))
+ while (!stop_work_alloc(cpus, false))
cpu_relax();
/* Schedule work on other CPUs and execute directly for local CPU */
@@ -656,8 +652,8 @@ int stop_machine_from_inactive_cpu(int (*fn)(void *), void
*data,
/* Busy wait for completion. */
while (!completion_done(&done.completion))
cpu_relax();
+ stop_work_free(cpus);
- mutex_unlock(&stop_cpus_mutex);
return ret ?: done.ret;
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/6] stop_machine: don't do for_each_cpu() twice in queue_stop_cpus_work()
queue_stop_cpus_work() can do everything in one for_each_cpu() loop.
This simplifies this code a bit, and this is also preparation for the
locking changes.
Signed-off-by: Oleg Nesterov
---
kernel/stop_machine.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 6e677b0..6212208 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -303,22 +303,19 @@ static void queue_stop_cpus_work(const struct cpumask
*cpumask,
struct cpu_stop_work *work;
unsigned int cpu;
- /* initialize works and done */
- for_each_cpu(cpu, cpumask) {
- work = &per_cpu(cpu_stopper.stop_work, cpu);
- work->fn = fn;
- work->arg = arg;
- work->done = done;
- }
-
/*
* Disable preemption while queueing to avoid getting
* preempted by a stopper which might wait for other stoppers
* to enter @fn which can lead to deadlock.
*/
lg_global_lock(&stop_cpus_lock);
- for_each_cpu(cpu, cpumask)
- cpu_stop_queue_work(cpu, &per_cpu(cpu_stopper.stop_work, cpu));
+ for_each_cpu(cpu, cpumask) {
+ work = &per_cpu(cpu_stopper.stop_work, cpu);
+ work->fn = fn;
+ work->arg = arg;
+ work->done = done;
+ cpu_stop_queue_work(cpu, work);
+ }
lg_global_unlock(&stop_cpus_lock);
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/6] stop_machine: move cpu_stopper_task and stop_cpus_work into struct cpu_stopper
Multpiple DEFINE_PER_CPU's do not make sense, move all the per-cpu
variables into struct cpu_stopper.
Signed-off-by: Oleg Nesterov
---
kernel/stop_machine.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index fd643d8..6e677b0 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -35,13 +35,16 @@ struct cpu_stop_done {
/* the actual stopper, one per every possible cpu, enabled on online cpus */
struct cpu_stopper {
+ struct task_struct *thread;
+
spinlock_t lock;
boolenabled;/* is this stopper enabled? */
struct list_headworks; /* list of pending works */
+
+ struct cpu_stop_workstop_work; /* for stop_cpus */
};
static DEFINE_PER_CPU(struct cpu_stopper, cpu_stopper);
-static DEFINE_PER_CPU(struct task_struct *, cpu_stopper_task);
static bool stop_machine_initialized = false;
/*
@@ -74,7 +77,6 @@ static void cpu_stop_signal_done(struct cpu_stop_done *done,
bool executed)
static void cpu_stop_queue_work(unsigned int cpu, struct cpu_stop_work *work)
{
struct cpu_stopper *stopper = &per_cpu(cpu_stopper, cpu);
- struct task_struct *p = per_cpu(cpu_stopper_task, cpu);
unsigned long flags;
@@ -82,7 +84,7 @@ static void cpu_stop_queue_work(unsigned int cpu, struct
cpu_stop_work *work)
if (stopper->enabled) {
list_add_tail(&work->list, &stopper->works);
- wake_up_process(p);
+ wake_up_process(stopper->thread);
} else
cpu_stop_signal_done(work->done, false);
@@ -293,7 +295,6 @@ void stop_one_cpu_nowait(unsigned int cpu, cpu_stop_fn_t
fn, void *arg,
/* static data for stop_cpus */
static DEFINE_MUTEX(stop_cpus_mutex);
-static DEFINE_PER_CPU(struct cpu_stop_work, stop_cpus_work);
static void queue_stop_cpus_work(const struct cpumask *cpumask,
cpu_stop_fn_t fn, void *arg,
@@ -304,7 +305,7 @@ static void queue_stop_cpus_work(const struct cpumask
*cpumask,
/* initialize works and done */
for_each_cpu(cpu, cpumask) {
- work = &per_cpu(stop_cpus_work, cpu);
+ work = &per_cpu(cpu_stopper.stop_work, cpu);
work->fn = fn;
work->arg = arg;
work->done = done;
@@ -317,7 +318,7 @@ static void queue_stop_cpus_work(const struct cpumask
*cpumask,
*/
lg_global_lock(&stop_cpus_lock);
for_each_cpu(cpu, cpumask)
- cpu_stop_queue_work(cpu, &per_cpu(stop_cpus_work, cpu));
+ cpu_stop_queue_work(cpu, &per_cpu(cpu_stopper.stop_work, cpu));
lg_global_unlock(&stop_cpus_lock);
}
@@ -458,7 +459,7 @@ extern void sched_set_stop_task(int cpu, struct task_struct
*stop);
static void cpu_stop_create(unsigned int cpu)
{
- sched_set_stop_task(cpu, per_cpu(cpu_stopper_task, cpu));
+ sched_set_stop_task(cpu, per_cpu(cpu_stopper.thread, cpu));
}
static void cpu_stop_park(unsigned int cpu)
@@ -485,7 +486,7 @@ static void cpu_stop_unpark(unsigned int cpu)
}
static struct smp_hotplug_thread cpu_stop_threads = {
- .store = &cpu_stopper_task,
+ .store = &cpu_stopper.thread,
.thread_should_run = cpu_stop_should_run,
.thread_fn = cpu_stopper_thread,
.thread_comm= "migration/%u",
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/6] stop_machine: kill stop_cpus_mutex and stop_cpus_lock
On 06/25, Peter Zijlstra wrote:
>
> On Tue, Jun 23, 2015 at 07:24:16PM +0200, Oleg Nesterov wrote:
> >
> > lock_stop_cpus_works(cpumask)
> > {
> > for_each_cpu(cpu, cpumask)
> > mutex_lock(per_cpu(cpu_stopper_task, cpu).work_mutex);
> > }
> >
> > unlock_stop_cpus_works(cpumask)
> > {
> > for_each_cpu(cpu, cpumask)
> > mutex_lock(...);
> > }
> >
> > which should be used instead of stop_cpus_mutex. After this change
> > stop_two_cpus() can just use stop_cpus().
>
> Right, lockdep annotating that will be 'interesting' though.
Sure, and this is too inefficient, this is only to explain what
I mean.
How about this series? Untested. For review.
> And
> stop_two_cpus() then has the problem of allocating a cpumask.
Yes, but we can avoid this, see the changelog in 5/6.
> Simpler to
> let it keep 'abuse' the queueing spinlock in there.
Not sure.
And note that this series kills stop_cpus_mutex, so that multiple
stop_cpus()'s / stop_machine()'s can run in parallel if cpumask's
do not overlap.
Note also the changelog in 6/6, we can simplify + optimize this code
a bit more.
What do you think?
Oleg.
include/linux/lglock.h |5 -
kernel/locking/lglock.c | 22 -
kernel/stop_machine.c | 197 ---
3 files changed, 119 insertions(+), 105 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/10] redesign compaction algorithm
2015-06-26 3:56 GMT+09:00 Vlastimil Babka : > On 25.6.2015 20:14, Joonsoo Kim wrote: >>> The long-term success rate of fragmentation avoidance depends on >>> > minimsing the number of UNMOVABLE allocation requests that use a >>> > pageblock belonging to another migratetype. Once such a fallback occurs, >>> > that pageblock potentially can never be used for a THP allocation again. >>> > >>> > Lets say there is an unmovable pageblock with 500 free pages in it. If >>> > the freepage scanner uses that pageblock and allocates all 500 free >>> > pages then the next unmovable allocation request needs a new pageblock. >>> > If one is not completely free then it will fallback to using a >>> > RECLAIMABLE or MOVABLE pageblock forever contaminating it. >> Yes, I can imagine that situation. But, as I said above, we already use >> non-movable pageblock for migration scanner. While unmovable >> pageblock with 500 free pages fills, some other unmovable pageblock >> with some movable pages will be emptied. Number of freepage >> on non-movable would be maintained so fallback doesn't happen. > > There's nothing that guarantees that the migration scanner will be emptying > unmovable pageblock, or am I missing something? As replied to Mel's comment, as number of unmovable pageblocks, which is filled by movable pages due to this compaction change increases, possible candidate reclaimable/migratable pages from them also increase. So, at some time, amount of used page by free scanner and amount of migrated page by migration scanner would be balanced. > Worse, those pageblocks would be > marked to skip by the free scanner if it isolated free pages from them, so > migration scanner would skip them. Yes, but, next iteration will move out movable pages from that pageblock and freed pages will be used for further unmovable allocation. So, in the long term, this doesn't make much more fragmentation. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/10] redesign compaction algorithm
2015-06-26 3:41 GMT+09:00 Mel Gorman : > On Fri, Jun 26, 2015 at 03:14:39AM +0900, Joonsoo Kim wrote: >> > It could though. Reclaim/compaction is entered for orders higher than >> > PAGE_ALLOC_COSTLY_ORDER and when scan priority is sufficiently high. >> > That could be adjusted if you have a viable case where orders < >> > PAGE_ALLOC_COSTLY_ORDER must succeed and currently requires excessive >> > reclaim instead of relying on compaction. >> >> Yes. I saw this problem in real situation. In ARM, order-2 allocation >> is requested >> in fork(), so it should be succeed. But, there is not enough order-2 >> freepage, >> so reclaim/compaction begins. Compaction fails repeatedly although >> I didn't check exact reason. > > That should be identified and repaired prior to reimplementing > compaction because it's important. Unfortunately, I got report a long time ago and I don't have any real environment to reproduce it. What I have remembered is that there are too many unmovable allocations from graphic driver and zram and they really makes fragmented memory. In that time, problem is solved by ad-hoc approach such as killing many apps. But, it's sub-optimal and loosing performance greatly so I imitate this effect in my benchmark and try to solve it by this patchset. >> >> >> 3) Compaction capability is highly depends on migratetype of memory, >> >> >> because freepage scanner doesn't scan unmovable pageblock. >> >> >> >> >> > >> >> > For a very good reason. Unmovable allocation requests that fallback to >> >> > other pageblocks are the worst in terms of fragmentation avoidance. The >> >> > more of these events there are, the more the system will decay. If there >> >> > are many of these events then a compaction benchmark may start with high >> >> > success rates but decay over time. >> >> > >> >> > Very broadly speaking, the more the mm_page_alloc_extfrag tracepoint >> >> > triggers with alloc_migratetype == MIGRATE_UNMOVABLE, the faster the >> >> > system is decaying. Having the freepage scanner select unmovable >> >> > pageblocks will trigger this event more frequently. >> >> > >> >> > The unfortunate impact is that selecting unmovable blocks from the free >> >> > csanner will improve compaction success rates for high-order kernel >> >> > allocations early in the lifetime of the system but later fail >> >> > high-order >> >> > allocation requests as more pageblocks get converted to unmovable. It >> >> > might be ok for kernel allocations but THP will eventually have a 100% >> >> > failure rate. >> >> >> >> I wrote rationale in the patch itself. We already use non-movable >> >> pageblock >> >> for migration scanner. It empties non-movable pageblock so number of >> >> freepage on non-movable pageblock will increase. Using non-movable >> >> pageblock for freepage scanner negates this effect so number of freepage >> >> on non-movable pageblock will be balanced. Could you tell me in detail >> >> how freepage scanner select unmovable pageblocks will cause >> >> more fragmentation? Possibly, I don't understand effect of this patch >> >> correctly and need some investigation. :) >> >> >> > >> > The long-term success rate of fragmentation avoidance depends on >> > minimsing the number of UNMOVABLE allocation requests that use a >> > pageblock belonging to another migratetype. Once such a fallback occurs, >> > that pageblock potentially can never be used for a THP allocation again. >> > >> > Lets say there is an unmovable pageblock with 500 free pages in it. If >> > the freepage scanner uses that pageblock and allocates all 500 free >> > pages then the next unmovable allocation request needs a new pageblock. >> > If one is not completely free then it will fallback to using a >> > RECLAIMABLE or MOVABLE pageblock forever contaminating it. >> >> Yes, I can imagine that situation. But, as I said above, we already use >> non-movable pageblock for migration scanner. While unmovable >> pageblock with 500 free pages fills, some other unmovable pageblock >> with some movable pages will be emptied. Number of freepage >> on non-movable would be maintained so fallback doesn't happen. >> >> Anyway, it is better to investigate this effect. I will do it and attach >> result on next submission. >> > > Lets say we have X unmovable pageblocks and Y pageblocks overall. If the > migration scanner takes movable pages from X then there is more space for > unmovable allocations without having to increase X -- this is good. If > the free scanner uses the X pageblocks as targets then they can fill. The > next unmovable allocation then falls back to another pageblock and we > either have X+1 unmovable pageblocks (full steal) or a mixed pageblock > (partial steal) that cannot be used for THP. Do this enough times and > X == Y and all THP allocations fail. This was similar with my understanding but different conclusion. As number of unmovable pageblocks, X, which is filled by movable pages due to this compaction change increases, reclaimed/mig
Re: [RFC PATCH 0/3] restartable sequences: fast user-space percpu critical sections
On Thu, Jun 25, 2015 at 6:15 PM, Mathieu Desnoyers wrote: > - On Jun 24, 2015, at 10:54 PM, Paul Turner p...@google.com wrote: > >> On Wed, Jun 24, 2015 at 5:07 PM, Andy Lutomirski wrote: >>> On Wed, Jun 24, 2015 at 3:26 PM, Paul Turner wrote: This is a fairly small series demonstrating a feature we've found to be quite powerful in practice, "restartable sequences". >>> >>> On an extremely short glance, I'm starting to think that the right >>> approach, at least for x86, is to implement per-cpu gsbase. Then you >>> could do cmpxchg with a gs prefix to atomically take a percpu lock and >>> atomically release a percpu lock and check whether someone else stole >>> the lock from you. (Note: cmpxchg, unlike lock cmpxchg, is very >>> fast.) >>> >>> This is totally useless for other architectures, but I think it would >>> be reasonable clean on x86. Thoughts? >> >> So this gives semantics that are obviously similar to this_cpu(). >> This provides allows reasonable per-cpu counters (which is alone >> almost sufficient for a strong user-space RCU implementation giving >> this some legs). >> >> However, unless there's a nice implementation trick I'm missing, the >> thing that stands out to me for locks (or other primitives) is that >> this forces a two-phase commit. There's no way (short of say, >> cmpxchg16b) to perform a write conditional on the lock not having been >> stolen from us (and subsequently release the lock). >> >> e.g. >> 1) We take the operation in some sort of speculative mode, that >> another thread on the same cpu is stilled allowed to steal from us >> 2) We prepare what we want to commit >> 3) At this point we have to promote the lock taken in (1) to perform >> our actual commit, or see that someone else has stolen (1) >> 4) Release the promoted lock in (3) >> >> However, this means that if we're preempted at (3) then no other >> thread on that cpu can make progress until we've been rescheduled and >> released the lock; a nice property of the model we have today is that >> threads sharing a cpu can not impede each other beyond what the >> scheduler allows. >> >> A lesser concern, but worth mentioning, is that there are also >> potential pitfalls in the interaction with signal handlers, >> particularly if a 2-phase commit is used. > > Assuming we have a gs segment we can use to address per-cpu locks > in userspace, would the following scheme take care of some of your > concerns ? > > per-cpu int32_t: each lock initialized to "cpu_nr" value > > per-cpu lock: > get current cpu number. Remember this value as "CPU lock nr". > use cmpxchg on gs:lock to grab the lock. > - Expect old value to be "CPU lock nr". > - Update with a lock flag in most significant bit, "CPU lock nr" > in lower bits. > - Retry if fails. Can be caused by migration or lock being already > held. So this is equivalent to just taking the lock in a non-speculative mode (e.g. non-stealable) from the start. The challenge remains exactly the same, as soon as an exclusive mode exists you have some 'critical' critical inner section about the commit, which impedes the progress of other threads if interrupted. [The only reason you'd take the lock in any sort of speculative mode above would be to reduce the length of this.] I definitely agree that this gets us locks and counters, there's lots of good things we can do with those and those alone may be sufficient to implement it this way but I feel there is a lot of power compared to what can be done with full lockless semantics that this leaves on the table. As a concrete example, consider what this does to the complexity and usefulness of Pop(). > > per-cpu unlock: > clear lock flag within the "CPU lock nr" lock. > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] RTC for 4.2
On Thu, Jun 25, 2015 at 12:16 PM, Alexandre Belloni wrote: > > Here is the pull-request for the RTC susbsystem for 4.2. This is my > first pull-request to you, don't hesitate to tell me if I need to adjust > something. Looks fine, but: > Conflicts: >drivers/rtc/Makefile > > Trivial add/add conflicts with the mfd tree, solved in linux-next > Resolution: take both sides. That's not the resolution I took - the re-sorting of the file made for more complex. Can you check my resolution? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec_load(2) bypasses signature verification
On 06/25/15 at 11:59am, Vivek Goyal wrote: > On Thu, Jun 25, 2015 at 04:48:18PM +0800, Dave Young wrote: > > On 06/19/15 at 09:09am, Vivek Goyal wrote: > > > On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote: > > > > > > If we want to disable unsigned kernel loading at compile time, then > > > > > > we > > > > > > really need to work on decoupling CONFIG_KEXEC and > > > > > > CONFIG_FILE_KEXEC. > > > > > > Introducing another config option is not the way forward, IMHO. > > > > > > > > > > Yes, let's do it in this way since everyone is fine with it. > > > > > > > > I will work on a patch if nobody else have interest or no time on it. > > > > > > Thanks Dave. Will be good if you can get this done. > > > > Vivek, I worked out some draft patches here: > > https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup > > > > Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option > > then split kexec_load code from general code. > > > > There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC > > can be disabled so I changed all kernel general and x86 #ifdef to use > > CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef > > I did not change anything other than the new Kconfig option. It will works > > because only x86 support KEXEC_FILE. > > > > Please take a look if you have time, if this is not what you want please let > > me know. > > > > I will have no time this week, only did building test, will do more test > > next > > week, if everything is ok I can send out the patches to list for review. > > Hi Dave, > > I have put few comments in github. Please have a look. Once you have > another version of patches, I will have another look. Vivek, thanks a lot. Will have a look. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 10/12] mm: add the buddy system interface
On 2015/6/26 7:54, Kamezawa Hiroyuki wrote:
> On 2015/06/25 18:44, Xishi Qiu wrote:
>> On 2015/6/10 11:06, Kamezawa Hiroyuki wrote:
>>
>>> On 2015/06/09 19:04, Xishi Qiu wrote:
On 2015/6/9 15:12, Kamezawa Hiroyuki wrote:
> On 2015/06/04 22:04, Xishi Qiu wrote:
>> Add the buddy system interface for address range mirroring feature.
>> Allocate mirrored pages in MIGRATE_MIRROR list. If there is no mirrored
>> pages
>> left, use other types pages.
>>
>> Signed-off-by: Xishi Qiu
>> ---
>> mm/page_alloc.c | 40 +++-
>> 1 file changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index d4d2066..0fb55288 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -599,6 +599,26 @@ static inline bool is_mirror_pfn(unsigned long pfn)
>>
>> return false;
>> }
>> +
>> +static inline bool change_to_mirror(gfp_t gfp_flags, int high_zoneidx)
>> +{
>> +/*
>> + * Do not alloc mirrored memory below 4G, because 0-4G is
>> + * all mirrored by default, and the list is always empty.
>> + */
>> +if (high_zoneidx < ZONE_NORMAL)
>> +return false;
>> +
>> +/* Alloc mirrored memory for only kernel */
>> +if (gfp_flags & __GFP_MIRROR)
>> +return true;
>
> GFP_KERNEL itself should imply mirror, I think.
>
Hi Kame,
How about like this: #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS
| __GFP_MIRROR) ?
>>>
>>> Hm it cannot cover GFP_ATOMIC at el.
>>>
>>> I guess, mirrored memory should be allocated if !__GFP_HIGHMEM or
>>> !__GFP_MOVABLE
>>
>>
>> Hi Kame,
>>
>> Can we distinguish allocations form user or kernel only by GFP flags?
>>
>
> Allocation from user and file caches are now *always* done with __GFP_MOVABLE.
>
> By this, pages will be allocated from MIGRATE_MOVABLE migration type.
> MOVABLE migration type means it's can
> be the target for page compaction or memory-hot-remove.
>
> Thanks,
> -Kame
>
So if we want all kernel memory allocated from mirror, how about change like
this?
__alloc_pages_nodemask()
gfpflags_to_migratetype()
if (!(gfp_mask & __GFP_MOVABLE))
return MIGRATE_MIRROR
Thanks,
Xishi Qiu
>
>
>
>
>
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 3/3] mm: make swapin readahead to improve thp collapse rate
On 06/24/2015 08:33 AM, Vlastimil Babka wrote: > On 06/22/2015 03:37 AM, Rik van Riel wrote: >> On 06/21/2015 02:11 PM, Kirill A. Shutemov wrote: >>> On Sat, Jun 20, 2015 at 02:28:06PM +0300, Ebru Akagunduz wrote: + __collapse_huge_page_swapin(mm, vma, address, pmd, pte); + >>> >>> And now the pages we swapped in are not isolated, right? >>> What prevents them from being swapped out again or whatever? >> >> Nothing, but __collapse_huge_page_isolate is run with the >> appropriate locks to ensure that once we actually collapse >> the THP, things are present. >> >> The way do_swap_page is called, khugepaged does not even >> wait for pages to be brought in from swap. It just maps >> in pages that are in the swap cache, and which can be >> immediately locked (without waiting). >> >> It will also start IO on pages that are not in memory >> yet, and will hopefully get those next round. > > Hm so what if the process is slightly larger than available memory and really > doesn't touch the swapped out pages that much? Won't that just be thrashing > and > next round you find them swapped out again? Yes, it might. However, all the policy smarts are in patch 2/3, not in patch 3/3 (which has the mechanism). I suspect the code could use some more smarts, but I am not quite sure what they should be... -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Friday, June 26, 2015 9:41 AM
>
> On Friday, June 26, 2015 12:51:39 AM Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > > Sent: Friday, June 26, 2015 8:44 AM
> > >
> > > On Thursday, June 25, 2015 12:43:39 AM Zheng, Lv wrote:
> > > > Hi, Rafael
> > > >
> > > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > > > > Sent: Thursday, June 25, 2015 7:57 AM
> > > > >
> > >
> > > [cut]
> > >
> > > > > >
> > > > > > +/***
> > > > > > + *
> > > > > > + * FUNCTION:acpi_set_firmware_waking_vector
> > > > > > + *
> > > > > > + * PARAMETERS: physical_address- 32-bit physical address of
> > > > > > ACPI real mode
> > > > > > + *entry point
> > > > > > + * physical_address64 - 64-bit physical address of
> > > > > > ACPI protected
> > > > > > + *entry point
> > > > > > + *
> > > > > > + * RETURN: Status
> > > > > > + *
> > > > > > + * DESCRIPTION: Sets the firmware_waking_vector fields of the FACS
> > > > > > + *
> > > > > > +
> > > > > > **/
> > > > > > +
> > > > > > +acpi_status
> > > > > > +acpi_set_firmware_waking_vector(acpi_physical_address
> > > > > > physical_address,
> > > > > > + acpi_physical_address
> > > > > > physical_address64)
> > > > >
> > > > > The question here is: Why does the host OS need to care about the
> > > > > second
> > > > > argument of this function that will always be 0? Why didn't you keep
> > > > > the
> > > > > old header of acpi_set_firmware_waking_vector() as a one-argument
> > > > > function
> > > > > taking a u32 and why didn't you add something like
> > > > >
> > > > > acpi_status acpi_set_firmware_waking_vector_full(u32
> > > > > real_mode_address,
> > > > > acpi_physical_address
> > > > > high_address)
> > > > >
> > > > > and why didn't you redefine acpi_set_firmware_waking_vector() as
> > > > >
> > > > > acpi_status acpi_set_firmware_waking_vector(u32 real_mode_address)
> > > > > {
> > > > > return acpi_set_firmware_waking_vector_full(real_mode_address,
> > > > > 0);
> > > > > }
> > > > >
> > > > > ?
> > > > >
> > > > > If you did that, there wouldn't be any need to touch the code in
> > > > > drivers/acpi/sleep.c and the arch headers, so can you please explain
> > > > > to me
> > > > > why *exactly* you didn't do that?
> > > >
> > > > Host OS can set non 0 address for both real_mode_address and
> > > > high_address to indicate that it can support both 32-bit and 64-
> bit
> > > resume environments.
> > > > So if a BIOS favors 32-bit resume environment, it can resume from here;
> > > > if another BIOS favors 64-bit resume environment, it
> can
> > > resume from there.
> > > > And host OSes can be implemented using only 1 binary to work with both
> > > > BIOSes.
> > >
> > > I'm not talking about that.
> > >
> > > It is fine to provide a *new* interface for the OSes that want to do that
> > > (if any), but *why* is that regarded as a good enough reason for
> > > essentially
> > > *removing* the old interface that Linux (and presumably other OSes too)
> > > have
> > > been using so far?
> >
> > Maybe we should ask Bob if we shall just provide a new interfaces for this
> > and keep the old ones?
>
> Sure, we can talk to Bob about that.
>
> > According to my understanding, there is no such example in the ACPICA
> > upstream.
>
> Even so, that doesn't necessarily mean it is be impossible.
Yes.
>
> > Some _full functions are still pending for being merged by ACPICA
> > upstream,
> > they are divergences for now.
>
> And it looks like this particular case will become one more divergence of that
> kind.
OK.
I'll refine the interface change to eliminate the divergence.
>
> > >
> > > We don't want to pass nonzero as high_address anyway, so why are we
> > > *forced* to
> > > make pointless changes to non-ACPICA code just to be able to always pass 0
> > > as high_address?
> >
> > IMO, OSPMs can do this if the cost is not high.
> > It seems by following your suggestion, we only need to do slight changes in
> > sleep.c.
>
> Which aren't necessary, right? And they don't really make things any better.
>
> So I don't see a reason to make them.
Yes.
If this is done in ACPICA, sleep.c needn't be changed.
Thanks and best regards
-Lv
Re: kexec crash kernel running with watchdog enabled
Hi,
(2015/06/25 1:31), dwal...@fifo99.com wrote:
> On Wed, Jun 24, 2015 at 03:52:48PM +0900, Masami Hiramatsu wrote:
>> Hi,
>>
>> On 2015/06/23 23:05, dwal...@fifo99.com wrote:
>>>
>>> Hi,
>>>
>>> There was a commit in kernel/panic.c which altered when the kexec crash
>>> kernel is executed,
>>>
>>> commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45
>>> Author: Masami Hiramatsu
>>> Date: Fri Jun 6 14:37:07 2014 -0700
>>>
>>> kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump after
>>> panic_notifers
>>>
>>>
>>> This made it possible for smp_send_stop() to be executed prior to calling
>>> the kexec crash
>>> kernel.
>>>
>>> The issue is that smp_send_stop() offlines the cores, and other code depend
>>> on the cores being online.
>>>
>>> In my case on Octeon here's an example,
>>>
>>> panic()
>>> crash_kexec()
>>> machine_crash_shutdown()
>>>octeon_generic_shutdown()
>>>
>>> Inside octeon_generic_shutdown() the Octeon watchdog is shutdown
>>> for_each_online_cpu(), but since
>>> most of the cpu's already got offlined in smp_send_stop() it means the
>>> watchdog is still alive on
>>> those cores. This results in a reboot during the crash kernel execution.
>>
>> Ah, I see.
>>
>>> Another example seem to be in default_machine_crash_shutdown() where
>>> crash_kexec_prepare_cpus() depends
>>> on an IPI for saving the registers on different cores. However, the cpu's
>>> are all offlined with
>>> interrupts disabled so they won't be running those IPI's in this case.
>>>
>>> I'm looking for any advice on how this should be fixed, or if it's already
>>> fixed. I'm not going to be
>>> submitting a patch so if anyone wants to submit one feel free to do so.
>>
>> Hmm, IMHO, when the cpu goes to offline in appropriate way(smp_send_stop),
>> it should stop
>> watchdog timer on the offlined cpu too.
>> Or, you can also register crash handler which stops all watchdogs, but it's
>> a bit tricky.
>>
>
> That doesn't really fix all the issue tho. As I was explaining generic MIPS
> code depends on the cpu's
> effectively being online for crash data collection (with an IPI). This issue
> may effect other architectures also,
> because smp_send_stop() offlines the cpu on other architectures also. I
> haven't surveyed the other architectures
> enough to know what issue could happen from this tho.
>
> Is it possible to move the smp_send_stop() below the notifiers ? I'm just
> throwing out ideas.
No, that doesn't works. Some notifiers assume that they run in
single core mode.
Another possible solution is to add notifiers just after
machine_crash_shutdown() like this:
void panic(const char *fmt, ...)
...
- if (!crash_kexec_post_notifiers)
- crash_kexec(NULL);
+ crash_kexec(NULL, buf);
and
-void crash_kexec(struct pt_regs *regs)
+void crash_kexec(struct pt_regs *regs, char *msg)
...
if (kexec_crash_image) {
struct pt_regs fixed_regs;
crash_setup_regs(&fixed_regs, regs);
crash_save_vmcoreinfo();
machine_crash_shutdown(&fixed_regs);
+ if (crash_kexec_post_notifiers) {
+ kmsg_dump(KMSG_DUMP_PANIC);
+
atomic_notifier_call_chain(&panic_notifier_list, 0, msg);
+ }
machine_kexec(kexec_crash_image);
Most of archs stop other cores in machine_crash_shutdown(),
so it will work well. Furthermore, it simplifies the special
case where crash_kexec() is called without entering panic().
However, we need some tweaks for sh and s390 cases. As for sh,
it seems not to stop other cores in the crash_kexec() sequence
(kdump support is incompleted?). For s390, smp_send_stop() is
called in machine_kexec() but not machine_crash_shutdown().
Regards,
--
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Mailbox changes for v4.2
On Thu, Jun 25, 2015 at 8:58 AM, Jassi Brar wrote: > > http://git.linaro.org/landing-teams/working/fujitsu/integration.git > mailbox-for-next So just looking at this pull request (and my previous merges from you) it does strike me that you seem to be one of the few people who never explain your pull requests.. Mind starting to write a small blurb every time you ask me to pull to explain what's new and what's going on? That will improve my merge logs.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] arm64: bpf: fix endianness conversion bugs
Upper bits should be zeroed in endianness conversion:
- even when there's no need to change endianness (i.e., BPF_FROM_BE
on big endian or BPF_FROM_LE on little endian);
- after rev16.
This patch fixes such bugs by emitting extra instructions to clear
upper bits.
Cc: Zi Shen Lim
Cc: Alexei Starovoitov
Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler")
Signed-off-by: Xi Wang
---
The current testsuite catches the 16-bit bugs. I'll send a separate
patch that extends test_bpf to catch the 32-bit ones.
---
arch/arm64/net/bpf_jit.h | 4
arch/arm64/net/bpf_jit_comp.c | 22 --
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/net/bpf_jit.h b/arch/arm64/net/bpf_jit.h
index de0a81a..98a26ce 100644
--- a/arch/arm64/net/bpf_jit.h
+++ b/arch/arm64/net/bpf_jit.h
@@ -110,6 +110,10 @@
/* Rd = Rn >> shift; signed */
#define A64_ASR(sf, Rd, Rn, shift) A64_SBFM(sf, Rd, Rn, shift, (sf) ? 63 : 31)
+/* Zero extend */
+#define A64_UXTH(sf, Rd, Rn) A64_UBFM(sf, Rd, Rn, 0, 15)
+#define A64_UXTW(sf, Rd, Rn) A64_UBFM(sf, Rd, Rn, 0, 31)
+
/* Move wide (immediate) */
#define A64_MOVEW(sf, Rd, imm16, shift, type) \
aarch64_insn_gen_movewide(Rd, imm16, shift, \
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index c81ddd4..c047598 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -289,23 +289,41 @@ static int build_insn(const struct bpf_insn *insn, struct
jit_ctx *ctx)
case BPF_ALU | BPF_END | BPF_FROM_BE:
#ifdef CONFIG_CPU_BIG_ENDIAN
if (BPF_SRC(code) == BPF_FROM_BE)
- break;
+ goto emit_bswap_uxt;
#else /* !CONFIG_CPU_BIG_ENDIAN */
if (BPF_SRC(code) == BPF_FROM_LE)
- break;
+ goto emit_bswap_uxt;
#endif
switch (imm) {
case 16:
emit(A64_REV16(is64, dst, dst), ctx);
+ /* zero-extend 16 bits into 64 bits */
+ emit(A64_UXTH(is64, dst, dst), ctx);
break;
case 32:
emit(A64_REV32(is64, dst, dst), ctx);
+ /* upper 32 bits already cleared */
break;
case 64:
emit(A64_REV64(dst, dst), ctx);
break;
}
break;
+emit_bswap_uxt:
+ switch (imm) {
+ case 16:
+ /* zero-extend 16 bits into 64 bits */
+ emit(A64_UXTH(is64, dst, dst), ctx);
+ break;
+ case 32:
+ /* zero-extend 32 bits into 64 bits */
+ emit(A64_UXTW(is64, dst, dst), ctx);
+ break;
+ case 64:
+ /* nop */
+ break;
+ }
+ break;
/* dst = imm */
case BPF_ALU | BPF_MOV | BPF_K:
case BPF_ALU64 | BPF_MOV | BPF_K:
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.
Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, June 26, 2015 9:21 AM > > On Thursday, June 25, 2015 12:29:02 AM Zheng, Lv wrote: > > Hi, Rafael > > > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > > Sent: Thursday, June 25, 2015 7:24 AM > > > To: Zheng, Lv > > [cut] > > > > > > > In fact, I don't see why we need to redefine the symbols at all. > > > > > > Couldn't acpi_set_firmware_waking_vector() be defined to take u32 and u64 > > > so > > > we could just pass acpi_wakeup_address (as already defined) as the first > > > argument > > > and 0 as the second argument to it? The back-and-forth type casts from > > > and > > > to acpi_physical_address don't look entirely clean to me. > > > > > > Moreover, I don't really see a functional difference between the old and > > > the > > > new code. > > > > > > The old code does "set the 32-bit waking vector and clear the 64-bit > > > waking > > > vector if present". The new code does "set the 32-bit waking vector and > > > either clear the 64-bit one if present, or assign the second function > > > argument > > > to it", but we always pass 0 as the second argument (which is *extremely* > > > obfuscated in your patch), so I really don't see the difference here. > > > > > > Am I missing anything? > > > > The story is: > > According to the test, if both 32-bit waking vector and 64-bit waking > > vector is > > set by the OSPM, > > The current code in Linux never does that. > > It never calls acpi_set_firmware_waking_vector64() and the > acpi_set_firmware_waking_vector() > (before your patch) explicitly clears the 64-bit vector address. In ACPICA upstream, this is an issue before applying this patch. acpi_set_firmware_waking_vector64() and acpi_set_firmware_waking_vector() depends on ACPI_MACHINE_WIDTH definition, thus cannot be used for this purpose. > > > BIOSes only support 32-bit resume environment will jump to the 32-bit waking > > vector address and BIOSes support 64-bit resume environment will jump to > > 64-bit waking vector. > > Which doesn't matter for Linux one whit. The bug report is against the 64-bit address favor mechanism. But if the OSPM can support resuming from 64-bit waking vector, the 64-bit address favor mechanism doesn't seem to be buggy. > > > So they can be set by the OSPMs simultaneously to indicate that the OSPM can > > support both resume environments. That's why ACPICA interface is changed. > > It shouldn't. It just forces host OSes to make pointless changes to their > non-ACPICA code. > > As I said elsewhere, the old acpi_set_firmware_waking_vector() should still be > available to the OSes that don't care about the 64-bit waking vector and a > *new* > interface should be added for those OSes that do care about it. And > *internally* > acpi_set_firmware_waking_vector() can be defined in terms of the new > interface, > but there's no reason at all for a host OS to care about that. OK, we can refine the interface inside of ACPICA. > > So the $subject patch is entirely poitless. It doesn't fix anything and it > doesn't even change the way the code works today in Linux. It just adds > complexity and pointlessly redefines some stuff. > It doesn't fix any functionality problem right here in this patch. But it fixes the code logic problem that acpi_set_firmware_waking_vector64()/acpi_set_firmware_waking_vector() depends on ACPI_MACHINE_WIDTH definition. And it facilitates the OSPMs with the capability to support both 32-bit/64-bit resuming environment. > So I'm not going to apply it. OK, I'll go back to refine the interface change. Thanks and best regards -Lv
[PATCH v2] drm/rockchip: import dma_buf to gem
We want to display a buffer allocated by other driver, need import
the buffer to gem.
Signed-off-by: Mark Yao
---
Changes in v2:
Adviced by Russell King
- check sgt-nents == 1 when get iova from scatterlist
- remove unused dma_map_sg/dma_unmap_sg, dma_buf_map_attachment->map_dma_buf
should do the dma_map
drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 +
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 40 +--
drivers/gpu/drm/rockchip/rockchip_drm_gem.h |5 +++-
3 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 3962176..9001a90 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -287,6 +287,7 @@ static struct drm_driver rockchip_drm_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = drm_gem_prime_import,
+ .gem_prime_import_sg_table = rockchip_gem_prime_import_sg_table,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
.gem_prime_vmap = rockchip_gem_prime_vmap,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index eb2282c..e8c4d4e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
@@ -105,6 +106,36 @@ int rockchip_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return ret;
}
+struct drm_gem_object *
+rockchip_gem_prime_import_sg_table(struct drm_device *drm,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sgt)
+{
+ struct rockchip_gem_object *rk_obj;
+ struct drm_gem_object *obj;
+
+ /*
+* Todo: only support continuous buffer now, plan to found a method
+* to import non continuous with iommu.
+*/
+ if (sgt->nents != 1)
+ return ERR_PTR(-EINVAL);
+
+ rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
+ if (!rk_obj)
+ return ERR_PTR(-ENOMEM);
+
+ obj = &rk_obj->base;
+
+ drm_gem_private_object_init(drm, obj, attach->dmabuf->size);
+
+ rk_obj->dma_addr = sg_dma_address(sgt->sgl);
+ rk_obj->sgt = sgt;
+ obj->size = sg_dma_len(sgt->sgl);
+
+ return obj;
+}
+
struct rockchip_gem_object *
rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
bool alloc_kmap)
@@ -142,11 +173,14 @@ void rockchip_gem_free_object(struct drm_gem_object *obj)
{
struct rockchip_gem_object *rk_obj;
- drm_gem_free_mmap_offset(obj);
-
rk_obj = to_rockchip_obj(obj);
- rockchip_gem_free_buf(rk_obj);
+ if (obj->import_attach) {
+ drm_prime_gem_destroy(obj, rk_obj->sgt);
+ } else {
+ drm_gem_free_mmap_offset(obj);
+ rockchip_gem_free_buf(rk_obj);
+ }
kfree(rk_obj);
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
index ad22618..9fd58e3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
@@ -21,6 +21,7 @@ struct rockchip_gem_object {
struct drm_gem_object base;
unsigned int flags;
+ struct sg_table *sgt;
void *kvaddr;
dma_addr_t dma_addr;
struct dma_attrs dma_attrs;
@@ -28,8 +29,10 @@ struct rockchip_gem_object {
struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
-rockchip_gem_prime_import_sg_table(struct drm_device *dev, size_t size,
+rockchip_gem_prime_import_sg_table(struct drm_device *drm,
+ struct dma_buf_attachment *attach,
struct sg_table *sgt);
+
void *rockchip_gem_prime_vmap(struct drm_gem_object *obj);
void rockchip_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/17] libnvdimm: Set numa_node to NVDIMM devices
On Thu, 2015-06-25 at 18:08 -0700, Dan Williams wrote:
> On Thu, Jun 25, 2015 at 5:55 PM, Toshi Kani wrote:
> > On Thu, 2015-06-25 at 23:42 +, Williams, Dan J wrote:
> >> On Thu, 2015-06-25 at 16:55 -0600, Toshi Kani wrote:
:
> >
> > Now, how do I unbind BTT? I did the following as a guess, but BTT got
> > reattached again before I have a chance to delete the metadata, which I
> > need /dev/pmemN.
> >
> > NUM=1
> > cd /sys/bus/nd/devices
> > echo "" > btt${NUM}.1/namespace
> > echo btt${NUM}.1 > ../drivers/nd_pmem/unbind
>
> echo 1 > namespace${NUM}.0/force_raw
>
> > echo namespace${NUM}.0 > ../drivers/nd_pmem/bind
> >
Cool! Yes, it works with the force_raw. (I changed the ordering a
bit).
NUM=1
cd /sys/bus/nd/devices
echo btt${NUM}.1 > ../drivers/nd_pmem/unbind
echo "" > btt${NUM}.1/namespace
echo 1 > namespace${NUM}.0/force_raw
echo namespace${NUM}.0 > ../drivers/nd_pmem/bind
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.
On 6/25/2015 4:24 PM, John Stultz wrote: From: Ruchi Kandoi This patch has been in the Android tree for ahwile, and I've not seen it posted for review. Unfortunately the PR_SET_TIMERSLACK_PID value has collided many times w/ upstream (first w/ PR_SET_THP_DISABLE, and again w/ PR_MPX_ENABLE_MANAGEMENT). So to try to avoid further ABI trouble, I wanted to send this out for initial review to see if there were any major objections, or ideas for alternative approaches. Thoughts and feedback would be appreciated. I am wondering if it would be more natural to make this a cgroup property.. and have a way for threads to inherit their cgroup effective value. it'll fit more natural in many places than just a per pid setting. (I have nothing against it per se other than that I think the security check is wrong; I fully expected to be on the level of ptrace_may_access(PTRACE_MODE_ATTACH) or the like.. not just NICE. you can seriously change task behavior with this by setting a 4 second value or so.. much more than just with nice) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the vfs tree with the ceph tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/ceph/dir.c
between commit:
fdd4e15838e5 ("ceph: rework dcache readdir")
from the ceph tree and commit:
dc3f4198eac1 ("make simple_positive() public")
from the vfs tree.
I fixed it up (I think - see below) and can carry the fix as necessary (no
action
is required).
Sage: that ceph tree commit has no Signed-off-by from its
committer :-( The same is true for almost all the commits in the ceph
tree ... and the committer (Ilya) is not listed as a maintainer of that
tree ... and its on github :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/ceph/dir.c
index 9314b4ea2375,edbb8da02a6a..
--- a/fs/ceph/dir.c
+++ b/fs/ceph/dir.c
@@@ -144,110 -123,101 +144,110 @@@ static int __dcache_readdir(struct fil
struct ceph_file_info *fi = file->private_data;
struct dentry *parent = file->f_path.dentry;
struct inode *dir = d_inode(parent);
- struct list_head *p;
- struct dentry *dentry, *last;
+ struct dentry *dentry, *last = NULL;
struct ceph_dentry_info *di;
+ unsigned nsize = PAGE_CACHE_SIZE / sizeof(struct dentry *);
int err = 0;
+ loff_t ptr_pos = 0;
+ struct ceph_readdir_cache_control cache_ctl = {};
- /* claim ref on last dentry we returned */
- last = fi->dentry;
- fi->dentry = NULL;
-
- dout("__dcache_readdir %p v%u at %llu (last %p)\n",
- dir, shared_gen, ctx->pos, last);
+ dout("__dcache_readdir %p v%u at %llu\n", dir, shared_gen, ctx->pos);
- spin_lock(&parent->d_lock);
-
- /* start at beginning? */
- if (ctx->pos == 2 || last == NULL ||
- fpos_cmp(ctx->pos, ceph_dentry(last)->offset) < 0) {
- if (list_empty(&parent->d_subdirs))
- goto out_unlock;
- p = parent->d_subdirs.prev;
- dout(" initial p %p/%p\n", p->prev, p->next);
- } else {
- p = last->d_child.prev;
+ /* we can calculate cache index for the first dirfrag */
+ if (ceph_frag_is_leftmost(fpos_frag(ctx->pos))) {
+ cache_ctl.index = fpos_off(ctx->pos) - 2;
+ BUG_ON(cache_ctl.index < 0);
+ ptr_pos = cache_ctl.index * sizeof(struct dentry *);
}
-more:
- dentry = list_entry(p, struct dentry, d_child);
- di = ceph_dentry(dentry);
- while (1) {
- dout(" p %p/%p %s d_subdirs %p/%p\n", p->prev, p->next,
- d_unhashed(dentry) ? "!hashed" : "hashed",
- parent->d_subdirs.prev, parent->d_subdirs.next);
- if (p == &parent->d_subdirs) {
+ while (true) {
+ pgoff_t pgoff;
+ bool emit_dentry;
+
+ if (ptr_pos >= i_size_read(dir)) {
fi->flags |= CEPH_F_ATEND;
- goto out_unlock;
+ err = 0;
+ break;
+ }
+
+ err = -EAGAIN;
+ pgoff = ptr_pos >> PAGE_CACHE_SHIFT;
+ if (!cache_ctl.page || pgoff != page_index(cache_ctl.page)) {
+ ceph_readdir_cache_release(&cache_ctl);
+ cache_ctl.page = find_lock_page(&dir->i_data, pgoff);
+ if (!cache_ctl.page) {
+ dout(" page %lu not found\n", pgoff);
+ break;
+ }
+ /* reading/filling the cache are serialized by
+ * i_mutex, no need to use page lock */
+ unlock_page(cache_ctl.page);
+ cache_ctl.dentries = kmap(cache_ctl.page);
}
- spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
+
+ rcu_read_lock();
+ spin_lock(&parent->d_lock);
+ /* check i_size again here, because empty directory can be
+ * marked as complete while not holding the i_mutex. */
+ if (ceph_dir_is_complete_ordered(dir) &&
+ ptr_pos < i_size_read(dir))
+ dentry = cache_ctl.dentries[cache_ctl.index % nsize];
+ else
+ dentry = NULL;
+ spin_unlock(&parent->d_lock);
+ if (dentry && !lockref_get_not_dead(&dentry->d_lockref))
+ dentry = NULL;
+ rcu_read_unlock();
+ if (!dentry)
+ break;
+
+ emit_dentry = false;
+ di = ceph_dentry(dentry);
+ spin_lock(&dentry->d_lock);
if (di->lease_shared_gen == shared_gen &&
- d_really_is_positive(dentry) &&
+ simple_positive(dentry) &&
ceph_snap(d_inode(dentry)) != CEPH_SNAPDIR &&
ceph_ino(d_inode(dentry
Re: [RFC PATCH 0/3] restartable sequences: fast user-space percpu critical sections
- On Jun 24, 2015, at 10:54 PM, Paul Turner p...@google.com wrote: > On Wed, Jun 24, 2015 at 5:07 PM, Andy Lutomirski wrote: >> On Wed, Jun 24, 2015 at 3:26 PM, Paul Turner wrote: >>> This is a fairly small series demonstrating a feature we've found to be >>> quite >>> powerful in practice, "restartable sequences". >>> >> >> On an extremely short glance, I'm starting to think that the right >> approach, at least for x86, is to implement per-cpu gsbase. Then you >> could do cmpxchg with a gs prefix to atomically take a percpu lock and >> atomically release a percpu lock and check whether someone else stole >> the lock from you. (Note: cmpxchg, unlike lock cmpxchg, is very >> fast.) >> >> This is totally useless for other architectures, but I think it would >> be reasonable clean on x86. Thoughts? > > So this gives semantics that are obviously similar to this_cpu(). > This provides allows reasonable per-cpu counters (which is alone > almost sufficient for a strong user-space RCU implementation giving > this some legs). > > However, unless there's a nice implementation trick I'm missing, the > thing that stands out to me for locks (or other primitives) is that > this forces a two-phase commit. There's no way (short of say, > cmpxchg16b) to perform a write conditional on the lock not having been > stolen from us (and subsequently release the lock). > > e.g. > 1) We take the operation in some sort of speculative mode, that > another thread on the same cpu is stilled allowed to steal from us > 2) We prepare what we want to commit > 3) At this point we have to promote the lock taken in (1) to perform > our actual commit, or see that someone else has stolen (1) > 4) Release the promoted lock in (3) > > However, this means that if we're preempted at (3) then no other > thread on that cpu can make progress until we've been rescheduled and > released the lock; a nice property of the model we have today is that > threads sharing a cpu can not impede each other beyond what the > scheduler allows. > > A lesser concern, but worth mentioning, is that there are also > potential pitfalls in the interaction with signal handlers, > particularly if a 2-phase commit is used. Assuming we have a gs segment we can use to address per-cpu locks in userspace, would the following scheme take care of some of your concerns ? per-cpu int32_t: each lock initialized to "cpu_nr" value per-cpu lock: get current cpu number. Remember this value as "CPU lock nr". use cmpxchg on gs:lock to grab the lock. - Expect old value to be "CPU lock nr". - Update with a lock flag in most significant bit, "CPU lock nr" in lower bits. - Retry if fails. Can be caused by migration or lock being already held. per-cpu unlock: clear lock flag within the "CPU lock nr" lock. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.
On Friday, June 26, 2015 12:51:39 AM Zheng, Lv wrote:
> Hi, Rafael
>
> > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > Sent: Friday, June 26, 2015 8:44 AM
> >
> > On Thursday, June 25, 2015 12:43:39 AM Zheng, Lv wrote:
> > > Hi, Rafael
> > >
> > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > > > Sent: Thursday, June 25, 2015 7:57 AM
> > > >
> >
> > [cut]
> >
> > > > >
> > > > > +/***
> > > > > + *
> > > > > + * FUNCTION:acpi_set_firmware_waking_vector
> > > > > + *
> > > > > + * PARAMETERS: physical_address- 32-bit physical address of
> > > > > ACPI real mode
> > > > > + *entry point
> > > > > + * physical_address64 - 64-bit physical address of
> > > > > ACPI protected
> > > > > + *entry point
> > > > > + *
> > > > > + * RETURN: Status
> > > > > + *
> > > > > + * DESCRIPTION: Sets the firmware_waking_vector fields of the FACS
> > > > > + *
> > > > > +
> > > > > **/
> > > > > +
> > > > > +acpi_status
> > > > > +acpi_set_firmware_waking_vector(acpi_physical_address
> > > > > physical_address,
> > > > > + acpi_physical_address
> > > > > physical_address64)
> > > >
> > > > The question here is: Why does the host OS need to care about the second
> > > > argument of this function that will always be 0? Why didn't you keep
> > > > the
> > > > old header of acpi_set_firmware_waking_vector() as a one-argument
> > > > function
> > > > taking a u32 and why didn't you add something like
> > > >
> > > > acpi_status acpi_set_firmware_waking_vector_full(u32 real_mode_address,
> > > > acpi_physical_address
> > > > high_address)
> > > >
> > > > and why didn't you redefine acpi_set_firmware_waking_vector() as
> > > >
> > > > acpi_status acpi_set_firmware_waking_vector(u32 real_mode_address)
> > > > {
> > > > return acpi_set_firmware_waking_vector_full(real_mode_address,
> > > > 0);
> > > > }
> > > >
> > > > ?
> > > >
> > > > If you did that, there wouldn't be any need to touch the code in
> > > > drivers/acpi/sleep.c and the arch headers, so can you please explain to
> > > > me
> > > > why *exactly* you didn't do that?
> > >
> > > Host OS can set non 0 address for both real_mode_address and
> > > high_address to indicate that it can support both 32-bit and 64-bit
> > resume environments.
> > > So if a BIOS favors 32-bit resume environment, it can resume from here;
> > > if another BIOS favors 64-bit resume environment, it can
> > resume from there.
> > > And host OSes can be implemented using only 1 binary to work with both
> > > BIOSes.
> >
> > I'm not talking about that.
> >
> > It is fine to provide a *new* interface for the OSes that want to do that
> > (if any), but *why* is that regarded as a good enough reason for essentially
> > *removing* the old interface that Linux (and presumably other OSes too) have
> > been using so far?
>
> Maybe we should ask Bob if we shall just provide a new interfaces for this
> and keep the old ones?
Sure, we can talk to Bob about that.
> According to my understanding, there is no such example in the ACPICA
> upstream.
Even so, that doesn't necessarily mean it is be impossible.
> Some _full functions are still pending for being merged by ACPICA
> upstream,
> they are divergences for now.
And it looks like this particular case will become one more divergence of that
kind.
> >
> > We don't want to pass nonzero as high_address anyway, so why are we
> > *forced* to
> > make pointless changes to non-ACPICA code just to be able to always pass 0
> > as high_address?
>
> IMO, OSPMs can do this if the cost is not high.
> It seems by following your suggestion, we only need to do slight changes in
> sleep.c.
Which aren't necessary, right? And they don't really make things any better.
So I don't see a reason to make them.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/3] video: fbdev: atyfb: clarify ioremap() base and length used
On Fri, Jun 26, 2015 at 02:11:03AM +0300, Ville Syrjälä wrote: > On Thu, Jun 25, 2015 at 04:06:45PM -0700, Luis R. Rodriguez wrote: > > On Thu, Jun 25, 2015 at 4:04 PM, Ville Syrjälä wrote: > > > it doesn't hurt too much > > > since smem_len gets overwritten later in aty_init(). > > > > That's the idea, we set it with a default as it will be overwritten > > later anyway. > > Maybe toss in a comment? Otherwise it's a bit dishonest and might give > someone the impression that all PCI cards really have 8MB of memory. Sure, mind this as a follow up patch if its too late? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/17] libnvdimm: Set numa_node to NVDIMM devices
On Thu, Jun 25, 2015 at 5:55 PM, Toshi Kani wrote:
> On Thu, 2015-06-25 at 23:42 +, Williams, Dan J wrote:
>> On Thu, 2015-06-25 at 16:55 -0600, Toshi Kani wrote:
>> > On Thu, 2015-06-25 at 15:34 -0700, Dan Williams wrote:
>> > > On Thu, Jun 25, 2015 at 3:11 PM, Toshi Kani wrote:
>> > > > On Thu, 2015-06-25 at 15:00 -0700, Dan Williams wrote:
>> > > > Yes, I see no problem with bound BTTs and their device files. So, how
>> > > > do we bind BTT with this new version?
>> > > >
>> > >
>> > > # cd /sys/bus/nd/devices
>> > > # uuidgen > btt6/uuid
>> > > # echo 4096 > btt6/sector_size
>> > > # echo namespace6.0 > btt6/namespace
>> > > # echo namespace6.0 > ../drivers/nd_pmem/unbind
>> > > # echo btt6 > ../drivers/nd_pmem/bind
>> > >
>> > > After reboot, when the system sees namespace6.0 again it will notice
>> > > the btt instance and attach bttX instead. The net effect is that now
>> > > you'll only ever have /dev/pmem6 or /dev/pmem6s, never both at the
>> > > same time that was a side effect of the stacking approach.
>> > >
>> > > I'll post the patch that updates libndctl and the unit tests shortly
>> >
>> > Maybe I am missing something, but I am getting errors on my system. (I
>> > used btt0 since there is no btt6.)
>> >
>> > # cat bind.sh
>> > set -x
>> > cd /sys/bus/nd/devices
>> > uuidgen > btt0/uuid
>> > echo 4096 > btt0/sector_size
>> > echo namespace0.0 > btt0/namespace
>> > echo namespace0.0 > ../drivers/nd_pmem/unbind
>> > echo btt0 > ../drivers/nd_pmem/bind
>> >
>> > # sh bind.sh
>> > + cd /sys/bus/nd/devices
>> > + uuidgen
>> > + echo 4096
>> > + echo namespace0.0
>> > bind.sh: line 6: echo: write error: Device or resource busy
>> > + echo namespace0.0
>> > bind.sh: line 7: echo: write error: No such device
>> > + echo btt0
>> > bind.sh: line 8: echo: write error: No such device
>> >
>> > # dmesg
>> > :
>> > [12513.839162] nd btt0: uuid_store: result: 0 wrote:
>> > b32cd195-9aae-4c54-a5ac-49adb50a8a98
>> > [12513.880286] nd btt0: sector_size_store: result: 0 wrote: 4096
>> > [12513.909494] nd btt0: namespace0.0 already claimed
>> > [12513.933364] nd btt0: namespace_store: result: -16 wrote: namespace0.0
>> > [12513.966808] ndbus0: nd_pmem.probe(btt0) = -19
>> >
>>
>> So this turned out to be a perfect example of why we might want to have
>> the region-id in the btt device name just like namespaces, because btt0
>> was actually bound to namespace4.0 on Toshi's system. The following
>> update, that I will fold in to the series, fixes this. Note that the
>> association of btt id to to namespace is still non-deterministic. I.e.
>> btt0.1 could be assigned as the btt for namespace0.0, but at least when
>> looking at /sys/bus/nd/devices it will be clear which btts belong to
>> which regions.
>>
>> # ls /sys/bus/nd/devices
>> btt0.0 btt3.0 btt6.0namespace2.0 namespace5.0 nmem1 nmem4
>> region2 region5
>> btt1.0 btt4.0 namespace0.0 namespace3.0 namespace6.0 nmem2 region0
>> region3 region6
>> btt2.0 btt5.0 namespace1.0 namespace4.0 nmem0 nmem3 region1
>> region4
>
> Yes, this works nicely. :-)
>
> Now, how do I unbind BTT? I did the following as a guess, but BTT got
> reattached again before I have a chance to delete the metadata, which I
> need /dev/pmemN.
>
> NUM=1
> cd /sys/bus/nd/devices
> echo "" > btt${NUM}.1/namespace
> echo btt${NUM}.1 > ../drivers/nd_pmem/unbind
echo 1 > namespace${NUM}.0/force_raw
> echo namespace${NUM}.0 > ../drivers/nd_pmem/bind
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: arizona: Declare 3-pole jack if we detect open circuit on mic
On 06/26/2015 12:47 AM, Charles Keepax wrote:
> Detecting an open-circuit on the microphone pin, usually means the
> headset has a microphone but the cable is faulty. Currently the code
> will simply stop detecting and declare nothing in this situation. It is
> better to declare this as headphones such that the user can still use
> their headset as plain headphones even if the microphone is faulty.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 4c47eb2..e216a97 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -829,7 +829,10 @@ static void arizona_micd_detect(struct work_struct *work)
> /* Due to jack detect this should never happen */
> if (!(val & ARIZONA_MICD_STS)) {
> dev_warn(arizona->dev, "Detected open circuit\n");
> + info->mic = false;
> + arizona_stop_mic(info);
> info->detecting = false;
> + arizona_identify_headphone(info);
> goto handled;
> }
>
>
Applied it.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] pci: xgene: Enable huge outbound bar support
X-Gene PCIe controllers support huge outbound BARs (with size upto 64GB). This patch configures additional 1 outbound BAR for X-Gene PCIe controllers with size larger than 4GB. This is required to support devices that request huge outbound memory (nVidia K40 as an example) Signed-off-by: Duc Dang Signed-off-by: Tanmay Inamdar --- arch/arm64/boot/dts/apm/apm-storm.dtsi | 33 +++-- drivers/pci/host/pci-xgene.c | 6 +- 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi index d8f3a1c..039206b 100644 --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi @@ -404,10 +404,11 @@ #size-cells = <2>; #address-cells = <3>; reg = < 0x00 0x1f2b 0x0 0x0001 /* Controller registers */ - 0xe0 0xd000 0x0 0x0004>; /* PCI config space */ + 0xe0 0x 0x0 0x0004>; /* PCI config space */ reg-names = "csr", "cfg"; ranges = <0x0100 0x00 0x 0xe0 0x1000 0x00 0x0001 /* io */ - 0x0200 0x00 0x8000 0xe1 0x8000 0x00 0x8000>; /* mem */ + 0x0200 0x00 0x8000 0xe1 0x8000 0x00 0x8000 /* mem */ + 0x0200 0x10 0x 0xf0 0x 0x10 0x>; /* mem */ dma-ranges = <0x4200 0x80 0x 0x80 0x 0x00 0x8000 0x4200 0x00 0x 0x00 0x 0x80 0x>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; @@ -428,10 +429,11 @@ #size-cells = <2>; #address-cells = <3>; reg = < 0x00 0x1f2c 0x0 0x0001 /* Controller registers */ - 0xd0 0xd000 0x0 0x0004>; /* PCI config space */ + 0xd0 0x 0x0 0x0004>; /* PCI config space */ reg-names = "csr", "cfg"; - ranges = <0x0100 0x0 0x 0xd0 0x1000 0x00 0x0001 /* io */ - 0x0200 0x0 0x8000 0xd1 0x8000 0x00 0x8000>; /* mem */ + ranges = <0x0100 0x00 0x 0xd0 0x1000 0x00 0x0001 /* io */ + 0x0200 0x00 0x8000 0xd1 0x8000 0x00 0x8000 /* mem */ + 0x0200 0x08 0x 0xd8 0x 0x08 0x>; /* mem */ dma-ranges = <0x4200 0x80 0x 0x80 0x 0x00 0x8000 0x4200 0x00 0x 0x00 0x 0x80 0x>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; @@ -452,10 +454,11 @@ #size-cells = <2>; #address-cells = <3>; reg = < 0x00 0x1f2d 0x0 0x0001 /* Controller registers */ -0x90 0xd000 0x0 0x0004>; /* PCI config space */ +0x90 0x 0x0 0x0004>; /* PCI config space */ reg-names = "csr", "cfg"; - ranges = <0x0100 0x0 0x 0x90 0x1000 0x0 0x0001 /* io */ - 0x0200 0x0 0x8000 0x91 0x8000 0x0 0x8000>; /* mem */ + ranges = <0x0100 0x00 0x 0x90 0x1000 0x00 0x0001 /* io */ + 0x0200 0x00 0x8000 0x91 0x8000 0x00 0x8000 /* mem */ + 0x0200 0x04 0x 0x94 0x 0x04 0x>; /* mem */ dma-ranges = <0x4200 0x80 0x 0x80 0x 0x00 0x8000 0x4200 0x00 0x 0x00 0x 0x80 0x>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; @@ -476,10 +479,11 @@ #size-cells = <2>; #address-cells = <3>; reg = < 0x00 0x1f50 0x0 0x0001 /* Controller registers */ - 0xa0 0xd000 0x0 0x0004>; /* PCI config space */ + 0xa0 0x 0x0 0x0004>; /* PCI config space */ reg-names = "csr", "cfg"; - ranges = <0x0100 0x0 0x 0xa0 0x1000 0x0 0x0001 /* io */ - 0x0200 0x0 0x8000 0xa1 0x8000 0x0 0x8000>; /* mem */ + ranges = <0x0100 0x00 0x 0
Re: [RFC] kthread_create_on_node is failing to honor the node choice
On 06/26/2015 05:44 AM, Nathan Zimmer wrote: > In kthread_create_on_node we set_cpus_allowed to cpu_all_mask > regardless of what the node is requested. > This seems incorrect. > > Signed-off-by: Nathan Zimmer > Cc: Andrew Morton > Cc: Nishanth Aravamudan > Cc: Tejun Heo > Cc: Lai Jiangshan > Cc: Mel Gorman > Cc: linux-kernel@vger.kernel.org > > --- > kernel/kthread.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/kernel/kthread.c b/kernel/kthread.c > index 10e489c..d885d66 100644 > --- a/kernel/kthread.c > +++ b/kernel/kthread.c > @@ -318,7 +318,10 @@ struct task_struct *kthread_create_on_node(int > (*threadfn)(void *data), >* The kernel thread should not inherit these properties. >*/ > sched_setscheduler_nocheck(task, SCHED_NORMAL, ¶m); > - set_cpus_allowed_ptr(task, cpu_all_mask); > + if (node == -1) > + set_cpus_allowed_ptr(task, cpu_all_mask); > + else > + set_cpus_allowed_ptr(task, cpumask_of_node(node)); cpumask_of_node(node) is bad here. It containers only online cpus. > } > kfree(create); > return task; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm tree for 4.2
Hi Linus, This is the main drm pull request for v4.2. I've one other new driver from freescale on my radar, it's been posted and reviewed, I'd just like to get someone to give it a last look, so maybe I'll send it or maybe I'll leave it. There is no major nouveau changes in here, Ben was working on something big, and we agreed it was a bit late, there wasn't anything else he considered urgent to merge. There might be another msm pull for some bits that are waiting on arm-soc, I'll see how we time it. I'm on holidays from middle of next week for a week, I'm sure everyone can survive without me. This touches some "of" stuff, acks are in place except for the fixes to the build in various configs,t hat I just applied. This also contains a couple of merge conflicts in radeon and i915, I've pushed a drm-next-merged branch to the same tree with them fixed up, the radeon one affects userspace API so please make sure you use the correct ordering for the two values, UNMAP is 0x25, RESET 0x26. Thanks, Dave. new drivers: virtio-gpu: KMS only pieces of driver for virtio-gpu in qemu. This is just the first part of this driver, enough to run unaccelerated userspace on. As qemu merges more we'll start adding the 3D features for the virgl 3d work. amdgpu: a new driver from AMD to driver their newer GPUs. (VI+) It contains a new cleaner userspace API, and is a clean break from radeon moving forward, that AMD are going to concentrate on. It also contains a set of register headers auto generated from AMD internal database. core: atomic modesetting API completed, enabled by default now. Add support for mode_id blob to atomic ioctl to complete interface. bunch of Displayport MST fixes lots of misc fixes. panel: new simple panels, fix some long-standing build issues with bridge drivers radeon: VCE1 support add a GPU reset counter for userspace lots of fixes. amdkfd: H/W debugger support module static user-mode queues support killing all the waves when a process terminates use standard DECLARE_BITMAP i915: Add Broxton support S3, rotation support for Skylake RPS booting tuning CPT modeset sequence fixes ns2501 dither support enable cmd parser on haswell cdclk handling fixes gen8 dynamic pte allocation lots of atomic conversion work exynos: Add atomic modesetting support Add iommu support Consolidate drm driver initialization and MIC, DECON and MIPI-DSI support for exynos5433 omapdrm: atomic modesetting support (fixes lots of things in rewrite) tegra: DP aux transaction fixes iommu support fix msm: adreno a306 support various dsi bits various 64-bit fixes NV12MT support rcar-du: atomic and misc fixes sti: fix HDMI timing complaince tilcdc: use drm component API to access tda998x driver fix module unloading qxl: stability fixes. The following changes since commit c65b99f046843d2455aa231747b5a07a999a9f3d: Linux 4.1-rc6 (2015-05-31 19:01:07 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to c5fd936e992dd2829167d2adc63e151675ca6898: drm/nouveau: Pause between setting gpu to D3hot and cutting the power (2015-06-26 10:26:37 +1000) A.Sunil Kamath (3): drm/i915/bxt: Implement enable/disable for Display C9 state drm/i915/skl: Implement enable/disable for Display C5 state. Implement enable/disable for Display C6 state Alex Deucher (70): drm/radeon: implement tn_set_vce_clocks drm/radeon/dpm: add vce dpm support for TN drm/radeon/dpm: add vce support for SI drm/radeon: add support for vce 1.0 clock gating drm/radeon/tn/si: enable/disable vce cg when encoding v2 drm/radeon: make dpcd parameters const drm/radeon: take the mode_config mutex when dealing with hpds (v2) drm/radeon: clean up radeon_audio_enable drm/amdgpu: add BIF 4.1 register headers drm/amdgpu: add BIF 5.0 register headers drm/amdgpu: add BIF 5.1 register headers drm/amdgpu: add DCE 8.0 register headers drm/amdgpu: add DCE 10.0 register headers drm/amdgpu: add DCE 11.0 register headers drm/amdgpu: add GCA 7.0 register headers drm/amdgpu: add GCA 7.2 register headers drm/amdgpu: add GCA 8.0 register headers drm/amdgpu: add GMC 7.0 register headers drm/amdgpu: add GMC 7.1 register headers drm/amdgpu: add GMC 8.1 register headers drm/amdgpu: add GMC 8.2 register headers drm/amdgpu: add OSS 2.0 regi
Re: [PATCH v2 15/17] libnvdimm: Set numa_node to NVDIMM devices
On Thu, 2015-06-25 at 23:42 +, Williams, Dan J wrote:
> On Thu, 2015-06-25 at 16:55 -0600, Toshi Kani wrote:
> > On Thu, 2015-06-25 at 15:34 -0700, Dan Williams wrote:
> > > On Thu, Jun 25, 2015 at 3:11 PM, Toshi Kani wrote:
> > > > On Thu, 2015-06-25 at 15:00 -0700, Dan Williams wrote:
> > > > Yes, I see no problem with bound BTTs and their device files. So, how
> > > > do we bind BTT with this new version?
> > > >
> > >
> > > # cd /sys/bus/nd/devices
> > > # uuidgen > btt6/uuid
> > > # echo 4096 > btt6/sector_size
> > > # echo namespace6.0 > btt6/namespace
> > > # echo namespace6.0 > ../drivers/nd_pmem/unbind
> > > # echo btt6 > ../drivers/nd_pmem/bind
> > >
> > > After reboot, when the system sees namespace6.0 again it will notice
> > > the btt instance and attach bttX instead. The net effect is that now
> > > you'll only ever have /dev/pmem6 or /dev/pmem6s, never both at the
> > > same time that was a side effect of the stacking approach.
> > >
> > > I'll post the patch that updates libndctl and the unit tests shortly
> >
> > Maybe I am missing something, but I am getting errors on my system. (I
> > used btt0 since there is no btt6.)
> >
> > # cat bind.sh
> > set -x
> > cd /sys/bus/nd/devices
> > uuidgen > btt0/uuid
> > echo 4096 > btt0/sector_size
> > echo namespace0.0 > btt0/namespace
> > echo namespace0.0 > ../drivers/nd_pmem/unbind
> > echo btt0 > ../drivers/nd_pmem/bind
> >
> > # sh bind.sh
> > + cd /sys/bus/nd/devices
> > + uuidgen
> > + echo 4096
> > + echo namespace0.0
> > bind.sh: line 6: echo: write error: Device or resource busy
> > + echo namespace0.0
> > bind.sh: line 7: echo: write error: No such device
> > + echo btt0
> > bind.sh: line 8: echo: write error: No such device
> >
> > # dmesg
> > :
> > [12513.839162] nd btt0: uuid_store: result: 0 wrote:
> > b32cd195-9aae-4c54-a5ac-49adb50a8a98
> > [12513.880286] nd btt0: sector_size_store: result: 0 wrote: 4096
> > [12513.909494] nd btt0: namespace0.0 already claimed
> > [12513.933364] nd btt0: namespace_store: result: -16 wrote: namespace0.0
> > [12513.966808] ndbus0: nd_pmem.probe(btt0) = -19
> >
>
> So this turned out to be a perfect example of why we might want to have
> the region-id in the btt device name just like namespaces, because btt0
> was actually bound to namespace4.0 on Toshi's system. The following
> update, that I will fold in to the series, fixes this. Note that the
> association of btt id to to namespace is still non-deterministic. I.e.
> btt0.1 could be assigned as the btt for namespace0.0, but at least when
> looking at /sys/bus/nd/devices it will be clear which btts belong to
> which regions.
>
> # ls /sys/bus/nd/devices
> btt0.0 btt3.0 btt6.0namespace2.0 namespace5.0 nmem1 nmem4
> region2 region5
> btt1.0 btt4.0 namespace0.0 namespace3.0 namespace6.0 nmem2 region0
> region3 region6
> btt2.0 btt5.0 namespace1.0 namespace4.0 nmem0 nmem3 region1
> region4
Yes, this works nicely. :-)
Now, how do I unbind BTT? I did the following as a guess, but BTT got
reattached again before I have a chance to delete the metadata, which I
need /dev/pmemN.
NUM=1
cd /sys/bus/nd/devices
echo "" > btt${NUM}.1/namespace
echo btt${NUM}.1 > ../drivers/nd_pmem/unbind
echo namespace${NUM}.0 > ../drivers/nd_pmem/bind
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.
On Thursday, June 25, 2015 12:29:02 AM Zheng, Lv wrote: > Hi, Rafael > > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > Sent: Thursday, June 25, 2015 7:24 AM > > To: Zheng, Lv [cut] > > > > In fact, I don't see why we need to redefine the symbols at all. > > > > Couldn't acpi_set_firmware_waking_vector() be defined to take u32 and u64 so > > we could just pass acpi_wakeup_address (as already defined) as the first > > argument > > and 0 as the second argument to it? The back-and-forth type casts from and > > to acpi_physical_address don't look entirely clean to me. > > > > Moreover, I don't really see a functional difference between the old and the > > new code. > > > > The old code does "set the 32-bit waking vector and clear the 64-bit waking > > vector if present". The new code does "set the 32-bit waking vector and > > either clear the 64-bit one if present, or assign the second function > > argument > > to it", but we always pass 0 as the second argument (which is *extremely* > > obfuscated in your patch), so I really don't see the difference here. > > > > Am I missing anything? > > The story is: > According to the test, if both 32-bit waking vector and 64-bit waking vector > is > set by the OSPM, The current code in Linux never does that. It never calls acpi_set_firmware_waking_vector64() and the acpi_set_firmware_waking_vector() (before your patch) explicitly clears the 64-bit vector address. > BIOSes only support 32-bit resume environment will jump to the 32-bit waking > vector address and BIOSes support 64-bit resume environment will jump to > 64-bit waking vector. Which doesn't matter for Linux one whit. > So they can be set by the OSPMs simultaneously to indicate that the OSPM can > support both resume environments. That's why ACPICA interface is changed. It shouldn't. It just forces host OSes to make pointless changes to their non-ACPICA code. As I said elsewhere, the old acpi_set_firmware_waking_vector() should still be available to the OSes that don't care about the 64-bit waking vector and a *new* interface should be added for those OSes that do care about it. And *internally* acpi_set_firmware_waking_vector() can be defined in terms of the new interface, but there's no reason at all for a host OS to care about that. So the $subject patch is entirely poitless. It doesn't fix anything and it doesn't even change the way the code works today in Linux. It just adds complexity and pointlessly redefines some stuff. So I'm not going to apply it. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 05/28] ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS.
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Friday, June 26, 2015 8:44 AM
>
> On Thursday, June 25, 2015 12:43:39 AM Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > > Sent: Thursday, June 25, 2015 7:57 AM
> > >
>
> [cut]
>
> > > >
> > > > +/***
> > > > + *
> > > > + * FUNCTION:acpi_set_firmware_waking_vector
> > > > + *
> > > > + * PARAMETERS: physical_address- 32-bit physical address of ACPI
> > > > real mode
> > > > + *entry point
> > > > + * physical_address64 - 64-bit physical address of ACPI
> > > > protected
> > > > + *entry point
> > > > + *
> > > > + * RETURN: Status
> > > > + *
> > > > + * DESCRIPTION: Sets the firmware_waking_vector fields of the FACS
> > > > + *
> > > > +
> > > > **/
> > > > +
> > > > +acpi_status
> > > > +acpi_set_firmware_waking_vector(acpi_physical_address physical_address,
> > > > + acpi_physical_address
> > > > physical_address64)
> > >
> > > The question here is: Why does the host OS need to care about the second
> > > argument of this function that will always be 0? Why didn't you keep the
> > > old header of acpi_set_firmware_waking_vector() as a one-argument function
> > > taking a u32 and why didn't you add something like
> > >
> > > acpi_status acpi_set_firmware_waking_vector_full(u32 real_mode_address,
> > > acpi_physical_address high_address)
> > >
> > > and why didn't you redefine acpi_set_firmware_waking_vector() as
> > >
> > > acpi_status acpi_set_firmware_waking_vector(u32 real_mode_address)
> > > {
> > > return acpi_set_firmware_waking_vector_full(real_mode_address, 0);
> > > }
> > >
> > > ?
> > >
> > > If you did that, there wouldn't be any need to touch the code in
> > > drivers/acpi/sleep.c and the arch headers, so can you please explain to me
> > > why *exactly* you didn't do that?
> >
> > Host OS can set non 0 address for both real_mode_address and high_address
> > to indicate that it can support both 32-bit and 64-bit
> resume environments.
> > So if a BIOS favors 32-bit resume environment, it can resume from here; if
> > another BIOS favors 64-bit resume environment, it can
> resume from there.
> > And host OSes can be implemented using only 1 binary to work with both
> > BIOSes.
>
> I'm not talking about that.
>
> It is fine to provide a *new* interface for the OSes that want to do that
> (if any), but *why* is that regarded as a good enough reason for essentially
> *removing* the old interface that Linux (and presumably other OSes too) have
> been using so far?
Maybe we should ask Bob if we shall just provide a new interfaces for this and
keep the old ones?
According to my understanding, there is no such example in the ACPICA upstream.
Some _full functions are still pending for being merged by ACPICA upstream,
they are divergences for now.
>
> We don't want to pass nonzero as high_address anyway, so why are we *forced*
> to
> make pointless changes to non-ACPICA code just to be able to always pass 0
> as high_address?
IMO, OSPMs can do this if the cost is not high.
It seems by following your suggestion, we only need to do slight changes in
sleep.c.
Thanks and best regards
-Lv
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] USB: cp210x: add ID for Aruba Networks controllers
Add the USB serial console device ID for Aruba Networks 7xxx series
controllers which have a USB port for their serial console.
Signed-off-by: Peter Sanford
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index ffd739e..eac7cca 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -187,6 +187,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1FB9, 0x0602) }, /* Lake Shore Model 648 Magnet Power
Supply */
{ USB_DEVICE(0x1FB9, 0x0700) }, /* Lake Shore Model 737 VSM Controller
*/
{ USB_DEVICE(0x1FB9, 0x0701) }, /* Lake Shore Model 776 Hall Matrix */
+ { USB_DEVICE(0x2626, 0xEA60) }, /* Aruba Networks 7xxx USB Serial
Console */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
{ USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] mtd: docg3: Don't do ERR_PTR(0)
On Thu, Jun 25, 2015 at 07:14:18PM +0200, Robert Jarzmik wrote: > From 20002639eac1bd7a81b0613c4bd15ae7522c269d Mon Sep 17 00:00:00 2001 > From: Robert Jarzmik > Date: Thu, 25 Jun 2015 19:07:48 +0200 > Subject: [PATCH] MAINTAINERS: mtd: docg3: add docg3 maintainer > > Add myself as maintainer of the NAND based MSystems DiskOnChip G3 > driver. > > Signed-off-by: Robert Jarzmik Queued, thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
