Re: Audio crackles with 4.1-rc1
At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: > > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > > > From: Takashi Iwai > > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 > > > > > > & co > > > > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives > > > > > > click > > > > > > noises at transition from D3 to D0 when the widget power-saving is > > > > > > enabled. Further debugging session showed that avoiding it isn't > > > > > > trivial, unfortunately, since paths are basically activated > > > > > > dynamically while the pins have been already enabled. > > > > > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > > > > > Reported-by: Jonathan McDowell > > > > > > Signed-off-by: Takashi Iwai > > > > > > --- > > > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c > > > > > > b/sound/pci/hda/patch_realtek.c > > > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > > > --- a/sound/pci/hda/patch_realtek.c > > > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec > > > > > > *codec) > > > > > > > > > > > > spec = codec->spec; > > > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > > > - codec->power_save_node = 1; > > > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > > > + codec->power_save_node = 1; > > > > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > > > >alc269_fixup_tbl, alc269_fixups); > > > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > > > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > > > > E7440): > > > > > > > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for > > > > > ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > > > [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 > > > > > (0x14/0x0/0x0/0x0/0x0) > > > > > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > > > > > (0x15/0x0/0x0/0x0/0x0) > > > > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: > > > > > mono_out=0x0 > > > > > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > > > > > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > > > > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset > > > > > Mic=0x1a > > > > > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal > > > > > Mic=0x12 > > > > > > > > > > 4.0.4 was fine. > > > > > > > > Does it happen only once at boot (i.e. at power up), or happens always > > > > at runtime PM? If it's a once-off boot thing, the patch shouldn't > > > > have much effect. Something else, very subtle thing, e.g. the order > > > > of verb execution, might cause this kind of problem. > > > > > > Only at power up. I've also suspend-resumed twice and can confirm it's > > > OK. > > > > > > There's a _very_ brief click at suspend (when the power is cut), but it > > > looks like a plain circuitry thing. I probably didn't notice it before > > > because I wasn't looking for it. > > > > Thanks. Do you get the same click noise when reloading snd-hda-intel > > driver? Also, does it happen when booting in runlevel 3? > > > > Last but not least, a patch like below has any effect? > > > > > > Takashi > > > > --- > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > > --- a/sound/pci/hda/hda_codec.c > > +++ b/sound/pci/hda/hda_codec.c > > @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct > > hda_codec *codec, > > break; > > } > > > > + if (power_state == AC_PWRST_D0) > > + msleep(100); > > return state; > > } > > > > Reloading snd-hda-intel does not trigger the noise, but it helps. I've > noticed that the clicks appear when loading/reloading pulseaudio. > > $ pulseaudio -k > > will spawn a new child in background (probably asked by kmix) and > immediately I hear the noise. Reloading the driver makes the problem go > away. Hm. It's a bit inconsistent, but still this can be only at the full power up sequence. > telinit 3 does nothing for me (Gentoo seems to have things wired > differently). Manually reloading alsasound (/etc/init.d/alsasound) did > not trigger the problem either. > > However! Your patch seems to work. Cold boot, pulseaudio restart and > nothing. Not a peep. :-) OK, could you try to reduce the sleep value from 100 to 10? Does it still work? thanks, Takashi --
Re: [PATCH] devicetree: xilinx: zynqmp: add sata node
On 06/10/2015 12:16 PM, Suneel Garapati wrote:
> add sata node with sata fixed clock nodes in dtsi file.
> enable sata in zynqmp-ep108.dts with broken-gen2.
>
> Signed-off-by: Suneel Garapati
> ---
> Note -
> Driver and bindings are added via libata/for-4.2 tree
> bindings is found in Documentation/devicetree/bindings/ata/ahci-ceva.txt
> ---
> arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 5 +
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 15 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> index 0a3f40e..981e594 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> @@ -42,6 +42,11 @@
> };
> };
>
> + {
> + status = "okay";
> + ceva,broken-gen2;
> +};
> +
> {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index 11e0b00..e7545ed 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -272,6 +272,21 @@
> #size-cells = <0>;
> };
>
> + sata_clk: sata_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <7500>;
> + };
> +
> + sata0: ahci@fd0c {
> + compatible = "ceva,ahci-1v84";
> + status = "disabled";
> + reg = <0x0 0xfd0c 0x2000>;
> + interrupt-parent = <>;
> + interrupts = <0 133 4>;
> + clocks = <_clk>;
> + };
> +
> sdhci0: sdhci@ff16 {
> compatible = "arasan,sdhci-8.9a";
> status = "disabled";
> --
> 2.1.2
>
Reviewed-by: Michal Simek
Thanks,
Michal
--
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 v3] sbs-battery: add option to always register battery
Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
device") introduced a step in probing the SBS battery, that tries to
talk to the device before actually registering it, saying:
this driver doesn't actually try talking to the device at probe
time, so if it's incorrectly configured in the device tree or
platform data (or if the battery has been removed from the system),
then probe will succeed and every access will sit there and time
out. The end result is a possibly laggy system that thinks it has a
battery but can never read status, which isn't very useful.
Which is of course reasonable. However, it is also very well possible
for a device to boot up on wall-power and be connected to a battery
later on. This is a scenario that the driver supported before said patch
was applied, and even easily achieved by booting up with the battery
attached and removing it later on. sbs-battery's 'present' sysfs file
can be used to determine if the device is available or not.
So with automated device detection lacking for now, in some cases it is
possible that one wants to register a battery, even if none are attached
at the moment. To facilitate this, add a module parameter that can be
used to configure forced loading module loading time. If set, the battery
will always be registered without checking the sanity of the connection.
Signed-off-by: Frans Klaver
---
v2..v3
- Switch from Kconfig to module parameter approach
- Move entire sanity check into if () clause, rather than using 'rc = 0'
v1..v2
device tree -> Kconfig
drivers/power/sbs-battery.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/power/sbs-battery.c b/drivers/power/sbs-battery.c
index c7b7b4018df3..3ccd3f172130 100644
--- a/drivers/power/sbs-battery.c
+++ b/drivers/power/sbs-battery.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -170,6 +171,7 @@ struct sbs_info {
static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
static char manufacturer[I2C_SMBUS_BLOCK_MAX + 1];
+static bool force_load;
static int sbs_read_word_data(struct i2c_client *client, u8 address)
{
@@ -882,14 +884,17 @@ static int sbs_probe(struct i2c_client *client,
skip_gpio:
/*
-* Before we register, we need to make sure we can actually talk
+* Before we register, we might need to make sure we can actually talk
* to the battery.
*/
- rc = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
- if (rc < 0) {
- dev_err(>dev, "%s: Failed to get device status\n",
- __func__);
- goto exit_psupply;
+ if (!force_load) {
+ rc = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
+
+ if (rc < 0) {
+ dev_err(>dev, "%s: Failed to get device
status\n",
+ __func__);
+ goto exit_psupply;
+ }
}
rc = power_supply_register(>dev, >power_supply);
@@ -990,3 +995,7 @@ module_i2c_driver(sbs_battery_driver);
MODULE_DESCRIPTION("SBS battery monitor driver");
MODULE_LICENSE("GPL");
+
+module_param(force_load, bool, S_IRUSR | S_IRGRP | S_IROTH);
+MODULE_PARM_DESC(force_load,
+"Attempt to load the driver even if no battery is connected");
--
2.3.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: [Cluster-devel] [PATCH] dlm: remove unnecessary error check
- Original Message -
> Bob Peterson wrote:
> > - Original Message -
> >
> >> Hi Bob,
> >>
> >> Bob Peterson wrote:
> >>
> >>> - Original Message -
> >>>
> >>>
> We don't need the redundant logic since send_message always returns 0.
>
> Signed-off-by: Guoqing Jiang
> ---
> fs/dlm/lock.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
> index 35502d4..6fc3de9 100644
> --- a/fs/dlm/lock.c
> +++ b/fs/dlm/lock.c
> @@ -3656,10 +3656,7 @@ static int send_common(struct dlm_rsb *r, struct
> dlm_lkb *lkb, int mstype)
>
> send_args(r, lkb, ms);
>
> -error = send_message(mh, ms);
> -if (error)
> -goto fail;
> -return 0;
> +return send_message(mh, ms);
Hi Guoqing,
Sorry, I was momentarily confused. I think you misunderstood what I was saying.
What I meant was: Instead of doing:
+ return send_message(mh, ms);
...where send_message returns 0, it might be better to have:
static void send_message(struct dlm_mhandle *mh, struct dlm_message *ms)
{
dlm_message_out(ms);
dlm_lowcomms_commit_buffer(mh);
}
...And in send_common, do (in both places):
+ send_message(mh, ms);
+ return 0;
Since it's so short, it might even be better to code send_message as a macro,
or at least an "inline" function.
Regards,
Bob Peterson
Red Hat File Systems
--
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] ARM: module: Add ".ref.text" to arm unwind tables
Gentle reminder for review comments.
> Forgot to add Maintainers. Adding them now.
>
>> On 05/13/2015 08:20 AM, Vignesh Radhakrishnan wrote:
>>> Functions inside kernel modules that use __ref
>>> will end up being placed in .ARM.exidx.ref.text
>>> section by gcc.
>>>
>>> Currently we don't consider adding these functions
>>> to arm unwind tables.
>>>
>>> Hence, if we turn slub debug on by default we end up
>>> with the messages of this sort:
>>>
>>> unwind: Index not found bf0011e0
>>>
>>> This is because slub debug saves stack trace of
>>> allocation's and free's. Therefore, we end up seeing
>>> a flood of these messages in dmesg since its not
>>> able to locate these functions.
>>>
>>> Fix this by adding .ref.text section to arm unwind tables.
>>>
>>
>> With this patch, I go from
>>
>> [ cut here ]
>> WARNING: CPU: 0 PID: 63 at drivers/misc/test.c:12
>> that_function+0x10/0x2c
>> [test]()
>> Modules linked in: test(P+)
>> CPU: 0 PID: 63 Comm: insmod Tainted: P4.1.0-rc2+ #28
>> Hardware name: ARM-Versatile PB
>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>> [] (show_stack) from []
>> (warn_slowpath_common+0x78/0xb0)
>> [] (warn_slowpath_common) from []
>> (warn_slowpath_null+0x1c/0x24)
>> [] (warn_slowpath_null) from []
>> (that_function+0x10/0x2c [test])
>> unwind: Index not found bf48
>> ---[ end trace 3e24f8edd90f3b27 ]---
>>
>> to
>>
>> [ cut here ]
>> WARNING: CPU: 0 PID: 63 at drivers/misc/test.c:12
>> that_function+0x10/0x2c
>> [test]()
>> Modules linked in: test(P+)
>> CPU: 0 PID: 63 Comm: insmod Tainted: P4.1.0-rc2+ #30
>> Hardware name: ARM-Versatile PB
>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>> [] (show_stack) from []
>> (warn_slowpath_common+0x78/0xb0)
>> [] (warn_slowpath_common) from []
>> (warn_slowpath_null+0x1c/0x24)
>> [] (warn_slowpath_null) from []
>> (that_function+0x10/0x2c [test])
>> [] (that_function [test]) from []
>> (awesome_module+0x10/0x1c [test])
>> [] (awesome_module [test]) from []
>> (do_one_initcall+0x80/0x1dc)
>> [] (do_one_initcall) from []
>> (do_init_module+0x58/0x1a8)
>> [] (do_init_module) from []
>> (load_module+0x170c/0x1c38)
>> [] (load_module) from []
>> (SyS_init_module+0xcc/0x124)
>> [] (SyS_init_module) from []
>> (ret_fast_syscall+0x0/0x30)
>> ---[ end trace 554c9ff461eb2505 ]---
>>
>> Tested-by: Laura Abbott
>>
>>> Signed-off-by: Vignesh Radhakrishnan
>>> ---
>>> arch/arm/include/asm/module.h | 1 +
>>> arch/arm/kernel/module.c | 4
>>> 2 files changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/include/asm/module.h
>>> b/arch/arm/include/asm/module.h
>>> index ed690c4..17640c9 100644
>>> --- a/arch/arm/include/asm/module.h
>>> +++ b/arch/arm/include/asm/module.h
>>> @@ -14,6 +14,7 @@ enum {
>>> ARM_SEC_DEVEXIT,
>>> ARM_SEC_HOT,
>>> ARM_SEC_UNLIKELY,
>>> + ARM_SEC_REF,
>>> ARM_SEC_MAX,
>>> };
>>>
>>> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
>>> index 2e11961..846b888 100644
>>> --- a/arch/arm/kernel/module.c
>>> +++ b/arch/arm/kernel/module.c
>>> @@ -308,6 +308,8 @@ int module_finalize(const Elf32_Ehdr *hdr, const
>>> Elf_Shdr *sechdrs,
>>> maps[ARM_SEC_UNLIKELY].unw_sec = s;
>>> else if (strcmp(".ARM.exidx.text.hot", secname) == 0)
>>> maps[ARM_SEC_HOT].unw_sec = s;
>>> + else if (strcmp(".ARM.exidx.ref.text", secname) == 0)
>>> + maps[ARM_SEC_REF].unw_sec = s;
>>> else if (strcmp(".init.text", secname) == 0)
>>> maps[ARM_SEC_INIT].txt_sec = s;
>>> else if (strcmp(".text", secname) == 0)
>>> @@ -318,6 +320,8 @@ int module_finalize(const Elf32_Ehdr *hdr, const
>>> Elf_Shdr *sechdrs,
>>> maps[ARM_SEC_UNLIKELY].txt_sec = s;
>>> else if (strcmp(".text.hot", secname) == 0)
>>> maps[ARM_SEC_HOT].txt_sec = s;
>>> + else if (strcmp(".ref.text", secname) == 0)
>>> + maps[ARM_SEC_REF].txt_sec = s;
>>> }
>>>
>>> for (i = 0; i < ARM_SEC_MAX; i++)
>>>
>>
>>
>
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of the Code Aurora Forum, hosted by The Linux Foundation.
> again
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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 00/21] On-demand device registration
On 06/10/2015 12:19 PM, Tomeu Vizoso wrote: > On 10 June 2015 at 09:30, Linus Walleij wrote: >> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso >> wrote: >>> On 2 June 2015 at 10:48, Linus Walleij wrote: >> This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) >>> >>> I understood above that you propose probing devices in order, but now >>> you mention that resource getters would block until the dependency is >>> fulfilled which confuses me because if we are probing in order then >>> all dependencies would be fulfilled before the device in question gets >>> probed. >> >> Sorry, the problem space is a bit convoluted so the answers >> get a bit convoluted. Maybe I'm thinking aloud and altering the course >> of my thoughts as I type... >> >> I guess there can be explicit dependencies for resources like this >> patch does, but another way would be for all resource fetch functions >> to be instrumented, so that you do not block until you try to take >> a resource that is not yet there, e.g.: >> >> regulator_get(...) -> not available, so: >> - identify target regulator provider - this will need instrumentation >> - probe it >> >> It then turns out the regulator driver is on the i2c bus, so we >> need to probe the i2c driver: >> - identify target i2c host for the regulator driver - this will need >> instrumentation >> - probe the i2c host driver >> >> i2c host comes out, probes the regulator driver, regulator driver >> probes and then the regulator_get() call returns. > > Hmm, if I understand correctly what you say, this is exactly what this > particular series does: > > regulator_get -> of_platform_device_ensure -> probe() on the platform > device that encloses the requested device node (i2c host) -> i2c slave > gets probed and the regulator registered -> regulator_get returns the > requested resource The downside of this solution is that it will not work without device tree or even without device dependencies not explicitly specified in device tree. > > The downside I'm currently looking at is that an explicit dependency > graph would be useful to have for other purposes. For example to print > a neat warning when a dependency cannot be fulfilled. Or to refuse to > unbind a device which other devices depend on, As I understand Greg you cannot prevent unbinding by design, see [1]. [1]: http://thread.gmane.org/gmane.linux.kernel/1154308/focus=1154648 > or to automatically > unbind the devices that depend on it, What about devices that have weak dependency? They should not be unbound but they should be somehow noticed about unbinding. In general many kernel frameworks are broken in handling hot-unbinding of drivers, consumers are not noticed about unbinding of their resource providers and usually they stay with broken handles or handles to dummy resources. I suspect the only proper solution for handling resources that can dynamically appear/disappear is to provide notification to their consumers about appearance change of the resource. I have proposed some times ago solution for above problems based on the statement above, cover letter explains it in more detail [2]. In short it solves following issues: - consumer receives resource as soon as it becomes available, - consumer is notified just before resource removal, - it can properly handle provider unbind/re-bind, - it avoids late init due to deferred probing, - it allows to track optional resources. [2]: http://thread.gmane.org/gmane.linux.kernel.gpio/5201 Regards Andrzej > or to print a warning if a > device is hotplugged off and other devices depend on it. > >> This requires instrumentation on anything providing a resource >> to another driver like those I mentioned and a lot of overhead >> infrastructure, but I think it's the right approach. However I don't >> know if I would ever be able to pull that off myself, I know talk >> is cheap and I should show the code instead. > > Yeah, if you can give it a second look and say if it matches what you > wrote above, it would be very much appreciated. > >> Deepest respect for your efforts! > > Thanks! > > Tomeu > >> Yours, >> Linus Walleij >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- > To unsubscribe from this list: send the line "unsubscribe linux-gpio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To
Re: [RFC] panic_on_oom_timeout
Michal Hocko wrote: > Hi, > during the last iteration of the timeout based oom killer discussion > (http://marc.info/?l=linux-mm=143351457601723) I've proposed to > introduce panic_on_oom_timeout as an extension to panic_on_oom rather > than oom timeout which would allow OOM killer to select another oom > victim and do that until the OOM is resolved or the system panics due to > potential oom victims depletion. I welcome the timeout, but I have several questions about implementation. > > My main rationale for going panic_on_oom_timeout way is that this > approach will lead to much more predictable behavior because the system > will get to a usable state after given amount of time + reboot time. > On the other hand, if the other approach was chosen then there is no > guarantee that another victim would be in any better situation than the > original one. In fact there might be many tasks blocked on a single lock > (e.g. i_mutex) and the oom killer doesn't have any way to find out which > task to kill in order to make the progress. The result would be > N*timeout time period when the system is basically unusable and the N is > unknown to the admin. My version ( http://marc.info/?l=linux-mm=143239200805478 ) implemented two timeouts. /proc/sys/vm/memdie_task_skip_secs is for choosing next OOM victim and /proc/sys/vm/memdie_task_panic_secs is for triggering panic. Therefore, the result is no longer N*timeout time period. > > I think that it is more appropriate to shut such a system down when such > a corner case is hit rather than struggle for basically unbounded amount > of time. Ditto. Not unbounded amount of time. > > Thoughts? An RFC implementing this is below. It is quite trivial and > I've tried to test it a bit. I will add the missing pieces if this looks > like a way to go. > > There are obviously places in the oom killer and the page allocator path > which could be improved and this patch doesn't try to put them aside. It > is just providing a reasonable the very last resort when things go > really wrong. > --- > From 35b7cff442326c609cdbb78757ef46e6d0ca0c61 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 9 Jun 2015 16:15:42 +0200 > Subject: [RFC] oom: implement panic_on_oom_timeout > > OOM killer is a desparate last resort reclaim attempt to free some > memory. It is based on heuristics which will never be 100% and may > result in an unusable or a locked up system. > > panic_on_oom sysctl knob allows to set the OOM policy to panic the > system instead of trying to resolve the OOM condition. This might be > useful for several reasons - e.g. reduce the downtime to a predictable > amount of time, allow to get a crash dump of the system and debug the > issue post-mortem. > > panic_on_oom is, however, a big hammer in many situations when the > OOM condition could be resolved in a reasonable time. So it would be > good to have some middle ground and allow the OOM killer to do its job > but have a failover when things go wrong and it is not able to make any > further progress for a considerable amount of time. > > This patch implements panic_on_oom_timeout sysctl which is active > only when panic_on_oom!=0 and it configures a maximum timeout for > the OOM killer to resolve the OOM situation. If the system is still > under OOM after the timeout expires it will panic the system as per > panic_on_oom configuration. A reasonably chosen timeout can protect from > both temporal OOM conditions and allows to have a predictable time frame > for the OOM condition. Since your version uses the oom_ctx as a global lock (it acts as a lock because it is assigned when atomic_read(_victims) == 0) without holding a refcount, you cannot safely handle OOM race like (1) p1 in memcg1 calls out_of_memory(). (2) memcg1 is copied to oom_ctx.memcg and 5 seconds of timeout starts. (3) mark_oom_victim(p1) is called. (4) p1 takes 3 seconds for some reason. (5) p2 in memcg2 calls out_of_memory(). (6) mark_oom_victim(p2) is called. (7) p1 calls unmark_oom_victim(). (8) all threads in memcg1 exits and memcg1 is released. (9) p2 takes 2 seconds for some reason. (10) 5 seconds of timeout expires despite individual delay was less than 5 seconds!? (11) panic_on_oom tries to dereference oom_ctx.memcg which is already released memcg1, resulting in oops. But panic() will not be called if panic_on_oops == 0 because workqueue callback is a sleepable context!? Since my version uses per a "struct task_struct" variable (memdie_start), 5 seconds of timeout is checked for individual memory cgroup. It can avoid unnecessary panic() calls if nobody needs to call out_of_memory() again (probably because somebody volunteered memory) when the OOM victim cannot be terminated for some reason. If we want distinction between "the entire system is under OOM" and "some memory cgroup is under OOM" because the former is urgent but the latter is less urgent, it can be modified to allow
Re: [PATCH v5 00/10] x86/asm: Compile-time asm code validation
On Wed, Jun 10, 2015 at 07:06:08AM -0500, Josh Poimboeuf wrote: > There are still a lot of outstanding warnings (which I'll paste as a > reply to this email). Once those are all cleaned up, we can change the > warnings to build errors and change the default to > CONFIG_ASM_VALIDATION=y so the asm code stays clean. Here are the 194 outstanding warnings I'm seeing with my Fedora kernel config. I'll keep chipping away at them. asmvalidate: arch/x86/crypto/crc32c-pcl-intel-asm_64.o: crc_pcl()+0x84: unsupported jump to outside of function asmvalidate: arch/x86/crypto/crc32c-pcl-intel-asm_64.o: crc_pcl(): unsupported fallthrough at end of function asmvalidate: arch/x86/crypto/sha1_avx2_x86_64_asm.o: sha1_transform_avx2()+0x645: unsupported jump to outside of function asmvalidate: arch/x86/crypto/sha1_avx2_x86_64_asm.o: sha1_transform_avx2()+0x1418: unsupported jump to outside of function asmvalidate: arch/x86/crypto/sha1_avx2_x86_64_asm.o: sha1_transform_avx2()+0x16e4: unsupported jump to outside of function asmvalidate: arch/x86/crypto/sha1_avx2_x86_64_asm.o: sha1_transform_avx2()+0x1a22: unsupported jump to outside of function asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: __camellia_enc_blk16(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: __camellia_dec_blk16(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_ecb_enc_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_ecb_dec_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_cbc_dec_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_ctr_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_xts_crypt_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_xts_enc_16way()+0xb: unsupported jump to outside of function asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_xts_enc_16way(): unsupported fallthrough at end of function asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_xts_dec_16way()+0x1e: unsupported jump to outside of function asmvalidate: arch/x86/crypto/camellia-aesni-avx-asm_64.o: camellia_xts_dec_16way(): unsupported fallthrough at end of function asmvalidate: arch/x86/crypto/cast5-avx-x86_64-asm_64.o: cast5_ecb_enc_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast5-avx-x86_64-asm_64.o: cast5_ecb_dec_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast5-avx-x86_64-asm_64.o: cast5_cbc_dec_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast5-avx-x86_64-asm_64.o: cast5_ctr_16way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast6-avx-x86_64-asm_64.o: cast6_ecb_enc_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast6-avx-x86_64-asm_64.o: cast6_ecb_dec_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast6-avx-x86_64-asm_64.o: cast6_cbc_dec_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast6-avx-x86_64-asm_64.o: cast6_ctr_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast6-avx-x86_64-asm_64.o: cast6_xts_enc_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/cast6-avx-x86_64-asm_64.o: cast6_xts_dec_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/twofish-avx-x86_64-asm_64.o: twofish_ecb_enc_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/twofish-avx-x86_64-asm_64.o: twofish_ecb_dec_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/twofish-avx-x86_64-asm_64.o: twofish_cbc_dec_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/twofish-avx-x86_64-asm_64.o: twofish_ctr_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/twofish-avx-x86_64-asm_64.o: twofish_xts_enc_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/twofish-avx-x86_64-asm_64.o: twofish_xts_dec_8way(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/serpent-avx-x86_64-asm_64.o: serpent_ecb_enc_8way_avx(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/serpent-avx-x86_64-asm_64.o: serpent_ecb_dec_8way_avx(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/serpent-avx-x86_64-asm_64.o: serpent_cbc_dec_8way_avx(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/serpent-avx-x86_64-asm_64.o: serpent_ctr_8way_avx(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/serpent-avx-x86_64-asm_64.o: serpent_xts_enc_8way_avx(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/serpent-avx-x86_64-asm_64.o: serpent_xts_dec_8way_avx():
[PATCH v6 1/2] ASoC: qcom: document apq8016 sbc machine driver bindings
This patch adds bindings for apq8016 sbc machine driver.
APQ8016 has 4 MI2S which can be configured to different sinks like
internal codec/external codec, this connection and various parameters
are controlled via 2 iomux registers.
Acked-by: Kenneth Westfield
Signed-off-by: Srinivas Kandagatla
---
.../devicetree/bindings/sound/qcom,apq8016-sbc.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
new file mode 100644
index 000..4812936
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
@@ -0,0 +1,60 @@
+* Qualcomm Technologies APQ8016 SBC ASoC machine driver
+
+This node models the Qualcomm Technologies APQ8016 SBC ASoC machine driver
+
+Required properties:
+
+- compatible : "qcom,apq8016-sbc-sndcard"
+
+- pinctrl-N: One property must exist for each entry in
+ pinctrl-names. See ../pinctrl/pinctrl-bindings.txt
+ for details of the property values.
+- pinctrl-names: Must contain a "default" entry.
+- reg : Must contain an address for each entry in reg-names.
+- reg-names: A list which must include the following entries:
+ * "mic-iomux"
+ * "spkr-iomux"
+- qcom,model : Name of the sound card.
+
+Dai-link subnode properties and subnodes:
+
+Required dai-link subnodes:
+
+- cpu : CPU sub-node
+- codec: CODEC sub-node
+
+Required CPU/CODEC subnodes properties:
+
+-link-name : Name of the dai link.
+-sound-dai : phandle and port of CPU/CODEC
+-capture-dai : phandle and port of CPU/CODEC
+
+Example:
+
+sound: sound {
+ compatible = "qcom,apq8016-sbc-sndcard";
+ reg = <0x07702000 0x4>, <0x07702004 0x4>;
+ reg-names = "mic-iomux", "spkr-iomux";
+ qcom,model = "DB410c";
+
+ /* I2S - Internal codec */
+ internal-dai-link@0 {
+ cpu { /* PRIMARY */
+ sound-dai = < MI2S_PRIMARY>;
+ };
+ codec {
+ sound-dai = <_codec 0>;
+ };
+ };
+
+ /* External Primary or External Secondary -ADV7533 HDMI */
+ external-dai-link@0 {
+ link-name = "ADV7533";
+ cpu { /* QUAT */
+ sound-dai = < MI2S_QUATERNARY>;
+ };
+ codec {
+ sound-dai = <_bridge 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/
[PATCH v6 0/2] ASoC: qcom: add support to apq8016 sbc machine driver
This patchset adds sound card support to APQ8016 SBC board aka DB410c. APQ8016 has 4 MI2S( Primary, Secondary, Tertiary, Quaternary) which can be routed to internal wcd codec or external codecs. This routing and various board specifics are controlled by 2 mux registers. All these patches are tested for HDMI audio via adv7533 bridge and Analog audio on APQ8016-SBC, msm8916-mtp boards. Changes since v5: - converted if-else to switch case as suggested by Mark. - moved usage of startup() to dai link init() as suggested by Mark. - replaced "external" boolean property with "link-name" property as suggested by Mark. Changes since v4 (https://lkml.org/lkml/2015/5/22/628) - moved all the dt parsing to single function, spotted by Mark. - removed unnecessary setting of card->dev = NULL spotted by Mark. - renamed the dai links to the correct codec names. - removed the special case for EPROBE_DEFER in probe, spotted by Mark. - Dropped all the Changes since comments as most of the patches in last series are merged to topic/qcom branch. --srini Srinivas Kandagatla (2): ASoC: qcom: document apq8016 sbc machine driver bindings ASoC: qcom: add apq8016 sound card support .../devicetree/bindings/sound/qcom,apq8016-sbc.txt | 60 +++ sound/soc/qcom/Kconfig | 9 + sound/soc/qcom/Makefile| 2 + sound/soc/qcom/apq8016_sbc.c | 198 + 4 files changed, 269 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt create mode 100644 sound/soc/qcom/apq8016_sbc.c -- 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 v6 2/2] ASoC: qcom: add apq8016 sound card support
This patch adds apq8016 machine driver support. This patch is tested on
DB410c and msm8916-mtp board for both hdmi and analog audio
features.
Acked-by: Kenneth Westfield
Signed-off-by: Srinivas Kandagatla
---
sound/soc/qcom/Kconfig | 9 ++
sound/soc/qcom/Makefile | 2 +
sound/soc/qcom/apq8016_sbc.c | 198 +++
3 files changed, 209 insertions(+)
create mode 100644 sound/soc/qcom/apq8016_sbc.c
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 938144c..807fedf 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -32,3 +32,12 @@ config SND_SOC_STORM
help
Say Y or M if you want add support for SoC audio on the
Qualcomm Technologies IPQ806X-based Storm board.
+
+config SND_SOC_APQ8016_SBC
+ tristate "SoC Audio support for APQ8016 SBC platforms"
+ depends on SND_SOC_QCOM && (ARCH_QCOM || COMPILE_TEST)
+ select SND_SOC_LPASS_APQ8016
+ help
+ Support for Qualcomm Technologies LPASS audio block in
+ APQ8016 SOC-based systems.
+ Say Y if you want to use audio devices on MI2S.
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index ac76308..79e5c50 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -11,5 +11,7 @@ obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += snd-soc-lpass-apq8016.o
# Machine
snd-soc-storm-objs := storm.o
+snd-soc-apq8016-sbc-objs := apq8016_sbc.o
obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
+obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c
new file mode 100644
index 000..1efdf00
--- /dev/null
+++ b/sound/soc/qcom/apq8016_sbc.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct apq8016_sbc_data {
+ void __iomem *mic_iomux;
+ void __iomem *spkr_iomux;
+ struct snd_soc_dai_link dai_link[]; /* dynamically allocated */
+};
+
+#define MIC_CTRL_QUA_WS_SLAVE_SEL_10 BIT(17)
+#define MIC_CTRL_TLMM_SCLK_EN BIT(1)
+#defineSPKR_CTL_PRI_WS_SLAVE_SEL_11(BIT(17) | BIT(16))
+
+static int apq8016_sbc_dai_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_card *card = rtd->card;
+ struct apq8016_sbc_data *pdata = snd_soc_card_get_drvdata(card);
+ int rval = 0;
+
+ switch (cpu_dai->id) {
+ case MI2S_PRIMARY:
+ writel(readl(pdata->spkr_iomux) | SPKR_CTL_PRI_WS_SLAVE_SEL_11,
+ pdata->spkr_iomux);
+ break;
+
+ case MI2S_QUATERNARY:
+ /* Configure the Quat MI2S to TLMM */
+ writel(readl(pdata->mic_iomux) | MIC_CTRL_QUA_WS_SLAVE_SEL_10 |
+ MIC_CTRL_TLMM_SCLK_EN,
+ pdata->mic_iomux);
+ break;
+
+ default:
+ dev_err(card->dev, "unsupported cpu dai configuration\n");
+ rval = -EINVAL;
+ break;
+
+ }
+
+ return rval;
+}
+
+static struct apq8016_sbc_data *apq8016_sbc_parse_of(struct snd_soc_card *card)
+{
+ struct device *dev = card->dev;
+ struct snd_soc_dai_link *link;
+ struct device_node *np, *codec, *cpu, *node = dev->of_node;
+ struct apq8016_sbc_data *data;
+ int ret, num_links;
+
+ ret = snd_soc_of_parse_card_name(card, "qcom,model");
+ if (ret) {
+ dev_err(dev, "Error parsing card name: %d\n", ret);
+ return ERR_PTR(ret);
+ }
+
+ /* Populate links */
+ num_links = of_get_child_count(node);
+
+ /* Allocate the private data and the DAI link array */
+ data = devm_kzalloc(dev, sizeof(*data) + sizeof(*link) * num_links,
+ GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ card->dai_link = >dai_link[0];
+ card->num_links = num_links;
+
+ link = data->dai_link;
+
+ for_each_child_of_node(node, np) {
+ cpu = of_get_child_by_name(np, "cpu");
+ codec = of_get_child_by_name(np, "codec");
+
+ if (!cpu || !codec) {
+ dev_err(dev, "Can't find cpu/codec DT node\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+
Re: [PATCH v6 5/6] i2c: at91: print hardware version
> >>>- dev_info(dev->dev, "AT91 i2c bus driver.\n"); > >>>+ dev_info(dev->dev, "AT91 i2c bus driver (version: %#x).\n", > > >>It looks as if you rather print the driver's version. :-) > > > From my point of view, having a version number for a Linux driver would > >be strange > >Not everybody shares your opinion. I tend to agree with Sergei but let's keep things simple: I'll make it "hw version" before applying. signature.asc Description: Digital signature
Re: [PATCH v4 2/9] x86: support kmap_atomic_pfn_t() for persistent memory
Btw, I don't think this actually is safe without refcounting your kmap structure. The driver model ->remove callback can be called at any time, which will ioremap the memory and remap the kmap structure. But at this point a user might still be using it. -- 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 5/6] i2c: at91: print hardware version
Hello. On 6/10/2015 11:05 AM, Ludovic Desroches wrote: The probe() function now prints the hardware version of the I2C controller. Signed-off-by: Cyrille Pitchen --- drivers/i2c/busses/i2c-at91.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 817ae69..6e88b30 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c [...] @@ -908,7 +910,8 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - dev_info(dev->dev, "AT91 i2c bus driver.\n"); + dev_info(dev->dev, "AT91 i2c bus driver (version: %#x).\n", It looks as if you rather print the driver's version. :-) From my point of view, having a version number for a Linux driver would be strange Not everybody shares your opinion. so it's not confusing. Oh, it is, from the purely grammatical PoV. Addiung "hardware " to "version" (or not mentioning the driver at all) would clear up that confusion. +at91_twi_read(dev, AT91_TWI_VER)); return 0; } WBR, Sergei Regards Ludovic WBR, Sergei -- 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 v5 01/10] x86/asm: Add FP_SAVE/RESTORE frame pointer macros
Add the FP_SAVE and FP_RESTORE asm macros, which can be used to save and restore the frame pointer. Signed-off-by: Josh Poimboeuf --- arch/x86/include/asm/func.h | 24 1 file changed, 24 insertions(+) create mode 100644 arch/x86/include/asm/func.h diff --git a/arch/x86/include/asm/func.h b/arch/x86/include/asm/func.h new file mode 100644 index 000..4d62782 --- /dev/null +++ b/arch/x86/include/asm/func.h @@ -0,0 +1,24 @@ +#ifndef _ASM_X86_FUNC_H +#define _ASM_X86_FUNC_H + +#include +#include + +/* + * These are frame pointer save and restore macros. They should be used by + * every callable non-leaf asm function. + */ +.macro FP_SAVE name + .if CONFIG_FRAME_POINTER + push %_ASM_BP + _ASM_MOV %_ASM_SP, %_ASM_BP + .endif +.endm + +.macro FP_RESTORE name + .if CONFIG_FRAME_POINTER + pop %_ASM_BP + .endif +.endm + +#endif /* _ASM_X86_FUNC_H */ -- 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/
[PATCH v5 07/10] x86/asm/acpi: Fix asmvalidate warnings for wakeup_64.S
Fix the following asmvalidate warnings: asmvalidate: arch/x86/kernel/acpi/wakeup_64.o: wakeup_long64()+0x15: unsupported jump to outside of function asmvalidate: arch/x86/kernel/acpi/wakeup_64.o: wakeup_long64()+0x55: unsupported jump to outside of function asmvalidate: arch/x86/kernel/acpi/wakeup_64.o: wakeup_long64(): unsupported fallthrough at end of function asmvalidate: arch/x86/kernel/acpi/wakeup_64.o: do_suspend_lowlevel()+0x9a: unsupported jump to outside of function asmvalidate: arch/x86/kernel/acpi/wakeup_64.o: do_suspend_lowlevel()+0x116: unsupported jump to outside of function asmvalidate: arch/x86/kernel/acpi/wakeup_64.o: do_suspend_lowlevel(): unsupported fallthrough at end of function asmvalidate: arch/x86/kernel/acpi/wakeup_64.o: do_suspend_lowlevel(): missing FP_SAVE/RESTORE macros 1. wakeup_long64() isn't a function that can be called. It's actually redirected to via a return instruction in the entry code. It shouldn't be annotated as a callable function. Change ENDPROC -> PROC accordingly. 2. do_suspend_lowlevel() is a non-leaf callable function, so save/restore the frame pointer with FP_SAVE/RESTORE. 3. Remove the unnecessary jump to .Lresume_point, as it just results in jumping to the next instruction (which is a nop because of the align). Otherwise asmvalidate gets confused by the jump. 4. Change the "jmp restore_processor_state" to a call instruction, because jumping outside the function's boundaries isn't allowed. Now restore_processor_state() will return back to do_suspend_lowlevel() instead of do_suspend_lowlevel()'s caller. 5. Remove superfluous rsp changes. Signed-off-by: Josh Poimboeuf Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Pavel Machek Cc: linux...@vger.kernel.org --- arch/x86/kernel/acpi/wakeup_64.S | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S index 8c35df4..7e442be 100644 --- a/arch/x86/kernel/acpi/wakeup_64.S +++ b/arch/x86/kernel/acpi/wakeup_64.S @@ -5,6 +5,7 @@ #include #include #include +#include # Copyright 2003 Pavel Machek , distribute under GPLv2 @@ -33,13 +34,13 @@ ENTRY(wakeup_long64) movqsaved_rip, %rax jmp *%rax -ENDPROC(wakeup_long64) +END(wakeup_long64) bogus_64_magic: jmp bogus_64_magic ENTRY(do_suspend_lowlevel) - subq$8, %rsp + FP_SAVE xorl%eax, %eax callsave_processor_state @@ -70,12 +71,11 @@ ENTRY(do_suspend_lowlevel) movq%rdi, saved_rdi movq%rsi, saved_rsi - addq$8, %rsp movl$3, %edi xorl%eax, %eax callx86_acpi_enter_sleep_state + /* in case something went wrong, restore the machine status and go on */ - jmp .Lresume_point .align 4 .Lresume_point: @@ -108,8 +108,9 @@ ENTRY(do_suspend_lowlevel) movqpt_regs_r15(%rax), %r15 xorl%eax, %eax - addq$8, %rsp - jmp restore_processor_state + callrestore_processor_state + FP_RESTORE + ret ENDPROC(do_suspend_lowlevel) .data -- 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/
[PATCH v5 06/10] x86/asm/efi: Fix asmvalidate warnings for efi_stub_64.S
Fix the following asmvalidate warnings: asmvalidate: arch/x86/platform/efi/efi_stub_64.o: efi_call(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/boot/compressed/efi_stub_64.o: efi_call(): missing FP_SAVE/RESTORE macros efi_call() is a non-leaf callable function, so save/restore the frame pointer with FP_SAVE/RESTORE. Signed-off-by: Josh Poimboeuf Cc: Matt Fleming Cc: linux-...@vger.kernel.org --- arch/x86/platform/efi/efi_stub_64.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/platform/efi/efi_stub_64.S b/arch/x86/platform/efi/efi_stub_64.S index 86d0f9e..0ca6bfb 100644 --- a/arch/x86/platform/efi/efi_stub_64.S +++ b/arch/x86/platform/efi/efi_stub_64.S @@ -11,6 +11,7 @@ #include #include #include +#include #define SAVE_XMM \ mov %rsp, %rax; \ @@ -74,6 +75,7 @@ .endm ENTRY(efi_call) + FP_SAVE SAVE_XMM mov (%rsp), %rax mov 8(%rax), %rax @@ -88,6 +90,7 @@ ENTRY(efi_call) RESTORE_PGT addq $48, %rsp RESTORE_XMM + FP_RESTORE ret ENDPROC(efi_call) -- 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/
[PATCH v5 08/10] x86/asm/head: Fix asmvalidate warnings for head_64.S
Fix the following asmvalidate warnings: asmvalidate: arch/x86/kernel/head_64.o: start_cpu0(): unsupported fallthrough at end of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x4: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xd: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x16: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x1f: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x28: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x31: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x3a: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x43: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x4a: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x55: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x5c: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x65: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x6e: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x77: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x80: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x8b: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x94: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x9b: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xa6: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xaf: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xb8: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xc1: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xca: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xd3: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xdc: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xe5: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xee: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0xf7: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x100: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x109: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x112: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array()+0x11b: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_array(): unsupported fallthrough at end of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_common()+0xbb: unsupported jump to outside of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_common(): unsupported fallthrough at end of function asmvalidate: arch/x86/kernel/head_64.o: early_idt_handler_common(): missing FP_SAVE/RESTORE macros 1. start_cpu0() isn't a normal callable function because it doesn't return to its caller. Change ENDPROC -> END accordingly. 2. early_idt_handler_array() and early_idt_handler_common() aren't callable functions. Change ENDPROC -> END accordingly. Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/head_64.S | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index e5c27f7..8ba22cf 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -20,6 +20,7 @@ #include #include #include +#include #ifdef CONFIG_PARAVIRT #include @@ -301,7 +302,7 @@ ENTRY(start_cpu0) pushq
[PATCH v5 09/10] x86/asm/lib: Fix asmvalidate warnings for lib functions
Fix the following asmvalidate warnings: asmvalidate: arch/x86/lib/clear_page_64.o: clear_page()+0x0: unsupported jump to outside of function asmvalidate: arch/x86/lib/clear_page_64.o: alternative jump to outside the scope of original function clear_page asmvalidate: arch/x86/lib/copy_page_64.o: copy_page()+0x0: unsupported jump to outside of function asmvalidate: arch/x86/lib/memcpy_64.o: memcpy()+0x0: unsupported jump to outside of function asmvalidate: arch/x86/lib/memcpy_64.o: __memcpy()+0x0: unsupported jump to outside of function asmvalidate: arch/x86/lib/memcpy_64.o: alternative jump to outside the scope of original function memcpy asmvalidate: arch/x86/lib/memset_64.o: memset()+0x0: unsupported jump to outside of function asmvalidate: arch/x86/lib/memset_64.o: __memset()+0x0: unsupported jump to outside of function asmvalidate: arch/x86/lib/memset_64.o: alternative jump to outside the scope of original function memset Change the annotations for clear_page(), copy_page(), memcpy(), and memset() so that they don't jump outside of their function boundaries. Signed-off-by: Josh Poimboeuf --- arch/x86/lib/clear_page_64.S | 9 +++-- arch/x86/lib/copy_page_64.S | 5 ++--- arch/x86/lib/memcpy_64.S | 10 -- arch/x86/lib/memset_64.S | 10 -- 4 files changed, 13 insertions(+), 21 deletions(-) diff --git a/arch/x86/lib/clear_page_64.S b/arch/x86/lib/clear_page_64.S index a2fe51b..c342566 100644 --- a/arch/x86/lib/clear_page_64.S +++ b/arch/x86/lib/clear_page_64.S @@ -22,10 +22,8 @@ ENTRY(clear_page) xorl %eax,%eax rep stosq ret -ENDPROC(clear_page) - -ENTRY(clear_page_orig) +clear_page_orig: xorl %eax,%eax movl $4096/64,%ecx .p2align 4 @@ -44,11 +42,10 @@ ENTRY(clear_page_orig) jnz .Lloop nop ret -ENDPROC(clear_page_orig) -ENTRY(clear_page_c_e) +clear_page_c_e: movl $4096,%ecx xorl %eax,%eax rep stosb ret -ENDPROC(clear_page_c_e) +ENDPROC(clear_page) diff --git a/arch/x86/lib/copy_page_64.S b/arch/x86/lib/copy_page_64.S index 009f982..81d5cba 100644 --- a/arch/x86/lib/copy_page_64.S +++ b/arch/x86/lib/copy_page_64.S @@ -16,9 +16,8 @@ ENTRY(copy_page) movl$4096/8, %ecx rep movsq ret -ENDPROC(copy_page) -ENTRY(copy_page_regs) +copy_page_regs: subq$2*8, %rsp movq%rbx, (%rsp) movq%r12, 1*8(%rsp) @@ -83,4 +82,4 @@ ENTRY(copy_page_regs) movq1*8(%rsp), %r12 addq$2*8, %rsp ret -ENDPROC(copy_page_regs) +ENDPROC(copy_page) diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S index 16698bb..64d00ec 100644 --- a/arch/x86/lib/memcpy_64.S +++ b/arch/x86/lib/memcpy_64.S @@ -37,21 +37,18 @@ ENTRY(memcpy) movl %edx, %ecx rep movsb ret -ENDPROC(memcpy) -ENDPROC(__memcpy) /* * memcpy_erms() - enhanced fast string memcpy. This is faster and * simpler than memcpy. Use memcpy_erms when possible. */ -ENTRY(memcpy_erms) +memcpy_erms: movq %rdi, %rax movq %rdx, %rcx rep movsb ret -ENDPROC(memcpy_erms) -ENTRY(memcpy_orig) +memcpy_orig: movq %rdi, %rax cmpq $0x20, %rdx @@ -176,4 +173,5 @@ ENTRY(memcpy_orig) .Lend: retq -ENDPROC(memcpy_orig) +ENDPROC(memcpy) +ENDPROC(__memcpy) diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S index 2661fad..a0d9f3f 100644 --- a/arch/x86/lib/memset_64.S +++ b/arch/x86/lib/memset_64.S @@ -41,8 +41,6 @@ ENTRY(__memset) rep stosb movq %r9,%rax ret -ENDPROC(memset) -ENDPROC(__memset) /* * ISO C memset - set a memory block to a byte value. This function uses @@ -55,16 +53,15 @@ ENDPROC(__memset) * * rax original destination */ -ENTRY(memset_erms) +memset_erms: movq %rdi,%r9 movb %sil,%al movq %rdx,%rcx rep stosb movq %r9,%rax ret -ENDPROC(memset_erms) -ENTRY(memset_orig) +memset_orig: movq %rdi,%r10 /* expand byte value */ @@ -135,4 +132,5 @@ ENTRY(memset_orig) subq %r8,%rdx jmp .Lafter_bad_alignment .Lfinal: -ENDPROC(memset_orig) +ENDPROC(memset) +ENDPROC(__memset) -- 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/
[PATCH v5 05/10] x86/asm/crypto: Fix asmvalidate warnings for ghash-clmulni-intel_asm.S
Fix the following asmvalidate warnings: asmvalidate: arch/x86/crypto/ghash-clmulni-intel_asm.o: clmul_ghash_mul(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/ghash-clmulni-intel_asm.o: clmul_ghash_update(): missing FP_SAVE/RESTORE macros These are non-leaf callable functions, so save/restore the frame pointer with FP_SAVE/RESTORE. Signed-off-by: Josh Poimboeuf Cc: linux-cry...@vger.kernel.org Cc: Herbert Xu Cc: "David S. Miller" --- arch/x86/crypto/ghash-clmulni-intel_asm.S | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/crypto/ghash-clmulni-intel_asm.S b/arch/x86/crypto/ghash-clmulni-intel_asm.S index 5d1e007..e5b76b1 100644 --- a/arch/x86/crypto/ghash-clmulni-intel_asm.S +++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S @@ -18,6 +18,7 @@ #include #include +#include .data @@ -94,6 +95,7 @@ ENDPROC(__clmul_gf128mul_ble) /* void clmul_ghash_mul(char *dst, const u128 *shash) */ ENTRY(clmul_ghash_mul) + FP_SAVE movups (%rdi), DATA movups (%rsi), SHASH movaps .Lbswap_mask, BSWAP @@ -101,6 +103,7 @@ ENTRY(clmul_ghash_mul) call __clmul_gf128mul_ble PSHUFB_XMM BSWAP DATA movups DATA, (%rdi) + FP_RESTORE ret ENDPROC(clmul_ghash_mul) @@ -109,6 +112,7 @@ ENDPROC(clmul_ghash_mul) *const u128 *shash); */ ENTRY(clmul_ghash_update) + FP_SAVE cmp $16, %rdx jb .Lupdate_just_ret# check length movaps .Lbswap_mask, BSWAP @@ -128,5 +132,6 @@ ENTRY(clmul_ghash_update) PSHUFB_XMM BSWAP DATA movups DATA, (%rdi) .Lupdate_just_ret: + FP_RESTORE ret ENDPROC(clmul_ghash_update) -- 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/
[PATCH v5 03/10] x86/asm/entry: Fix asmvalidate warnings for entry_64_compat.S
Fix the following asmvalidate warnings: asmvalidate: arch/x86/entry/entry_64_compat.o: native_usergs_sysret32(): unsupported fallthrough at end of function asmvalidate: arch/x86/entry/entry_64_compat.o: entry_SYSENTER_compat()+0xcf: unsupported jump to outside of function asmvalidate: arch/x86/entry/entry_64_compat.o: entry_SYSENTER_compat()+0x113: unsupported jump to outside of function asmvalidate: arch/x86/entry/entry_64_compat.o: entry_SYSENTER_compat()+0x16d: unsupported jump to outside of function asmvalidate: arch/x86/entry/entry_64_compat.o: entry_SYSENTER_compat(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/entry/entry_64_compat.o: .entry.text+0x56e: return instruction outside of a function 1. native_usergs_sysret32 is redirected to from a jump rather than a call, so it shouldn't be annotated as a function. Change ENDPROC -> END accordingly. 2. Ditto for entry_SYSENTER_compat. 3. The stub functions can be called, so annotate them as functions with ENTRY/ENDPROC. 4. The stub functions aren't leaf functions, so save/restore the frame pointer with FP_SAVE/RESTORE. 5. The stub functions all jump outside of their respective functions' boundaries to the ia32_ptregs_common label. Change them to be self-contained so they stay within their boundaries. Signed-off-by: Josh Poimboeuf --- arch/x86/entry/entry_64_compat.S | 35 +++ arch/x86/include/asm/func.h | 6 ++ 2 files changed, 25 insertions(+), 16 deletions(-) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index bb187a6..07f5ae8 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -13,6 +13,7 @@ #include #include #include +#include #include #include @@ -32,7 +33,7 @@ ENTRY(native_usergs_sysret32) swapgs sysretl -ENDPROC(native_usergs_sysret32) +END(native_usergs_sysret32) #endif /* @@ -270,7 +271,7 @@ sysenter_tracesys: RESTORE_EXTRA_REGS jmp sysenter_do_call -ENDPROC(entry_SYSENTER_compat) +END(entry_SYSENTER_compat) /* * 32-bit SYSCALL instruction entry. @@ -523,10 +524,15 @@ ia32_tracesys: END(entry_INT80_compat) .macro PTREGSCALL label, func - ALIGN -GLOBAL(\label) - leaq\func(%rip), %rax - jmp ia32_ptregs_common +ENTRY(\label) + FP_SAVE + leaq\func(%rip),%rax + SAVE_EXTRA_REGS(8+FP_SIZE) + call*%rax + RESTORE_EXTRA_REGS(8+FP_SIZE) + FP_RESTORE + ret +ENDPROC(\label) .endm PTREGSCALL stub32_rt_sigreturn, sys32_rt_sigreturn @@ -534,9 +540,9 @@ GLOBAL(\label) PTREGSCALL stub32_fork, sys_fork PTREGSCALL stub32_vfork,sys_vfork - ALIGN -GLOBAL(stub32_clone) - leaqsys_clone(%rip), %rax +ENTRY(stub32_clone) + FP_SAVE + leaqsys_clone(%rip),%rax /* * The 32-bit clone ABI is: clone(..., int tls_val, int *child_tidptr). * The 64-bit clone ABI is: clone(..., int *child_tidptr, int tls_val). @@ -545,12 +551,9 @@ GLOBAL(stub32_clone) * so we need to swap arguments here before calling it: */ xchg%r8, %rcx - jmp ia32_ptregs_common - - ALIGN -ia32_ptregs_common: - SAVE_EXTRA_REGS 8 + SAVE_EXTRA_REGS(8+FP_SIZE) call*%rax - RESTORE_EXTRA_REGS 8 + RESTORE_EXTRA_REGS(8+FP_SIZE) + FP_RESTORE ret -END(ia32_ptregs_common) +ENDPROC(stub32_clone) diff --git a/arch/x86/include/asm/func.h b/arch/x86/include/asm/func.h index 52b3225..1d923bd 100644 --- a/arch/x86/include/asm/func.h +++ b/arch/x86/include/asm/func.h @@ -37,6 +37,12 @@ .endif .endm +#ifdef CONFIG_FRAME_POINTER +#define FP_SIZE __ASM_SEL(4, 8) +#else +#define FP_SIZE 0 +#endif + /* * This macro tells the asm validation script to ignore the instruction * immediately after the macro. It should only be used in special cases where -- 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/
[PATCH v5 10/10] x86/asm/lib: Fix asmvalidate warnings for rwsem.S
Fix the following asmvalidate warnings: asmvalidate: arch/x86/lib/rwsem.o: call_rwsem_down_read_failed(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/lib/rwsem.o: call_rwsem_down_write_failed(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/lib/rwsem.o: call_rwsem_wake(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/lib/rwsem.o: call_rwsem_downgrade_wake(): missing FP_SAVE/RESTORE macros These are callable non-leaf functions, so save/restore the frame pointer with FP_SAVE/RESTORE. Signed-off-by: Josh Poimboeuf --- arch/x86/lib/rwsem.S | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S index 40027db..709bc9d 100644 --- a/arch/x86/lib/rwsem.S +++ b/arch/x86/lib/rwsem.S @@ -15,6 +15,7 @@ #include #include +#include #define __ASM_HALF_REG(reg)__ASM_SEL(reg, e##reg) #define __ASM_HALF_SIZE(inst) __ASM_SEL(inst##w, inst##l) @@ -84,24 +85,29 @@ /* Fix up special calling conventions */ ENTRY(call_rwsem_down_read_failed) + FP_SAVE save_common_regs __ASM_SIZE(push,) %__ASM_REG(dx) movq %rax,%rdi call rwsem_down_read_failed __ASM_SIZE(pop,) %__ASM_REG(dx) restore_common_regs + FP_RESTORE ret ENDPROC(call_rwsem_down_read_failed) ENTRY(call_rwsem_down_write_failed) + FP_SAVE save_common_regs movq %rax,%rdi call rwsem_down_write_failed restore_common_regs + FP_RESTORE ret ENDPROC(call_rwsem_down_write_failed) ENTRY(call_rwsem_wake) + FP_SAVE /* do nothing if still outstanding active readers */ __ASM_HALF_SIZE(dec) %__ASM_HALF_REG(dx) jnz 1f @@ -109,15 +115,18 @@ ENTRY(call_rwsem_wake) movq %rax,%rdi call rwsem_wake restore_common_regs -1: ret +1: FP_RESTORE + ret ENDPROC(call_rwsem_wake) ENTRY(call_rwsem_downgrade_wake) + FP_SAVE save_common_regs __ASM_SIZE(push,) %__ASM_REG(dx) movq %rax,%rdi call rwsem_downgrade_wake __ASM_SIZE(pop,) %__ASM_REG(dx) restore_common_regs + FP_RESTORE ret ENDPROC(call_rwsem_downgrade_wake) -- 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/
[PATCH v5 02/10] x86: Compile-time asm code validation
Add a new CONFIG_ASM_VALIDATION option which adds an asmvalidate host tool which runs on every compiled .S file. Its goal is to enforce sane rules on all asm code, so that stack debug metadata (frame/back chain pointers and/or DWARF CFI metadata) can be made reliable. It enforces the following rules: 1. Each callable function must be annotated with the ELF STT_FUNC type. This is typically done using the ENTRY/ENDPROC macros. If asmvalidate finds a return instruction outside of a function, it flags an error, since that usually indicates callable code which should be annotated accordingly. 2. Each callable function must never leave its own bounds (i.e. with a jump to outside the function) except when returning. 3. Each callable non-leaf function must have frame pointer logic (if required by CONFIG_FRAME_POINTER or the architecture's back chain rules). This can be done with the new FP_SAVE/FP_RESTORE macros. It currently only supports x86_64. It *almost* supports x86_32, but the stackvalidate code doesn't yet know how to deal with 32-bit REL relocations for the return whitelists. I tried to make the code generic so that support for other architectures can be plugged in pretty easily. As a first step, CONFIG_ASM_VALIDATION is disabled by default, and all reported non-compliances result in warnings. Once we get them all cleaned up, we can change the default to CONFIG_ASM_VALIDATION=y and change the warnings to build errors so the asm code can stay clean. Signed-off-by: Josh Poimboeuf --- MAINTAINERS | 6 + arch/Kconfig | 3 + arch/x86/Kconfig | 1 + arch/x86/Makefile | 6 +- arch/x86/include/asm/func.h | 32 lib/Kconfig.debug | 21 +++ scripts/Makefile | 1 + scripts/Makefile.build| 23 ++- scripts/asmvalidate/Makefile | 17 ++ scripts/asmvalidate/arch-x86.c| 283 ++ scripts/asmvalidate/arch.h| 40 + scripts/asmvalidate/asmvalidate.c | 324 ++ scripts/asmvalidate/elf.c | 354 ++ scripts/asmvalidate/elf.h | 74 scripts/asmvalidate/list.h| 217 +++ 15 files changed, 1399 insertions(+), 3 deletions(-) create mode 100644 scripts/asmvalidate/Makefile create mode 100644 scripts/asmvalidate/arch-x86.c create mode 100644 scripts/asmvalidate/arch.h create mode 100644 scripts/asmvalidate/asmvalidate.c create mode 100644 scripts/asmvalidate/elf.c create mode 100644 scripts/asmvalidate/elf.h create mode 100644 scripts/asmvalidate/list.h diff --git a/MAINTAINERS b/MAINTAINERS index 469cd4d..831bf8b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1664,6 +1664,12 @@ S: Maintained F: Documentation/hwmon/asc7621 F: drivers/hwmon/asc7621.c +ASM VALIDATION +M: Josh Poimboeuf +S: Supported +F: scripts/asmvalidate/ +F: arch/x86/include/asm/func.h + ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS M: Corentin Chary L: acpi4asus-u...@lists.sourceforge.net diff --git a/arch/Kconfig b/arch/Kconfig index a65eafb..8d85326 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -499,6 +499,9 @@ config ARCH_HAS_ELF_RANDOMIZE - arch_mmap_rnd() - arch_randomize_brk() +config HAVE_ASM_VALIDATION + bool + # # ABI hall of shame # diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 228aa35..a85e149 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -144,6 +144,7 @@ config X86 select VIRT_TO_BUS select X86_DEV_DMA_OPS if X86_64 select X86_FEATURE_NAMESif PROC_FS + select HAVE_ASM_VALIDATION if X86_64 config INSTRUCTION_DECODER def_bool y diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 118e6de..e2dd40e 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -174,9 +174,13 @@ KBUILD_CFLAGS += $(call cc-option,-mno-avx,) KBUILD_CFLAGS += $(mflags-y) KBUILD_AFLAGS += $(mflags-y) -archscripts: scripts_basic +archscripts: scripts_basic $(objtree)/arch/x86/lib/inat-tables.c $(Q)$(MAKE) $(build)=arch/x86/tools relocs +# this file is needed early by scripts/asmvalidate +$(objtree)/arch/x86/lib/inat-tables.c: + $(Q)$(MAKE) $(build)=arch/x86/lib $@ + ### # Syscall table generation diff --git a/arch/x86/include/asm/func.h b/arch/x86/include/asm/func.h index 4d62782..52b3225 100644 --- a/arch/x86/include/asm/func.h +++ b/arch/x86/include/asm/func.h @@ -9,6 +9,14 @@ * every callable non-leaf asm function. */ .macro FP_SAVE name + .if CONFIG_ASM_VALIDATION + 163: + .pushsection __asmvalidate_fp_save, "ae" + _ASM_ALIGN + .long 163b - . + .popsection + .endif + .if CONFIG_FRAME_POINTER push %_ASM_BP
[PATCH v5 04/10] x86/asm/crypto: Fix asmvalidate warnings for aesni-intel_asm.S
Fix the following asmvalidate warnings: asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_set_key(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_enc(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_dec(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_ecb_enc(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_ecb_dec(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_cbc_enc(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_cbc_dec(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_ctr_enc(): missing FP_SAVE/RESTORE macros asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_xts_crypt8(): missing FP_SAVE/RESTORE macros These are all non-leaf callable functions, so save/restore the frame pointer with FP_SAVE/RESTORE. Signed-off-by: Josh Poimboeuf Cc: linux-cry...@vger.kernel.org Cc: Herbert Xu Cc: "David S. Miller" --- arch/x86/crypto/aesni-intel_asm.S | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 6bd2c6c..83465f9a 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -31,6 +31,7 @@ #include #include +#include /* * The following macros are used to move an (un)aligned 16 byte value to/from @@ -1800,6 +1801,7 @@ ENDPROC(_key_expansion_256b) * unsigned int key_len) */ ENTRY(aesni_set_key) + FP_SAVE #ifndef __x86_64__ pushl KEYP movl 8(%esp), KEYP # ctx @@ -1905,6 +1907,7 @@ ENTRY(aesni_set_key) #ifndef __x86_64__ popl KEYP #endif + FP_RESTORE ret ENDPROC(aesni_set_key) @@ -1912,6 +1915,7 @@ ENDPROC(aesni_set_key) * void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src) */ ENTRY(aesni_enc) + FP_SAVE #ifndef __x86_64__ pushl KEYP pushl KLEN @@ -1927,6 +1931,7 @@ ENTRY(aesni_enc) popl KLEN popl KEYP #endif + FP_RESTORE ret ENDPROC(aesni_enc) @@ -2101,6 +2106,7 @@ ENDPROC(_aesni_enc4) * void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src) */ ENTRY(aesni_dec) + FP_SAVE #ifndef __x86_64__ pushl KEYP pushl KLEN @@ -2117,6 +2123,7 @@ ENTRY(aesni_dec) popl KLEN popl KEYP #endif + FP_RESTORE ret ENDPROC(aesni_dec) @@ -2292,6 +2299,7 @@ ENDPROC(_aesni_dec4) * size_t len) */ ENTRY(aesni_ecb_enc) + FP_SAVE #ifndef __x86_64__ pushl LEN pushl KEYP @@ -2342,6 +2350,7 @@ ENTRY(aesni_ecb_enc) popl KEYP popl LEN #endif + FP_RESTORE ret ENDPROC(aesni_ecb_enc) @@ -2350,6 +2359,7 @@ ENDPROC(aesni_ecb_enc) * size_t len); */ ENTRY(aesni_ecb_dec) + FP_SAVE #ifndef __x86_64__ pushl LEN pushl KEYP @@ -2401,6 +2411,7 @@ ENTRY(aesni_ecb_dec) popl KEYP popl LEN #endif + FP_RESTORE ret ENDPROC(aesni_ecb_dec) @@ -2409,6 +2420,7 @@ ENDPROC(aesni_ecb_dec) * size_t len, u8 *iv) */ ENTRY(aesni_cbc_enc) + FP_SAVE #ifndef __x86_64__ pushl IVP pushl LEN @@ -2443,6 +2455,7 @@ ENTRY(aesni_cbc_enc) popl LEN popl IVP #endif + FP_RESTORE ret ENDPROC(aesni_cbc_enc) @@ -2451,6 +2464,7 @@ ENDPROC(aesni_cbc_enc) * size_t len, u8 *iv) */ ENTRY(aesni_cbc_dec) + FP_SAVE #ifndef __x86_64__ pushl IVP pushl LEN @@ -2534,6 +2548,7 @@ ENTRY(aesni_cbc_dec) popl LEN popl IVP #endif + FP_RESTORE ret ENDPROC(aesni_cbc_dec) @@ -2598,6 +2613,7 @@ ENDPROC(_aesni_inc) * size_t len, u8 *iv) */ ENTRY(aesni_ctr_enc) + FP_SAVE cmp $16, LEN jb .Lctr_enc_just_ret mov 480(KEYP), KLEN @@ -2651,6 +2667,7 @@ ENTRY(aesni_ctr_enc) .Lctr_enc_ret: movups IV, (IVP) .Lctr_enc_just_ret: + FP_RESTORE ret ENDPROC(aesni_ctr_enc) @@ -2677,6 +2694,7 @@ ENDPROC(aesni_ctr_enc) * bool enc, u8 *iv) */ ENTRY(aesni_xts_crypt8) + FP_SAVE cmpb $0, %cl movl $0, %ecx movl $240, %r10d @@ -2777,6 +2795,7 @@ ENTRY(aesni_xts_crypt8) pxor INC, STATE4 movdqu STATE4, 0x70(OUTP) + FP_RESTORE ret ENDPROC(aesni_xts_crypt8) -- 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/
[PATCH v5 00/10] x86/asm: Compile-time asm code validation
The previous version of this patch set was named "Compile-time stack frame pointer validation". I changed the subject from "frame pointer validation" to "asm code validation" because the focus of the patch set has changed to be less frame pointer-focused and more asm-focused. I also renamed the tool to asmvalidate (it was previously called stackvalidate) and basically rewrote most of the code. The goal of asm validation is to enforce sane rules on asm code: all callable asm functions must be self-contained and properly annotated. Some of the benefits are: - Frame pointers are more reliable. - DWARF CFI metadata can be autogenerated (coming soon). - The asm code becomes less like spaghetti, more like C, and easier to comprehend. The asmvalidate tool runs on every compiled .S file, and enforces the following rules: 1. Each callable function must be annotated with the ELF STT_FUNC type. This is typically done using the existing ENTRY/ENDPROC macros. If asmvalidate finds a return instruction outside of a function, it flags an error, since that usually indicates callable code which should be annotated accordingly. 2. Each callable function must never leave its own bounds (i.e. with a jump to outside the function) except when returning. 3. Each callable non-leaf function must have frame pointer logic (if required by CONFIG_FRAME_POINTER or the architecture's back chain rules). This should by done by the FP_SAVE/FP_RESTORE macros. It currently only supports x86_64, but the code is generic and designed for it to be easy to plug in support for other architectures. There are still a lot of outstanding warnings (which I'll paste as a reply to this email). Once those are all cleaned up, we can change the warnings to build errors and change the default to CONFIG_ASM_VALIDATION=y so the asm code stays clean. The first patch adds some frame pointer macros. The second patch adds asmvalidate support. The rest of the patches have fixes for (some of) the reported warnings. These patches are based on tip/master. [1] http://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com v5: - stackvalidate -> asmvalidate - frame pointers only required for non-leaf functions - check for the use of the FP_SAVE/RESTORE macros instead of manually analyzing code to detect frame pointer usage - additional checks to ensure each function doesn't leave its boundaries - make the macros simpler and more flexible - support for analyzing ALTERNATIVE macros - simplified the arch interfaces in scripts/asmvalidate/arch.h - fixed some asmvalidate warnings - rebased onto latest tip asm cleanups - many more small changes v4: - Changed the default to CONFIG_STACK_VALIDATION=n, until all the asm code can get cleaned up. - Fixed a stackvalidate error path exit code issue found by Michal Marek. v3: - Added a patch to make the push/pop CFI macros arch-independent, as suggested by H. Peter Anvin v2: - Fixed memory leaks reported by Petr Mladek Josh Poimboeuf (10): x86/asm: Add FP_SAVE/RESTORE frame pointer macros x86: Compile-time asm code validation x86/asm/entry: Fix asmvalidate warnings for entry_64_compat.S x86/asm/crypto: Fix asmvalidate warnings for aesni-intel_asm.S x86/asm/crypto: Fix asmvalidate warnings for ghash-clmulni-intel_asm.S x86/asm/efi: Fix asmvalidate warnings for efi_stub_64.S x86/asm/acpi: Fix asmvalidate warnings for wakeup_64.S x86/asm/head: Fix asmvalidate warnings for head_64.S x86/asm/lib: Fix asmvalidate warnings for lib functions x86/asm/lib: Fix asmvalidate warnings for rwsem.S MAINTAINERS | 6 + arch/Kconfig | 3 + arch/x86/Kconfig | 1 + arch/x86/Makefile | 6 +- arch/x86/crypto/aesni-intel_asm.S | 19 ++ arch/x86/crypto/ghash-clmulni-intel_asm.S | 5 + arch/x86/entry/entry_64_compat.S | 35 +-- arch/x86/include/asm/func.h | 62 ++ arch/x86/kernel/acpi/wakeup_64.S | 13 +- arch/x86/kernel/head_64.S | 7 +- arch/x86/lib/clear_page_64.S | 9 +- arch/x86/lib/copy_page_64.S | 5 +- arch/x86/lib/memcpy_64.S | 10 +- arch/x86/lib/memset_64.S | 10 +- arch/x86/lib/rwsem.S | 11 +- arch/x86/platform/efi/efi_stub_64.S | 3 + lib/Kconfig.debug | 21 ++ scripts/Makefile | 1 + scripts/Makefile.build| 23 +- scripts/asmvalidate/Makefile | 17 ++ scripts/asmvalidate/arch-x86.c| 283 scripts/asmvalidate/arch.h| 40 scripts/asmvalidate/asmvalidate.c | 324 +++ scripts/asmvalidate/elf.c | 354 ++ scripts/asmvalidate/elf.h | 74 +++
Re: [PATCH 3/5] soc: Mediatek: Add SCPSYS power domain driver
2015-06-09 10:47 GMT+02:00 Sascha Hauer :
> This adds a power domain driver for the Mediatek SCPSYS unit.
>
> The System Control Processor System (SCPSYS) has several power
> management related tasks in the system. The tasks include thermal
> measurement, dynamic voltage frequency scaling (DVFS), interrupt
> filter and lowlevel sleep control. The System Power Manager (SPM)
> inside the SCPSYS is for the MTCMOS power domain control.
>
> For now this driver only adds power domain support, the more
> advanced features are not yet supported. The driver implements
> the generic PM domain device tree bindings, the first user will
> most likely be the Mediatek AFE audio driver.
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/soc/mediatek/Kconfig | 9 +
> drivers/soc/mediatek/Makefile| 1 +
> drivers/soc/mediatek/mtk-scpsys.c| 490
> +++
> include/dt-bindings/power/mt8173-power.h | 15 +
> 4 files changed, 515 insertions(+)
> create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
> create mode 100644 include/dt-bindings/power/mt8173-power.h
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index e4f37a3..9a61b54 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -18,3 +18,12 @@ config MTK_PMIC_WRAP
> Say yes here to add support for MediaTek PMIC Wrapper found
> on different MediaTek SoCs. The PMIC wrapper is a proprietary
> hardware to connect the PMIC.
> +
> +config MTK_SCPSYS
> + bool "MediaTek SCPSYS Support"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + select REGMAP
> + select MTK_INFRACFG
> + help
> + Say yes here to add support for the MediaTek SCPSYS power domain
> + driver.
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 3fa940f..12998b0 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> +obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> b/drivers/soc/mediatek/mtk-scpsys.c
> new file mode 100644
> index 000..b9eed37
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -0,0 +1,490 @@
> +/*
> + * Copyright (c) 2015 Pengutronix, Sascha Hauer
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SPM_VDE_PWR_CON0x0210
> +#define SPM_MFG_PWR_CON0x0214
> +#define SPM_VEN_PWR_CON0x0230
> +#define SPM_ISP_PWR_CON0x0238
> +#define SPM_DIS_PWR_CON0x023c
> +#define SPM_VEN2_PWR_CON 0x0298
> +#define SPM_AUDIO_PWR_CON 0x029c
> +#define SPM_MFG_2D_PWR_CON 0x02c0
> +#define SPM_MFG_ASYNC_PWR_CON 0x02c4
> +#define SPM_USB_PWR_CON0x02cc
> +#define SPM_PWR_STATUS 0x060c
> +#define SPM_PWR_STATUS_2ND 0x0610
> +
> +#define PWR_RST_B_BIT BIT(0)
> +#define PWR_ISO_BITBIT(1)
> +#define PWR_ON_BIT BIT(2)
> +#define PWR_ON_2ND_BIT BIT(3)
> +#define PWR_CLK_DIS_BITBIT(4)
> +
> +#define PWR_STATUS_DISPBIT(3)
> +#define PWR_STATUS_MFG BIT(4)
> +#define PWR_STATUS_ISP BIT(5)
> +#define PWR_STATUS_VDECBIT(7)
> +#define PWR_STATUS_VENC_LT BIT(20)
> +#define PWR_STATUS_VENCBIT(21)
> +#define PWR_STATUS_MFG_2D BIT(22)
> +#define PWR_STATUS_MFG_ASYNC BIT(23)
> +#define PWR_STATUS_AUDIO BIT(24)
> +#define PWR_STATUS_USB BIT(25)
> +
> +enum clk_id {
> + MT8173_CLK_NONE,
> + MT8173_CLK_MM,
> + MT8173_CLK_MFG,
> + MT8173_CLK_MAX = MT8173_CLK_MFG,
> +};
> +
> +struct scp_domain_data {
> + const char *name;
> + u32 sta_mask;
> + int ctl_offs;
> + u32 sram_pdn_bits;
> + u32 sram_pdn_ack_bits;
> + u32 bus_prot_mask;
> + enum clk_id clk_id;
> +};
> +
> +static const struct scp_domain_data scp_domain_data[] __initconst = {
> + [MT8173_POWER_DOMAIN_VDEC] = {
> + .name =
Re: [PATCH v5 1/7] mmc: dt-bindings: add Mediatek MMC bindings
On 10 June 2015 at 04:24, Chaotian Jing wrote:
> Document the device-tree binding of Mediatek MMC host
>
> Signed-off-by: Chaotian Jing
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt | 32
>
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/mtk-sd.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> new file mode 100644
> index 000..a1adfa4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -0,0 +1,32 @@
> +* MTK MMC controller
> +
> +The MTK MSDC can act as a MMC controller
> +to support MMC, SD, and SDIO types of memory cards.
> +
> +This file documents differences between the core properties in mmc.txt
> +and the properties used by the msdc driver.
> +
> +Required properties:
> +- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
> +- interrupts: Should contain MSDC interrupt number
> +- clocks: MSDC source clock, HCLK
> +- clock-names: "source", "hclk"
According to the mmc driver, hclk is treated as an optional clock.
Therefore I think you should list it under an "Optional properties"
section instead.
> +- pinctrl-names: should be "default", "state_uhs"
> +- pinctrl-0: should contain default/high speed pin ctrl
> +- pinctrl-1: should contain uhs mode pin ctrl
> +- vmmc-supply: power to the Core
> +- vqmmc-supply: power to the IO
> +
> +Examples:
> +mmc0: mmc@1123 {
> + compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
> + reg = <0 0x1123 0 0x108>;
> + interrupts = ;
> + vmmc-supply = <_vemc_3v3_reg>;
> + vqmmc-supply = <_vio18_reg>;
> + clocks = < CLK_PERI_MSDC30_0>, <
> CLK_TOP_MSDC50_0_H_SEL>;
> + clock-names = "source", "hclk";
> + pinctrl-names = "default", "state_uhs";
> + pinctrl-0 = <_pins_default>;
> + pinctrl-1 = <_pins_uhs>;
> +};
> --
> 1.8.1.1.dirty
>
Kind regards
Uffe
--
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 6/7] staging: fsl-mc: Add locking to serialize mc_send_command() calls
On Tue, Jun 09, 2015 at 04:59:07PM -0500, J. German Rivera wrote: > Add a locking mechanism to serialize mc_send_command() calls that use > the same fsl_mc_io object (same MC portal). When the fsl_mc_io object is > created the owner needs to know in which type of context the fsl_mc_io > object is going to be used. A flag passed-in to fsl_create_mc_io() > will indicate whether the fsl_mc_io object will be used in atomic or > non-atomic context. If the fsl_mc_io object is going to be used in > non-atomic context only, mc_send_command() calls with it will be > serialized using a mutex. Otherwise, if the fsl_mc_io object is > going to be used in atomic context, mc_semd_command() calls with it > will be serialized using a spinlock. > > Signed-off-by: J. German Rivera > Reviewed-by: Stuart Yoder My understanding is that no one actually sets FSL_MC_IO_ATOMIC_CONTEXT_PORTAL? It's hard to review patches 6 & 7 properly without users. Why don't you just wait on those until we have a use for it. regards, dan carpenter -- 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 3/7] mmc: mediatek: Add PM support for MMC driver
On 10 June 2015 at 04:24, Chaotian Jing wrote: > Add PM support for Mediatek MMC driver > Save/restore registers when PM > > Signed-off-by: Chaotian Jing > --- > drivers/mmc/host/mtk-sd.c | 88 > +-- > 1 file changed, 85 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c > index 8de3299..62e966f 100644 > --- a/drivers/mmc/host/mtk-sd.c > +++ b/drivers/mmc/host/mtk-sd.c > @@ -22,6 +22,7 @@ > #include > #include > #include Add pm.h as well. > +#include > #include > #include > [...] Kind regards Uffe -- 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: Tree for Jun 10
Hi all, Changes since 20150609: The drm tree still had its build failures for which I applied a supplied patch. Non-merge commits (relative to Linus' tree): 9544 8352 files changed, 893218 insertions(+), 188316 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 219 trees (counting Linus' and 31 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (e64f638483a2 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (0bbe6b5a73c0 ARM: 8388/1: tcm: Don't crash when TCM banks are protected by TrustZone) Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array index in OSS IRQ source initialization) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (c65b99f04684 Linux 4.1-rc6) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (c46a024ea5eb Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (9c5a18a31b32 cfg80211: wext: clear sinfo struct before calling driver) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (132bd96bc56f ALSA: hda - fix number of devices query on hotplug) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging tty.current/tty-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb.current/usb-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect __init/__exit annotations) Merging usb-serial-fixes/usb-linus (df72d588c54d USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle) Merging staging.current/staging-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging char-misc.current/char-misc-linus (e26081808eda Linux 4.1-rc4) Merging input-current/for-linus (7f2ca8b55aef Input: synaptics - add min/max quirk for Lenovo S540) Merging crypto-current/master (f858c7bcca8c crypto: algif_aead - Disable AEAD user-space for now) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => cpumask_local_spread, lament) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (3f5f1554ee71 drm/i915: Fix DDC probe for passive adapters) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic) Merging arc/for-next (3596ba60b383 ARC: [axs101] Add missing
Re: [PATCH v5 2/7] mmc: mediatek: Add Mediatek MMC driver
[...]
> +static int msdc_drv_probe(struct platform_device *pdev)
> +{
> + struct mmc_host *mmc;
> + struct msdc_host *host;
> + struct resource *res;
> + int ret;
> +
> + if (!pdev->dev.of_node) {
> + dev_err(>dev, "No DT found\n");
> + return -EINVAL;
> + }
> + /* Allocate MMC host for this device */
> + mmc = mmc_alloc_host(sizeof(struct msdc_host), >dev);
> + if (!mmc)
> + return -ENOMEM;
> +
> + host = mmc_priv(mmc);
> + ret = mmc_of_parse(mmc);
> + if (ret)
> + goto host_free;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + host->base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(host->base)) {
> + ret = PTR_ERR(host->base);
> + goto host_free;
> + }
> +
> + ret = mmc_regulator_get_supply(mmc);
> + if (ret == -EPROBE_DEFER)
> + goto host_free;
> +
> + host->src_clk = devm_clk_get(>dev, "source");
> + if (IS_ERR(host->src_clk)) {
> + ret = PTR_ERR(host->src_clk);
> + goto host_free;
> + }
> +
> + host->h_clk = devm_clk_get(>dev, "hclk");
> + if (IS_ERR(host->h_clk)) {
> + /* host->h_clk is optional, Only for MSDC0/3 at MT8173 */
> + dev_dbg(>dev,
> + "Invalid hclk from the device tree!\n");
> + }
> +
> + host->irq = platform_get_irq(pdev, 0);
> + if (host->irq < 0) {
> + ret = -EINVAL;
> + goto host_free;
> + }
> +
> + host->pinctrl = devm_pinctrl_get(>dev);
> + if (IS_ERR(host->pinctrl)) {
> + ret = PTR_ERR(host->pinctrl);
> + dev_err(>dev, "Cannot find pinctrl!\n");
> + goto host_free;
> + }
> +
> + host->pins_default = pinctrl_lookup_state(host->pinctrl, "default");
> + if (IS_ERR(host->pins_default)) {
> + ret = PTR_ERR(host->pins_default);
> + dev_err(>dev, "Cannot find pinctrl default!\n");
> + goto host_free;
> + }
> +
> + host->pins_uhs = pinctrl_lookup_state(host->pinctrl, "state_uhs");
> + if (IS_ERR(host->pins_uhs)) {
> + ret = PTR_ERR(host->pins_uhs);
> + dev_err(>dev, "Cannot find pinctrl uhs!\n");
> + goto host_free;
> + }
> +
> + host->dev = >dev;
> + host->mmc = mmc;
> + host->hclk = clk_get_rate(host->src_clk);
This looks odd. The clock rate for the source clock is assigned as the
speed of hclk!? Why?
> + /* Set host parameters to mmc */
> + mmc->ops = _msdc_ops;
> + mmc->f_min = host->hclk / (4 * 255);
> +
> + mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
> + /* MMC core transfer sizes tunable parameters */
> + mmc->max_segs = MAX_BD_NUM;
> + mmc->max_seg_size = BDMA_DESC_BUFLEN;
> + mmc->max_blk_size = 2048;
> + mmc->max_req_size = 512 * 1024;
> + mmc->max_blk_count = mmc->max_req_size / 512;
> + host->dma_mask = DMA_BIT_MASK(32);
> + mmc_dev(mmc)->dma_mask = >dma_mask;
> +
> + host->timeout_clks = 3 * 1048576;
> + host->dma.gpd = dma_alloc_coherent(>dev,
> + sizeof(struct mt_gpdma_desc),
> + >dma.gpd_addr, GFP_KERNEL);
> + host->dma.bd = dma_alloc_coherent(>dev,
> + MAX_BD_NUM * sizeof(struct mt_bdma_desc),
> + >dma.bd_addr, GFP_KERNEL);
> + if (!host->dma.gpd || !host->dma.bd) {
> + ret = -ENOMEM;
> + goto release_mem;
> + }
> + msdc_init_gpd_bd(host, >dma);
> + INIT_DELAYED_WORK(>req_timeout, msdc_request_timeout);
> + spin_lock_init(>lock);
> +
> + platform_set_drvdata(pdev, mmc);
> + msdc_ungate_clock(host);
> + msdc_init_hw(host);
> +
> + ret = devm_request_irq(>dev, host->irq, msdc_irq,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT, pdev->name, host);
> + if (ret)
> + goto release;
> +
> + ret = mmc_add_host(mmc);
> + if (ret)
> + goto release;
> +
> + return 0;
> +
> +release:
> + platform_set_drvdata(pdev, NULL);
> + msdc_deinit_hw(host);
> + msdc_gate_clock(host);
> +release_mem:
> + if (host->dma.gpd)
> + dma_free_coherent(>dev,
> + sizeof(struct mt_gpdma_desc),
> + host->dma.gpd, host->dma.gpd_addr);
> + if (host->dma.bd)
> + dma_free_coherent(>dev,
> + MAX_BD_NUM * sizeof(struct mt_bdma_desc),
> + host->dma.bd, host->dma.bd_addr);
> +host_free:
> + mmc_free_host(mmc);
> +
> + return ret;
> +}
[...]
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] DRM: Armada: fixup wait_event_timeout being ignored
On Wed, 10 Jun 2015, Russell King - ARM Linux wrote: > On Wed, Jun 10, 2015 at 01:07:08PM +0200, Nicholas Mc Guire wrote: > > The calling side seems to assume 0 as success and <0 as error so > > returning -ETIME should be fine here. > > The idea here is to allow the remainder of the code to execute when > the condition succeeds _or_ times out. If it times out, that is > not a failure - it merely means that the display has been blanked > and we're not seeing frame done interrupts anymore. > > The code should not be checking the returned value at all - in fact > I have updates to this code which (in part) remove this, and fix a > glaring problem that the wait queue is never woken. > > I wonder how many places you've made this same mistake... please > ensure that you review the code you're changing carefully. > Sorry for that - I do try my best to understand the code - my obviously wrong understanding of the code was that a negative return was being expected as being possible and then handed back to the caller so I assumed that would be the timeout case - but as this can never happen it was basically ignoring the timeout - that the execution should continue in the case of timeout being reached was not clear to me (it might be worth a comment ?) I did find similar cases in other drivers ./drivers/media/platform/s5p-tv/mixer_reg.c:364 incorrect check for negative return checking for < 0 and returning (so unreachable return statement with no effect but no side-effect in that condition ither) or ./drivers/media/pci/ddbridge/ddbridge-core.c:89 incorrect check for negative return which checked for <= 0 and was fixed up to == 0 which is correct as the < 0 case simply is unreachable - so no change of error handling logic. but those two other cases I think are correctly fixed up. thx! hofrat -- 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: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > > From: Takashi Iwai > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & > > > > > co > > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > > > noises at transition from D3 to D0 when the widget power-saving is > > > > > enabled. Further debugging session showed that avoiding it isn't > > > > > trivial, unfortunately, since paths are basically activated > > > > > dynamically while the pins have been already enabled. > > > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > > > Reported-by: Jonathan McDowell > > > > > Signed-off-by: Takashi Iwai > > > > > --- > > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c > > > > > b/sound/pci/hda/patch_realtek.c > > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > > --- a/sound/pci/hda/patch_realtek.c > > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > > > > > spec = codec->spec; > > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > > - codec->power_save_node = 1; > > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > > + codec->power_save_node = 1; > > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > > > alc269_fixup_tbl, alc269_fixups); > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > > > E7440): > > > > > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for > > > > ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > > [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 > > > > (0x14/0x0/0x0/0x0/0x0) > > > > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > > > > (0x15/0x0/0x0/0x0/0x0) > > > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 > > > > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > > > > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > > > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > > > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > > > > > 4.0.4 was fine. > > > > > > Does it happen only once at boot (i.e. at power up), or happens always > > > at runtime PM? If it's a once-off boot thing, the patch shouldn't > > > have much effect. Something else, very subtle thing, e.g. the order > > > of verb execution, might cause this kind of problem. > > > > Only at power up. I've also suspend-resumed twice and can confirm it's > > OK. > > > > There's a _very_ brief click at suspend (when the power is cut), but it > > looks like a plain circuitry thing. I probably didn't notice it before > > because I wasn't looking for it. > > Thanks. Do you get the same click noise when reloading snd-hda-intel > driver? Also, does it happen when booting in runlevel 3? > > Last but not least, a patch like below has any effect? > > > Takashi > > --- > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct > hda_codec *codec, > break; > } > > + if (power_state == AC_PWRST_D0) > + msleep(100); > return state; > } > Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio. $ pulseaudio -k will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away. telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either. However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-) -- Mihai Donțu -- 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/4] VFIO: platform: add reset struct and lookup table
Hi Alex,
On 06/09/2015 08:26 PM, Alex Williamson wrote:
> On Fri, 2015-06-05 at 17:06 +0200, Eric Auger wrote:
>> This patch introduces the vfio_platform_reset_combo struct that
>> stores all the information useful to handle the reset modality:
>> compat string, name of the reset function, name of the module that
>> implements the reset function. A lookup table of such structures
>> is added, currently containing a single sentinel element. A new
>> type field is added in vfio_platform_device to store what kind of
>> reset is associated to the device, if any.
>>
>> Signed-off-by: Eric Auger
>> ---
>> drivers/vfio/platform/vfio_platform_common.c | 6 ++
>> drivers/vfio/platform/vfio_platform_private.h | 12
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/vfio/platform/vfio_platform_common.c
>> b/drivers/vfio/platform/vfio_platform_common.c
>> index abcff7a..d970776 100644
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -25,6 +25,12 @@
>>
>> static DEFINE_MUTEX(driver_lock);
>>
>> +static const struct vfio_platform_reset_combo reset_lookup_table[] = {
>> +{
>> +.type = VFIO_PLATFORM_RESET_TYPE_MAX
>> +},
>> +};
>> +
>> static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
>> {
>> int cnt = 0, i;
>> diff --git a/drivers/vfio/platform/vfio_platform_private.h
>> b/drivers/vfio/platform/vfio_platform_private.h
>> index 5d31e04..d864124 100644
>> --- a/drivers/vfio/platform/vfio_platform_private.h
>> +++ b/drivers/vfio/platform/vfio_platform_private.h
>> @@ -49,6 +49,10 @@ struct vfio_platform_region {
>> void __iomem*ioaddr;
>> };
>>
>> +enum vfio_platform_reset_type {
>> +VFIO_PLATFORM_RESET_TYPE_MAX /* last element */,
>> +};
>> +
>> struct vfio_platform_device {
>> struct vfio_platform_region *regions;
>> u32 num_regions;
>> @@ -56,6 +60,7 @@ struct vfio_platform_device {
>> u32 num_irqs;
>> int refcnt;
>> struct mutexigate;
>> +enum vfio_platform_reset_type type;
>>
>> /*
>> * These fields should be filled by the bus specific binder
>> @@ -69,6 +74,13 @@ struct vfio_platform_device {
>> int (*get_irq)(struct vfio_platform_device *vdev, int i);
>> };
>>
>> +struct vfio_platform_reset_combo {
>> +enum vfio_platform_reset_type type;
>> +char *compat;
>> +char *reset_function_name;
>> +char *module_name;
>> +};
>> +
>
> I don't really understand the benefit of vfio_platform_reset_type, what
> does it add? If we want an array end marker, we could just use NULL,
> but if we're dealing with a static table, we could always use ARRAY_SIZE
> and avoid an end marker altogether. If the concern is matching the
> symbol to put when the device is released, we could just use
> symbol_put_addr() and avoid any sort of lookup. Seems like there could
> also be a smattering of "const" in this struct definition too.
Agreed. I will respin accordingly.
Best Regards
Eric
>
>> extern int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>>struct device *dev);
>> extern struct vfio_platform_device *vfio_platform_remove_common
>
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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 3/4] VFIO: platform: populate the reset function on probe
On 06/09/2015 08:26 PM, Alex Williamson wrote:
> On Fri, 2015-06-05 at 17:06 +0200, Eric Auger wrote:
>> The reset function lookup happens on vfio-platform probe. The reset
>> module load is requested and a reference to the function symbol is
>> hold. The reference is released on vfio-platform remove.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v1 -> v2:
>> - [get,put]_reset now is called once on probe/remove
>> - use request_module to automatically load the reset module that
>> matches the compatibility string
>> - lookup table is used instead of list
>> - remove registration mechanism: reset function name is stored in the
>> lookup table.
>> - use device_property_read_string instead of
>> device_property_read_string_array
>> ---
>> drivers/vfio/platform/vfio_platform_common.c | 48
>> +++-
>> 1 file changed, 47 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/vfio/platform/vfio_platform_common.c
>> b/drivers/vfio/platform/vfio_platform_common.c
>> index 995929b..d474d6a 100644
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -31,6 +31,47 @@ static const struct vfio_platform_reset_combo
>> reset_lookup_table[] = {
>> },
>> };
>>
>> +static int vfio_platform_get_reset(struct vfio_platform_device *vdev,
>> + struct device *dev)
>> +{
>> +const char *compat;
>> +const struct vfio_platform_reset_combo *iter = reset_lookup_table;
>> +int (*reset)(struct vfio_platform_device *);
>> +int ret;
>> +
>> +vdev->type = VFIO_PLATFORM_RESET_TYPE_MAX;
>> +ret = device_property_read_string(dev, "compatible", );
>> +if (ret)
>> +return ret;
>> +
>> +while (iter->type < VFIO_PLATFORM_RESET_TYPE_MAX) {
>> +if (!strcmp(iter->compat, compat)) {
>> +request_module(iter->module_name);
>> +reset = __symbol_get(iter->reset_function_name);
>
> symbol_get() appears to be the more robust and dominant interface for
> this, why use __symbol_get()?
I used this because it takes a const char * as an argument and this is
what I use as a datatype for storing the reset function name. Symbol_get
is provided with the symbol directly? It is also used
drivers/mtd/chips/gen_probe.c.
>
>> +if (reset) {
>> +vdev->type = iter->type;
>> +vdev->reset = reset;
>> +return 0;
>> +}
>> +}
>> +iter++;
>> +}
>> +return -1;
>
> -ENODEV seems preferable to -1, but shouldn't this really be a void
> function?
yes indeed
>
>> +}
>> +
>> +static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
>> +{
>> +const struct vfio_platform_reset_combo *iter = reset_lookup_table;
>> +
>> +while (iter->type < VFIO_PLATFORM_RESET_TYPE_MAX) {
>> +if (iter->type == vdev->type) {
>
> Again, I don't see the value in storing the enum, since the table is
> static, it could just as easily be the array index and avoid this loop,
> but we can avoid it anyway with symbol_put_addr().
yes you're definitively right!
Thanks
Eric
>
>> +__symbol_put(iter->reset_function_name);
>> +return;
>> +}
>> +iter++;
>> +}
>> +}
>> +
>> static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
>> {
>> int cnt = 0, i;
>> @@ -519,6 +560,8 @@ int vfio_platform_probe_common(struct
>> vfio_platform_device *vdev,
>> return ret;
>> }
>>
>> +vfio_platform_get_reset(vdev, dev);
>> +
>> mutex_init(>igate);
>>
>> return 0;
>> @@ -530,8 +573,11 @@ struct vfio_platform_device
>> *vfio_platform_remove_common(struct device *dev)
>> struct vfio_platform_device *vdev;
>>
>> vdev = vfio_del_group_dev(dev);
>> -if (vdev)
>> +
>> +if (vdev) {
>> +vfio_platform_put_reset(vdev);
>> iommu_group_put(dev->iommu_group);
>> +}
>>
>> return vdev;
>> }
>
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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: [Drbd-dev] [PATCH 00/10] Zero out devices instead of initial full sync
resent, accidentally truncated the Cc list. also added one paragraph. On Wed, Jun 10, 2015 at 03:48:19PM +0800, Nick Wang wrote: > Full sync for drbd initial usually take a long time, especically > when network become the bottleneck the syncing. Simply skip the > full sync with "--clear-bitmap" may not the perfect solution > for all the cases. So this patches can be used to zero out > devices locally instead of a full sync,two make consistent block > device. This approach can be useful when lack of network bandwidth > to sync. > > The patches add one new option "--zap-devices" to "new-current-uuid" > to zero out devices. Besides the change of drbd, also need to modify > drbd-utils for the flag. > > All patches are compiled/tested against SLES12. Completely unnecessary. Zero out the devices in userspace, then set up DRBD, and skip the initial sync. On backends that support it, you can already simply blkdiscard /dev/drbdX (or use the implicit discard of some mkfs) once you set it up for the first time, even when the initial resync just began, and that discard will finish the "initial resync", without taking up any real network bandwidth. In short: I don't see the point. Lars Ellenberg -- 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 v9 4/5] serial: stm32-usart: Add STM32 USART Driver
2015-05-31 23:52 GMT+02:00 Greg Kroah-Hartman : > On Fri, May 22, 2015 at 11:03:35PM +0200, Maxime Coquelin wrote: >> This drivers adds support to the STM32 USART controller, which is a >> standard serial driver. >> >> Tested-by: Chanwoo Choi >> Reviewed-by: Peter Hurley >> Reviewed-by: Vladimir Zapolskiy >> Reviewed-by: Andy Shevchenko >> Signed-off-by: Maxime Coquelin > > Acked-by: Greg Kroah-Hartman Thanks Greg. Will you apply it to your tty tree for v4.2? Or it should go in someone else tree? Regards, Maxime -- 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] clk: Move debug_node field under DEBUG_FS flag in struct clk_core
The debug_node field is only used when DEBUG_FS config is selected,
so declare it only if DEBUG_FS is selected.
Signed-off-by: Maxime Coquelin
---
drivers/clk/clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 459ce9d..afbaa73 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -68,11 +68,11 @@ struct clk_core {
int phase;
struct hlist_head children;
struct hlist_node child_node;
- struct hlist_node debug_node;
struct hlist_head clks;
unsigned intnotifier_count;
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
+ struct hlist_node debug_node;
#endif
struct kref ref;
};
--
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] ARM: irqflags: Get arch_irqs_disabled from asm-generic
Commit cb1293e2f594 ("ARM: 8375/1: disable some options on ARMv7-M")
causes the build to on ARMv7-M machines:
CC arch/arm/kernel/asm-offsets.s
In file included from include/linux/sem.h:5:0,
from include/linux/sched.h:35,
from arch/arm/kernel/asm-offsets.c:14:
include/linux/rcupdate.h: In function 'rcu_read_lock_sched_held':
include/linux/rcupdate.h:539:2: error: implicit declaration of function
'arch_irqs_disabled' [-Werror=implicit-function-declaration]
return preempt_count() != 0 || irqs_disabled();
asm-generic/irqflags.h provides an implementation of arch_irqs_disabled().
Lets grab an implementation from there!
Suggested-by: Russell King
Signed-off-by: Daniel Thompson
Acked-by: Maxime Coquelin
---
Notes:
Compile tested on v4.1-rc6 using all arch/arm/configs.
Boot tested on v4.1-rc6 with versatile_defconfig and multi_v7_defconfig.
Boot tested on linux-next-20150608 using stm32_defconfig (out-of-tree).
arch/arm/include/asm/irqflags.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
index 3b763d6652a0..43908146a5cf 100644
--- a/arch/arm/include/asm/irqflags.h
+++ b/arch/arm/include/asm/irqflags.h
@@ -20,6 +20,7 @@
#if __LINUX_ARM_ARCH__ >= 6
+#define arch_local_irq_save arch_local_irq_save
static inline unsigned long arch_local_irq_save(void)
{
unsigned long flags;
@@ -31,6 +32,7 @@ static inline unsigned long arch_local_irq_save(void)
return flags;
}
+#define arch_local_irq_enable arch_local_irq_enable
static inline void arch_local_irq_enable(void)
{
asm volatile(
@@ -40,6 +42,7 @@ static inline void arch_local_irq_enable(void)
: "memory", "cc");
}
+#define arch_local_irq_disable arch_local_irq_disable
static inline void arch_local_irq_disable(void)
{
asm volatile(
@@ -56,6 +59,7 @@ static inline void arch_local_irq_disable(void)
/*
* Save the current interrupt enable state & disable IRQs
*/
+#define arch_local_irq_save arch_local_irq_save
static inline unsigned long arch_local_irq_save(void)
{
unsigned long flags, temp;
@@ -73,6 +77,7 @@ static inline unsigned long arch_local_irq_save(void)
/*
* Enable IRQs
*/
+#define arch_local_irq_enable arch_local_irq_enable
static inline void arch_local_irq_enable(void)
{
unsigned long temp;
@@ -88,6 +93,7 @@ static inline void arch_local_irq_enable(void)
/*
* Disable IRQs
*/
+#define arch_local_irq_disable arch_local_irq_disable
static inline void arch_local_irq_disable(void)
{
unsigned long temp;
@@ -135,6 +141,7 @@ static inline void arch_local_irq_disable(void)
/*
* Save the current interrupt enable state.
*/
+#define arch_local_save_flags arch_local_save_flags
static inline unsigned long arch_local_save_flags(void)
{
unsigned long flags;
@@ -147,6 +154,7 @@ static inline unsigned long arch_local_save_flags(void)
/*
* restore saved IRQ & FIQ state
*/
+#define arch_local_irq_restore arch_local_irq_restore
static inline void arch_local_irq_restore(unsigned long flags)
{
asm volatile(
@@ -156,10 +164,13 @@ static inline void arch_local_irq_restore(unsigned long
flags)
: "memory", "cc");
}
+#define arch_irqs_disabled_flags arch_irqs_disabled_flags
static inline int arch_irqs_disabled_flags(unsigned long flags)
{
return flags & IRQMASK_I_BIT;
}
+#include
+
#endif /* ifdef __KERNEL__ */
#endif /* ifndef __ASM_ARM_IRQFLAGS_H */
--
2.4.2
--
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] DRM: Armada: fixup wait_event_timeout being ignored
On Wed, Jun 10, 2015 at 01:07:08PM +0200, Nicholas Mc Guire wrote: > The calling side seems to assume 0 as success and <0 as error so > returning -ETIME should be fine here. The idea here is to allow the remainder of the code to execute when the condition succeeds _or_ times out. If it times out, that is not a failure - it merely means that the display has been blanked and we're not seeing frame done interrupts anymore. The code should not be checking the returned value at all - in fact I have updates to this code which (in part) remove this, and fix a glaring problem that the wait queue is never woken. I wonder how many places you've made this same mistake... please ensure that you review the code you're changing carefully. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 v2] arm DMA: Fix allocation from CMA for coherent DMA
ping!
On Wed, Jun 3, 2015 at 7:15 PM, Lorenzo Nava wrote:
> This patch allows the use of CMA for DMA coherent memory allocation.
> At the moment if the input parameter "is_coherent" is set to true
> the allocation is not made using the CMA, which I think is not the
> desired behaviour.
>
> Signed-off-by: Lorenzo Nava
> ---
> Changes in v2:
> correct __arm_dma_free() according to __dma_alloc() allocation
> ---
> arch/arm/mm/dma-mapping.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 7e7583d..15643b9 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -645,9 +645,9 @@ static void *__dma_alloc(struct device *dev, size_t size,
> dma_addr_t *handle,
> size = PAGE_ALIGN(size);
> want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs);
>
> - if (is_coherent || nommu())
> + if (nommu())
> addr = __alloc_simple_buffer(dev, size, gfp, );
> - else if (!(gfp & __GFP_WAIT))
> + else if (!is_coherent && !(gfp & __GFP_WAIT))
> addr = __alloc_from_pool(size, );
> else if (!dev_get_cma_area(dev))
> addr = __alloc_remap_buffer(dev, size, gfp, prot, ,
> caller, want_vaddr);
> @@ -735,7 +735,7 @@ static void __arm_dma_free(struct device *dev, size_t
> size, void *cpu_addr,
>
> size = PAGE_ALIGN(size);
>
> - if (is_coherent || nommu()) {
> + if (nommu()) {
> __dma_free_buffer(page, size);
> } else if (__free_from_pool(cpu_addr, size)) {
> return;
> --
> 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: [PATCH v2] crypto: drbg - reseed often if seedsource is degraded
On Wed, Jun 10, 2015 at 03:33:37AM +0200, Stephan Mueller wrote: > Changes v2: > * port the patch to current cryptodev tree plus the async seeding DRBG patches Applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] DRM: Armada: fixup wait_event_timeout being ignored
event API conformance testing with coccinelle spatches are being
used to locate API usage inconsistencies this triggert with:
./drivers/gpu/drm/armada/armada_overlay.c:153
incorrect check for negative return
Return type of wait_event_timeout is signed long not int and the
return type is >=0 always thus the negative check was effectively
ignoring the timeout event - this looks like a bug.
An appropriately named variable of type long is inserted and the
call fixed up as well as the negative return check changed to detect
the timeout event.
Signed-off-by: Nicholas Mc Guire
---
The calling side seems to assume 0 as success and <0 as error so
returning -ETIME should be fine here.
Patch was compile tested with imx_v6_v7_defconfig + CONFIG_DRM_ARMADA=m
Patch is against 4.1-rc7 (localversion-next is -next-20150609)
drivers/gpu/drm/armada/armada_overlay.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index c5b06fd..f308949 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -107,7 +107,7 @@ armada_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
uint32_t val, ctrl0;
unsigned idx = 0;
- int ret;
+ long time_left;
crtc_w = armada_limit(crtc_x, crtc_w, dcrtc->crtc.mode.hdisplay);
crtc_h = armada_limit(crtc_y, crtc_h, dcrtc->crtc.mode.vdisplay);
@@ -150,11 +150,11 @@ armada_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
dcrtc->base + LCD_SPU_SRAM_PARA1);
}
- ret = wait_event_timeout(dplane->vbl.wait,
-list_empty(>vbl.update.node),
-HZ/25);
- if (ret < 0)
- return ret;
+ time_left = wait_event_timeout(dplane->vbl.wait,
+ list_empty(>vbl.update.node),
+ HZ / 25);
+ if (time_left == 0)
+ return -ETIME;
if (plane->fb != fb) {
struct armada_gem_object *obj = drm_fb_obj(fb);
--
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: [PATCH 22/28] ARCv2: STAR 9000837815 workaround hardware exclusive transactions livelock
On Wed, Jun 10, 2015 at 10:01:01AM +, Vineet Gupta wrote: > OK - I need some more time to rehash the exact details with our > hardware folks. But AFAIKR, this was hardware livelock in llock/scond > when 2 cores were doing r-m-w to two different words in the same cache > line - adding prefetchw (prefetch with a write intent) would get the > line in exclusive state and break the livelock. > > The test itself was one from EEMBC Multibench but I'll have to look it > up. > > Wasn't there something similar in ARM world too - they have some sort > of snoop-delayed exclusive handling in hardware to mitigate something > similar although as Will later remarked it involved llock/scond with > vanilla ld/st to same line/word ? > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/254142.html Cute, I was not aware of that. Sounds reasonable (unfortunate but understandable). Speaking as someone who at times does full arch sweeps on code like this it really helps understanding if such things are explained a wee bit better than not at all :-) -- 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] s390/zcrypt: Convert use of __constant_cpu_to_le16 to cpu_to_le16
In big endian cases, the macro cpu_to_le16 unfolds to __swab16
which provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
Signed-off-by: Vaishali Thakkar
---
drivers/s390/crypto/zcrypt_pcicc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/crypto/zcrypt_pcicc.c
b/drivers/s390/crypto/zcrypt_pcicc.c
index 4d14c04..9f18876 100644
--- a/drivers/s390/crypto/zcrypt_pcicc.c
+++ b/drivers/s390/crypto/zcrypt_pcicc.c
@@ -98,11 +98,11 @@ static struct ap_driver zcrypt_pcicc_driver = {
* - VUD block
*/
static struct CPRB static_cprb = {
- .cprb_len = __constant_cpu_to_le16(0x0070),
+ .cprb_len = cpu_to_le16(0x0070),
.cprb_ver_id= 0x41,
.func_id= {0x54,0x32},
.checkpoint_flag= 0x01,
- .svr_namel = __constant_cpu_to_le16(0x0008),
+ .svr_namel = cpu_to_le16(0x0008),
.svr_name = {'I','C','S','F',' ',' ',' ',' '}
};
@@ -164,7 +164,7 @@ static int ICAMEX_msg_to_type6MEX_msg(struct zcrypt_device
*zdev,
};
static struct function_and_rules_block static_pke_function_and_rules ={
.function_code = {'P','K'},
- .ulen = __constant_cpu_to_le16(10),
+ .ulen = cpu_to_le16(10),
.only_rule = {'P','K','C','S','-','1','.','2'}
};
struct {
@@ -251,7 +251,7 @@ static int ICACRT_msg_to_type6CRT_msg(struct zcrypt_device
*zdev,
};
static struct function_and_rules_block static_pkd_function_and_rules ={
.function_code = {'P','D'},
- .ulen = __constant_cpu_to_le16(10),
+ .ulen = cpu_to_le16(10),
.only_rule = {'P','K','C','S','-','1','.','2'}
};
struct {
--
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] regulator: max8973: Fix up ramp_delay for MAX8973_RAMP_25mV_PER_US case
On Wednesday 10 June 2015 04:22 PM, Axel Lin wrote: This looks like a typo, can you confirm? Ooops, silly mistake.. yes, it is typo and same exist on my downstream code also. Thanks for correction. Reviewed-by: Laxman Dewangan -- 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 20/28] ARCv2: barriers
On Wed, Jun 10, 2015 at 09:34:18AM +, Vineet Gupta wrote:
> On Tuesday 09 June 2015 06:10 PM, Peter Zijlstra wrote:
> > On Tue, Jun 09, 2015 at 05:18:20PM +0530, Vineet Gupta wrote:
> >
> > A description of how your hardware works; or a reference to the platform
> > documentation would not go amiss.
>
> Honestly the docs group is working on a publicly sharable version of PRM
> (Programmer's Reference Manual) but it might take some more time.
Good news that. I appreciate these things can take some time.
> I'm sure kernel
> developers including you don't like to sign an NDA
It might also be a question on your company vs my company. But yes, I
generally prefer not to do NDAs.
> The information I have in
> comments is pretty much what we have in there w.r.t. the barrier
> instructions. But
> I will capture the the weak memory ordering and other details as part of
> changelog
> here too.
Right, so I think we all understand weak (ARM, PPC etc..) and we all
understand load/load, store/store and load-store/load-store barriers.
Although explicitly mentioning it never hurt anybody ;-)
I think the most interesting part is the device side.
> >> +/*
> >> + * DSYNC:
> >> + * - Waits for completion of all outstanding memory operations before
> >> any new
> >> + * operations can begin
> >> + * - Includes implicit memory operations such as cache/TLB/BPU
> >> maintenance ops
> >> + * - Lighter version of SYNC as it doesn't wait for non-memory
> >> operations
> >> + */
> >> +#define mb() asm volatile("dsync\n" : : : "memory")
> > So mb() is supposed to order against things like DMA memory ops, is DMA
> > part of point 1 or 3, if 3, this is not a suitable instruction.
>
> Can u please explain the DMA case a bit more ? From what I understood and
> used in
> say ethernet driver, it is more of a line drawn between say cpu updating a
> shared
> buffer descriptor and kicking a MMIO register (which in turn could initiate a
> DMA)
> but I'm not sure how mb() can possibly order with DMA per se (unless there's
> some
> advanced form of IO-coherency)
I'm afraid I might not be the best of sources here, I tend to stay away
from actual device stuff like that. I've Cc'ed Will Deacon who might be
able to shed a bit more light on this aspect.
--
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 RFC v3 2/2] spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller
This patch adds support for GQSPI controller driver used by Zynq Ultrascale+ MPSoC Signed-off-by: Ranjit Waghmode --- In v3, accommodating review comments given by Shubhrajyoti. Changes in v3: - Updated chip assert/de-assert timeout loop using jiffies - Updated minor kernel doc comments - Removed unwanted variable initialization in zynqmp_qspi_selectspimode() function - In probe() updated goto statement to disable clocks if error occurs while registering interrupts. Changes in v2: - Replacing all readl/writel calls with respective zynqmp_gqspi_read/write wrappers - Renamed function zynqmp_gqspi_selectflash to zynqmp_gqspi_selectslave - Renamed formal parameters of the function zynqmp_gqspi_selectslave - Updated all default cases of switch statements - Removed typecasting of variable data in zynqmp_qspi_copy_read_data() - Added return code check around clk_enable() calls - Factored the clk_get_rate() API outside the loop - Added generic fifo entry in zynqmp_qspi_chipselect() function to assure the CS assert and CS de-assert - To assure an endianness, added memcpy() in zynqmp_qspi_filltxfifo() function - For making sure that there is no HW setting during the transfer via setup(), Moved function call of zynqmp_qspi_setup_transfer() to zynqmp_qspi_filltxfifo() function. - Set master->num_chipselect to default value instead of reading it via device-tree --- --- drivers/spi/Kconfig|6 + drivers/spi/Makefile |1 + drivers/spi/spi-zynqmp-gqspi.c | 1122 3 files changed, 1129 insertions(+) create mode 100755 drivers/spi/spi-zynqmp-gqspi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 72b0590..4406a85 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -610,6 +610,12 @@ config SPI_XTENSA_XTFPGA 16 bit words in SPI mode 0, automatically asserting CS on transfer start and deasserting on end. +config SPI_ZYNQMP_GQSPI + tristate "Xilinx ZynqMP GQSPI controller" + depends on SPI_MASTER + help + Enables Xilinx GQSPI controller driver for Zynq UltraScale+ MPSoC. + config SPI_NUC900 tristate "Nuvoton NUC900 series SPI" depends on ARCH_W90X900 diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index d8cbf65..52db832 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -89,3 +89,4 @@ obj-$(CONFIG_SPI_TXX9)+= spi-txx9.o obj-$(CONFIG_SPI_XCOMM)+= spi-xcomm.o obj-$(CONFIG_SPI_XILINX) += spi-xilinx.o obj-$(CONFIG_SPI_XTENSA_XTFPGA)+= spi-xtensa-xtfpga.o +obj-$(CONFIG_SPI_ZYNQMP_GQSPI) += spi-zynqmp-gqspi.o diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c new file mode 100755 index 000..87b20a5 --- /dev/null +++ b/drivers/spi/spi-zynqmp-gqspi.c @@ -0,0 +1,1122 @@ +/* + * Xilinx Zynq UltraScale+ MPSoC Quad-SPI (QSPI) controller driver + * (master mode only) + * + * Copyright (C) 2009 - 2015 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Generic QSPI register offsets */ +#define GQSPI_CONFIG_OFST 0x0100 +#define GQSPI_ISR_OFST 0x0104 +#define GQSPI_IDR_OFST 0x010C +#define GQSPI_IER_OFST 0x0108 +#define GQSPI_IMASK_OFST 0x0110 +#define GQSPI_EN_OFST 0x0114 +#define GQSPI_TXD_OFST 0x011C +#define GQSPI_RXD_OFST 0x0120 +#define GQSPI_TX_THRESHOLD_OFST0x0128 +#define GQSPI_RX_THRESHOLD_OFST0x012C +#define GQSPI_LPBK_DLY_ADJ_OFST0x0138 +#define GQSPI_GEN_FIFO_OFST0x0140 +#define GQSPI_SEL_OFST 0x0144 +#define GQSPI_GF_THRESHOLD_OFST0x0150 +#define GQSPI_FIFO_CTRL_OFST 0x014C +#define GQSPI_QSPIDMA_DST_CTRL_OFST0x080C +#define GQSPI_QSPIDMA_DST_SIZE_OFST0x0804 +#define GQSPI_QSPIDMA_DST_STS_OFST 0x0808 +#define GQSPI_QSPIDMA_DST_I_STS_OFST 0x0814 +#define GQSPI_QSPIDMA_DST_I_EN_OFST0x0818 +#define GQSPI_QSPIDMA_DST_I_DIS_OFST 0x081C +#define GQSPI_QSPIDMA_DST_I_MASK_OFST 0x0820 +#define GQSPI_QSPIDMA_DST_ADDR_OFST0x0800 +#define GQSPI_QSPIDMA_DST_ADDR_MSB_OFST 0x0828 + +/* GQSPI register bit masks */ +#define GQSPI_SEL_MASK 0x0001 +#define GQSPI_EN_MASK 0x0001 +#define GQSPI_LPBK_DLY_ADJ_USE_LPBK_MASK 0x0020 +#define
Re: [PATCH 18/28] ARC: add smp barriers around atomics per memory-barrriers.txt
On Wed, Jun 10, 2015 at 09:17:16AM +, Vineet Gupta wrote:
> >> --- a/arch/arc/include/asm/spinlock.h
> >> +++ b/arch/arc/include/asm/spinlock.h
> >> @@ -22,24 +22,32 @@ static inline void arch_spin_lock(arch_spinlock_t
> >> *lock)
> >> {
> >>unsigned int tmp = __ARCH_SPIN_LOCK_LOCKED__;
> >>
> >> + smp_mb();
> >> +
> >>__asm__ __volatile__(
> >>"1: ex %0, [%1]\n"
> >>" breq %0, %2, 1b\n"
> >>: "+" (tmp)
> >>: "r"(&(lock->slock)), "ir"(__ARCH_SPIN_LOCK_LOCKED__)
> >>: "memory");
> >> +
> >> + smp_mb();
> >> }
> > Both these are only required to provide an ACQUIRE barrier, if all you
> > have is smp_mb(), the second is sufficient.
>
> Essentially ARCv2 is weakly ordered with explicit ordering provided by DMB
> instructions with semantics load/load, store/store, all/all.
>
> I wanted to clarify a couple of things
> (1) ACQUIRE barrier implies store/{store,load} while RELEASE implies
> {load,store}/store and given what DMB provides for ARCv2, smp_mb() is the
> only fit ?
Please see Documentation/memory-barriers.txt, but a quick recap:
- ACQUIRE: both loads and stores before to the barrier are allowed to
be observed after it. Neither loads nor stores after the barrier are
allowed to be observed before it.
- RELEASE: both loads and stores before it must be observed before the
barrier. However, any load or store after it may be observed before
it.
Therefore:
X = Y = 0;
[S] X = 1
ACQUIRE
RELEASE
[S] Y = 1
is in fact fully unordered, because both stores are allowed to cross in,
and could cross one another on the inside, like:
ACQUIRE
[S] Y = 1
[S] X = 1
RELEASE
> (2) Do we need smp_mb() on both sides of spin lock/unlock - doesn't ACQUIRE
> imply
> we have a smp_mb() after lock but before any subsequent critical section - so
> the
> top hunk is not necessarily needed. Similarly RELEASE requires a smp_mb()
> before
> the memory operation for lock, but not after.
You do not need an smp_mb() on both sides, as you say, after lock and
before unlock is sufficient. The main point being that things can not
escape out of the critical section. Its fine for them to leak in.
--
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] regulator: max8973: Fix up ramp_delay for MAX8973_RAMP_25mV_PER_US case
Fix trivial typo. Signed-off-by: Axel Lin --- Hi Laxman, This looks like a typo, can you confirm? Thanks, Axel drivers/regulator/max8973-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/max8973-regulator.c b/drivers/regulator/max8973-regulator.c index 89e53e0..6f2bdad 100644 --- a/drivers/regulator/max8973-regulator.c +++ b/drivers/regulator/max8973-regulator.c @@ -312,7 +312,7 @@ static int max8973_init_dcdc(struct max8973_chip *max, max->desc.ramp_delay = 12000; break; case MAX8973_RAMP_25mV_PER_US: - max->desc.ramp_delay = 252000; + max->desc.ramp_delay = 25000; break; case MAX8973_RAMP_50mV_PER_US: max->desc.ramp_delay = 5; -- 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/
[PATCH] qeth: Convert use of __constant_htons to htons
In little endian cases, the macro htons unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_htons and htons expand directly to the same expression.
So, replace __constant_htons with htons with the goal of getting
rid of the definition of __constant_htons completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_htons(x)
+ htons(x)
Signed-off-by: Vaishali Thakkar
---
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/net/qeth_l2_main.c b/drivers/s390/net/qeth_l2_main.c
index 0ea0869..a124f59 100644
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -272,7 +272,7 @@ static void qeth_l2_fill_header(struct qeth_card *card,
struct qeth_hdr *hdr,
/* VSWITCH relies on the VLAN
* information to be present in
* the QDIO header */
- if (veth->h_vlan_proto == __constant_htons(ETH_P_8021Q)) {
+ if (veth->h_vlan_proto == htons(ETH_P_8021Q)) {
hdr->hdr.l2.flags[2] |= QETH_LAYER2_FLAG_VLAN;
hdr->hdr.l2.vlan_id = ntohs(veth->h_vlan_TCI);
}
diff --git a/drivers/s390/net/qeth_l3_main.c b/drivers/s390/net/qeth_l3_main.c
index 04e42c6..bd6b5a9 100644
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1887,13 +1887,13 @@ static inline int qeth_l3_rebuild_skb(struct qeth_card
*card,
case QETH_CAST_MULTICAST:
switch (prot) {
#ifdef CONFIG_QETH_IPV6
- case __constant_htons(ETH_P_IPV6):
+ case htons(ETH_P_IPV6):
ndisc_mc_map((struct in6_addr *)
skb->data + 24,
tg_addr, card->dev, 0);
break;
#endif
- case __constant_htons(ETH_P_IP):
+ case htons(ETH_P_IP):
ip_hdr = (struct iphdr *)skb->data;
ip_eth_mc_map(ip_hdr->daddr, tg_addr);
break;
@@ -3015,7 +3015,7 @@ static int qeth_l3_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev)
skb_copy_to_linear_data_offset(new_skb, 8,
new_skb->data + 12, 4);
tag = (u16 *)(new_skb->data + 12);
- *tag = __constant_htons(ETH_P_8021Q);
+ *tag = htons(ETH_P_8021Q);
*(tag + 1) = htons(skb_vlan_tag_get(new_skb));
}
}
--
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: Audio crackles with 4.1-rc1
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > From: Takashi Iwai > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > > noises at transition from D3 to D0 when the widget power-saving is > > > > enabled. Further debugging session showed that avoiding it isn't > > > > trivial, unfortunately, since paths are basically activated > > > > dynamically while the pins have been already enabled. > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > Reported-by: Jonathan McDowell > > > > Signed-off-by: Takashi Iwai > > > > --- > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c > > > > b/sound/pci/hda/patch_realtek.c > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > --- a/sound/pci/hda/patch_realtek.c > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > > > spec = codec->spec; > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > - codec->power_save_node = 1; > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > + codec->power_save_node = 1; > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > >alc269_fixup_tbl, alc269_fixups); > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > > E7440): > > > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: > > > line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 > > > (0x14/0x0/0x0/0x0/0x0) > > > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > > > (0x15/0x0/0x0/0x0/0x0) > > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 > > > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > > > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > > > 4.0.4 was fine. > > > > Does it happen only once at boot (i.e. at power up), or happens always > > at runtime PM? If it's a once-off boot thing, the patch shouldn't > > have much effect. Something else, very subtle thing, e.g. the order > > of verb execution, might cause this kind of problem. > > Only at power up. I've also suspend-resumed twice and can confirm it's > OK. > > There's a _very_ brief click at suspend (when the power is cut), but it > looks like a plain circuitry thing. I probably didn't notice it before > because I wasn't looking for it. Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3? Last but not least, a patch like below has any effect? Takashi --- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; } + if (power_state == AC_PWRST_D0) + msleep(100); return state; } -- 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 v11 4/5] x86/earlyprintk: setup earlyprintk as early as possible
2015-06-10 16:36 GMT+06:00 Alexander Kuleshov : > 2015-06-10 15:44 GMT+06:00 Andy Shevchenko > : >> You do parsing twice (still original code and your piece here), and >> honestly I don't like your approach in this form. > > I just researched earlyprintk and we can use not only serial, but > vga and pciserial. What if I'll rename setup_early_serial_console > to the setup_earlyprintk_console, will add variable, something like > this > We can't use pciserial, accidently hit from cut, sorry for the noise. -- 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: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > From: Takashi Iwai > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > noises at transition from D3 to D0 when the widget power-saving is > > > enabled. Further debugging session showed that avoiding it isn't > > > trivial, unfortunately, since paths are basically activated > > > dynamically while the pins have been already enabled. > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > Reported-by: Jonathan McDowell > > > Signed-off-by: Takashi Iwai > > > --- > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > > index 2e246fe495f6..31f8f13be907 100644 > > > --- a/sound/pci/hda/patch_realtek.c > > > +++ b/sound/pci/hda/patch_realtek.c > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > spec = codec->spec; > > > spec->gen.shared_mic_vref_pin = 0x18; > > > - codec->power_save_node = 1; > > > + if (codec->core.vendor_id != 0x10ec0292) > > > + codec->power_save_node = 1; > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > alc269_fixup_tbl, alc269_fixups); > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > E7440): > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: > > line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 > > (0x14/0x0/0x0/0x0/0x0) > > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > > (0x15/0x0/0x0/0x0/0x0) > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 > > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > 4.0.4 was fine. > > Does it happen only once at boot (i.e. at power up), or happens always > at runtime PM? If it's a once-off boot thing, the patch shouldn't > have much effect. Something else, very subtle thing, e.g. the order > of verb execution, might cause this kind of problem. Only at power up. I've also suspend-resumed twice and can confirm it's OK. There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it. -- Mihai Donțu -- 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/18] kthreads/signal: Safer kthread API and signal handling
On Tue, Jun 09, 2015 at 03:14:46PM +0900, Tejun Heo wrote: > Hey, Peter. > > On Fri, Jun 05, 2015 at 06:22:16PM +0200, Peter Zijlstra wrote: > > There's a lot more problems with workqueues: > > > > - they're not regular tasks and all the task controls don't work on > >them. This means all things scheduler, like cpu-affinity, nice, and > >RT/deadline scheduling policies. Instead there is some half baked > >secondary interface for some of these. > > Because there's a pool of them and the workers come and go > dynamically. There's no way around it. The attributes just have to > be per-pool. Sure, but there's a few possible ways to still make that work with the regular syscall interfaces. 1) propagate the change to any one worker to all workers of the same pool 2) have a common ancestor task for each pool, and allow changing that. You can combine that with either the propagation like above, or a rule that workers kill themselves if they observe their parent changed (eg. check a attribute sequence count after each work). > >But this also very much includes things like cgroups, which brings me > >to the second point. > > > > - its oblivious to cgroups (as it is to RT priority for example) both > >leading to priority inversion. A work enqueued from a deep/limited > >cgroup does not inherit the task's cgroup. Instead this work is ran > >from the root cgroup. > > > >This breaks cgroup isolation, more significantly so when a large part > >of the actual work is done from workqueues (as some workloads end up > >being). Instead of being able to control the work, it all ends up in > >the root cgroup outside of control. > > cgroup support will surely be added but I'm not sure we can or should > do inheritance automatically. I think its a good default to inherit stuff from the task that queued it. > Using a different API doesn't solve the > problem automatically either. A lot of kthreads are shared > system-wide after all. We'll need an abstraction layer to deal with > that no matter where we do it. Yes, hardware threads are global, but so is the hardware. Those are not a problem provided the thread map 1:1 with the actual devices and do not service multiple devices from a single thread. Once you start combining things you start to get all the above problems all over again. -- 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 RFC v3 1/2] devicetree: Add DT bindings documentation for Zynq Ultrascale+ MPSoC GQSPI controller
Add bindings documentation for GQSPI controller driver used by
Zynq Ultrascale+ MPSoC
Signed-off-by: Ranjit Waghmode
---
Changes in v3:
- Did split in register addressing as per Sorens request
Changes in v2:
No changes in v2
---
.../devicetree/bindings/spi/spi-zynqmp-qspi.txt| 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
new file mode 100644
index 000..c8f50e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
@@ -0,0 +1,26 @@
+Xilinx Zynq UltraScale+ MPSoC GQSPI controller Device Tree Bindings
+---
+
+Required properties:
+- compatible : Should be "xlnx,zynqmp-qspi-1.0".
+- reg : Physical base address and size of GQSPI registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller.
+- clock-names : List of input clock names - "ref_clk", "pclk"
+ (See clock bindings for details).
+- clocks : Clock phandles (see clock bindings for details).
+
+Optional properties:
+- num-cs : Number of chip selects used.
+
+Example:
+ qspi: spi@ff0f {
+ compatible = "xlnx,zynqmp-qspi-1.0";
+ clock-names = "ref_clk", "pclk";
+ clocks = <_clk _clk>;
+ interrupts = <0 15 4>;
+ interrupt-parent = <>;
+ num-cs = <1>;
+ reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 0x800>;
+ };
--
2.1.2
--
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 v11 4/5] x86/earlyprintk: setup earlyprintk as early as possible
2015-06-10 15:44 GMT+06:00 Andy Shevchenko :
> You do parsing twice (still original code and your piece here), and
> honestly I don't like your approach in this form.
I just researched earlyprintk and we can use not only serial, but
vga and pciserial. What if I'll rename setup_early_serial_console
to the setup_earlyprintk_console, will add variable, something like
this
static unsigned int early = 1;
to the arch/x86/kernel/earlyprintk.c and refactor the
setup_early_serial_console as:
int __init setup_earlyprintk_console(void)
{
char *arg;
arg = strstr(boot_command_line, "earlyprintk=");
if (!arg)
return -1;
early = 0;
return setup_early_printk(arg);
}
After this we can check in the setup_earlyprintk
is it early to set other consoles or not,
while (*buf != '\0') {
#ifdef CONFIG_EARLY_PRINTK_EFI
if (!strncmp(buf, "efi", 3) && early)
early_console_register(_efi_console, keep);
#endif
}
early = 1;
So, when we will call setup_earlyprintk_console from the
arch/x86/kernel/head{32,64}.c, early variable will be 0 and
it allows us to setup only 'real early' consoles and when
setup_earlyprintk will be called by the do_early_param
early variable will be one and we will be able to setup
efi console and etc
What do you think about it?
--
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] usb: udc: Convert use of __constant_cpu_to_leXX to cpu_to_leXX
In big endian cases, the macro cpu_to_le{16,32} unfolds to __swab{16,32}
which provides special case for constants. In little endian cases,
__constant_cpu_to_le{16,32} and cpu_to_le{16,32} expand directly to
the same expression. So, replace __constant_cpu_to_le{16,32} with
cpu_to_le{16,32} with the goal of getting rid of the definition of
__constant_cpu_to_le{16,32} completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
(
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
|
- __constant_cpu_to_le32(x)
+ cpu_to_le32(x)
)
Signed-off-by: Vaishali Thakkar
---
drivers/usb/gadget/udc/net2272.c | 4 ++--
drivers/usb/gadget/udc/pch_udc.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index 195baf3..c2ed5da 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -1826,9 +1826,9 @@ net2272_handle_stat0_irqs(struct net2272 *dev, u8 stat)
if (!e || u.r.wLength > 2)
goto do_stall;
if (net2272_ep_read(e, EP_RSPSET) & (1 <<
ENDPOINT_HALT))
- status = __constant_cpu_to_le16(1);
+ status = cpu_to_le16(1);
else
- status = __constant_cpu_to_le16(0);
+ status = cpu_to_le16(0);
/* don't bother with a request object! */
net2272_ep_write(>ep[0], EP_IRQENB, 0);
diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 613547f..dcf5def 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -1793,7 +1793,7 @@ static struct usb_request *pch_udc_alloc_request(struct
usb_ep *usbep,
}
/* prevent from using desc. - set HOST BUSY */
dma_desc->status |= PCH_UDC_BS_HST_BSY;
- dma_desc->dataptr = __constant_cpu_to_le32(DMA_ADDR_INVALID);
+ dma_desc->dataptr = cpu_to_le32(DMA_ADDR_INVALID);
req->td_data = dma_desc;
req->td_data_last = dma_desc;
req->chain_len = 1;
--
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: [RFT v2 06/48] pinctrl: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
2015-06-04 6:13 GMT+02:00 Jiang Liu : > Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we > already have a pointer to corresponding irq_desc. > > Signed-off-by: Jiang Liu > Acked-by: Linus Walleij > --- [...] > drivers/pinctrl/mediatek/pinctrl-mtk-common.c |4 ++-- For the changes in pinctrl-mtk-common.c: Acked-by: Matthias Brugger -- 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] MIPS: bugfix of local_r4k_flush_icache_range - added L2 flush
On Thu, May 28, 2015 at 01:37:24PM -0700, Leonid Yegoshin wrote: > This function is used to flush code used in NMI and EJTAG debug exceptions. > However, during that exceptions the Status.ERL bit is set, which means > that code runs as UNCACHABLE. So, flush code down to memory is needed. > > Signed-off-by: Leonid Yegoshin > --- > arch/mips/mm/c-r4k.c | 10 +- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c > index 0dbb65a51ce5..9f0299bb9a2a 100644 > --- a/arch/mips/mm/c-r4k.c > +++ b/arch/mips/mm/c-r4k.c > @@ -666,17 +666,9 @@ static inline void local_r4k_flush_icache_range(unsigned > long start, unsigned lo > break; > } > } > -#ifdef CONFIG_EVA > - /* > - * Due to all possible segment mappings, there might cache aliases > - * caused by the bootloader being in non-EVA mode, and the CPU switching > - * to EVA during early kernel init. It's best to flush the scache > - * to avoid having secondary cores fetching stale data and lead to > - * kernel crashes. > - */ > + > bc_wback_inv(start, (end - start)); > __sync(); > -#endif > } I was wondering why there was a cache flush at all so I dove into git history and found: commit 4676f9359fa5190ee6f42bbf2c27d28beb14d26a Author: Leonid Yegoshin Date: Tue Jan 21 09:48:48 2014 + MIPS: mm: c-r4k: Flush scache to avoid cache aliases There is a chance for the secondary cache to have memory aliases. This can happen if the bootloader is in a non-EVA mode (or even in EVA mode but with different mapping from the kernel) and the kernel switching to EVA afterwards. It's best to flush the icache to avoid having the secondary CPUs fetching stale data from it. Signed-off-by: Leonid Yegoshin Signed-off-by: Markos Chandras flush_icache_range() really only is meant to deal with I-cache coherency issues as they appear during normal kernel operation, that is code is modified and will be executed from RAM. I doesn't know about aliases and it's not meant to know. As I understand you only need this on startup. Making this function work for your special use results in a performance penalty for every other user of this function. How about reverting this commit and calling __flush_cache_all() to make sure your kernel code gets flushed out to the other end of the universe - or memory, what ever comes first? Ralf -- 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: deleting a btrfs subvolume shut up a server
On Thu, May 14, 2015 at 02:16:58PM +0200, Toralf Förster wrote: > I created at a 3 TB btrfs formatted disk a btrfs subvolume, unpacked a > minimal Gentoo Linux in it, created in addition few files within it under > ./tmp and bind mount from the host few files onto those files. If I now > delete in another terminal the subvolume - then the server dies immediately > > It is a headless server, I had to request a manually reset to get it back. > Nothing in the syslog (syslog-ng 3.6.2) - the server was just shot in he head. > > This happened 2 times in a row. Host is a stable hardened Gentoo with 4.0.2 > kernel. Hmm, is it possible to get some information from netconsole? Thanks, -liubo > > :-/ > > -- > Toralf > pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E > -- > "; the past is all dirty and cruel in the modern popular imagination, with > the exception of the Romans, who are just cruel" > Ian Mortimer, 2008, "The Time Traveller's Guide to Medieval England" > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 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/
Re: Audio crackles with 4.1-rc1
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > From: Takashi Iwai > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > noises at transition from D3 to D0 when the widget power-saving is > > enabled. Further debugging session showed that avoiding it isn't > > trivial, unfortunately, since paths are basically activated > > dynamically while the pins have been already enabled. > > > > This patch disables the widget power-saving for such codecs. > > > > Reported-by: Jonathan McDowell > > Signed-off-by: Takashi Iwai > > --- > > sound/pci/hda/patch_realtek.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > index 2e246fe495f6..31f8f13be907 100644 > > --- a/sound/pci/hda/patch_realtek.c > > +++ b/sound/pci/hda/patch_realtek.c > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > spec = codec->spec; > > spec->gen.shared_mic_vref_pin = 0x18; > > - codec->power_save_node = 1; > > + if (codec->core.vendor_id != 0x10ec0292) > > + codec->power_save_node = 1; > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > >alc269_fixup_tbl, alc269_fixups); > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > get the audio artifacts (crackles) when I boot my laptop (Latitude > E7440): > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: > line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 > (0x14/0x0/0x0/0x0/0x0) > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > (0x15/0x0/0x0/0x0/0x0) > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > 4.0.4 was fine. Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem. Takashi -- 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 00/21] On-demand device registration
On 10 June 2015 at 09:30, Linus Walleij wrote: > On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso > wrote: >> On 2 June 2015 at 10:48, Linus Walleij wrote: > >>> This is what systemd is doing in userspace for starting services: >>> ask for your dependencies and wait for them if they are not >>> there. So drivers ask for resources and wait for them. It also >>> needs to be abstract, so for example we need to be able to >>> hang on regulator_get() until the driver is up and providing that >>> regulator, and as long as everything is in slowpath it should >>> be OK. (And vice versa mutatis mutandis for clk, gpio, pin >>> control, interrupts (!) and DMA channels for example.) >> >> I understood above that you propose probing devices in order, but now >> you mention that resource getters would block until the dependency is >> fulfilled which confuses me because if we are probing in order then >> all dependencies would be fulfilled before the device in question gets >> probed. > > Sorry, the problem space is a bit convoluted so the answers > get a bit convoluted. Maybe I'm thinking aloud and altering the course > of my thoughts as I type... > > I guess there can be explicit dependencies for resources like this > patch does, but another way would be for all resource fetch functions > to be instrumented, so that you do not block until you try to take > a resource that is not yet there, e.g.: > > regulator_get(...) -> not available, so: > - identify target regulator provider - this will need instrumentation > - probe it > > It then turns out the regulator driver is on the i2c bus, so we > need to probe the i2c driver: > - identify target i2c host for the regulator driver - this will need > instrumentation > - probe the i2c host driver > > i2c host comes out, probes the regulator driver, regulator driver > probes and then the regulator_get() call returns. Hmm, if I understand correctly what you say, this is exactly what this particular series does: regulator_get -> of_platform_device_ensure -> probe() on the platform device that encloses the requested device node (i2c host) -> i2c slave gets probed and the regulator registered -> regulator_get returns the requested resource The downside I'm currently looking at is that an explicit dependency graph would be useful to have for other purposes. For example to print a neat warning when a dependency cannot be fulfilled. Or to refuse to unbind a device which other devices depend on, or to automatically unbind the devices that depend on it, or to print a warning if a device is hotplugged off and other devices depend on it. > This requires instrumentation on anything providing a resource > to another driver like those I mentioned and a lot of overhead > infrastructure, but I think it's the right approach. However I don't > know if I would ever be able to pull that off myself, I know talk > is cheap and I should show the code instead. Yeah, if you can give it a second look and say if it matches what you wrote above, it would be very much appreciated. > Deepest respect for your efforts! Thanks! Tomeu > Yours, > Linus Walleij > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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: Audio crackles with 4.1-rc1
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > From: Takashi Iwai > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > noises at transition from D3 to D0 when the widget power-saving is > enabled. Further debugging session showed that avoiding it isn't > trivial, unfortunately, since paths are basically activated > dynamically while the pins have been already enabled. > > This patch disables the widget power-saving for such codecs. > > Reported-by: Jonathan McDowell > Signed-off-by: Takashi Iwai > --- > sound/pci/hda/patch_realtek.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > index 2e246fe495f6..31f8f13be907 100644 > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > spec = codec->spec; > spec->gen.shared_mic_vref_pin = 0x18; > - codec->power_save_node = 1; > + if (codec->core.vendor_id != 0x10ec0292) > + codec->power_save_node = 1; > > snd_hda_pick_fixup(codec, alc269_fixup_models, > alc269_fixup_tbl, alc269_fixups); I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440): [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 4.0.4 was fine. -- Mihai Donțu -- 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] Input: goodix - do not explicitly set evbits in input device
On Tue, 2015-06-09 at 11:52 -0700, Dmitry Torokhov wrote: > input_mt_init_slots() will do that for us. I'm guessing you know what you're doing here, but I couldn't find where the EV_SYN bit would have been set in the input_mt_init_slots() call chain. > Signed-off-by: Dmitry Torokhov > --- > drivers/input/touchscreen/goodix.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/input/touchscreen/goodix.c > b/drivers/input/touchscreen/goodix.c > index 73ade35..b4d12e2 100644 > --- a/drivers/input/touchscreen/goodix.c > +++ b/drivers/input/touchscreen/goodix.c > @@ -301,10 +301,6 @@ static int goodix_request_input_dev(struct > goodix_ts_data *ts, u16 version, > return -ENOMEM; > } > > - ts->input_dev->evbit[0] = BIT_MASK(EV_SYN) | > - BIT_MASK(EV_KEY) | > - BIT_MASK(EV_ABS); > - > input_set_abs_params(ts->input_dev, ABS_MT_POSITION_X, >0, ts->abs_x_max, 0, 0); > input_set_abs_params(ts->input_dev, ABS_MT_POSITION_Y, > -- > 2.2.0.rc0.207.ga3a616c > > -- 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] checkpatch: Add some _destroy functions to NEEDLESS_IF tests
On (06/09/15 22:52), Joe Perches wrote:
> Sergey Senozhatsky has modified several destroy functions that can
> now be called with NULL values.
>
> - kmem_cache_destroy()
> - mempool_destroy()
> - dma_pool_destroy()
>
> Update checkpatch to warn when those functions are preceded by an if.
>
> Update checkpatch to --fix all the calls too only when the code style
> form is using leading tabs.
>
> from:
> if (foo)
> (foo);
> to:
> (foo);
>
> Signed-off-by: Joe Perches
nice.
works fine to me. you can add
Tested-by: Sergey Senozhatsky
if needed.
-ss
> ---
> V2: Remove useless debugging print messages and multiple quotemetas
>
> scripts/checkpatch.pl | 32
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 69c4716..87d3bf1aa 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4800,10 +4800,34 @@ sub process {
>
> # check for needless "if () fn()" uses
> if ($prevline =~ /\bif\s*\(\s*($Lval)\s*\)/) {
> - my $expr = '\s*\(\s*' . quotemeta($1) . '\s*\)\s*;';
> - if ($line =~
> /\b(kfree|usb_free_urb|debugfs_remove(?:_recursive)?)$expr/) {
> - WARN('NEEDLESS_IF',
> - "$1(NULL) is safe and this check is
> probably not required\n" . $hereprev);
> + my $tested = quotemeta($1);
> + my $expr = '\s*\(\s*' . $tested . '\s*\)\s*;';
> + if ($line =~
> /\b(kfree|usb_free_urb|debugfs_remove(?:_recursive)?|(?:kmem_cache|mempool|dma_pool)_destroy)$expr/)
> {
> + my $func = $1;
> + if (WARN('NEEDLESS_IF',
> + "$func(NULL) is safe and this check is
> probably not required\n" . $hereprev) &&
> + $fix) {
> + my $do_fix = 1;
> + my $leading_tabs = "";
> + my $new_leading_tabs = "";
> + if ($lines[$linenr - 2] =~
> /^\+(\t*)if\s*\(\s*$tested\s*\)\s*$/) {
> + $leading_tabs = $1;
> + } else {
> + $do_fix = 0;
> + }
> + if ($lines[$linenr - 1] =~
> /^\+(\t+)$func\s*\(\s*$tested\s*\)\s*;\s*$/) {
> + $new_leading_tabs = $1;
> + if (length($leading_tabs) + 1
> ne length($new_leading_tabs)) {
> + $do_fix = 0;
> + }
> + } else {
> + $do_fix = 0;
> + }
> + if ($do_fix) {
> + fix_delete_line($fixlinenr - 1,
> $prevrawline);
> + $fixed[$fixlinenr] =~
> s/^\+$new_leading_tabs/\+$leading_tabs/;
> + }
> + }
> }
> }
>
>
>
--
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] devicetree: xilinx: zynqmp: add sata node
add sata node with sata fixed clock nodes in dtsi file.
enable sata in zynqmp-ep108.dts with broken-gen2.
Signed-off-by: Suneel Garapati
---
Note -
Driver and bindings are added via libata/for-4.2 tree
bindings is found in Documentation/devicetree/bindings/ata/ahci-ceva.txt
---
arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 5 +
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 15 +++
2 files changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index 0a3f40e..981e594 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -42,6 +42,11 @@
};
};
+ {
+ status = "okay";
+ ceva,broken-gen2;
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 11e0b00..e7545ed 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -272,6 +272,21 @@
#size-cells = <0>;
};
+ sata_clk: sata_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <7500>;
+ };
+
+ sata0: ahci@fd0c {
+ compatible = "ceva,ahci-1v84";
+ status = "disabled";
+ reg = <0x0 0xfd0c 0x2000>;
+ interrupt-parent = <>;
+ interrupts = <0 133 4>;
+ clocks = <_clk>;
+ };
+
sdhci0: sdhci@ff16 {
compatible = "arasan,sdhci-8.9a";
status = "disabled";
--
2.1.2
--
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 0/3] TLB flush multiple pages per IPI v5
On Wed, Jun 10, 2015 at 11:08:13AM +0200, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > Stop this crap. > > > > I made a really clear and unambiguous chain of arguments: > > > > - I'm unconvinced about the benefits of INVLPG in general, and your > > patches adds > >a whole new bunch of them. [...] > > ... and note that your claim that 'we were doing them before, this is just an > equivalent transformation' is utter bullsh*t technically: what we were doing > previously was a hideously expensive IPI combined with an INVLPG. > And replacing it with an INVLPG without excessive IPI transmission is changing one major variable. Going straight to a full TLB flush is changing two major variables. I thought the refill cost was high, parially based on the estimate of 22,000 cycles in https://lkml.org/lkml/2014/7/31/825. I've been told in these discussions that I'm wrong and the cost is not high. As it'll always be variable, we can never be sure which is why I do not see a value to building a complex test around it that will be invalidated the instant we use a different CPU. When/if a workload shows up that really cares about those refill costs then there will be a stable test case to work from. > The behavior was dominated by the huge overhead of the remote flushing IPI, > which > does not prove or disprove either your or my opinion! > > Preserving that old INVLPG logic without measuring its benefits _again_ would > be > cargo cult programming. > > So I think this should be measured, and I don't mind worst-case TLB trashing > measurements, which would be relatively straightforward to construct and the > results should be unambiguous. > > The batching limit (which you set to 32) should then be tuned by comparing it > to a > working full-flushing batching logic, not by comparing it to the previous > single > IPI per single flush approach! > We can decrease it easily but increasing it means we also have to change SWAP_CLUSTER_MAX because otherwise enough pages are not unmapped for flushes and it is a requirement that we flush before freeing the pages. That changes another complex variable because at the very least, it alters LRU lock hold times. > ... and if the benefits of a complex algorithm are not measurable and if > there are > doubts about the cost/benefit tradeoff then frankly it should not exist in > the > kernel in the first place. It's not like the Linux TLB flushing code is too > boring > due to overwhelming simplicity. > > and yes, it's my job as a maintainer to request measurements justifying > complexity > and your ad hominem attacks against me are disgusting - you should know > better. > It was not intended as an ad hominem attack and my apologies for that. I wanted to express my frustration that a series that adjusted one variable with known benefit will be rejected for a series that adjusts two major variables instead with the second variable being very sensitive to workload and CPU. -- Mel Gorman SUSE Labs -- 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] regulator: Add lockdep asserts to help detecting locking misuse
On Wed, Jun 10, 2015 at 03:23:12PM +0900, Krzysztof Kozlowski wrote: > Add lockdep_assert_held_once() to functions explicitly mentioning that > rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't > pollute the dmesg to much. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] ARM: Re-enable TRACE_IRQFLAGS_SUPPORT on ARMv7-M
2015-06-09 19:37 GMT+02:00 Daniel Thompson : > On 09/06/15 16:01, Russell King - ARM Linux wrote: >> >> On Tue, Jun 09, 2015 at 12:41:50PM +0100, Daniel Thompson wrote: >>> >>> Does the following patch, which makes the arch_irqs_disabled() >>> implementation from asm-generic available on arm, fix the build for you? >> >> >> Yes, this is exactly the kind of fix for this I'm looking for. Once >> everyone's happy with it, it can find it's way to the patch system. > > > From my side, using v4.1-rc6 plus the patch, I can build all defconfigs and > both versatile_defconfig and multi_v7_defconfig remain bootable (so both > ways through the arch #ifdef in irqflag.h). > > Similarly working on linux-next-20150608 plus the patch I am able to build > and boot Maxime's stm32 code (and show that without the patch it doesn't > build). Ok, thanks for having tested on STM32. > > From my side I think that makes it good to go. > > So... in the absense of objections I will send it to the patch tracker > tomorrow. For what it is worth, you can add: Acked-by: Maxime Coquelin Regards, Maxime -- 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 22/28] ARCv2: STAR 9000837815 workaround hardware exclusive transactions livelock
On Tuesday 09 June 2015 06:05 PM, Peter Zijlstra wrote: On Tue, Jun 09, 2015 at 05:18:22PM +0530, Vineet Gupta wrote: This really really wants a Changelog describing the actual hardware fail and why this workaround is sufficient. OK - I need some more time to rehash the exact details with our hardware folks. But AFAIKR, this was hardware livelock in llock/scond when 2 cores were doing r-m-w to two different words in the same cache line - adding prefetchw (prefetch with a write intent) would get the line in exclusive state and break the livelock. The test itself was one from EEMBC Multibench but I'll have to look it up. Wasn't there something similar in ARM world too - they have some sort of snoop-delayed exclusive handling in hardware to mitigate something similar although as Will later remarked it involved llock/scond with vanilla ld/st to same line/word ? http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/254142.html Thx, -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/
Re: [PATCH v5] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
On Tue, Jun 09, 2015 at 10:02:00PM +0100, Russell King - ARM Linux wrote: > On Tue, Jun 09, 2015 at 12:08:28PM -0700, Stephen Boyd wrote: > > On 04/13/2015 06:42 AM, Russell King - ARM Linux wrote: > > > On Fri, Apr 10, 2015 at 03:33:11PM -0700, Stephen Boyd wrote: > > >> Cc: Mark Rutland > > >> Cc: Nicolas Pitre > > >> Cc: Dave Martin > > >> Acked-by: Simon Horman [shmobile portion] > > >> Tested-by: Simon Horman > > >> Cc: Magnus Damm > > >> Cc: > > >> Cc: Tyler Baker > > >> Cc: Geert Uytterhoeven > > >> Signed-off-by: Stephen Boyd > > > Let's see some more acks for this... > > > > > > > Nobody else has acked this so far. Shall I put it in the patch tracker > > now? Or is there someone more specific we need an ack from? > > I guess if people haven't responded by now, they're never going to respond, > and I guess we take their non-response as tacit approval for the change. > > Maybe we ought to have tacit-acked-by: which we can add when someones > been Cc'd and hasn't responded. :) I think we also need a "To:" tag for people who don't notice when they are cc'ed ;). -- Catalin -- 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/4] mm: Send one IPI per CPU to TLB flush all entries after unmapping pages
On Wed, Jun 10, 2015 at 10:26:40AM +0200, Ingo Molnar wrote: > > * Mel Gorman wrote: > > > On a 4-socket machine the results were > > > > 4.1.0-rc6 4.1.0-rc6 > > batchdirty-v6 batchunmap-v6 > > Ops lru-file-mmap-read-elapsed 121.27 ( 0.00%) 118.79 ( 2.05%) > > > >4.1.0-rc6 4.1.0-rc6 > > batchdirty-v6 batchunmap-v6 > > User 620.84 608.48 > > System 4245.354152.89 > > Elapsed 122.65 120.15 > > > > In this case the workload completed faster and there was less CPU overhead > > but as it's a NUMA machine there are a lot of factors at play. It's easier > > to quantify on a single socket machine; > > > > 4.1.0-rc6 4.1.0-rc6 > > batchdirty-v6 batchunmap-v6 > > Ops lru-file-mmap-read-elapsed20.35 ( 0.00%)21.52 ( -5.75%) > > > >4.1.0-rc6 4.1.0-rc6 > > batchdirty-v6r5batchunmap-v6r5 > > User 58.02 60.70 > > System 77.57 81.92 > > Elapsed22.14 23.16 > > > > That shows the workload takes 5.75% longer to complete with a similar > > increase in the system CPU usage. > > Btw., do you have any stddev noise numbers? > 4.1.0-rc6 4.1.0-rc6 4.1.0-rc6 4.1.0-rc6 vanilla flushfull-v6r5 batchdirty-v6r5batchunmap-v6r5 Ops lru-file-mmap-read-elapsed 25.43 ( 0.00%)20.59 ( 19.03%) 20.35 ( 19.98%)21.52 ( 15.38%) Ops lru-file-mmap-read-time_stddv 0.32 ( 0.00%) 0.32 ( -1.30%) 0.39 (-23.00%) 0.45 (-40.91%) flushfull -- patch 2 batchdirty -- patch 3 batchunmap -- patch 4 So the impact of tracking the PFNs is outside the noise and there is definite direct cost to it. This was expected for both the PFN tracking and the individual flushes. > The batching speedup is brutal enough to not need any noise estimations, it's > a > clear winner. > Agreed. > But this PFN tracking patch is more difficult to judge as the numbers are > pretty > close to each other. > It's definitely measurable, no doubt about it and there never was. The concerns were always the refill costs due to flushing potentially active TLB entries unnecessarily. From https://lkml.org/lkml/2014/7/31/825, this is potentially high where it says that a 512 DTLB refill takes 22,000 cycles which is higher than the individual flushes. However, this is an estimate and it'll always be a case of "it depends". It's been asserted that the refill costs are really low so lets just go with that, drop patch 4 and wait and see who complains. -- Mel Gorman SUSE Labs -- 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] slub/slab: fix kmemleak didn't work on some case
On Wed, Jun 10, 2015 at 08:45:50AM +0100, Zhang, Yanmin wrote: > On 2015/6/9 23:03, Catalin Marinas wrote: > > On Tue, Jun 09, 2015 at 09:10:45AM +0100, Zhang, Yanmin wrote: > >> On 2015/6/8 18:13, Catalin Marinas wrote: > >>> As I replied already, I don't think this is that bad, or at least not > >>> worse than what kmemleak already does (looking at all data whether it's > >>> pointer or not). > >> It depends. As for memleak, developers prefers there are false alarms > >> instead > >> of missing some leaked memory. > > Lots of false positives aren't that nice, you spend a lot of time > > debugging them (I've been there in the early kmemleak days). Anyway, > > your use case is not about false positives vs. negatives but just false > > negatives. > > > > My point is that there is a lot of random, pointer-like data read by > > kmemleak even without this memset (e.g. thread stacks, non-pointer data > > in kmalloc'ed structures, data/bss sections). Just doing this memset may > > reduce the chance of false negatives a bit but I don't think it would be > > noticeable. > > > > If there is some serious memory leak (lots of objects), they would > > likely show up at some point. Even if it's a one-off leak, it's possible > > that it shows up after some time (e.g. the object pointing to this > > memory block is freed). > > > >>> It also doesn't solve the kmem_cache_alloc() case where > >>> the original object size is no longer available. > >> Such issue around kmem_cache_alloc() case happens only when the > >> caller doesn't initialize or use the full object, so the object keeps > >> old dirty data. > > The kmem_cache blocks size would be aligned to a cache line, so you > > still have some extra bytes never touched by the caller. > > > >> This patch is to resolve the redundant unused space (more than object size) > >> although the full object is used by kernel. > > So this solves only the cases where the original object size is still > > known (e.g. kmalloc). It could also be solved by telling kmemleak the > > actual object size. > > Your explanation is reasonable. The patch is for debug purpose. > Maintainers can make decision based on balance. The patch, as it stands, should not go in: - too much code duplication (I already commented that a function similar to kmemleak_erase would look much better) - I don't think there is a noticeable benefit but happy to be proven wrong - there are other ways of achieving the same > Xinwu is a new developer in kernel community. Accepting the patch > into kernel can encourage him definitely. :) As would constructive feedback ;) That said, it would probably be more beneficial to be able to tell kmemleak of the actual object size via another callback. This solves the scanning of the extra data in a slab, restricts pointer values referencing the object and better identification of the leaked objects (by printing its real size). Two options: a) Use the existing kmemleak_free_part() function to free the end of the slab. This was originally meant for memblock freeing but can be improved slightly to avoid creating a new object and deleting the old one when only the last part of the block is freed. b) Implement a new kmemleak_set_size(const void *ptr, size_t size). All it needs to do is update the object->size value, no need for re-inserting into the rb-tree. Option (b) is probably better, especially with the latest patches I posted where kmemleak_free*() always deletes the original object. -- Catalin -- 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 v11 4/5] x86/earlyprintk: setup earlyprintk as early as possible
On Wed, 2015-06-10 at 00:00 +0600, Alexander Kuleshov wrote:
> 2015-06-09 23:00 GMT+06:00 Andy Shevchenko
> :
> >
> > I'm still not convincing by this code to be in that form and here. What
> > about to refactor setup_early_printk() to helper which will do parse
> > parameters to a let say structure where one of the flag will be
> > struct early_printk_param {
> > …
> > const char *arg;
> > bool serial;
> > }
> >
> > Your function will be something like this
> >
> > struct early_printk_param epp;
> >
> > parse_early_printk_param();
> >
> > if (!epp->serial)
> > return /* whatever error code */;
> >
> > return setup_early_printk(epp.arg);
> >
>
> Hello Andy,
>
> But what is difference between parsing to string and
> passing it and parsing to structure and pass its field?
You do parsing twice (still original code and your piece here), and
honestly I don't like your approach in this form.
>
> Thank you.
--
Andy Shevchenko
Intel Finland Oy
--
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 3/8] Driver core: wakeup the parent device before trying probe
On Wed, 2015-06-10 at 02:08 +0200, Rafael J. Wysocki wrote:
> On Tuesday, June 09, 2015 01:42:00 AM Rafael J. Wysocki wrote:
> > On Monday, June 01, 2015 05:47:57 PM Andy Shevchenko wrote:
> > > From: Heikki Krogerus
> > >
> > > If the parent is still suspended when driver probe is
> > > attempted, the result may be failure.
> > >
> > > For example, if the parent is a PCI MFD device that has been
> > > suspended when we try to probe our device, any register
> > > reads will return 0x.
> > >
> > > To fix the problem, making sure the parent is always awake
> > > before attempting driver probe.
> > >
> > > Signed-off-by: Heikki Krogerus
> > > Signed-off-by: Andy Shevchenko
> > > ---
> > > drivers/base/dd.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > index e843fdb..cfbeff3 100644
> > > --- a/drivers/base/dd.c
> > > +++ b/drivers/base/dd.c
> > > @@ -399,6 +399,8 @@ EXPORT_SYMBOL_GPL(wait_for_device_probe);
> > > *
> > > * This function must be called with @dev lock held. When called for a
> > > * USB interface, @dev->parent lock must be held as well.
> > > + *
> > > + * If device has a parent it will be powered on during device's probe().
> > > */
> > > int driver_probe_device(struct device_driver *drv, struct device *dev)
> > > {
> > > @@ -410,10 +412,16 @@ int driver_probe_device(struct device_driver *drv,
> > > struct device *dev)
> > > pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
> > >drv->bus->name, __func__, dev_name(dev), drv->name);
> > >
> > > + if (dev->parent)
> > > + pm_runtime_get_sync(dev->parent);
> > > +
> >
> > For some bus types that will resume and suspend the parent for many times in
> > a row in device_attach() until an appropriate driver is found. Would it be
> > more efficient to call it once before the bus_for_each_drv() loop in there?
>
> Actually, something like the below should work too (the bumping up of the
> parent's usage counter before the loop will keep it in the runtime-active
> state throughout the loop).
>
Thanks for the patch! We are going to test this soon.
By the way, can you give your Ack for patches 1 and 2 if there is no
objection?
> ---
> drivers/base/dd.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> Index: linux-pm/drivers/base/dd.c
> ===
> --- linux-pm.orig/drivers/base/dd.c
> +++ linux-pm/drivers/base/dd.c
> @@ -399,6 +399,8 @@ EXPORT_SYMBOL_GPL(wait_for_device_probe)
> *
> * This function must be called with @dev lock held. When called for a
> * USB interface, @dev->parent lock must be held as well.
> + *
> + * If the device has a parent, runtime-resume the parent before driver
> probing.
> */
> int driver_probe_device(struct device_driver *drv, struct device *dev)
> {
> @@ -410,10 +412,16 @@ int driver_probe_device(struct device_dr
> pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
>drv->bus->name, __func__, dev_name(dev), drv->name);
>
> + if (dev->parent)
> + pm_runtime_get_sync(dev->parent);
> +
> pm_runtime_barrier(dev);
> ret = really_probe(dev, drv);
> pm_request_idle(dev);
>
> + if (dev->parent)
> + pm_runtime_put(dev->parent);
> +
> return ret;
> }
>
> @@ -459,8 +467,14 @@ int device_attach(struct device *dev)
> ret = 0;
> }
> } else {
> + if (dev->parent)
> + pm_runtime_get_sync(dev->parent);
> +
> ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
> pm_request_idle(dev);
> +
> + if (dev->parent)
> + pm_runtime_put(dev->parent);
> }
> out_unlock:
> device_unlock(dev);
>
--
Andy Shevchenko
Intel Finland Oy
--
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 20/28] ARCv2: barriers
On Tuesday 09 June 2015 06:10 PM, Peter Zijlstra wrote:
> On Tue, Jun 09, 2015 at 05:18:20PM +0530, Vineet Gupta wrote:
>
> A description of how your hardware works; or a reference to the platform
> documentation would not go amiss.
Honestly the docs group is working on a publicly sharable version of PRM
(Programmer's Reference Manual) but it might take some more time. I'm sure
kernel
developers including you don't like to sign an NDA The information I have in
comments is pretty much what we have in there w.r.t. the barrier instructions.
But
I will capture the the weak memory ordering and other details as part of
changelog
here too.
>> [snip ]
>> +/*
>> + * DMB:
>> + * - Ensures that selected memory operation issued before it will complete
>> + * before any subsequent memory operation of same type
>> + */
>> +#define smp_mb()asm volatile("dmb 3\n" : : : "memory")
>> +#define smp_rmb() asm volatile("dmb 1\n" : : : "memory")
>> +#define smp_wmb() asm volatile("dmb 2\n" : : : "memory")
>> +
>> +/*
>> + * DSYNC:
>> + * - Waits for completion of all outstanding memory operations before any
>> new
>> + * operations can begin
>> + * - Includes implicit memory operations such as cache/TLB/BPU
>> maintenance ops
>> + * - Lighter version of SYNC as it doesn't wait for non-memory operations
>> + */
>> +#define mb()asm volatile("dsync\n" : : : "memory")
> So mb() is supposed to order against things like DMA memory ops, is DMA
> part of point 1 or 3, if 3, this is not a suitable instruction.
Can u please explain the DMA case a bit more ? From what I understood and used
in
say ethernet driver, it is more of a line drawn between say cpu updating a
shared
buffer descriptor and kicking a MMIO register (which in turn could initiate a
DMA)
but I'm not sure how mb() can possibly order with DMA per se (unless there's
some
advanced form of IO-coherency)
-Vineet
>
>> +#else /* CONFIG_ISA_ARCOMPACT */
>> +
>> +/* SYNC:
>> + * - Waits for completion of all outstanding memory transactions AND all
>> + * previous instructions to reture
>> + */
>> +#define mb()asm volatile("sync\n" : : : "memory")
>> +
>> +#endif /* CONFIG_ISA_ARCV2 */
>
>
--
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 6/6] mm, compaction: decouple updating pageblock_skip and cached pfn
The pageblock_skip bitmap and cached scanner pfn's are two mechanisms in
compaction to prevent rescanning pages where isolation has recently failed
or they were scanned during the previous compaction attempt.
Currently, both kinds of information are updated via update_pageblock_skip(),
which is suboptimal for the cached scanner pfn's:
- The condition "isolation has failed in the pageblock" checked by
update_pageblock_skip() may be valid for the pageblock_skip bitmap, but makes
less sense for cached pfn's. There's little point for the next compaction
attempt to scan again a pageblock where all pages that could be isolated were
already processed.
- whole pageblocks can be skipped at the level of isolate_migratepages() or
isolate_freepages() before going into the corresponding _block() function.
Not updating cached scanner positions at the higher level may again result
in extra iterations.
This patch moves updating cached scanner pfn's from update_pageblock_skip()
to dedicated functions, which are called directly from isolate_migratepages()
and isolate_freepages(), resolving both inefficiencies.
During testing, the observed differences in compact_migrate_scanned and
compact_free_scanned were lost in the noise.
Signed-off-by: Vlastimil Babka
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
---
mm/compaction.c | 48 +---
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 4a14084..c326607 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -261,17 +261,31 @@ void reset_isolation_suitable(pg_data_t *pgdat)
}
}
+static inline void
+update_cached_migrate_pfn(struct zone *zone, unsigned long pfn,
+ enum migrate_mode mode)
+{
+ if (pfn > zone->compact_cached_migrate_pfn[0])
+ zone->compact_cached_migrate_pfn[0] = pfn;
+ if (mode != MIGRATE_ASYNC &&
+ pfn > zone->compact_cached_migrate_pfn[1])
+ zone->compact_cached_migrate_pfn[1] = pfn;
+}
+
+static inline void
+update_cached_free_pfn(struct zone *zone, unsigned long pfn)
+{
+ if (pfn < zone->compact_cached_free_pfn)
+ zone->compact_cached_free_pfn = pfn;
+}
+
/*
* If no pages were isolated then mark this pageblock to be skipped in the
* future. The information is later cleared by __reset_isolation_suitable().
*/
static void update_pageblock_skip(struct compact_control *cc,
- struct page *page, unsigned long nr_isolated,
- bool migrate_scanner)
+ struct page *page, unsigned long nr_isolated)
{
- struct zone *zone = cc->zone;
- unsigned long pfn;
-
if (cc->ignore_skip_hint)
return;
@@ -282,20 +296,6 @@ static void update_pageblock_skip(struct compact_control
*cc,
return;
set_pageblock_skip(page);
-
- pfn = page_to_pfn(page);
-
- /* Update where async and sync compaction should restart */
- if (migrate_scanner) {
- if (pfn > zone->compact_cached_migrate_pfn[0])
- zone->compact_cached_migrate_pfn[0] = pfn;
- if (cc->mode != MIGRATE_ASYNC &&
- pfn > zone->compact_cached_migrate_pfn[1])
- zone->compact_cached_migrate_pfn[1] = pfn;
- } else {
- if (pfn < zone->compact_cached_free_pfn)
- zone->compact_cached_free_pfn = pfn;
- }
}
#else
static inline bool isolation_suitable(struct compact_control *cc,
@@ -305,8 +305,7 @@ static inline bool isolation_suitable(struct
compact_control *cc,
}
static void update_pageblock_skip(struct compact_control *cc,
- struct page *page, unsigned long nr_isolated,
- bool migrate_scanner)
+ struct page *page, unsigned long nr_isolated)
{
}
#endif /* CONFIG_COMPACTION */
@@ -540,7 +539,7 @@ isolate_fail:
/* Update the pageblock-skip if the whole pageblock was scanned */
if (blockpfn == end_pfn)
- update_pageblock_skip(cc, valid_page, total_isolated, false);
+ update_pageblock_skip(cc, valid_page, total_isolated);
count_compact_events(COMPACTFREE_SCANNED, nr_scanned);
if (total_isolated)
@@ -843,7 +842,7 @@ isolate_success:
* if the whole pageblock was scanned without isolating any page.
*/
if (low_pfn == end_pfn)
- update_pageblock_skip(cc, valid_page, nr_isolated, true);
+ update_pageblock_skip(cc, valid_page, nr_isolated);
trace_mm_compaction_isolate_migratepages(start_pfn, low_pfn,
nr_scanned, nr_isolated);
@@ -1043,6 +1042,7 @@ static void
[PATCH 5/6] mm, compaction: skip compound pages by order in free scanner
The compaction free scanner is looking for PageBuddy() pages and skipping all
others. For large compound pages such as THP or hugetlbfs, we can save a lot
of iterations if we skip them at once using their compound_order(). This is
generally unsafe and we can read a bogus value of order due to a race, but if
we are careful, the only danger is skipping too much.
When tested with stress-highalloc from mmtests on 4GB system with 1GB hugetlbfs
pages, the vmstat compact_free_scanned count decreased by at least 15%.
Signed-off-by: Vlastimil Babka
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
---
mm/compaction.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/mm/compaction.c b/mm/compaction.c
index e37d361..4a14084 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -437,6 +437,24 @@ static unsigned long isolate_freepages_block(struct
compact_control *cc,
if (!valid_page)
valid_page = page;
+
+ /*
+* For compound pages such as THP and hugetlbfs, we can save
+* potentially a lot of iterations if we skip them at once.
+* The check is racy, but we can consider only valid values
+* and the only danger is skipping too much.
+*/
+ if (PageCompound(page)) {
+ unsigned int comp_order = compound_order(page);
+
+ if (comp_order > 0 && comp_order < MAX_ORDER) {
+ blockpfn += (1UL << comp_order) - 1;
+ cursor += (1UL << comp_order) - 1;
+ }
+
+ goto isolate_fail;
+ }
+
if (!PageBuddy(page))
goto isolate_fail;
@@ -496,6 +514,13 @@ isolate_fail:
}
+ /*
+* There is a tiny chance that we have read bogus compound_order(),
+* so be careful to not go outside of the pageblock.
+*/
+ if (unlikely(blockpfn > end_pfn))
+ blockpfn = end_pfn;
+
trace_mm_compaction_isolate_freepages(*start_pfn, blockpfn,
nr_scanned, total_isolated);
--
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/
[PATCH 4/6] mm, compaction: always skip compound pages by order in migrate scanner
The compaction migrate scanner tries to skip compound pages by their order, to
reduce number of iterations for pages it cannot isolate. The check is only done
if PageLRU() is true, which means it applies to THP pages, but not e.g.
hugetlbfs pages or any other non-LRU compound pages, which we have to iterate
by base pages.
This limitation comes from the assumption that it's only safe to read
compound_order() when we have the zone's lru_lock and THP cannot be split under
us. But the only danger (after filtering out order values that are not below
MAX_ORDER, to prevent overflows) is that we skip too much or too little after
reading a bogus compound_order() due to a rare race. This is the same reasoning
as patch 99c0fd5e51c4 ("mm, compaction: skip buddy pages by their order in the
migrate scanner") introduced for unsafely reading PageBuddy() order.
After this patch, all pages are tested for PageCompound() and we skip them by
compound_order(). The test is done after the test for balloon_page_movable()
as we don't want to assume if balloon pages (or other pages with own isolation
and migration implementation if a generic API gets implemented) are compound
or not.
When tested with stress-highalloc from mmtests on 4GB system with 1GB hugetlbfs
pages, the vmstat compact_migrate_scanned count decreased by 15%.
Signed-off-by: Vlastimil Babka
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
---
mm/compaction.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index d334bb3..e37d361 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -680,6 +680,8 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
/* Time to isolate some pages for migration */
for (; low_pfn < end_pfn; low_pfn++) {
+ bool is_lru;
+
/*
* Periodically drop the lock (if held) regardless of its
* contention, to give chance to IRQs. Abort async compaction
@@ -723,39 +725,35 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
* It's possible to migrate LRU pages and balloon pages
* Skip any other type of page
*/
- if (!PageLRU(page)) {
+ is_lru = PageLRU(page);
+ if (!is_lru) {
if (unlikely(balloon_page_movable(page))) {
if (balloon_page_isolate(page)) {
/* Successfully isolated */
goto isolate_success;
}
}
- continue;
}
/*
-* PageLRU is set. lru_lock normally excludes isolation
-* splitting and collapsing (collapsing has already happened
-* if PageLRU is set) but the lock is not necessarily taken
-* here and it is wasteful to take it just to check transhuge.
-* Check PageCompound without lock and skip the whole pageblock
-* if it's a transhuge page, as calling compound_order()
-* without preventing THP from splitting the page underneath us
-* may return surprising results.
-* If we happen to check a THP tail page, compound_order()
-* returns 0. It should be rare enough to not bother with
-* using compound_head() in that case.
+* Regardless of being on LRU, compound pages such as THP and
+* hugetlbfs are not to be compacted. We can potentially save
+* a lot of iterations if we skip them at once. The check is
+* racy, but we can consider only valid values and the only
+* danger is skipping too much.
*/
if (PageCompound(page)) {
- int nr;
- if (locked)
- nr = 1 << compound_order(page);
- else
- nr = pageblock_nr_pages;
- low_pfn += nr - 1;
+ unsigned int comp_order = compound_order(page);
+
+ if (comp_order > 0 && comp_order < MAX_ORDER)
+ low_pfn += (1UL << comp_order) - 1;
+
continue;
}
+ if (!is_lru)
+ continue;
+
/*
* Migration will fail if an anonymous page is pinned in memory,
* so avoid taking lru_lock and isolating it unnecessarily in an
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On 06/10/2015 05:21 PM, Joerg Roedel wrote: On Tue, Jun 09, 2015 at 01:55:50PM +0100, David Woodhouse wrote: On Mon, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote: So I think we need to read out that bit when we find translation enabled and if it is different from what we would set it to, we bail out of any copying, disable translation and proceed as in a normal boot. Given that this is only for kdump and not the general case of kexec, that's probably tolerable. Of course we do still need to make it *not* broken for the case where DMA_RTADDR_RTT is set, as it is at the moment. Yes, I just sent a patch for this and will include it into my x86/vt-d branch if not objections come in. And I suspect if we're doing that, it might be simple enough to make it convert to/from the extended page tables. I don't think we want to preserve PASID tables; only the "second level" (i.e. traditional) translation. So we could happily pull the page table pointer out of either kind of context entry, and install it into either kind. I think there's a simple mapping of translation types too. I need to sort out the translation types when adding the real PASID support (imminently!) anyway. What happens when we take away the PASID tables from a device? Can it also go into some failure state? When doing this, we need at least setup the page request queue before we copy over anything and change the root-entry. Then we can handle any faults that are caused by this and tell the device to not try further. Joerg Is PASID part of new specs? Is there any plan to upgrade the driver to support the latest vt-d specs? Zhenhua -- 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] GPIO / ACPI: export acpi_gpiochip_request(free)_interrupts for module use
On Wed, Jun 10, 2015 at 05:12:07PM +0800, Hanjun Guo wrote: > acpi_gpiochip_request(free)_interrupts can be used for modules, > so export them. This also fixs a compile error when xgene-sb > configured as kernel module. Reviwed-by: Mark Brown signature.asc Description: Digital signature
[PATCH 1/6] mm, compaction: more robust check for scanners meeting
Compaction should finish when the migration and free scanner meet, i.e. they
reach the same pageblock. Currently however, the test in compact_finished()
simply just compares the exact pfns, which may yield a false negative when the
free scanner position is in the middle of a pageblock and the migration scanner
reaches the beginning of the same pageblock.
This hasn't been a problem until commit e14c720efdd7 ("mm, compaction: remember
position within pageblock in free pages scanner") allowed the free scanner
position to be in the middle of a pageblock between invocations. The hot-fix
1d5bfe1ffb5b ("mm, compaction: prevent infinite loop in compact_zone")
prevented the issue by adding a special check in the migration scanner to
satisfy the current detection of scanners meeting.
However, the proper fix is to make the detection more robust. This patch
introduces the compact_scanners_met() function that returns true when the free
scanner position is in the same or lower pageblock than the migration scanner.
The special case in isolate_migratepages() introduced by 1d5bfe1ffb5b is
removed.
Suggested-by: Joonsoo Kim
Signed-off-by: Vlastimil Babka
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
---
mm/compaction.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 16e1b57..d46aaeb 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -902,6 +902,16 @@ static bool suitable_migration_target(struct page *page)
}
/*
+ * Test whether the free scanner has reached the same or lower pageblock than
+ * the migration scanner, and compaction should thus terminate.
+ */
+static inline bool compact_scanners_met(struct compact_control *cc)
+{
+ return (cc->free_pfn >> pageblock_order)
+ <= (cc->migrate_pfn >> pageblock_order);
+}
+
+/*
* Based on information in the current compact_control, find blocks
* suitable for isolating free pages from and then isolate them.
*/
@@ -1131,12 +1141,8 @@ static isolate_migrate_t isolate_migratepages(struct
zone *zone,
}
acct_isolated(zone, cc);
- /*
-* Record where migration scanner will be restarted. If we end up in
-* the same pageblock as the free scanner, make the scanners fully
-* meet so that compact_finished() terminates compaction.
-*/
- cc->migrate_pfn = (end_pfn <= cc->free_pfn) ? low_pfn : cc->free_pfn;
+ /* Record where migration scanner will be restarted. */
+ cc->migrate_pfn = low_pfn;
return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
}
@@ -1151,7 +1157,7 @@ static int __compact_finished(struct zone *zone, struct
compact_control *cc,
return COMPACT_PARTIAL;
/* Compaction run completes if the migrate and free scanner meet */
- if (cc->free_pfn <= cc->migrate_pfn) {
+ if (compact_scanners_met(cc)) {
/* Let the next compaction start anew. */
zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
@@ -1380,7 +1386,7 @@ static int compact_zone(struct zone *zone, struct
compact_control *cc)
* migrate_pages() may return -ENOMEM when scanners meet
* and we want compact_finished() to detect it
*/
- if (err == -ENOMEM && cc->free_pfn > cc->migrate_pfn) {
+ if (err == -ENOMEM && !compact_scanners_met(cc)) {
ret = COMPACT_PARTIAL;
goto out;
}
--
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/
[PATCH 0/6] Assorted compaction cleanups and optimizations
This series is partly the cleanups that were posted as part of the RFC for changing initial scanning positions [1] and partly new relatively simple scanner optimizations (yes, they are still possible). I've resumed working on the bigger scanner changes, but that will take a while, so no point in delaying these smaller patches. The interesting patches are 4 and 5, and somewhat patch 6. In 4, skipping of compound pages in single iteration is improved for migration scanner, so it works also for !PageLRU compound pages such as hugetlbfs, slab etc. Patch 5 introduces this kind of skipping in the free scanner. The trick is that we can read compound_order() without any protection, if we are careful to filter out values larger than MAX_ORDER. The only danger is that we skip too much. The same trick was already used for reading the freepage order in the migrate scanner. Patch 6 avoids some rescanning when compaction restarts from cached scanner positions, but the benefits are small enough to be lost in the noise. To demonstrate improvements of Patches 4 and 5 I've run stress-highalloc from mmtests, set to simulate THP allocations (including __GFP_COMP) on a 4GB system where 1GB was occupied by hugetlbfs pages. I'll include just the relevant stats: Patch 3 Patch 4 Patch 5 Patch 6 Compaction stalls 7523752975157495 Compaction success 323 304 322 289 Compaction failures 7200722471927206 Page migrate success247778 264395 240737 248956 Page migrate failure 15358 33184 21621 23657 Compaction pages isolated 906928 980192 909983 958044 Compaction migrate scanned 2005277 1692805 1498800 1750952 Compaction free scanned 1325528411539986 9011276 9703018 Compaction cost288 305 277 289 With 5 iterations per patch, the results are still noisy, but we can see that Patch 4 does reduce migrate_scanned by 15% thanks to skipping the hugetlbfs pages at once. Interestingly, free_scanned is also reduced and I have no idea why. Patch 5 further reduces free_scanned as expected, by 15%. Other stats are unaffected modulo noise. Patch 6 looks like a regression but I believe it's just the noise. I've verified that compaction now restarts from the exact pfns it left off, using tracepoints. [1] https://lkml.org/lkml/2015/1/19/158 Vlastimil Babka (6): mm, compaction: more robust check for scanners meeting mm, compaction: simplify handling restart position in free pages scanner mm, compaction: encapsulate resetting cached scanner positions mm, compaction: always skip compound pages by order in migrate scanner mm, compaction: skip compound pages by order in free scanner mm, compaction: decouple updating pageblock_skip and cached pfn mm/compaction.c | 188 ++-- 1 file changed, 115 insertions(+), 73 deletions(-) -- 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/
[PATCH 2/6] mm, compaction: simplify handling restart position in free pages scanner
Handling the position where compaction free scanner should restart (stored in
cc->free_pfn) got more complex with commit e14c720efdd7 ("mm, compaction:
remember position within pageblock in free pages scanner"). Currently the
position is updated in each loop iteration of isolate_freepages(), although it
should be enough to update it only when breaking from the loop. There's also
an extra check outside the loop updates the position in case we have met the
migration scanner.
This can be simplified if we move the test for having isolated enough from the
for loop header next to the test for contention, and determining the restart
position only in these cases. We can reuse the isolate_start_pfn variable for
this instead of setting cc->free_pfn directly. Outside the loop, we can simply
set cc->free_pfn to current value of isolate_start_pfn without any extra check.
Also add a VM_BUG_ON to catch possible mistake in the future, in case we later
add a new condition that terminates isolate_freepages_block() prematurely
without also considering the condition in isolate_freepages().
Signed-off-by: Vlastimil Babka
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
---
mm/compaction.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index d46aaeb..7e0a814 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -947,8 +947,7 @@ static void isolate_freepages(struct compact_control *cc)
* pages on cc->migratepages. We stop searching if the migrate
* and free page scanners meet or enough free pages are isolated.
*/
- for (; block_start_pfn >= low_pfn &&
- cc->nr_migratepages > cc->nr_freepages;
+ for (; block_start_pfn >= low_pfn;
block_end_pfn = block_start_pfn,
block_start_pfn -= pageblock_nr_pages,
isolate_start_pfn = block_start_pfn) {
@@ -980,6 +979,8 @@ static void isolate_freepages(struct compact_control *cc)
block_end_pfn, freelist, false);
/*
+* If we isolated enough freepages, or aborted due to async
+* compaction being contended, terminate the loop.
* Remember where the free scanner should restart next time,
* which is where isolate_freepages_block() left off.
* But if it scanned the whole pageblock, isolate_start_pfn
@@ -988,27 +989,31 @@ static void isolate_freepages(struct compact_control *cc)
* In that case we will however want to restart at the start
* of the previous pageblock.
*/
- cc->free_pfn = (isolate_start_pfn < block_end_pfn) ?
- isolate_start_pfn :
- block_start_pfn - pageblock_nr_pages;
-
- /*
-* isolate_freepages_block() might have aborted due to async
-* compaction being contended
-*/
- if (cc->contended)
+ if ((cc->nr_freepages >= cc->nr_migratepages)
+ || cc->contended) {
+ if (isolate_start_pfn >= block_end_pfn)
+ isolate_start_pfn =
+ block_start_pfn - pageblock_nr_pages;
break;
+ } else {
+ /*
+* isolate_freepages_block() should not terminate
+* prematurely unless contended, or isolated enough
+*/
+ VM_BUG_ON(isolate_start_pfn < block_end_pfn);
+ }
}
/* split_free_page does not map the pages */
map_pages(freelist);
/*
-* If we crossed the migrate scanner, we want to keep it that way
-* so that compact_finished() may detect this
+* Record where the free scanner will restart next time. Either we
+* broke from the loop and set isolate_start_pfn based on the last
+* call to isolate_freepages_block(), or we met the migration scanner
+* and the loop terminated due to isolate_start_pfn < low_pfn
*/
- if (block_start_pfn < low_pfn)
- cc->free_pfn = cc->migrate_pfn;
+ cc->free_pfn = isolate_start_pfn;
}
/*
--
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/
[PATCH 3/6] mm, compaction: encapsulate resetting cached scanner positions
Resetting the cached compaction scanner positions is now done implicitly in
__reset_isolation_suitable() and compact_finished(). Encapsulate the
functionality in a new function reset_cached_positions() and call it explicitly
where needed.
Signed-off-by: Vlastimil Babka
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
---
mm/compaction.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 7e0a814..d334bb3 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -207,6 +207,13 @@ static inline bool isolation_suitable(struct
compact_control *cc,
return !get_pageblock_skip(page);
}
+static void reset_cached_positions(struct zone *zone)
+{
+ zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
+ zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
+ zone->compact_cached_free_pfn = zone_end_pfn(zone);
+}
+
/*
* This function is called to clear all cached information on pageblocks that
* should be skipped for page isolation when the migrate and free page scanner
@@ -218,9 +225,6 @@ static void __reset_isolation_suitable(struct zone *zone)
unsigned long end_pfn = zone_end_pfn(zone);
unsigned long pfn;
- zone->compact_cached_migrate_pfn[0] = start_pfn;
- zone->compact_cached_migrate_pfn[1] = start_pfn;
- zone->compact_cached_free_pfn = end_pfn;
zone->compact_blockskip_flush = false;
/* Walk the zone and mark every pageblock as suitable for isolation */
@@ -250,8 +254,10 @@ void reset_isolation_suitable(pg_data_t *pgdat)
continue;
/* Only flush if a full compaction finished recently */
- if (zone->compact_blockskip_flush)
+ if (zone->compact_blockskip_flush) {
__reset_isolation_suitable(zone);
+ reset_cached_positions(zone);
+ }
}
}
@@ -1164,9 +1170,7 @@ static int __compact_finished(struct zone *zone, struct
compact_control *cc,
/* Compaction run completes if the migrate and free scanner meet */
if (compact_scanners_met(cc)) {
/* Let the next compaction start anew. */
- zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
- zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
- zone->compact_cached_free_pfn = zone_end_pfn(zone);
+ reset_cached_positions(zone);
/*
* Mark that the PG_migrate_skip information should be cleared
@@ -1329,8 +1333,10 @@ static int compact_zone(struct zone *zone, struct
compact_control *cc)
* is about to be retried after being deferred. kswapd does not do
* this reset as it'll reset the cached information when going to sleep.
*/
- if (compaction_restarting(zone, cc->order) && !current_is_kswapd())
+ if (compaction_restarting(zone, cc->order) && !current_is_kswapd()) {
__reset_isolation_suitable(zone);
+ reset_cached_positions(zone);
+ }
/*
* Setup to move all movable pages to the end of the zone. Used cached
--
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 1/2] scatterlist: use sg_phys()
On Tue, Jun 09, 2015 at 12:27:10PM -0400, Dan Williams wrote:
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 7e7583ddd607..9f6ff6671f01 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1502,7 +1502,7 @@ static int __map_sg_chunk(struct device *dev, struct
> scatterlist *sg,
> return -ENOMEM;
>
> for (count = 0, s = sg; count < (size >> PAGE_SHIFT); s = sg_next(s)) {
> - phys_addr_t phys = page_to_phys(sg_page(s));
> + phys_addr_t phys = sg_phys(s) - s->offset;
So sg_phys() turns out to be 'page_to_phys(sg_page(s)) + s->offset',
which makes the above statement to:
page_to_phys(sg_page(s)) + s->offset - s->offset;
The compiler will probably optimize that away, but it still doesn't look
like an improvement.
> unsigned int len = PAGE_ALIGN(s->offset + s->length);
>
> if (!is_coherent &&
> diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
> index ed7ba8a11822..dcb3c594d626 100644
> --- a/arch/microblaze/kernel/dma.c
> +++ b/arch/microblaze/kernel/dma.c
> @@ -61,7 +61,7 @@ static int dma_direct_map_sg(struct device *dev, struct
> scatterlist *sgl,
> /* FIXME this part of code is untested */
> for_each_sg(sgl, sg, nents, i) {
> sg->dma_address = sg_phys(sg);
> - __dma_sync(page_to_phys(sg_page(sg)) + sg->offset,
> + __dma_sync(sg_phys(sg),
> sg->length, direction);
Here the replacement makes sense, but weird indendation. Could all be
moved to one line, I guess.
> }
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 68d43beccb7e..9b9ada71e0d3 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1998,7 +1998,7 @@ static int __domain_mapping(struct dmar_domain *domain,
> unsigned long iov_pfn,
> sg_res = aligned_nrpages(sg->offset, sg->length);
> sg->dma_address = ((dma_addr_t)iov_pfn <<
> VTD_PAGE_SHIFT) + sg->offset;
> sg->dma_length = sg->length;
> - pteval = page_to_phys(sg_page(sg)) | prot;
> + pteval = (sg_phys(sg) - sg->offset) | prot;
Here it doesn't make sense too. In general, please remove the cases
where you have to subtract sg->offset after the conversion.
Joerg
--
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: Discussion: quick_pit_calibrate is slow
* George Spelvin wrote: > > Could you please structure it the following way: > > > > - first a patch that fixes bogus comments about the current code. It has > > bitrotten and if we change it significantly we better have a well > > documented starting point that is easier to compare against. Btw., we should make the patch fixing Adrian's system patch 0, as it looks simple and obvious enough, agreed? > > - then a patch that introduces your more accurate calibration method and > > uses it as the first method to calibrate. If it fails (and it should have > > a > > notion of failing) then it should fall back to the other two methods. > > > > - possibly add a boot option to skip your new calibration method - > > i.e. to make the kernel behave in the old way. This would be useful > > for tracking down any regressions in this. > > > > - then maybe add a patch for the RTC method, but as a .config driven > > opt-in > >initially. > > Sonds good, but when do we get to the decruftification? I'd prefer to > prepare > the final patch (if nothing else, so Linus will be reassured by the > diffstat), > although I can see holding it back for a few releases. what do you call 'decruftification'? So I'd suggest besides obvious bug (and comment) fixes we should not change the current calibration code but add your new logic as the first step, and preserve those other methods, because we know that it works reasonably well on a wide range of hardware. Because it all has to be kept in perspective: the benefits of any changes here are a small boot speedup plus more stable calibration at best (and a warm fuzzy feeling from having nicely structured, well working code), while the drawbacks are the potential for totally miscalibrated systems that were working fine before. Once your bits work fine will there be any need for any of the two other PIT based calibration methods? We can simply remove them at a suitable point in time and have a single (and by definition non-crufty) piece of PIT calibration code. (and RTC if that can be managed.) > > Please also add calibration tracing code (.config driven and default-off), > > so > > that the statistical properties of calibration can be debugged and > > validated > > without patching the kernel. > > Definitely desired, but I have to be careful here. Obviously I can't print > during the timing loop, so it will take either a lot of memory, or add > significant computation to the loop. So in theory you can use a tracepoint and enable boot tracing. Not sure it's initialized that early in the bootup, has to be explored ... > I also don't want to flood the kernel log before syslog is started. By default it should not print any trace. So I don't think the details really matter: this is a boot and .config option for debugging, not for production kernels. You can do a big memory array and printk the result or use the generic tracing facilities if they are available. People can increase the kmsg buffer if it does not fit. > >> Any suggestions for a reasonable time/quality tradeoff? 500 ppm ASAP? > >> Best I can do in 10 ms? Wait until the PIT is 500 ppm and then use > >> the better result from a higher-resolution timer if available? > > > So I'd suggest a minimum polling interval (at least 1 msecs?) plus a > > ppm target. Would 100ppm be too aggressive? > > How about 122 ppm (1/8192) because I'm lazy? :-) ;-) > What I imagine is this: > > - The code will loop until it reaches 122 ppm or 55 ms, whichever comes > first. (There's also a minimum, before which 122 ppm isn't checked.) > - Initially, failure to reach 122 ppm will print a message and fall back. > - In the final cleanup patch, I'll accept anything up to 500 ppm > and only fail (and disable TSC) if I can't reach that. Sounds good to me in principle. Thanks, Ingo -- 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 v11 3/5] x86/earlyprintk: Allocate early log_buf as early as possible
2015-06-10 15:04 GMT+06:00 Borislav Petkov : > Yes, so this whole approach and what you're trying to achieve > seems kinda confusing and wrong. First of all, the early_printk() > machinery prints to a special console driver, i.e., I'm looking at the > registration fun in setup_early_printk(). > > So using early_printk() to print to dmesg is the wrong tool for the > job. Actually, if you want to do that, you can just as well use plain > printk() and try to make it work much earlier. Which is basically what > you did by using the printk_func per_cpu ptr, but that was hacky and > ugly. > > In order to do that right, you need to slow down first, think hard > and look hard and long at printk(), log_buf, the statically allocated > smaller __log_buf and the whole machinery behind it. Whether it can be > used that early or not. And to explain why it can or why it cannot in > your commit messages. Then test your stuff a *lot* on the hw you have > access to because printk() is not a joke. It needs to be very reliable > and to work. > That's right, I thought this too. But when you answered on 10th (https://lkml.org/lkml/2015/6/8/157) revision that you do not see earlyprintk messages in the dmesg output and I thought that he should be there, but didint research printk/log_buf and related stuff properly. I will try to learn all earlyprintk related things in more clear way and resend the patch. Thank you. -- 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 5/5] usb: dwc3: ep0: handle non maxpacket aligned transfers > 512
Use chained TRB mechanism to handle non maxpacket aligned transfers
greater than bounce buffer size. With this the first TRB will be programmed
to receive 'ALIGN(ur->length - maxp, maxp)' data and the second TRB
will be programmed to receive the remaining data using bounce buffer.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c | 42 --
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6847afe..4c777fe 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -830,13 +830,26 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
maxp = ep0->endpoint.maxpacket;
if (dwc->ep0_bounced) {
+ /*
+* Handle the first TRB before handling the bounce buffer if
+* the request length is greater than the bounce buffer size
+*/
+ if (ur->length > DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = ALIGN(ur->length - maxp, maxp);
+ transferred = transfer_size - length;
+ buf = (u8 *)buf + transferred;
+ ur->actual += transferred;
+ remaining_ur_length -= transferred;
+
+ trb++;
+ length = trb->size & DWC3_TRB_SIZE_MASK;
+
+ ep0->free_slot = 0;
+ }
+
transfer_size = roundup((ur->length - transfer_size),
maxp);
- /* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received */
- if (transfer_size > DWC3_EP0_BOUNCE_SIZE)
- transfer_size = DWC3_EP0_BOUNCE_SIZE;
-
transferred = min_t(u32, remaining_ur_length,
transfer_size - length);
memcpy(buf, dwc->ep0_bounce, transferred);
@@ -959,21 +972,22 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}
maxpacket = dep->endpoint.maxpacket;
- transfer_size = roundup((req->request.length - transfer_size),
- maxpacket);
- if (transfer_size > DWC3_EP0_BOUNCE_SIZE) {
- dev_WARN(dwc->dev, "bounce buf can't handle req len\n");
- transfer_size = DWC3_EP0_BOUNCE_SIZE;
+ if (req->request.length > DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = ALIGN(req->request.length - maxpacket,
+ maxpacket);
+ ret = dwc3_ep0_start_trans(dwc, dep->number,
+ req->request.dma,
+ transfer_size,
+ DWC3_TRBCTL_CONTROL_DATA,
+ true);
}
+ transfer_size = roundup((req->request.length - transfer_size),
+ maxpacket);
+
dwc->ep0_bounced = true;
- /*
-* REVISIT in case request length is bigger than
-* DWC3_EP0_BOUNCE_SIZE we will need two chained
-* TRBs to handle the transfer.
-*/
ret = dwc3_ep0_start_trans(dwc, dep->number,
dwc->ep0_bounce_addr, transfer_size,
DWC3_TRBCTL_CONTROL_DATA, false);
--
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 0/3] TLB flush multiple pages per IPI v5
On Wed, Jun 10, 2015 at 10:51:41AM +0200, Ingo Molnar wrote: > > * Mel Gorman wrote: > > > > I think since it is you who wants to introduce additional complexity into > > > the > > > x86 MM code the burden is on you to provide proof that the complexity of > > > pfn > > > (or struct page) tracking is worth it. > > > > I'm taking a situation whereby IPIs are sent like crazy with interrupt > > storms > > and replacing it with something that is a lot more efficient that minimises > > the > > number of potential surprises. I'm stating that the benefit of PFN tracking > > is > > unknowable in the general case because it depends on the workload, timing > > and > > the exact CPU used so any example provided can be naked with a > > counter-example > > such as a trivial sequential reader that shows no benefit. The series as > > posted > > is approximately in line with current behaviour minimising the chances of > > surprise regressions from excessive TLB flush. > > > > You are actively blocking a measurable improvement and forcing it to be > > replaced > > with something whose full impact is unquantifiable. Any regressions in this > > area > > due to increased TLB misses could take several kernel releases as the issue > > will > > be so difficult to detect. > > > > I'm going to implement the approach you are forcing because there is an x86 > > part > > of the patch and you are the maintainer that could indefinitely NAK it. > > However, > > I'm extremely pissed about being forced to introduce these indirect > > unpredictable costs because I know the alternative is you dragging this out > > for > > weeks with no satisfactory conclusion in an argument that I cannot prove in > > the > > general case. > > Stop this crap. > > I made a really clear and unambiguous chain of arguments: > > - I'm unconvinced about the benefits of INVLPG in general, and your patches > adds >a whole new bunch of them. I cited measurements and went out on a limb to >explain my position, backed with numbers and logic. It's admittedly still > a >speculative position and I might be wrong, but I think it's well grounded >position that you cannot just brush aside. > And I explained my concerns with the use of a full flush and the difficulty of measuring its impact in the general case. I also explained why I thought starting with PFN tracking was an incremental approach. The argument looped so I bailed. > - I suggested that you split this approach into steps that first does the > simpler >approach that will give us at least 95% of the benefits, then the more > complex >one on top of it. Your false claim that I'm blocking a clear improvement is >pure demagogy! > The splitting was already done, released and I followed up saying that I'll be dropping patch 4 in the final merge request. In the event we find in a few kernel releases time that it was required then there will be a realistic bug report to use as a reference. > - I very clearly claimed that I am more than willing to be convinced by > numbers. >It's not _that_ hard to construct a memory trashing workload with a >TLB-efficient iteration that uses say 80% of the TLB cache, to measure the >worst-case overhead of full flushes. > And what I had said was that in the general case that it will not show us any proof. Any other workload will always behave differently and two critical components are the exact timing versus kswapd running and the CPU used. Even if it's demonstrated for a single workload on one CPU then we would still be faced with the same problem and dropping patch 4. -- Mel Gorman SUSE Labs -- 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 v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On Tue, Jun 09, 2015 at 01:55:50PM +0100, David Woodhouse wrote: > On Mon, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote: > > So I think we need to read out that bit when we find translation enabled > > and if it is different from what we would set it to, we bail out of any > > copying, disable translation and proceed as in a normal boot. > > Given that this is only for kdump and not the general case of kexec, > that's probably tolerable. Of course we do still need to make it *not* > broken for the case where DMA_RTADDR_RTT is set, as it is at the > moment. Yes, I just sent a patch for this and will include it into my x86/vt-d branch if not objections come in. > And I suspect if we're doing that, it might be simple enough to make it > convert to/from the extended page tables. I don't think we want to > preserve PASID tables; only the "second level" (i.e. traditional) > translation. So we could happily pull the page table pointer out of > either kind of context entry, and install it into either kind. I think > there's a simple mapping of translation types too. I need to sort out > the translation types when adding the real PASID support (imminently!) > anyway. What happens when we take away the PASID tables from a device? Can it also go into some failure state? When doing this, we need at least setup the page request queue before we copy over anything and change the root-entry. Then we can handle any faults that are caused by this and tell the device to not try further. Joerg -- 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/5] usb: dwc3: ep0: preparation for handling non maxpacket aligned transfers > 512
No functional change. This is in preparation for handling non maxpacket
aligned transfers greater than bounce buffer size. This is basically to
avoid code duplication when using chained TRB transfers to handle
non maxpacket aligned transfers greater than bounce buffer size.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 713e46a..4998074 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -779,7 +779,11 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
struct usb_request *ur;
struct dwc3_trb *trb;
struct dwc3_ep *ep0;
- u32 transferred;
+ unsignedtransfer_size = 0;
+ unsignedmaxp;
+ unsignedremaining_ur_length;
+ void*buf;
+ u32 transferred = 0;
u32 status;
u32 length;
u8 epnum;
@@ -808,20 +812,24 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
}
ur = >request;
+ buf = ur->buf;
+ remaining_ur_length = ur->length;
length = trb->size & DWC3_TRB_SIZE_MASK;
+ maxp = ep0->endpoint.maxpacket;
+
if (dwc->ep0_bounced) {
- unsigned maxp = ep0->endpoint.maxpacket;
- unsigned transfer_size = roundup(ur->length, maxp);
+ transfer_size = roundup((ur->length - transfer_size),
+ maxp);
/* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received */
if (transfer_size > DWC3_EP0_BOUNCE_SIZE)
transfer_size = DWC3_EP0_BOUNCE_SIZE;
- transferred = min_t(u32, ur->length,
- transfer_size - length);
- memcpy(ur->buf, dwc->ep0_bounce, transferred);
+ transferred = min_t(u32, remaining_ur_length,
+ transfer_size - length);
+ memcpy(buf, dwc->ep0_bounce, transferred);
} else {
transferred = ur->length - length;
}
@@ -930,7 +938,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
DWC3_TRBCTL_CONTROL_DATA);
} else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
&& (dep->number == 0)) {
- u32 transfer_size;
+ u32 transfer_size = 0;
u32 maxpacket;
ret = usb_gadget_map_request(>gadget, >request,
@@ -941,7 +949,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}
maxpacket = dep->endpoint.maxpacket;
- transfer_size = roundup(req->request.length, maxpacket);
+ transfer_size = roundup((req->request.length - transfer_size),
+ maxpacket);
if (transfer_size > DWC3_EP0_BOUNCE_SIZE) {
dev_WARN(dwc->dev, "bounce buf can't handle req len\n");
--
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 3/5] usb: dwc3; ep0: Modify _dwc3_ep0_start_trans_ API to take 'chain' parameter
No functional change. Added a new parameter in _dwc3_ep0_start_trans_ to
indicate whether the TRB is a chained TRB or last TRB. This is in
preparation for adding chained TRB support for ep0.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 4998074..d1a2be1 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum dwc3_ep0_state
state)
}
static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t buf_dma,
- u32 len, u32 type)
+ u32 len, u32 type, unsigned chain)
{
struct dwc3_gadget_ep_cmd_params params;
struct dwc3_trb *trb;
@@ -302,7 +302,7 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
int ret;
ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
- DWC3_TRBCTL_CONTROL_SETUP);
+ DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret < 0);
}
@@ -851,7 +851,7 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
ret = dwc3_ep0_start_trans(dwc, epnum,
dwc->ctrl_req_addr, 0,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
WARN_ON(ret < 0);
}
}
@@ -935,7 +935,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
if (req->request.length == 0) {
ret = dwc3_ep0_start_trans(dwc, dep->number,
dwc->ctrl_req_addr, 0,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
} else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
&& (dep->number == 0)) {
u32 transfer_size = 0;
@@ -966,7 +966,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
*/
ret = dwc3_ep0_start_trans(dwc, dep->number,
dwc->ep0_bounce_addr, transfer_size,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
} else {
ret = usb_gadget_map_request(>gadget, >request,
dep->number);
@@ -976,7 +976,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}
ret = dwc3_ep0_start_trans(dwc, dep->number, req->request.dma,
- req->request.length, DWC3_TRBCTL_CONTROL_DATA);
+ req->request.length, DWC3_TRBCTL_CONTROL_DATA,
+ false);
}
WARN_ON(ret < 0);
@@ -991,7 +992,7 @@ static int dwc3_ep0_start_control_status(struct dwc3_ep
*dep)
: DWC3_TRBCTL_CONTROL_STATUS2;
return dwc3_ep0_start_trans(dwc, dep->number,
- dwc->ctrl_req_addr, 0, type);
+ dwc->ctrl_req_addr, 0, type, false);
}
static void __dwc3_ep0_do_control_status(struct dwc3 *dwc, struct dwc3_ep *dep)
--
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 0/5] usb: dwc3: handle non maxpacket aligned transfers > 512
Patch series adds support to handle non maxpacket aligned transfers greater than bounce buffer size (512). It first adds chained TRB support and then uses it to handle non maxpacket aligned transfers greater than bounce buffer size. Also included a cleanup patch to use 'roundup' macro. This series is created after applying [1] Non maxpacket aligned transfers can be initiated by "./testusb -t 14 -c 1 -s 520 -v 1" Before this series: unknown speed /dev/bus/usb/001/0180 /dev/bus/usb/001/018 test 14 --> 110 (Connection timed out) After this series: unknown speed /dev/bus/usb/001/0230 /dev/bus/usb/001/023 test 14,0.000486 secs Tested this patch using USB3 Gen X CV (ch9 tests: usb2 and usb3, link layer testing and MSC tests) and using USB2 X CV (ch9 tests, MSC tests) and verified this doesn't cause additional failures. Lecroy compliance tests fail even without this patch series so deferred testing it. [1] -> http://permalink.gmane.org/gmane.linux.kernel/1972684 Kishon Vijay Abraham I (5): usb: dwc3: ep0: use _roundup_ to calculate the transfer size usb: dwc3: ep0: preparation for handling non maxpacket aligned transfers > 512 usb: dwc3; ep0: Modify _dwc3_ep0_start_trans_ API to take 'chain' parameter usb: dwc3: ep0: Add chained TRB support usb: dwc3: ep0: handle non maxpacket aligned transfers > 512 drivers/usb/dwc3/ep0.c| 94 ++--- drivers/usb/dwc3/gadget.c |2 +- 2 files changed, 64 insertions(+), 32 deletions(-) -- 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 4/5] usb: dwc3: ep0: Add chained TRB support
Add chained TRB support to ep0. Now TRB's can be chained just by
invoking _dwc3_ep0_start_trans_ with 'chain' parameter set to true.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c| 16 +---
drivers/usb/dwc3/gadget.c |2 +-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index d1a2be1..6847afe 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -70,7 +70,10 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
return 0;
}
- trb = dwc->ep0_trb;
+ trb = >ep0_trb[dep->free_slot];
+
+ if (chain)
+ dep->free_slot++;
trb->bpl = lower_32_bits(buf_dma);
trb->bph = upper_32_bits(buf_dma);
@@ -78,10 +81,17 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
trb->ctrl = type;
trb->ctrl |= (DWC3_TRB_CTRL_HWO
- | DWC3_TRB_CTRL_LST
- | DWC3_TRB_CTRL_IOC
| DWC3_TRB_CTRL_ISP_IMI);
+ if (chain)
+ trb->ctrl |= DWC3_TRB_CTRL_CHN;
+ else
+ trb->ctrl |= (DWC3_TRB_CTRL_IOC
+ | DWC3_TRB_CTRL_LST);
+
+ if (chain)
+ return 0;
+
memset(, 0, sizeof(params));
params.param0 = upper_32_bits(dwc->ep0_trb_addr);
params.param1 = lower_32_bits(dwc->ep0_trb_addr);
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8946c32..b8d0a84 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2677,7 +2677,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err0;
}
- dwc->ep0_trb = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dwc->ep0_trb = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
>ep0_trb_addr, GFP_KERNEL);
if (!dwc->ep0_trb) {
dev_err(dwc->dev, "failed to allocate ep0 trb\n");
--
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/5] usb: dwc3: ep0: use _roundup_ to calculate the transfer size
No functional change. Used _roundup_ macro to calculate the transfer
size aligned to maxpacket in dwc3_ep0_complete_data. It also makes it
similar to how transfer size is calculated in __dwc3_ep0_do_control_data.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 8858c60..713e46a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -812,10 +812,8 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
length = trb->size & DWC3_TRB_SIZE_MASK;
if (dwc->ep0_bounced) {
- unsigned transfer_size = ur->length;
unsigned maxp = ep0->endpoint.maxpacket;
-
- transfer_size += (maxp - (transfer_size % maxp));
+ unsigned transfer_size = roundup(ur->length, maxp);
/* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received */
if (transfer_size > DWC3_EP0_BOUNCE_SIZE)
--
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: [REBASED 2/5] regulator: pwm-regulator: Separate voltage-table initialisation
Hi,
> Take this out of the main .probe() routine in order to facilitate the
> introduction of different ways to obtain 'duty cycle' information.
>
> Signed-off-by: Lee Jones
> ---
> drivers/mfd/mfd-child.c | 47
> drivers/regulator/pwm-regulator.c | 77
> +++
> 2 files changed, 92 insertions(+), 32 deletions(-)
> create mode 100644 drivers/mfd/mfd-child.c
>
> diff --git a/drivers/mfd/mfd-child.c b/drivers/mfd/mfd-child.c
> new file mode 100644
> index 000..f233add
> --- /dev/null
> +++ b/drivers/mfd/mfd-child.c
> @@ -0,0 +1,47 @@
> +#include
> +#include
> +#include
> +#include
> +
> +static int simple_mfd_child_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + void __iomem *base;
> + int irq;
> +
> + printk("LEE: %s %s()[%d]: Enter\n", __FILE__, __func__, __LINE__);
> +
Debugging remnant?
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + dev_err(>dev, "Phys: %x: %x\n", res->start, resource_size(res));
> +
That's not an error message and thus shouldn't be printed with
dev_err(). dev_dbg() would be more appropriate here.
> + base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + dev_err(>dev, "Virt: %p\n", base);
dto.
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(>dev, "failed to get IRQ: %d\n", irq);
> + return irq;
> + }
> +
> + dev_err(>dev, "IRQ: %d\n", irq);
> +
dto.
> + return 0;
> +}
> +
> +static const struct of_device_id simple_mfd_child_of_match[] = {
> + { .compatible = "simple-mfd-child" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, simple_mfd_child_of_match);
> +
> +static struct platform_driver simple_mfd_child_driver = {
> + .probe = simple_mfd_child_probe,
> + .driver = {
> + .name = "simple-mfd-child",
> + .of_match_table = of_match_ptr(simple_mfd_child_of_match),
> + },
> +};
> +module_platform_driver(simple_mfd_child_driver);
> diff --git a/drivers/regulator/pwm-regulator.c
> b/drivers/regulator/pwm-regulator.c
> index ffa9612..25560fc 100644
> --- a/drivers/regulator/pwm-regulator.c
> +++ b/drivers/regulator/pwm-regulator.c
> @@ -78,8 +78,7 @@ static int pwm_regulator_list_voltage(struct regulator_dev
> *rdev,
>
> return drvdata->duty_cycle_table[selector].uV;
> }
> -
> -static struct regulator_ops pwm_regulator_voltage_ops = {
> +static struct regulator_ops pwm_regulator_voltage_table_ops = {
> .set_voltage_sel = pwm_regulator_set_voltage_sel,
> .get_voltage_sel = pwm_regulator_get_voltage_sel,
> .list_voltage= pwm_regulator_list_voltage,
> @@ -88,20 +87,55 @@ static struct regulator_ops pwm_regulator_voltage_ops = {
>
> static struct regulator_desc pwm_regulator_desc = {
> .name = "pwm-regulator",
> - .ops= _regulator_voltage_ops,
> .type = REGULATOR_VOLTAGE,
> .owner = THIS_MODULE,
> .supply_name= "pwm",
> };
>
> +static int pwm_regulator_init_table(struct platform_device *pdev,
> + struct pwm_regulator_data *drvdata)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct pwm_voltages *duty_cycle_table;
> + int length;
> + int ret;
> +
> + of_find_property(np, "voltage-table", );
> +
> + if ((length < sizeof(*duty_cycle_table)) ||
> + (length % sizeof(*duty_cycle_table))) {
> + dev_err(>dev,
> + "voltage-table length(%d) is invalid\n",
> + length);
> + return -EINVAL;
> + }
> +
> + duty_cycle_table = devm_kzalloc(>dev, length, GFP_KERNEL);
> + if (!duty_cycle_table)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32_array(np, "voltage-table",
> + (u32 *)duty_cycle_table,
> + length / sizeof(u32));
> + if (ret) {
> + dev_err(>dev, "Failed to read voltage-table\n");
> + return ret;
> + }
> +
> + drvdata->duty_cycle_table = duty_cycle_table;
> + pwm_regulator_desc.ops = _regulator_voltage_table_ops;
> + pwm_regulator_desc.n_voltages = length / sizeof(*duty_cycle_table);
> +
> + return 0;
> +}
> +
> static int pwm_regulator_probe(struct platform_device *pdev)
> {
> struct pwm_regulator_data *drvdata;
> - struct property *prop;
> struct regulator_dev *regulator;
> struct regulator_config config = { };
> struct device_node *np = pdev->dev.of_node;
> - int length, ret;
> + int ret;
>
> if (!np) {
> dev_err(>dev, "Device Tree node missing\n");
> @@ -112,36 +146,15 @@ static int pwm_regulator_probe(struct platform_device
> *pdev)
> if (!drvdata)
> return -ENOMEM;
>
> - /*
Re: [PATCH 18/28] ARC: add smp barriers around atomics per memory-barrriers.txt
On Tuesday 09 June 2015 06:00 PM, Peter Zijlstra wrote:
> On Tue, Jun 09, 2015 at 05:18:18PM +0530, Vineet Gupta wrote:
>
> Please try and provide at least _some_ Changelog body.
>
>
Will do as comments in source as well as commit log in v2.
>> diff --git a/arch/arc/include/asm/spinlock.h
>> b/arch/arc/include/asm/spinlock.h
>> index b6a8c2dfbe6e..8af8eaad4999 100644
>> --- a/arch/arc/include/asm/spinlock.h
>> +++ b/arch/arc/include/asm/spinlock.h
>> @@ -22,24 +22,32 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>> {
>> unsigned int tmp = __ARCH_SPIN_LOCK_LOCKED__;
>>
>> +smp_mb();
>> +
>> __asm__ __volatile__(
>> "1: ex %0, [%1]\n"
>> " breq %0, %2, 1b\n"
>> : "+" (tmp)
>> : "r"(&(lock->slock)), "ir"(__ARCH_SPIN_LOCK_LOCKED__)
>> : "memory");
>> +
>> +smp_mb();
>> }
>>
>> static inline int arch_spin_trylock(arch_spinlock_t *lock)
>> {
>> unsigned int tmp = __ARCH_SPIN_LOCK_LOCKED__;
>>
>> +smp_mb();
>> +
>> __asm__ __volatile__(
>> "1: ex %0, [%1]\n"
>> : "+r" (tmp)
>> : "r"(&(lock->slock))
>> : "memory");
>>
>> +smp_mb();
>> +
>> return (tmp == __ARCH_SPIN_LOCK_UNLOCKED__);
>> }
>>
> Both these are only required to provide an ACQUIRE barrier, if all you
> have is smp_mb(), the second is sufficient.
Essentially ARCv2 is weakly ordered with explicit ordering provided by DMB
instructions with semantics load/load, store/store, all/all.
I wanted to clarify a couple of things
(1) ACQUIRE barrier implies store/{store,load} while RELEASE implies
{load,store}/store and given what DMB provides for ARCv2, smp_mb() is the only
fit ?
(2) Do we need smp_mb() on both sides of spin lock/unlock - doesn't ACQUIRE
imply
we have a smp_mb() after lock but before any subsequent critical section - so
the
top hunk is not necessarily needed. Similarly RELEASE requires a smp_mb() before
the memory operation for lock, but not after.
> Also note that a failed trylock is not required to provide _any_ barrier
> at all.
But that means wrapping the barrier in a branch etc, I'd rather keep them
uniform
for now - unless we see performance hits due to that. I suppose all of that is
more relevant for heavy metal 4k cpu stuff ?
>
>> @@ -47,6 +55,8 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
>> {
>> unsigned int tmp = __ARCH_SPIN_LOCK_UNLOCKED__;
>>
>> +smp_mb();
>> +
>> __asm__ __volatile__(
>> " ex %0, [%1]\n"
>> : "+r" (tmp)
> This requires a RELEASE barrier, again, if all you have is smp_mb(),
> this is indeed correct.
Ok, actually we already had a smp_mb() in the end of this function - but
depending
on what ur reply is to #2 above we can remove that (as a seperate commit)
>
> Describing some of this would make for a fine Changelog body :-)
I will spin a v2 after your response, with more informative changelog.
Thx for the review.
-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/
[REBASED v1.1 2/5] regulator: pwm-regulator: Separate voltage-table initialisation
Take this out of the main .probe() routine in order to facilitate the
introduction of different ways to obtain 'duty cycle' information.
Signed-off-by: Lee Jones
---
drivers/regulator/pwm-regulator.c | 77 +++
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index ffa9612..25560fc 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -78,8 +78,7 @@ static int pwm_regulator_list_voltage(struct regulator_dev
*rdev,
return drvdata->duty_cycle_table[selector].uV;
}
-
-static struct regulator_ops pwm_regulator_voltage_ops = {
+static struct regulator_ops pwm_regulator_voltage_table_ops = {
.set_voltage_sel = pwm_regulator_set_voltage_sel,
.get_voltage_sel = pwm_regulator_get_voltage_sel,
.list_voltage= pwm_regulator_list_voltage,
@@ -88,20 +87,55 @@ static struct regulator_ops pwm_regulator_voltage_ops = {
static struct regulator_desc pwm_regulator_desc = {
.name = "pwm-regulator",
- .ops= _regulator_voltage_ops,
.type = REGULATOR_VOLTAGE,
.owner = THIS_MODULE,
.supply_name= "pwm",
};
+static int pwm_regulator_init_table(struct platform_device *pdev,
+ struct pwm_regulator_data *drvdata)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct pwm_voltages *duty_cycle_table;
+ int length;
+ int ret;
+
+ of_find_property(np, "voltage-table", );
+
+ if ((length < sizeof(*duty_cycle_table)) ||
+ (length % sizeof(*duty_cycle_table))) {
+ dev_err(>dev,
+ "voltage-table length(%d) is invalid\n",
+ length);
+ return -EINVAL;
+ }
+
+ duty_cycle_table = devm_kzalloc(>dev, length, GFP_KERNEL);
+ if (!duty_cycle_table)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, "voltage-table",
+(u32 *)duty_cycle_table,
+length / sizeof(u32));
+ if (ret) {
+ dev_err(>dev, "Failed to read voltage-table\n");
+ return ret;
+ }
+
+ drvdata->duty_cycle_table = duty_cycle_table;
+ pwm_regulator_desc.ops = _regulator_voltage_table_ops;
+ pwm_regulator_desc.n_voltages = length / sizeof(*duty_cycle_table);
+
+ return 0;
+}
+
static int pwm_regulator_probe(struct platform_device *pdev)
{
struct pwm_regulator_data *drvdata;
- struct property *prop;
struct regulator_dev *regulator;
struct regulator_config config = { };
struct device_node *np = pdev->dev.of_node;
- int length, ret;
+ int ret;
if (!np) {
dev_err(>dev, "Device Tree node missing\n");
@@ -112,36 +146,15 @@ static int pwm_regulator_probe(struct platform_device
*pdev)
if (!drvdata)
return -ENOMEM;
- /* determine the number of voltage-table */
- prop = of_find_property(np, "voltage-table", );
- if (!prop) {
- dev_err(>dev, "No voltage-table\n");
- return -EINVAL;
- }
-
- if ((length < sizeof(*drvdata->duty_cycle_table)) ||
- (length % sizeof(*drvdata->duty_cycle_table))) {
- dev_err(>dev, "voltage-table length(%d) is invalid\n",
- length);
+ if (of_find_property(np, "voltage-table", NULL)) {
+ ret = pwm_regulator_init_table(pdev, drvdata);
+ if (ret)
+ return ret;
+ } else {
+ dev_err(>dev, "No \"voltage-table\" supplied\n");
return -EINVAL;
}
- pwm_regulator_desc.n_voltages = length /
sizeof(*drvdata->duty_cycle_table);
-
- drvdata->duty_cycle_table = devm_kzalloc(>dev,
-length, GFP_KERNEL);
- if (!drvdata->duty_cycle_table)
- return -ENOMEM;
-
- /* read voltage table from DT property */
- ret = of_property_read_u32_array(np, "voltage-table",
-(u32 *)drvdata->duty_cycle_table,
-length / sizeof(u32));
- if (ret < 0) {
- dev_err(>dev, "read voltage-table failed\n");
- return ret;
- }
-
config.init_data = of_get_regulator_init_data(>dev, np,
_regulator_desc);
if (!config.init_data)
--
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/
