Re: [RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path
Hi Anton, Anton Blanchard writes: > Hi Nikunj, > >> From: Nikunj A Dadhania >> >> powerpc/numa: initialize distance lookup table from drconf path >> >> In some situations, a NUMA guest that supports >> ibm,dynamic-memory-reconfiguration node will end up having flat NUMA >> distances between nodes. This is because of two problems in the >> current code. > > Thanks for the patch. Have we tested that this doesn't regress the > non dynamic representation? Yes, that is tested. And works as expected. Regards Nikunj -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
> [Adding Rob] Rob is not the only DT Maintainer, there are many of them. The DT list was CC'ed, which they are all part of. Adding them all separately is not required IMO. > On 22-06-15, 16:43, Lee Jones wrote: > > At least some description was required here on why you need additional > bindings are what are they. Sure, I can do that. > Over that, this patch should have been present before any other > patches using these bindings. I've never heard that one before, but it's easy to re-order the set. > > Cc: devicet...@vger.kernel.org > > Signed-off-by: Lee Jones > > --- > > .../devicetree/bindings/cpufreq/cpufreq-st.txt | 48 > > ++ > > 1 file changed, 48 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt > > > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt > > b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt > > new file mode 100644 > > index 000..cfa8952 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt > > @@ -0,0 +1,48 @@ > > +Binding for ST's CPUFreq driver > > +=== > > OPP-v2 bindings are out now and you can probably use them to make life > simple, they are part of Rafael's recent pull request: > https://lkml.org/lkml/2015/6/22/606 > > > +Required properties: > > +--- > > +- compatible : Supported values are: > > + "st,stih407-cpufreq" > > Nodes for virtual devices aren't allowed in DT. Then why do Exynos, Spear, HREF and Snowball have CPUFreq nodes? One rule for one ... ? > > +Required properties [for working voltage scaling]: > > +- > > + > > +Located in CPUFreq's node: > > + > > +- st,syscfg: Phandle to Major number register > > + First cell: offset to major number > > +- st,syscfg-eng: Phandle to Minor number and Pcode registers > > + First cell: offset to process code > > + Second cell: offset to minor number > > + > > +Located in CPU's node: > > + > > +- st,opp-list : Bootloader provided node containing one or > > more 'opp@X' sub-nodes > > I can see that this will be passed in from the bootloader. But at > least an example on how exactly things would actually look would have > been good. In logs if not in this file. Sure. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VFIO: platform: enable ARM64 build
Hi Baptiste, Alex, On 06/23/2015 08:56 AM, Baptiste Reynal wrote: > On Mon, Jun 22, 2015 at 6:26 PM, Alex Williamson > wrote: >> On Mon, 2015-06-22 at 17:56 +0200, Eric Auger wrote: >>> Hi Baptiste, >>> >>> No unfortunately I don't have any HW to test this currently. I just >>> test-compiled this. Up to you to decide whether you prefer waiting for a >>> functional test for this. I sent that patch since I expect ARM64 to be >>> the main platform where the VFIO platform drivermight be used for >>> virtualization use case. > > > On my side, VFIO has been tested on ARM64 using Fastmodels without > problems, we can go ahead with the patch. OK great > >> >> FWIW, I've been occasionally removing the arch condition entirely to >> build test on x86 as well. The Intel VT-d code certainly allows for >> devices described by ACPI, which I assume would fall under the platform >> category, but I don't know of any systems that do this, let alone any >> x86 platform devices that we'd actually want to expose to the user. >> Eventually we might want to consider decoupling this from an arch-based >> Kconfig option, but we could just as easily let the first non-ARM user >> think about that problem. Thanks, >> >> Alex >> > > Indeed, I'd rather wait for someone to show up with some use cases and > tests before removing this condition. OK Eric > > Regards, > Baptiste > >>> On 06/22/2015 05:49 PM, Baptiste Reynal wrote: Acked-by: Baptiste Reynal Tested-by: Baptiste Reynal Out of curiosity, have you get VFIO running on ARM64 without any problems ? On Mon, Jun 15, 2015 at 11:13 AM, Eric Auger wrote: > This patch enables building VFIO platform and derivatives on ARM64. > > Signed-off-by: Eric Auger > --- > drivers/vfio/platform/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig > index 1df7477..bb30128 100644 > --- a/drivers/vfio/platform/Kconfig > +++ b/drivers/vfio/platform/Kconfig > @@ -1,6 +1,6 @@ > config VFIO_PLATFORM > tristate "VFIO support for platform devices" > - depends on VFIO && EVENTFD && ARM > + depends on VFIO && EVENTFD && (ARM || ARM64) > select VFIO_VIRQFD > help > Support for platform devices with VFIO. This is required to make > -- > 1.9.1 > >>> >> >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] ARM: STi: STiH407: Move PWM nodes STiH407 => STiH407-family
On Tue, 23 Jun 2015, Viresh Kumar wrote: > On 22-06-15, 16:43, Lee Jones wrote: > > This also incorporates the STiH410. > > Any explanation to why this patch is part of this series ? Because the CPUFreq regulator is controlled with PWM and CPUFreq will fail on STiH410 (my main development platform) without it. It's safe for you to ignore it though. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] ARM: STi: STiH407: Provide a node for CPUFreq
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> [Ccing Rob]
Rob is already Cc'ed.
> On 22-06-15, 16:43, Lee Jones wrote:
> > Signed-off-by: Lee Jones
> > ---
> > arch/arm/boot/dts/stih407-family.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > b/arch/arm/boot/dts/stih407-family.dtsi
> > index f48767e..f57fd83 100644
> > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > @@ -98,6 +98,11 @@
> > ranges;
> > compatible = "simple-bus";
> >
> > + cpufreq {
> > + compatible = "st,stih407-cpufreq";
> > + st,syscfg = <&syscfg_core 0x8e0>;
> > + };
>
> These virtual nodes aren't allowed in DT and you have added them
> before the bindings patch :).
This isn't a virtual node, but you bring up a good point.
The compatible string should also contain "syscon".
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.1 WARNING in drm_ioctl.c
In data martedì 23 giugno 2015 08:39:47, Daniel Vetter ha scritto: > On Mon, Jun 22, 2015 at 04:04:20PM +0200, Fabio Coatti wrote: > > Hi All, > > > > just compiled 4.1 and just got this warning, twice, in my dmesg: > > > > > > [lun giu 22 11:43:18 2015] [ cut here ] > > [lun giu 22 11:43:18 2015] WARNING: CPU: 1 PID: 2184 at > > drivers/gpu/drm/drm_ioctl.c:144 drm_setversion+0xe1/0x179() > > [lun giu 22 11:43:18 2015] No drm_driver.set_busid() implementation > > provided by 0x81ec3980. Use drm_dev_set_unique() to set the > > unique name explicitly. > > [lun giu 22 11:43:18 2015] Modules linked in: > > [lun giu 22 11:43:18 2015] bnep algif_skcipher cdc_wdm cdc_acm uvcvideo > > videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev > > btusb btbcm btintel bluetooth hp_wmi sparse_keymap intel_rapl iosf_mbi > > x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi coretemp > > kvm_intel > > kvm snd_hda_codec_generic crct10dif_pclmul crc32_pclmul snd_hda_intel > > iwldvm snd_hda_controller snd_hda_codec snd_hwdep psmouse snd_hda_core > > iwlwifi snd_pcm snd_timer snd soundcore wmi hp_accel(+) hp_wireless > > lis3lv02d sch_fq_codel dm_zero dm_persistent_data dm_service_time > > dm_round_robin dm_queue_length dm_multipath dm_delay virtio_pci > > virtio_blk virtio_balloon virtio_ring virtio fuse overlay linear raid0 > > dm_raid dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log ohci_pci > > ohci_hcd uhci_hcd > > [lun giu 22 11:43:18 2015] CPU: 1 PID: 2184 Comm: X Tainted: GW > > 4.1.0 #1 > > [lun giu 22 11:43:18 2015] Hardware name: Hewlett-Packard HP EliteBook > > Folio 9470m/18DF, BIOS 68IBD Ver. F.40 02/01/2013 > > [lun giu 22 11:43:18 2015] 0009 > > 818d8bfd 8800b226fd38 > > [lun giu 22 11:43:18 2015] 810c5426 880235437240 > > 8152870c 8800b2f16000 > > [lun giu 22 11:43:18 2015] 880234ffc000 8800b226fdf0 > > 8800b2c8f300 c0106407 > > [lun giu 22 11:43:18 2015] Call Trace: > > [lun giu 22 11:43:18 2015] [] ? dump_stack+0x47/0x67 > > [lun giu 22 11:43:18 2015] [] ? > > warn_slowpath_common+0x9d/0xb5 > > [lun giu 22 11:43:18 2015] [] ? > > drm_setversion+0xe1/0x179 [lun giu 22 11:43:18 2015] > > [] ? warn_slowpath_fmt+0x4a/0x4f [lun giu 22 11:43:18 > > 2015] [] ? drm_setversion+0xe1/0x179 [lun giu 22 > > 11:43:18 2015] [] ? drm_ioctl+0x376/0x3dd [lun giu 22 > > 11:43:18 2015] [] ? drm_version+0x8d/0x8d [lun giu 22 > > 11:43:18 2015] [] ? do_filp_open+0x30/0x74 [lun giu 22 > > 11:43:18 2015] [] ? do_vfs_ioctl+0x379/0x431 [lun giu > > 22 11:43:18 2015] [] ? __fd_install+0x20/0x52 [lun giu > > 22 11:43:18 2015] [] ? do_sys_open+0x1c0/0x1d2 [lun > > giu 22 11:43:18 2015] [] ? SyS_ioctl+0x3e/0x5a [lun > > giu 22 11:43:18 2015] [] ? > > system_call_fastpath+0x16/0x6e > > [lun giu 22 11:43:18 2015] ---[ end trace 46364eedd82ef148 ]--- > > > > It does not seems to affect normal behaviour, but maybe the report could > > be > > interesting for maintainers. > > > > Sorry if this has already been reported; if more information is needed > > just > > let me know (please CC: me as I'm not subscribed to lists.) > > Which drm driver are you using? I didn't spot anything in your module list > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg > will tell us for sure. > -Daniel Attached the drm.debug output, grepped for "drm". Let me know if I stripped something useful. Thanks, -- Fabio drm.debug.gz Description: application/gzip
Re: [PATCH 2/2] PM / Domains: Avoid infinite loops in attach/detach code
Hi Rafael,
On Tue, Jun 23, 2015 at 1:41 AM, Rafael J. Wysocki wrote:
> On Monday, June 22, 2015 09:31:22 AM Geert Uytterhoeven wrote:
>> If pm_genpd_{add,remove}_device() keeps on failing with -EAGAIN, we end
>> up with an infinite loop in genpd_dev_pm_{at,de}tach().
>>
>> This may happen due to a genpd.prepared_count imbalance. This is a bug
>> elsewhere, but it will result in a system lock up, possibly during
>> reboot of an otherwise functioning system.
>>
>> To avoid this, put a limit on the maximum number of loop iterations,
>> including a simple back-off mechanism. If the limit is reached, the
>> operation will just fail. An error message is already printed.
>>
>> Signed-off-by: Geert Uytterhoeven
>
> This was too late for my first 4.2 pull request, but I may push it in the
> second half of the merge window. Does it depend on anything?
Not that I'm aware of.
It applies fine on v4.1 or next-20150622.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
Thanks for your timely review Viresh.
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 22-06-15, 16:43, Lee Jones wrote:
> > +config ARM_ST_CPUFREQ
> > + bool "ST CPUFreq support"
>
> Isn't using ST just too generic? There are multiple SoCs ST has been
> involved with, I have worked on a completely different series.
> Probably a more relative string is required here, like stih407 ?
This is ST's only CPUFreq implementation and is pretty board
agnostic. This particular driver only currently supports the STiH407
family, but internally it supports some others too. I'll have a chat
and see if we can make it more specific somehow.
> > + depends on SOC_STIH407
[...]
> > +static int st_cpufreq_get_dvfs_info(struct platform_device *pdev)
> > +{
> > + struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
> > + struct st_dvfs_tab *dvfs_tab = &ddata->dvfs_tab[0];
> > + struct device_node *np = pdev->dev.of_node;
> > + struct device_node *opplist, *opp;
> > + unsigned int minor = 0, major = 0;
> > + int err, ret = 0;
> > +
> > + opplist = of_get_child_by_name(np, "opp-list");
>
> st,opp-list ?
Sure.
[...]
> > +out:
> > + of_node_put(opplist);
> > +
> > + if (!ddata->dvfs_tab_count) {
> > + dev_err(&pdev->dev, "No suitable AVS table found\n");
>
> Why is this an error? I thought in this case you will go ahead with
> the normal OPP-table.
I've written it so it's an error within this function, as it makes the
function fail, but is downgraded by the caller to a warning and
gracefully bypassed to still allow frequency scaling.
> > + return -EINVAL;
[...]
> > + for (i = 0; i < ddata->dvfs_tab_count; i++, dvfs_tab++) {
> > + unsigned int f = dvfs_tab->freq * 1000;
> > + unsigned int v = dvfs_tab->avs * 1000;
> > +
> > + opp = dev_pm_opp_find_freq_exact(cpu_dev, f, false);
> > +
> > + /* Remove existing voltage-less OPP entry */
> > + if (!IS_ERR(opp))
> > + dev_pm_opp_remove(cpu_dev, f);
> > +
> > + /* Supply new fully populated OPP entry */
> > + ret = dev_pm_opp_add(cpu_dev, f, v);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Failed to add OPP %u\n", f);
> > + return ret;
> > + }
> > + }
>
> So you have added new OPPs here, but cpufreq-dt will try to add old
> OPPs. You must be getting lots of warnings ?
Yes, we recieve the 'duplicate OPPs detected' warning, but there is
nothing we can do about that.
> > +
> > + return 0;
> > +}
[...]
> > +static const struct reg_field
> > sti_stih407_dvfs_regfields[DVFS_MAX_REGFIELDS] = {
> > + [PCODE] = REG_FIELD(0, 16, 19),
> > + [SUBSTRATE] = REG_FIELD(0, 0, 2),
> > +};
> > +
> > +static struct of_device_id sti_cpufreq_of_match[] = {
> > + {
> > + .compatible = "st,stih407-cpufreq",
> > + .data = &sti_stih407_dvfs_regfields,
> > + },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, sti_cpufreq_of_match);
> > +
> > +/* Find process code -- calibrated per-SoC */
> > +static void sti_cpufreq_get_pcode(struct platform_device *pdev)
> > +{
> > + struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
> > + struct device_node *np = pdev->dev.of_node;
> > + const struct reg_field *reg_fields;
> > + const struct of_device_id *match;
> > + int pcode_offset;
> > + int ret;
> > +
> > + ddata->regmap_eng = syscon_regmap_lookup_by_phandle(np,
> > "st,syscfg-eng");
> > + if (IS_ERR(ddata->regmap_eng)) {
> > + dev_warn(&pdev->dev, "\"st,syscfg-eng\" not supplied\n");
> > + goto set_default;
> > + }
> > +
> > + ret = of_property_read_u32_index(np, "st,syscfg-eng",
> > +PCODE_INDEX, &pcode_offset);
> > + if (ret) {
> > + dev_warn(&pdev->dev, "Process code offset is required\n");
> > + goto set_default;
> > + }
> > +
> > + match = of_match_node(sti_cpufreq_of_match, np);
>
> Are you planning to add more entries to this table? We are here as
> probe() is called only after matching for this string.
Yes, when new platforms are enabled. The information stored in .data
will be different.
> > + if (!match) {
> > + dev_warn(&pdev->dev, "Failed to match device\n");
> > + goto set_default;
> > + }
> > + reg_fields = match->data;
> > +
> > + ddata->pcode = st_cpufreq_fetch_regmap_field(pdev, reg_fields,
> > +pcode_offset,
> > +PCODE);
> > + if (ddata->pcode < 0)
> > + goto set_default;
> > +
> > + ddata->substrate = st_cpufreq_fetch_regmap_field(pdev, reg_fields,
> > +pcode_offset,
> > +SUBSTRATE);
> > + if (ddata->substrate < 0)
> > + goto set_default;
>
> Maybe:
>
> if (ddata->substrate >= 0)
Re: [RFC][PATCH 09/13] hotplug: Replace hotplug lock with percpu-rwsem
On Tue, Jun 23, 2015 at 12:57:39AM +0200, Oleg Nesterov wrote: > > + > > + lock_map_acquire_read(&cpu_hotplug.rwsem.rw_sem.dep_map); > > + _percpu_down_read(&cpu_hotplug.rwsem); > > } > > Confused... Why do we need _percpu_down_read()? Can't get_online_cpus() > just use percpu_down_read() ? > > Yes, percpu_down_read() is not recursive, like the normal down_read(). > But this does not matter because we rely on ->cpuhp_ref anyway? While we will not call the actual lock, lockdep will still get confused by the inconsistent locking order observed. Change it and boot, you'll find lockdep output pretty quickly. > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -1410,6 +1410,8 @@ static struct task_struct *copy_process( > > p->sequential_io_avg= 0; > > #endif > > > > + cpu_hotplug_init_task(p); > > This is probably unnecessary, copy_process() should not be called under > get_online_cpus(). Probably true, in which case we could still use the callback to insert a WARN_ON_ONCE(p->cpuhp_ref) :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] NET: Add ezchip ethernet driver
From: Mahesh Bandewar Date: Mon, 22 Jun 2015 10:45:15 -0700 > On Tue, Jun 16, 2015 at 7:35 AM, Noam Camus wrote: >> @@ -0,0 +1,27 @@ >> +# >> +# EZchip network device configuration >> +# >> + >> +config NET_VENDOR_EZCHIP >> + bool "EZchip devices" >> + default y >> > Why this has to be included in the default build? Shouldn't it be > either "m" or "N" by default? It's a vendor guard, which are always enabled yes by default. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [v2 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
On Mon, 22 Jun 2015, Daniel Vetter wrote: > On Mon, Jun 22, 2015 at 04:33:22PM +0530, Varka Bhadram wrote: > > Hi Shobhit Kumar, > > > > On 06/22/2015 04:24 PM, Shobhit Kumar wrote: > > > > >On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup > > >entry for the same to be used by the consumer (Intel GFX) > > > > > >v2: Remove the lookup table on driver unload (Thierry) > > > > > >v3: Correct the subject line (Lee jones) > > > > This part should only describe what this is about.. > > > > Don't put this patch change history over here. > > Include this change history after > > ... > > Signed-off-by: Author > > --- > > > > >CC: Samuel Ortiz > > >Cc: Linus Walleij > > >Cc: Alexandre Courbot > > >Cc: Thierry Reding > > >Acked-by: Lee Jones > > >Signed-off-by: Shobhit Kumar > > >--- > > > > Here you add this change history so that after applying this > > will not be the part of your commit description. > > > > This comment is applicable for all of your patches. > > It's honestly a per-maintainer thing and hard to tell who wants what ... > Personally I do want to include the patch changelog in the commit message. The patch change-log should go below the '---'. There are very few (weird ;) ) Maintainers who like to see them in the commit log. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 00/27] perf stat: Introduce --per-thread option
On Mon, Jun 22, 2015 at 08:06:00PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Jun 23, 2015 at 12:36:01AM +0200, Jiri Olsa escreveu: > > hi, > > adding the possibility to display stat data per thread. > > > > Allowing following commands and output: > > > > $ perf stat -e cycles,instructions --per-thread -p 30190,30242 > > While testing Adrian's Intel PT patchkit I realised we have --per-thread > in 'record', wonder if using a long option with the exact same name but > different meanings for 'stat' and 'record' would cause confusion... I think the name fits for both stat and record.. and both are doing different thing, so both --per-thread are also different.. and well documented ;-) jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: kdbus: to merge or not to merge?
On Tue, Jun 23, 2015 at 8:41 AM, Greg KH wrote: >> The current state of uncertainty is problematic, I think. The kdbus >> team is spending a lot of time making things compatible with kdbus, >> and the latest systemd release makes kdbus userspace support >> mandatory. > > I stopped here in this email, as this is just flat out totally wrong, > and I don't want to waste my time trying to refute other totally wrong > statements as that would just somehow give them some validation that > they could possibly be correct. For the guys who not follow systemd development, this is the announcement in question: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html * kdbus support is no longer compile-time optional. It is now always built-in. However, it can still be disabled at runtime using the kdbus=0 kernel command line setting, and that setting may be changed to default to off, by specifying --disable-kdbus at build-time. Note though that the kernel command line setting has no effect if the kdbus.ko kernel module is not installed, in which case kdbus is (obviously) also disabled. We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled. Now kdbus is opt-out instead of opt-in. Although I didn't test it so far, systemd should work just fine if kdbus is not present as it can fall back to dbus. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.1 WARNING in drm_ioctl.c
Hi, On 23 June 2015 at 07:39, Daniel Vetter wrote: > Which drm driver are you using? I didn't spot anything in your module list > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg > will tell us for sure. That'd be vgem. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 077/105] drm/i915: Dont skip request retirement if the active list is empty
On Fri, 19 Jun 2015, Greg Kroah-Hartman wrote:
> 4.0-stable review patch. If anyone has any objections, please let me know.
The commit to be backported is already reverted in upstream, and I just
got an email from you backporting the revert as well... would be best to
*not* backport either of these:
commit 0aedb1626566efd72b369c01992ee7413c82a0c5
Author: Ville Syrjälä
Date: Thu May 28 18:32:36 2015 +0300
drm/i915: Don't skip request retirement if the active list is empty
commit 245ec9d85696c3e539b23e210f248698b478379c
Author: Jani Nikula
Date: Mon Jun 15 12:59:37 2015 +0300
Revert "drm/i915: Don't skip request retirement if the active list is empty"
I only marked the revert cc: stable because the original was too.
BR,
Jani.
>
> --
>
> From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?=
>
> commit 0aedb1626566efd72b369c01992ee7413c82a0c5 upstream.
>
> Apparently we can have requests even if though the active list is empty,
> so do the request retirement regardless of whether there's anything
> on the active list.
>
> The way it happened here is that during suspend intel_ring_idle()
> notices the olr hanging around and then proceeds to get rid of it by
> adding a request. However since there was nothing on the active lists
> i915_gem_retire_requests() didn't clean those up, and so the idle work
> never runs, and we leave the GPU "busy" during suspend resulting in a
> WARN later.
>
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Chris Wilson
> Signed-off-by: Jani Nikula
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/gpu/drm/i915/i915_gem.c |3 ---
> 1 file changed, 3 deletions(-)
>
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2732,9 +2732,6 @@ void i915_gem_reset(struct drm_device *d
> void
> i915_gem_retire_requests_ring(struct intel_engine_cs *ring)
> {
> - if (list_empty(&ring->request_list))
> - return;
> -
> WARN_ON(i915_verify_lists(ring->dev));
>
> /* Retire requests first as we use it above for the early return.
>
>
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 05/13] percpu-rwsem: Optimize readers and reduce global impact
A bit off-topic probably
but maybe this should not be in kernel/locking/percpu-rwsem.c but in a
generic percpu location as this construct is present in the core a few times
atleast in:
kernel/irq/irqdesc.c:kstat_irqs
kernel/fork.c:nr_processes
mm/memcontrol.c:mem_cgroup_read_events
mm/memcontrol.c:mem_cgroup_read_stat
> +
> +#define per_cpu_sum(var) \
> +({ \
> + typeof(var) __sum = 0; \
> + int cpu;\
> + for_each_possible_cpu(cpu) \
> + __sum += per_cpu(var, cpu); \
> + __sum; \
> +})
> +
so maybe put it into include/linux/percpu.h ?
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [STLinux Kernel] [PATCH 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
On 06/23/2015 09:16 AM, Lee Jones wrote: Thanks for your timely review Viresh. On Tue, 23 Jun 2015, Viresh Kumar wrote: On 22-06-15, 16:43, Lee Jones wrote: +config ARM_ST_CPUFREQ + bool "ST CPUFreq support" Isn't using ST just too generic? There are multiple SoCs ST has been involved with, I have worked on a completely different series. Probably a more relative string is required here, like stih407 ? This is ST's only CPUFreq implementation and is pretty board agnostic. This particular driver only currently supports the STiH407 family, but internally it supports some others too. I'll have a chat and see if we can make it more specific somehow. I think you can use STI instead. Regards, Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel
* Jiang Liu wrote:
> The data type resource_size_t may be 32 bits or 64 bits depending on
> CONFIG_PHYS_ADDR_T_64BIT. So reject ACPI resource descriptors which
> will cause resource_size_t overflow with 32bit kernel
>
> This issue was triggered on a platform running 32bit kernel with an
> ACPI resource descriptor with address range [0x4-0xf].
> Please refer to https://lkml.org/lkml/2015/6/19/277 for more information.
>
> Reported-by: Boszormenyi Zoltan
> Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to
> simplify implementation")
> Signed-off-by: Jiang Liu
> Cc: sta...@vger.kernel.org # 4.0
Yeah, so please use the customary changelog style we use in the kernel:
" Current code does (A), this causes problem (B) when doing (C).
In that case the user notices (D).
We can improve this doing (E), because now the user will experience (F),
which is more desirable."
Please fill in A-F accordingly.
In particular your changelog is missing 'B' and 'D': what exactly is a
'resource_size_t overflow' and what does the user notice from it?
Your changelog is also missing 'F'.
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 2/2] x86/mm/pat, drivers/media/ivtv: replace WARN() with pr_warn()
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> On built-in kernels this will always splat. Fix that.
>
> Reported-by: Fengguang Wu [0-day test robot]
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/media/pci/ivtv/ivtvfb.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
> index 4cb365d..6f0c364 100644
> --- a/drivers/media/pci/ivtv/ivtvfb.c
> +++ b/drivers/media/pci/ivtv/ivtvfb.c
> @@ -38,6 +38,8 @@
> Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include
> #include
> #include
> @@ -1266,8 +1268,8 @@ static int __init ivtvfb_init(void)
> int err;
>
> #ifdef CONFIG_X86_64
> - if (WARN(pat_enabled(),
> - "ivtvfb needs PAT disabled, boot with nopat kernel
> parameter\n")) {
> + if (pat_enabled()) {
> + pr_warn("ivtvfb needs PAT disabled, boot with nopat kernel
> parameter\n");
> return -ENODEV;
> }
So why should a built-in kernel bzImage with this driver enabled but the driver
not present print this warning?
Why not only print in a code path where we know the hardware is present?
allyesconfig bootups are noisy enough as-is ...
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 1/2] x86/mm/pat, drivers/infiniband/ipath: replace WARN() with pr_warn()
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> On built-in kernels this will always splat. Fix that.
>
> Reported-by: Fengguang Wu [0-day test robot]
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c
> b/drivers/infiniband/hw/ipath/ipath_driver.c
> index 2d7e503..871dbe5 100644
> --- a/drivers/infiniband/hw/ipath/ipath_driver.c
> +++ b/drivers/infiniband/hw/ipath/ipath_driver.c
> @@ -31,6 +31,8 @@
> * SOFTWARE.
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include
> #include
> #include
> @@ -399,8 +401,8 @@ static int ipath_init_one(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> u32 bar0 = 0, bar1 = 0;
>
> #ifdef CONFIG_X86_64
> - if (WARN(pat_enabled(),
> - "ipath needs PAT disabled, boot with nopat kernel
> parameter\n")) {
> + if (pat_enabled()) {
> + pr_warn("ipath needs PAT disabled, boot with nopat kernel
> parameter\n");
> ret = -ENODEV;
> goto bail;
> }
Same observation as for the other patch: please only warn if the hardware is
present and the driver tries to activate. No need to annoy others.
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: Build regressions/improvements in v4.1
Hi Russell,
On Mon, Jun 22, 2015 at 11:18 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 22, 2015 at 10:52:13PM +0200, Geert Uytterhoeven wrote:
>> On Mon, Jun 22, 2015 at 10:48 PM, Geert Uytterhoeven
>> wrote:
>> > JFYI, when comparing v4.1[1] to v4.1-rc8[3], the summaries are:
>> > - build errors: +44/-7
>>
>> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
>> 'L_PTE_MT_BUFFERABLE' undeclared here (not in a function): => 81:10
>> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
>> 'L_PTE_MT_DEV_CACHED' undeclared here (not in a function): => 117:10
>> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
>> 'L_PTE_MT_DEV_NONSHARED' undeclared here (not in a function): =>
>> 108:10
>
> I'm rather ignoring this because I don't see these errors here. This
> is one of the problems of just throwing out build reports. With zero
> information such as a configuration or a method on how to cause the
> errors, it's pretty much worthless to post errors.
>
> Folk who do build testing need to be smarter, and consider what it's
> like to be on the receiving end of their report emails...
Fortunately the kisskb service has good bookkeeping of build logs and configs.
Re-adding the lost URL:
>> [1] http://kisskb.ellerman.id.au/kisskb/head/9038/ (all 254 configs)
1. Open URL in web browser,
2. Click on "Failed", next to "arm-randconfig",
3. Click on "Download", next to "arm-randconfig",
4. Reproduce,
5. Fix,
6. Profit! ;-)
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/2] perf tools: Print a newline before dumping Aggregated stats
When dumping events with 'perf report -D' the event print always starts with a newline (see dump_event()). Do the same with the "Aggregated stats" print so that it is not jammed up against the last event print. Signed-off-by: Adrian Hunter --- tools/perf/util/session.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c index aac1c4cee1e8..b5549b58bb2b 100644 --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -1728,7 +1728,7 @@ size_t perf_session__fprintf_nr_events(struct perf_session *session, FILE *fp) if (perf_header__has_feat(&session->header, HEADER_AUXTRACE)) msg = " (excludes AUX area (e.g. instruction trace) decoded / synthesized events)"; - ret = fprintf(fp, "Aggregated stats:%s\n", msg); + ret = fprintf(fp, "\nAggregated stats:%s\n", msg); ret += events_stats__fprintf(&session->evlist->stats, fp); return ret; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
On 23-06-15, 08:06, Lee Jones wrote:
> > [Adding Rob]
>
> Rob is not the only DT Maintainer, there are many of them. The DT
> list was CC'ed, which they are all part of. Adding them all
> separately is not required IMO.
I didn't Cc him because you missed him, but because we have been
discussing opp-v2 bindings recently and this was somehow related to
that. :)
> > On 22-06-15, 16:43, Lee Jones wrote:
> >
> > At least some description was required here on why you need additional
> > bindings are what are they.
>
> Sure, I can do that.
>
> > Over that, this patch should have been present before any other
> > patches using these bindings.
>
> I've never heard that one before, but it's easy to re-order the set.
I don't know, but it seems obvious to me: Bindings first and then the
code.
> > > +Required properties:
> > > +---
> > > +- compatible : Supported values are:
> > > + "st,stih407-cpufreq"
> >
> > Nodes for virtual devices aren't allowed in DT.
>
> Then why do Exynos, Spear, HREF and Snowball have CPUFreq nodes?
>
> One rule for one ... ?
Not really, but I got a bit confused now with your reply.
So, what I meant when I wrote: "Nodes for virtual devices aren't
allowed in DT", was that we aren't supposed to do something like:
cpufreq {
...
}
in DT as cpufreq isn't a device here. A CPU is a device and that can
contain whatever property we feel is reasonable.
What SPEAr and Exyons did was putting something in the cpu-node. Not a
node for cpufreq device itself. Couldn't find HREF and snowball's
bindings though..
--
viresh
--
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 5/8] ARM: STi: STiH407: Move PWM nodes STiH407 => STiH407-family
On 23-06-15, 08:08, Lee Jones wrote: > Because the CPUFreq regulator is controlled with PWM and CPUFreq will > fail on STiH410 (my main development platform) without it. I see, probably this should find a place in the cover-letter :) > It's safe for you to ignore it though. Thanks :) -- viresh -- 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/2] perf tools: Print a newline when dumping PERF_RECORD_FINISHED_ROUND
With 'perf report -D' the PERF_RECORD_FINISHED_ROUND
event was printed without a newline, resulting in:
0x91a18 [0x8]: PERF_RECORD_FINISHED_ROUNDAggregated stats
Other events print their details, but PERF_RECORD_FINISHED_ROUND
doesn't have any so just add a print for a newline.
Signed-off-by: Adrian Hunter
---
tools/perf/util/session.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index aa482c10469d..aac1c4cee1e8 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -686,6 +686,8 @@ static int process_finished_round(struct perf_tool *tool
__maybe_unused,
union perf_event *event __maybe_unused,
struct ordered_events *oe)
{
+ if (dump_trace)
+ fprintf(stdout, "\n");
return ordered_events__flush(oe, OE_FLUSH__ROUND);
}
--
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 V2 04/10] Drivers: hv: vmbus: add special kexec handler
On Thu, Jun 04, K. Y. Srinivasan wrote: > +++ b/arch/x86/kernel/cpu/mshyperv.c > @@ -18,6 +18,9 @@ > #include > #include > #include > +#ifdef CONFIG_KEXEC > +#include > +#endif Is this #ifdef required? Olaf -- 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/
spoluprace
Mam vzajemne mit prospech podnik pro nas oba. pokud mate zajem, muzete mi dostat na e-mailovou adresu a pro detaily a vysvetlení. E-mail: jgg.c...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] ARM: STi: STiH407: Provide a node for CPUFreq
On 23-06-15, 08:10, Lee Jones wrote: > > These virtual nodes aren't allowed in DT and you have added them > > before the bindings patch :). > > This isn't a virtual node, but you bring up a good point. Hmm, wrong choice of words. Sorry.. So, its a node for a virtual device :). The device is CPU and it already has a node for itself. And so such nodes were discouraged earlier by DT maintainers. -- viresh -- 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 v2 20/28] ARCv2: barriers
ARCv2 based HS38 cores are weakly ordered and thus explicit barriers for
kernel proper.
SMP barrier is provided by DMB instruction which also guarantees local
barrier hence used as backend of smp_*mb() as well as *mb() APIs
Also hookup barriers into MMIO accessors to avoid ordering issues in IO
Cc: Peter Zijlstra (Intel)
Cc: Will Deacon
Signed-off-by: Vineet Gupta
---
Changes since v1
* Better changelog and comments
* local/mandatory barriers to NOT use DSYNC, but DMB
* define DMB based mandatory barriers even for !SMP
---
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/Kbuild| 1 -
arch/arc/include/asm/barrier.h | 48 ++
arch/arc/include/asm/io.h | 42 +---
3 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644 arch/arc/include/asm/barrier.h
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index be0c39e76f7c..59e2dd1d434f 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -1,5 +1,4 @@
generic-y += auxvec.h
-generic-y += barrier.h
generic-y += bitsperlong.h
generic-y += bugs.h
generic-y += clkdev.h
diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
new file mode 100644
index ..a7209983ee64
--- /dev/null
+++ b/arch/arc/include/asm/barrier.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2014-15 Synopsys, Inc. (www.synopsys.com)
+ *
+ * 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.
+ */
+
+#ifndef __ASM_BARRIER_H
+#define __ASM_BARRIER_H
+
+#ifdef CONFIG_ISA_ARCV2
+
+/*
+ * ARCv2 based HS38 cores are in-order issue, but still weakly ordered
+ * due to micro-arch buffering/queuing of load/store, cache hit vs. miss ...
+ *
+ * Explicit barrier provided by DMB instruction
+ * - Operand supports fine grained load/store/load+store semantics
+ * - Ensures that selected memory operation issued before it will complete
+ *before any subsequent memory operation of same type
+ * - DMB guarantees SMP as well as local barrier semantics
+ *(asm-generic/barrier.h ensures sane smp_*mb if not defined here, i.e.
+ *UP: barrier(), SMP: smp_*mb == *mb)
+ * - DSYNC provides DMB+completion_of_cache_bpu_maintenance_ops hence not
needed
+ *in the general case. Plus it only provides full barrier.
+ */
+
+#define mb() asm volatile("dmb 3\n" : : : "memory")
+#define rmb() asm volatile("dmb 1\n" : : : "memory")
+#define wmb() asm volatile("dmb 2\n" : : : "memory")
+
+#endif
+
+#ifdef CONFIG_ISA_ARCOMPACT
+
+/*
+ * ARCompact based cores (ARC700) only have SYNC instruction which is super
+ * heavy weight as it flushes the pipeline as well.
+ * There are no real SMP implementations of such cores.
+ */
+
+#define mb() asm volatile("sync\n" : : : "memory")
+#endif
+
+#include
+
+#endif
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index cabd518cb253..18c685bf9748 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -98,9 +98,45 @@ static inline void __raw_writel(u32 w, volatile void __iomem
*addr)
}
-#define readb_relaxed readb
-#define readw_relaxed readw
-#define readl_relaxed readl
+#ifdef CONFIG_ISA_ARCV2
+#include
+#define __iormb() rmb()
+#define __iowmb() wmb()
+#else
+#define __iormb() do { } while (0)
+#define __iowmb() do { } while (0)
+#endif
+
+/*
+ * MMIO can also get buffered/optimized in micro-arch, so barriers needed
+ * Based on ARM model for the typical use case
+ *
+ *
+ *
+ * or:
+ *
+ *
+ *
+ * http://www.spinics.net/lists/kernel/msg2018397.html
+ */
+#define readb(c) ({ u8 __v = readb_relaxed(c); __iormb(); __v;
})
+#define readw(c) ({ u16 __v = readw_relaxed(c); __iormb(); __v;
})
+#define readl(c) ({ u32 __v = readl_relaxed(c); __iormb(); __v;
})
+
+#define writeb(v,c)({ __iowmb(); writeb_relaxed(v,c); })
+#define writew(v,c)({ __iowmb(); writew_relaxed(v,c); })
+#define writel(v,c)({ __iowmb(); writel_relaxed(v,c); })
+
+/*
+ * Relaxed API for drivers which can handle any ordering themselves
+ */
+#define readb_relaxed(c) __raw_readb(c)
+#define readw_relaxed(c) __raw_readw(c)
+#define readl_relaxed(c) __raw_readl(c)
+
+#define writeb_relaxed(v,c)__raw_writeb(v,c)
+#define writew_relaxed(v,c)__raw_writew(v,c)
+#define writel_relaxed(v,c)__raw_writel(v,c)
#include
--
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 v2 22/28] ARCv2: STAR 9000837815 workaround hardware exclusive transactions livelock
A quad core SMP build could get into hardware livelock with concurrent
LLOCK/SCOND. Workaround that by adding a PREFETCHW which is serialized by
SCU (System Coherency Unit). It brings the cache line in Exclusive state
and makes others invalidate their lines. This gives enough time for
winner to complete the LLOCK/SCOND, before others can get the line back.
The prefetchw in the ll/sc loop is not nice but this is the only
software workaround for current version of RTL.
Cc: Peter Zijlstra (Intel)
Cc: Will Deacon
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/atomic.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index 20b7dc17979e..03484cb4d16d 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -23,13 +23,21 @@
#define atomic_set(v, i) (((v)->counter) = (i))
+#ifdef CONFIG_ISA_ARCV2
+#define PREFETCHW " prefetchw [%1]\n"
+#else
+#define PREFETCHW
+#endif
+
#define ATOMIC_OP(op, c_op, asm_op)\
static inline void atomic_##op(int i, atomic_t *v) \
{ \
unsigned int temp; \
\
__asm__ __volatile__( \
- "1: llock %0, [%1]\n" \
+ "1: \n" \
+ PREFETCHW \
+ " llock %0, [%1]\n" \
" " #asm_op " %0, %0, %2 \n" \
" scond %0, [%1]\n" \
" bnz 1b \n" \
@@ -50,7 +58,9 @@ static inline int atomic_##op##_return(int i, atomic_t *v)
\
smp_mb(); \
\
__asm__ __volatile__( \
- "1: llock %0, [%1]\n" \
+ "1: \n" \
+ PREFETCHW \
+ " llock %0, [%1]\n" \
" " #asm_op " %0, %0, %2 \n" \
" scond %0, [%1]\n" \
" bnz 1b \n" \
--
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 v9 2/4] sched: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner, and it is still followed by this rewrite. This
rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the codes as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics. As a
result, we have less load tracking overhead, better performance, and
especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du
---
include/linux/sched.h | 40 ++--
kernel/sched/core.c | 3 -
kernel/sched/debug.c | 41 ++--
kernel/sched/fair.c | 630 +-
kernel/sched/sched.h | 28 +--
5 files changed, 249 insertions(+), 493 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index af0eeba..8b4bc4f 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1183,29 +1183,23 @@ struct load_weight {
u32 inv_weight;
};
+/*
+ * The load_avg/util_avg represents an infinite geometric series:
+ * 1) load_avg describes the amount of time that a sched_entity
+ * is runnable on a rq. It is based on both load_sum and the
+ * weight of the task.
+ * 2) util_avg describes the amount of time that a sched_entity
+ * is running on a CPU. It is based on util_sum and is scaled
+ * in the range [0..SCHED_LOAD_SCALE].
+ * The 64 bit load_sum can:
+ * 1) for cfs_rq, afford 4353082796 (=2^64/47742/88761) entities with
+ * the highest weight (=88761) always runnable, we should not overflow
+ * 2) for entity, support any load.weight always runnable
+ */
struct sched_avg {
- u64 last_runnable_update;
- s64 decay_count;
- /*
-* utilization_avg_contrib describes the amount of time that a
-* sched_entity is running on a CPU. It is based on running_avg_sum
-* and is scaled in the range [0..SCHED_LOAD_SCALE].
-* load_avg_contrib described the amount of time that a sched_entity
-* is runnable on a rq. It is based on both runnable_avg_sum and the
-
[PATCH v9 0/4] sched: Rewrite runnable load and utilization average tracking
Hi Peter and Ingo,
The 9th version has the following changes, would you please give it a look?
1) util_avg fix
2) update_tg_load_avg() in update_blocked_averages(), because
cfs_rq's load_avg is updated
3) Add some debug print
Thanks to Boqun for his tests and thoughts. Thanks to Dietmar for the
suggestions.
Thanks,
Yuyang
v8 changes:
Changes are made for the 8th version:
1) Rebase to the latest tip tree
2) scale_load_down the weight when doing the averages
3) change util_sum to u32
Thanks a lot for Ben's comments, which lead to this version.
Thanks to Vincent for review.
v7 changes:
The 7th version mostly is to accommodate the utilization load average recently
merged into kernel. The general idea is as well to update the cfs_rq as a whole
as opposed to only updating an entity at a time and update the cfs_rq with the
only updated entity.
1) Rename utilization_load_avg to util_avg to be concise and meaningful
2) To track the cfs_rq util_avg, simply use "cfs_rq->curr != NULL" as the
predicate. This should be equivalent to but simpler than aggregating each
individual child sched_entity's util_avg when "cfs_rq->curr == se". Because
if cfs_rq->curr != NULL, the cfs_rq->curr has to be some se.
3) Remove se's util_avg from its cfs_rq's when migrating it, this was already
proposed by Morten and patches sent
3) The group entity's load average is initiated when the entity is created
4) Small nits: the entity's util_avg is removed from switched_from_fair()
and task_move_group_fair().
Thanks a lot for Vincent and Morten's help for the 7th version.
Thanks,
Yuyang
v6 changes:
Many thanks to PeterZ for his review, to Dietmar, and to Fengguang for 0Day and
LKP.
Rebased on v3.18-rc2.
- Unify decay_load 32 and 64 bits by mul_u64_u32_shr
- Add force option in update_tg_load_avg
- Read real-time cfs's load_avg for calc_tg_weight
- Have tg_load_avg_contrib ifdef CONFIG_FAIR_GROUP_SCHED
- Bug fix
v5 changes:
Thank Peter intensively for reviewing this patchset in detail and all his
comments.
And Mike for general and cgroup pipe-test. Morten, Ben, and Vincent in the
discussion.
- Remove dead task and task group load_avg
- Do not update trivial delta to task_group load_avg (threshold 1/64
old_contrib)
- mul_u64_u32_shr() is used in decay_load, so on 64bit, load_sum can afford
about 4353082796 (=2^64/47742/88761) entities with the highest weight (=88761)
always runnable, greater than previous theoretical maximum 132845
- Various code efficiency and style changes
We carried out some performance tests (thanks to Fengguang and his LKP). The
results
are shown as follows. The patchset (including threepatches) is on top of
mainline
v3.16-rc5. We may report more perf numbers later.
Overall, this rewrite has better performance, and reduced net overhead in load
average tracking, flat efficiency in multi-layer cgroup pipe-test.
v4 changes:
Thanks to Morten, Ben, and Fengguang for v4 revision.
- Insert memory barrier before writing cfs_rq->load_last_update_copy.
- Fix typos.
v3 changes:
Many thanks to Ben for v3 revision.
Regarding the overflow issue, we now have for both entity and cfs_rq:
struct sched_avg {
.
u64 load_sum;
unsigned long load_avg;
.
};
Given the weight for both entity and cfs_rq is:
struct load_weight {
unsigned long weight;
.
};
So, load_sum's max is 47742 * load.weight (which is unsigned long), then on
32bit,
it is absolutly safe. On 64bit, with unsigned long being 64bit, but we can
afford
about 4353082796 (=2^64/47742/88761) entities with the highest weight (=88761)
always runnable, even considering we may multiply 1<<15 in decay_load64, we can
still support 132845 (=4353082796/2^15) always runnable, which should be
acceptible.
load_avg = load_sum / 47742 = load.weight (which is unsigned long), so it
should be
perfectly safe for both entity (even with arbitrary user group share) and
cfs_rq on
both 32bit and 64bit. Originally, we saved this division, but have to get it
back
because of the overflow issue on 32bit (actually load average itself is safe
from
overflow, but the rest of the code referencing it always uses long, such as
cpu_load,
etc., which prevents it from saving).
- Fix overflow issue both for entity and cfs_rq on both 32bit and 64bit.
- Track all entities (both task and group entity) due to group entity's clock
issue.
This actually improves code simplicity.
- Make a copy of cfs_rq sched_avg's last_update_time, to read an intact 64bit
variable on 32bit machine when in data race (hope I did it right).
- Minor fixes and code improvement.
v2 changes:
Thanks to PeterZ and Ben for their help in fixing the issues and improving
the quality, and Fengguang and his 0Day in finding compile errors in different
configurations for version 2.
- Batch update the tg->load_avg, making sure it is up-to-date before
update_cfs_shares
- Remove migrating task from the old CPU/cfs_rq, and do so with atomic
operations
Yuyang Du (4)
Re: [PATCH v2 11/15] KVM: MTRR: sort variable MTRRs
On 23/06/2015 04:29, Xiao Guangrong wrote: >>> >>> >>> If so, can you look at kvm/queue and see if it is okay for you (so that >>> we can get the series in 4.2)? >> >> Ping? >> >> If I don't get testing results before Wednesday, I'll drop this series >> from the 4.2 pull request. > > Paolo, sorry for the delay. Your changes are good to me. Thanks! Is this a Tested-by? :) Paolo -- 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 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
On Mon, 2015-06-22 at 16:43 +0100, Lee Jones wrote:
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> +config ARM_ST_CPUFREQ
> +>> bool "ST CPUFreq support"
> +>> depends on SOC_STIH407
> +>> help
> +>> OPP list for cpufreq-dt driver can be provided through DT or can be
> +>> created at runtime. Select this if you want create OPP list at
> runtime.
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> +obj-$(CONFIG_ARM_ST_CPUFREQ) += st-cpufreq.o
> --- /dev/null
> +++ b/drivers/cpufreq/st-cpufreq.c
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> +#include
> +MODULE_DEVICE_TABLE(of, sti_cpufreq_of_match);
>
> +module_platform_driver(sti_cpufreq);
>
> +MODULE_AUTHOR("Ajitpal Singh ");
> +MODULE_DESCRIPTION("Creates an OPP list for cpufreq-cpu0 at runtime");
> +MODULE_LICENSE("GPL v2");
(There's a mismatch between the license used in the comment at the top
of this file and the ident used in the MODULE_LICENSE() macro. See
include/linux/module.h.)
st-cpufreq.o can only be built-in. But the code contains of few lines
that are only useful if the code can be modular. Was ARM_ST_CPUFREQ
perhaps meant to be tristate?
Thanks,
Paul Bolle
--
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 v9 3/4] sched: Init cfs_rq's sched_entity load average
The runnable load and utilization averages of cfs_rq's sched_entity
were not initiated. Like done to a task, give new cfs_rq' sched_entity
start values to heavy its load in infant time.
Signed-off-by: Yuyang Du
---
kernel/sched/core.c | 2 +-
kernel/sched/fair.c | 11 ++-
kernel/sched/sched.h | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4dfab27..2d4c597 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2112,7 +2112,7 @@ void wake_up_new_task(struct task_struct *p)
#endif
/* Initialize new task's runnable average */
- init_task_runnable_average(p);
+ init_entity_runnable_average(&p->se);
rq = __task_rq_lock(p);
activate_task(rq, p, 0);
p->on_rq = TASK_ON_RQ_QUEUED;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 452c932..c1772bf 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -672,10 +672,10 @@ static unsigned long task_h_load(struct task_struct *p);
#define LOAD_AVG_MAX 47742 /* maximum possible load avg */
#define LOAD_AVG_MAX_N 345 /* number of full periods to produce LOAD_MAX_AVG */
-/* Give new task start runnable values to heavy its load in infant time */
-void init_task_runnable_average(struct task_struct *p)
+/* Give new sched_entity start runnable values to heavy its load in infant
time */
+void init_entity_runnable_average(struct sched_entity *se)
{
- struct sched_avg *sa = &p->se.avg;
+ struct sched_avg *sa = &se->avg;
sa->last_update_time = 0;
/*
@@ -684,14 +684,14 @@ void init_task_runnable_average(struct task_struct *p)
* will definitely be update (after enqueue).
*/
sa->period_contrib = 1023;
- sa->load_avg = scale_load_down(p->se.load.weight);
+ sa->load_avg = scale_load_down(se->load.weight);
sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
sa->util_avg = scale_load_down(SCHED_LOAD_SCALE);
sa->util_sum = LOAD_AVG_MAX;
/* when this task enqueue'ed, it will contribute to its cfs_rq's
load_avg */
}
#else
-void init_task_runnable_average(struct task_struct *p)
+void init_entity_runnable_average(struct sched_entity *se)
{
}
#endif
@@ -8055,6 +8055,7 @@ int alloc_fair_sched_group(struct task_group *tg, struct
task_group *parent)
init_cfs_rq(cfs_rq);
init_tg_cfs_entry(tg, cfs_rq, se, i, parent->se[i]);
+ init_entity_runnable_average(se);
}
return 1;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 3dfec8d..f2b17ea 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1293,7 +1293,7 @@ extern void init_dl_task_timer(struct sched_dl_entity
*dl_se);
unsigned long to_ratio(u64 period, u64 runtime);
-extern void init_task_runnable_average(struct task_struct *p);
+extern void init_entity_runnable_average(struct sched_entity *se);
static inline void add_nr_running(struct rq *rq, unsigned count)
{
--
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 v9 4/4] sched: Remove task and group entity load when they are dead
When task exits or group is destroyed, the entity's load should be
removed from its parent cfs_rq's load. Otherwise, it will take time
for the parent cfs_rq to decay the dead entity's load to 0, which
is not desired.
Signed-off-by: Yuyang Du
---
kernel/sched/fair.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c1772bf..931d911 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4919,6 +4919,11 @@ static void migrate_task_rq_fair(struct task_struct *p,
int next_cpu)
/* We have migrated, no longer consider this task hot */
p->se.exec_start = 0;
}
+
+static void task_dead_fair(struct task_struct *p)
+{
+ remove_entity_load_avg(&p->se);
+}
#endif /* CONFIG_SMP */
static unsigned long
@@ -8017,8 +8022,11 @@ void free_fair_sched_group(struct task_group *tg)
for_each_possible_cpu(i) {
if (tg->cfs_rq)
kfree(tg->cfs_rq[i]);
- if (tg->se)
+ if (tg->se) {
+ if (tg->se[i])
+ remove_entity_load_avg(tg->se[i]);
kfree(tg->se[i]);
+ }
}
kfree(tg->cfs_rq);
@@ -8205,6 +8213,7 @@ const struct sched_class fair_sched_class = {
.rq_offline = rq_offline_fair,
.task_waking= task_waking_fair,
+ .task_dead = task_dead_fair,
#endif
.set_curr_task = set_curr_task_fair,
--
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 v9 1/4] sched: Remove rq's runnable avg
The per-rq runnable averages (rq->avg) was introduced by Ben with this commit:
commit 18bf2805d9b30cb823d4919b42cd230f59c7ce1f
Author: Ben Segall
Date: Thu Oct 4 12:51:20 2012 +0200
sched: Maintain per-rq runnable averages
Since runqueues do not have a corresponding sched_entity we instead embed a
sched_avg structure directly.
Signed-off-by: Ben Segall
Reviewed-by: Paul Turner
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/20120823141506.442637...@google.com
Signed-off-by: Ingo Molnar
With CONFIG_FAIR_GROUP_SCHED=y, the rq->avg (runnable_avg_sum, avg_period) is
used to calc the contrib in __update_tg_runnable_avg() for the root group.
But the root group's load data is never consumed since its merge into kernel
in 2012. The basic reason is we have just one root group, and it is
meaningless to give it weight. As the extra code is in the scheduler's
hot path, so it is better to remove it.
Signed-off-by: Yuyang Du
---
kernel/sched/debug.c | 7 +--
kernel/sched/fair.c | 25 -
kernel/sched/sched.h | 2 --
3 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index f94724e..ca39cb7 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -68,13 +68,8 @@ static void print_cfs_group_stats(struct seq_file *m, int
cpu, struct task_group
#define PN(F) \
SEQ_printf(m, " .%-30s: %lld.%06ld\n", #F, SPLIT_NS((long long)F))
- if (!se) {
- struct sched_avg *avg = &cpu_rq(cpu)->avg;
- P(avg->runnable_avg_sum);
- P(avg->avg_period);
+ if (!se)
return;
- }
-
PN(se->exec_start);
PN(se->vruntime);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 40a7fcb..7922532 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2728,19 +2728,12 @@ static inline void __update_group_entity_contrib(struct
sched_entity *se)
}
}
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
-{
- __update_entity_runnable_avg(rq_clock_task(rq), cpu_of(rq), &rq->avg,
- runnable, runnable);
- __update_tg_runnable_avg(&rq->avg, &rq->cfs);
-}
#else /* CONFIG_FAIR_GROUP_SCHED */
static inline void __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
int force_update) {}
static inline void __update_tg_runnable_avg(struct sched_avg *sa,
struct cfs_rq *cfs_rq) {}
static inline void __update_group_entity_contrib(struct sched_entity *se) {}
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable) {}
#endif /* CONFIG_FAIR_GROUP_SCHED */
static inline void __update_task_entity_contrib(struct sched_entity *se)
@@ -2944,7 +2937,6 @@ static inline void dequeue_entity_load_avg(struct cfs_rq
*cfs_rq,
*/
void idle_enter_fair(struct rq *this_rq)
{
- update_rq_runnable_avg(this_rq, 1);
}
/*
@@ -2954,7 +2946,6 @@ void idle_enter_fair(struct rq *this_rq)
*/
void idle_exit_fair(struct rq *this_rq)
{
- update_rq_runnable_avg(this_rq, 0);
}
static int idle_balance(struct rq *this_rq);
@@ -2963,7 +2954,6 @@ static int idle_balance(struct rq *this_rq);
static inline void update_entity_load_avg(struct sched_entity *se,
int update_cfs_rq) {}
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable) {}
static inline void enqueue_entity_load_avg(struct cfs_rq *cfs_rq,
struct sched_entity *se,
int wakeup) {}
@@ -4262,10 +4252,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p,
int flags)
update_entity_load_avg(se, 1);
}
- if (!se) {
- update_rq_runnable_avg(rq, rq->nr_running);
+ if (!se)
add_nr_running(rq, 1);
- }
+
hrtick_update(rq);
}
@@ -4323,10 +4312,9 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
update_entity_load_avg(se, 1);
}
- if (!se) {
+ if (!se)
sub_nr_running(rq, 1);
- update_rq_runnable_avg(rq, 1);
- }
+
hrtick_update(rq);
}
@@ -6034,9 +6022,6 @@ static void __update_blocked_averages_cpu(struct
task_group *tg, int cpu)
*/
if (!se->avg.runnable_avg_sum && !cfs_rq->nr_running)
list_del_leaf_cfs_rq(cfs_rq);
- } else {
- struct rq *rq = rq_of(cfs_rq);
- update_rq_runnable_avg(rq, rq->nr_running);
}
}
@@ -8020,8 +8005,6 @@ static void task_tick_fair(struct rq *rq, struct
task_struct *curr, int queued)
if (numabalancing_enabled)
task_tick_numa(rq, curr);
-
- update_rq_runnable_avg(rq, 1);
}
/*
dif
Re: [PATCH] drivers: staging: rtl8192u: Fix "space required before the open parenthesis '('" errors
On Mon, Jun 22, 2015 at 06:25:11AM -0500, Greg Donald wrote: > Umm.. you have to fix more than one error if there's more than one > error on or very near the same line you are already fixing, else > checkpatch.pl complains that your patch has errors. Not to mention > Greg KH has never complained: > > http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/log/?qt=grep&q=gdonald > Actually, Greg complains about these all the time. And here is a useless URL that you can look at: http://slashdot.org I'm sure it supports my argument. But seriously, he does complain about these. 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: [BUG] ohci_enable() fails during resume
Lukasz Stelmach wrote: > A bit, suddenly by desktop PC started to fail to resume. [...] > The failing code is somewhere around line 2400 of > drivers/firewire/ohci.c (the latest mainline). >0x003f <+31>: callq 0xb037 >0x0044 <+36>: mov0x898(%rbx),%rax > -->0x004b <+43>: mov(%rax),%edx <-- (The copy_config_rom call was not actually executed; the else branch jumped to 44.) ohci->next_config_rom is NULL because ohci->config_rom is NULL. > The code around the line 2400 appears to handle multiple > firewire ports (if I recognise variable names correctly, e.g. > next_config_rom). No, this code handles multiple versions of the same data structure. > Hardware bug in the on-board firewire controller *and* a bug in the > driver. Indeed; this appears to be the culprit: > [ 232.855042] firewire_ohci :04:03.0: added OHCI v1.0 device as card 0, > 8 IR + 8 IT contexts, quirks 0x0 > [ 232.864724] firewire_ohci :04:03.0: bad self ID 0/1 ( != > ~) With the "bad self ID", bus_reset_work() just aborts, and the controller is never completely initialized (therefore the unexpected NULL). Try unloading and reloading the firewire-ohci module to see if you can ever avoid the "bad self ID" error. But if it stays, your hardware indeed appears to be broken. Regards, Clemens -- 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 Monday 22 June 2015 07:06 PM, Will Deacon wrote:
>> OK, so given that regular/mmio is also weakly ordered, it would seem that we
>> need
>> > full mb() *before* and *after* the IO access in the non relaxed API. ARM
>> > code
>> > seems to put a rmb() after the readl and wmb() before the writel. Is that
>> > based on
>> > how h/w provides for some ?
> We figured that you'd likely be doing something like:
>
>
>
>
> or:
>
>
>
>
> so ended up with writel doing {wmb(); writel_relaxed} and readl doing
> {readl_relaxed; rmb()}.
>
>> > In one of the links you posted above, Catalin posed the same question, but
>> > I
>> > didn't see response to that.
>> >
>> > | If we are to make the writel/readl on ARM fully ordered with both IO
>> > | (enforced by hardware) and uncached memory, do we add barriers on each
>> > | side of the writel/readl etc.? The common cases would require a barrier
>> > | before writel (write buffer flushing) and a barrier after readl (in case
>> > | of polling for a "DMA complete" state).
>> > |
>> > | So if io_wmb() just orders to IO writes (writel_relaxed), does it mean
>> > | that we still need a mighty wmb() that orders any type of accesses (i.e.
>> > | uncached memory vs IO)? Can drivers not use the strict writel() and no
>> > | longer rely on wmb() (wondering whether we could simplify it on ARM with
>> > | fully ordered IO accessors)?
>> >
>> > Further readl/writel would be no different than ioread32/iowrite32 ?
> ioread32/iowrite32 can be used with port addresses and dispatch to the
> relevant accessors depending on that. The memory ordering semantics should
> be the same as readl/writel.
>
>> > FWIW, h/w folks tell me that DMB guarentess local barrier semantics so we
>> > don't
>> > need to use DSYNC. Latter only provides full r+w+TLB/BPU stuff while DMB
>> > allows
>> > finer grained r/w/r+w. But if we need full mb then using one vs. other
>> > becomes a
>> > moot point.
> I'd say go with what we do on ARM/arm64, then at least we have consistency
> in the use of barriers.
Thx for very helpful review/feedback Will. I've posted a v2 !
-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 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
On 23-06-15, 08:16, Lee Jones wrote:
> Thanks for your timely review Viresh.
Your welcome Lee :)
> On Tue, 23 Jun 2015, Viresh Kumar wrote:
> > On 22-06-15, 16:43, Lee Jones wrote:
> > > +config ARM_ST_CPUFREQ
> > > + bool "ST CPUFreq support"
> >
> > Isn't using ST just too generic? There are multiple SoCs ST has been
> > involved with, I have worked on a completely different series.
> > Probably a more relative string is required here, like stih407 ?
>
> This is ST's only CPUFreq implementation and is pretty board
> agnostic. This particular driver only currently supports the STiH407
> family, but internally it supports some others too. I'll have a chat
> and see if we can make it more specific somehow.
So, SPEAr is also from ST. And it already have a driver for itself.
> > > + if (!ddata->dvfs_tab_count) {
> > > + dev_err(&pdev->dev, "No suitable AVS table found\n");
> >
> > Why is this an error? I thought in this case you will go ahead with
> > the normal OPP-table.
>
> I've written it so it's an error within this function, as it makes the
> function fail, but is downgraded by the caller to a warning and
> gracefully bypassed to still allow frequency scaling.
Not that, I was asking about the print. I thought we will still try to
find OPP from the CPU node and a warning or a error might not be the
right choice. You can surely add a debug print. Currently you are
doing a dev_err() here, followed by a dev_warn() I think..
> > So you have added new OPPs here, but cpufreq-dt will try to add old
> > OPPs. You must be getting lots of warnings ?
>
> Yes, we recieve the 'duplicate OPPs detected' warning, but there is
> nothing we can do about that.
:)
OPP-v2 will get that solved too..
> > > + if (ddata->substrate < 0)
> > > + goto set_default;
> >
> > Maybe:
> >
> > if (ddata->substrate >= 0)
> > return;
>
> 0 is a valid substrate value.
I had >= in the comparison. Wasn't that right?
And I was just suggesting that a single return can be used instead of
if (xyz)
goto set_default;
return;
--
viresh
--
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: staging patch not in staging tree (was: Re: [PATCH 1/2] staging: ft1000-usb: fixed table alignment)
On Tue, Jun 23, 2015 at 11:03:34AM +0530, Sudip Mukherjee wrote:
> On Mon, Jun 22, 2015 at 07:06:49PM +0530, Sudip Mukherjee wrote:
> > On Mon, Jun 22, 2015 at 03:02:37PM +0200, Peter Karlsson wrote:
> > > On 2015-06-22 06:29, Sudip Mukherjee wrote:
> > > > which tree have you been using?
> > > > Greg will have three staging tree, use staging-testing
> > >
> > > I have used linux-next tree :/
> > well, I am now confused why linux-next is not having this struct.
> > at line 415 of drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
> > struct timeval tv; is there in staging-next. And today's linux-next
> > has merged staging-next. Then how that struct timeval is not there in
> > linux-next ?
>
> I was doing a bisect to see why the files are differing in staging-next
> and linux-next. And it turns out to be:
> 8b37bf430656 ("staging: ft1000: Replace timeval and time_t with time64_t")
>
> which didn't go through the staging tree.
>
It's going through Arnd's tree since he does time stuff. He should have
sent it for an Ack or something. Maybe he is planning to do that later.
The patch is very old.
Not a big deal?
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 v2 2/4] sched:Consider imbalance_pct when comparing loads in numa_has_capacity
* Srikar Dronamraju wrote: > * Rik van Riel [2015-06-16 10:39:13]: > > > On 06/16/2015 07:56 AM, Srikar Dronamraju wrote: > > > This is consistent with all other load balancing instances where we > > > absorb unfairness upto env->imbalance_pct. Absorbing unfairness upto > > > env->imbalance_pct allows to pull and retain task to their preferred > > > nodes. > > > > > > Signed-off-by: Srikar Dronamraju > > > > How does this work with other workloads, eg. > > single instance SPECjbb2005, or two SPECjbb2005 > > instances on a four node system? > > > > Is the load still balanced evenly between nodes > > with this patch? > > > > Yes, I have looked at mpstat logs while running SPECjbb2005 for 1JVMper > System, 2 JVMs per System and 4 JVMs per System and observed that the > load spreading was similar with and without this patch. > > Also I have visualized using htop when running 0.5X (i.e 48 threads on > 96 cpu system) cpu stress workloads to see that the spread is similar > before and after the patch. > > Please let me know if there are any better ways to observe the > spread. [...] There are. I see you are using prehistoric tooling, but see the various NUMA convergence latency measurement utilities in 'perf bench numa': triton:~/tip> perf bench numa mem -h # Running 'numa/mem' benchmark: # Running main, "perf bench numa numa-mem -h" usage: perf bench numa -p, --nr_proc number of processes -t, --nr_threads number of threads per process -G, --mb_global global memory (MBs) -P, --mb_proc process memory (MBs) -L, --mb_proc_locked process serialized/locked memory access (MBs), <= process_memory -T, --mb_thread thread memory (MBs) -l, --nr_loops max number of loops to run -s, --nr_secs max number of seconds to run -u, --usleep usecs to sleep per loop iteration -R, --data_reads access the data via writes (can be mixed with -W) -W, --data_writes access the data via writes (can be mixed with -R) -B, --data_backwards access the data backwards as well -Z, --data_zero_memset access the data via glibc bzero only -r, --data_rand_walk access the data with random (32bit LFSR) walk -z, --init_zero bzero the initial allocations -I, --init_random randomize the contents of the initial allocations -0, --init_cpu0 do the initial allocations on CPU#0 -x, --perturb_secs perturb thread 0/0 every X secs, to test convergence stability -d, --show_detailsShow details -a, --all Run all tests in the suite -H, --thp MADV_NOHUGEPAGE < 0 < MADV_HUGEPAGE -c, --show_convergence show convergence details -m, --measure_convergence measure convergence latency -q, --quiet quiet mode -S, --serialize-startup serialize thread startup -C, --cpus bind the first N tasks to these specific cpus (the rest is unbound) -M, --memnodes bind the first N tasks to these specific memory nodes (the rest is unbound) '-m' will measure convergence. '-c' will visualize it. '--thp' can be used to turn hugepages on/off For example you can create a 'numa02' work-alike by doing: vega:~> cat numa02 #!/bin/bash perf bench numa mem --no-data_rand_walk -p 1 -t 32 -G 0 -P 0 -T 32 -l 800 -zZ0c $@ this perf bench numa command mimics numa02 pretty exactly on a 32 CPU system. This will run it in a loop: vega:~> cat numa02-loop while :; do ./numa02 2>&1 | grep runtime-max/thread sleep 1 done Or here are various numa01 work-alikes: vega:~> cat numa01 perf bench numa mem --no-data_rand_walk -p 2 -t 16 -G 0 -P 3072 -T 0 -l 50 -zZ0c $@ vega:~> cat numa01-hard-bind ./numa01 --cpus=0-16_16x16#16 --memnodes=0x16,2x16 or numa01-thread-alloc: vega:~> cat numa01-THREAD_ALLOC perf bench numa mem --no-data_rand_walk -p 2 -t 16 -G 0 -P 0 -T 192 -l 1000 -zZ0c $@ You can generate very flexible setups of NUMA access patterns, and measure their behavior accurately. It's all so much more capable and more flexible than autonumabench ... Also, when you are trying to report numbers for multiple runs, please use something like: perf stat --null --repeat 3 ... This will run the workload 3 times (doing only time measurement) and report the stddev in a human readable form. 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/
[PATCH v4] powerpc/rcpm: add RCPM driver
From: Tang Yuantian
There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.
The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.
Signed-off-by: Chenhui Zhao
Signed-off-by: Tang Yuantian
---
v4:
- refine bindings document
v3:
- added static and __init modifier to fsl_rcpm_init
v2:
- fix code style issues
- refine compatible string match part
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 42 +++
arch/powerpc/include/asm/fsl_guts.h| 105 +++
arch/powerpc/include/asm/fsl_pm.h | 48 +++
arch/powerpc/platforms/85xx/Kconfig| 1 +
arch/powerpc/sysdev/Kconfig| 5 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_rcpm.c | 338 +
7 files changed, 540 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
create mode 100644 arch/powerpc/include/asm/fsl_pm.h
create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
new file mode 100644
index 000..1f58018
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -0,0 +1,42 @@
+* Run Control and Power Management
+
+The RCPM performs all device-level tasks associated with device run control
+and power management.
+
+Required properites:
+ - reg : Offset and length of the register set of RCPM block.
+ - compatible : Sould contain a chip-specific RCPM block compatible string
+ and (if applicable) may contain a chassis-version RCPM compatible
string.
+ Chip-specific strings are of the form "fsl,-rcpm", such as:
+ * "fsl,p2041-rcpm"
+ * "fsl,p3041-rcpm"
+ * "fsl,p4080-rcpm"
+ * "fsl,p5020-rcpm"
+ * "fsl,p5040-rcpm"
+ * "fsl,t4240-rcpm"
+ * "fsl,b4420-rcpm"
+ * "fsl,b4860-rcpm"
+
+ Chassis-version RCPM strings include:
+ * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
+ * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
+
+All references to "1.0" and "2.0" refer to the QorIQ chassis version to
+which the chip complies.
+Chassis VersionExample Chips
+------
+1.0p4080, p5020, p5040, p2041, p3041
+2.0t4240, b4860, t1040, b4420
+
+Example:
+The RCPM node for T4240:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
+ reg = <0xe2000 0x1000>;
+ };
+
+The RCPM node for P4080:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,qoriq-rcpm-1.0";
+ reg = <0xe2000 0x1000>;
+ };
diff --git a/arch/powerpc/include/asm/fsl_guts.h
b/arch/powerpc/include/asm/fsl_guts.h
index 43b6bb1..a67413c 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -188,5 +188,110 @@ static inline void guts_set_pmuxcr_dma(struct ccsr_guts
__iomem *guts,
#endif
+struct ccsr_rcpm_v1 {
+ u8 res[4];
+ __be32 cdozsr; /* 0x0004 Core Doze Status Register */
+ u8 res0008[4];
+ __be32 cdozcr; /* 0x000c Core Doze Control Register */
+ u8 res0010[4];
+ __be32 cnapsr; /* 0x0014 Core Nap Status Register */
+ u8 res0018[4];
+ __be32 cnapcr; /* 0x001c Core Nap Control Register */
+ u8 res0020[4];
+ __be32 cdozpsr;/* 0x0024 Core Doze Previous Status Register */
+ u8 res0028[4];
+ __be32 cnappsr;/* 0x002c Core Nap Previous Status Register */
+ u8 res0030[4];
+ __be32 cwaitsr;/* 0x0034 Core Wait Status Register */
+ u8 res0038[4];
+ __be32 cwdtdsr;/* 0x003c Core Watchdog Detect Status Register */
+ __be32 powmgtcsr; /* 0x0040 PM Control&Status Register */
+#define RCPM_POWMGTCSR_SLP 0x0002
+ u8 res0044[12];
+ __be32 ippdexpcr; /* 0x0050 IP Powerdown Exception Control Register */
+ u8 res0054[16];
+ __be32 cpmimr; /* 0x0064 Core PM IRQ Mask Register */
+ u8 res0068[4];
+ __be32 cpmcimr;/* 0x006c Core PM Critical IRQ Mask Register */
+ u8 res0070[4];
+ __be32 cpmmcmr;/* 0x0074 Core PM Machine Check Mask Register */
+ u8 res0078[4];
+ __be32 cpmnmimr; /* 0x007c Core PM NMI Mask Register */
+ u8 res0080[4];
+ __be32 ctbenr; /* 0x0084 Core Time Base Enable Register */
+ u8 res0088[4];
+ __be32 ctbckselr; /* 0x008c Core Time Base Clock Select Register */
+ u8 res0090[4];
+ __be32 ctbhltc
Re: staging patch not in staging tree (was: Re: [PATCH 1/2] staging: ft1000-usb: fixed table alignment)
On Tue, Jun 23, 2015 at 11:05:47AM +0300, Dan Carpenter wrote:
> On Tue, Jun 23, 2015 at 11:03:34AM +0530, Sudip Mukherjee wrote:
> > On Mon, Jun 22, 2015 at 07:06:49PM +0530, Sudip Mukherjee wrote:
> > > On Mon, Jun 22, 2015 at 03:02:37PM +0200, Peter Karlsson wrote:
> > > > On 2015-06-22 06:29, Sudip Mukherjee wrote:
> > > > > which tree have you been using?
> > > > > Greg will have three staging tree, use staging-testing
> > > >
> > > > I have used linux-next tree :/
> > > well, I am now confused why linux-next is not having this struct.
> > > at line 415 of drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
> > > struct timeval tv; is there in staging-next. And today's linux-next
> > > has merged staging-next. Then how that struct timeval is not there in
> > > linux-next ?
> >
> > I was doing a bisect to see why the files are differing in staging-next
> > and linux-next. And it turns out to be:
> > 8b37bf430656 ("staging: ft1000: Replace timeval and time_t with time64_t")
> >
> > which didn't go through the staging tree.
> >
>
> It's going through Arnd's tree since he does time stuff. He should have
> sent it for an Ack or something. Maybe he is planning to do that later.
>
> The patch is very old.
>
> Not a big deal?
there was no patch in ft1000 so its not a big deal. But will it not be
merge conflict when Linus tries to merge staging tree and Arnd's tree?
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dell-laptop: Fix allocating & freeing SMI buffer page
This commit fix kernel crash when probing for rfkill devices in dell-laptop
driver failed. Function free_page() was incorrectly used on struct page *
instead of virtual address of SMI buffer.
This commit also simplify allocating page for SMI buffer by using
__get_free_page() function instead of sequential call of functions
alloc_page() and page_address().
Signed-off-by: Pali Rohár
Acked-by: Michal Hocko
Cc: sta...@vger.kernel.org
---
drivers/platform/x86/dell-laptop.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index d688d80..2c1d5f5 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -305,7 +305,6 @@ static const struct dmi_system_id dell_quirks[] __initconst
= {
};
static struct calling_interface_buffer *buffer;
-static struct page *bufferpage;
static DEFINE_MUTEX(buffer_mutex);
static int hwswitch_state;
@@ -1896,12 +1895,11 @@ static int __init dell_init(void)
* Allocate buffer below 4GB for SMI data--only 32-bit physical addr
* is passed to SMI handler.
*/
- bufferpage = alloc_page(GFP_KERNEL | GFP_DMA32);
- if (!bufferpage) {
+ buffer = (void *)__get_free_page(GFP_KERNEL | GFP_DMA32);
+ if (!buffer) {
ret = -ENOMEM;
goto fail_buffer;
}
- buffer = page_address(bufferpage);
ret = dell_setup_rfkill();
@@ -1965,7 +1963,7 @@ fail_backlight:
cancel_delayed_work_sync(&dell_rfkill_work);
dell_cleanup_rfkill();
fail_rfkill:
- free_page((unsigned long)bufferpage);
+ free_page((unsigned long)buffer);
fail_buffer:
platform_device_del(platform_device);
fail_platform_device2:
--
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/
Linux 4.0.6 breaks my disk/lvm/filesystem setup
Hello everybody,
with Linux 4.0.5 everything was perfectly fine, Linux 4.0.6 breaks the setup
on one of my systems: Only three of my logical volumes are available, systemd
reports:
lvm2-pvscan@254:3.service: State 'stop-sigterm' timed out. Killing.
Followed by a lot of failed dependencies. The setup looks like this:
NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:00 953,9G 0 disk
|-sda18:10 1M 0 part
|-sda28:20 256M 0 part /boot/efi
|-sda38:30 7,8G 0 part
| |-vg-iso 254:00 4G 0 lvm /srv/iso
| |-vg-persist 254:10 2G 0 lvm /srv/iso/persist
| `-vg-boot 254:20 128M 0 lvm /boot
|-sda48:40 913,9G 0 part
| `-cvg 254:30 913,9G 0 crypt
| |-cvg-swap 254:40 4G 0 lvm [SWAP]
| |-cvg-root 254:5040G 0 lvm /
| |-cvg-log 254:60 1G 0 lvm /var/log
| |-cvg-home 254:70 500G 0 lvm /home
| |-cvg-vbox_win7 254:8032G 0 lvm
| |-cvg-vbox_win8 254:9032G 0 lvm
| |-cvg-git 254:10 012G 0 lvm /srv/git
| `-cvg-chroots 254:11 016G 0 lvm /var/lib/archbuild
`-sda58:5032G 0 part
Another system is just fine, the only difference is a logical volume with
btrfs (cvg-chroots). Possibly the btrfs fixes are involved?
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
pgpqKZwfozaE6.pgp
Description: OpenPGP digital signature
[GIT pull] scheduler/locking updates for 4.2
Linus,
please pull the latest sched-locking-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-locking-for-linus
These locking updates depend on the alreay merged sched/core branch:
- Lockless top waiter wakeup for rtmutex (Davidlohr)
- Reduce hash bucket lock contention for PI futexes (Sebastian)
- Documentation update (Davidlohr)
Thanks,
tglx
-->
Davidlohr Bueso (2):
locking/rtmutex: Implement lockless top-waiter wakeup
locking/rtmutex: Update stale plist comments
Sebastian Andrzej Siewior (1):
futex: Lower the lock contention on the HB lock during wake up
kernel/futex.c | 32 +--
kernel/locking/rtmutex.c| 87 ++---
kernel/locking/rtmutex_common.h | 3 ++
3 files changed, 88 insertions(+), 34 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index f9984c363e9a..a0cf6fa953de 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1117,11 +1117,14 @@ static void mark_wake_futex(struct wake_q_head *wake_q,
struct futex_q *q)
q->lock_ptr = NULL;
}
-static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *this)
+static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *this,
+struct futex_hash_bucket *hb)
{
struct task_struct *new_owner;
struct futex_pi_state *pi_state = this->pi_state;
u32 uninitialized_var(curval), newval;
+ WAKE_Q(wake_q);
+ bool deboost;
int ret = 0;
if (!pi_state)
@@ -1173,7 +1176,19 @@ static int wake_futex_pi(u32 __user *uaddr, u32 uval,
struct futex_q *this)
raw_spin_unlock_irq(&new_owner->pi_lock);
raw_spin_unlock(&pi_state->pi_mutex.wait_lock);
- rt_mutex_unlock(&pi_state->pi_mutex);
+
+ deboost = rt_mutex_futex_unlock(&pi_state->pi_mutex, &wake_q);
+
+ /*
+* First unlock HB so the waiter does not spin on it once he got woken
+* up. Second wake up the waiter before the priority is adjusted. If we
+* deboost first (and lose our higher priority), then the task might get
+* scheduled away before the wake up can take place.
+*/
+ spin_unlock(&hb->lock);
+ wake_up_q(&wake_q);
+ if (deboost)
+ rt_mutex_adjust_prio(current);
return 0;
}
@@ -2413,13 +2428,23 @@ retry:
*/
match = futex_top_waiter(hb, &key);
if (match) {
- ret = wake_futex_pi(uaddr, uval, match);
+ ret = wake_futex_pi(uaddr, uval, match, hb);
+ /*
+* In case of success wake_futex_pi dropped the hash
+* bucket lock.
+*/
+ if (!ret)
+ goto out_putkey;
/*
* The atomic access to the futex value generated a
* pagefault, so retry the user-access and the wakeup:
*/
if (ret == -EFAULT)
goto pi_faulted;
+ /*
+* wake_futex_pi has detected invalid state. Tell user
+* space.
+*/
goto out_unlock;
}
@@ -2440,6 +2465,7 @@ retry:
out_unlock:
spin_unlock(&hb->lock);
+out_putkey:
put_futex_key(&key);
return ret;
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index b025295f4966..86d4853d7b40 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -300,7 +300,7 @@ static void __rt_mutex_adjust_prio(struct task_struct *task)
* of task. We do not use the spin_xx_mutex() variants here as we are
* outside of the debug path.)
*/
-static void rt_mutex_adjust_prio(struct task_struct *task)
+void rt_mutex_adjust_prio(struct task_struct *task)
{
unsigned long flags;
@@ -624,7 +624,7 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
*/
prerequeue_top_waiter = rt_mutex_top_waiter(lock);
- /* [7] Requeue the waiter in the lock waiter list. */
+ /* [7] Requeue the waiter in the lock waiter tree. */
rt_mutex_dequeue(lock, waiter);
waiter->prio = task->prio;
rt_mutex_enqueue(lock, waiter);
@@ -662,7 +662,7 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
/*
* The waiter became the new top (highest priority)
* waiter on the lock. Replace the previous top waiter
-* in the owner tasks pi waiters list with this waiter
+* in the owner tasks pi waiters tree with this waiter
* and adjust the priority of the owner.
*/
rt_mutex_dequeue_pi(task, prerequeue_top_waiter);
@@ -673,7 +673,7 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
/*
* The waite
linux-next: Tree for Jun 23
Hi all, Changes since 20150622: The drm-exynos tree gained a build failure so I used the version from next-20150622. Non-merge commits (relative to Linus' tree): 11719 9842 files changed, 1023630 insertions(+), 237137 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 221 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 (052b398a43a7 Merge branch 'for-linus-1' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) 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 (1214c525484c m68k: Use for_each_sg()) 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 (468479e6043c packet: avoid out of bounds read in round robin fanout) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (145c0e914d2c ALSA: hda - Fix unused label skip_i915) 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 (0f57d86787d8 Linux 4.1-rc8) 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 (469d7d22cea1 Input: pixcir_i2c_ts - fix receive error) Merging crypto-current/master (fe55dfdcdfab crypto: marvell/cesa - remove COMPILE_TEST dependency) CONFLICT (content): Merge conflict in net/ipv6/esp6.c CONFLICT (content): Merge conflict in net/ipv4/esp4.c 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 (b953c0d234bc Linux 4.1) 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 (5793e273a134 ARC: intc: split into ARCompact ISA specific, common bits) Merging arm
Re: [PATCH v2 0/4] net/macb: add sama5d2 support
From: Nicolas Ferre Date: Thu, 18 Jun 2015 16:27:19 +0200 > This series is basically the support for another flavor of the GEM IP > configuration. It ended up being a series because of some little fixes made to > the binding documentation before adding the new compatibility string. ... > v2: - fix bindings > - add sama5d2 compatibility string to the binding documentation Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] clk: stm32: Add clock driver for STM32F4[23]xxx devices
On 22/06/15 23:48, Stephen Boyd wrote: On 06/10, Daniel Thompson wrote: This patchset implements a clock driver for STM32F42xxx and STM32F43xxx series devices. It supports decoding the state configured by the bootloader (PLL, clock select, bus dividers) and all the gates clocks. It does not currently support the I2S and SAI PLLs. Relies on "Add support to STMicroeletronics STM32 family" v9 by Maxime Coquelin: http://thread.gmane.org/gmane.linux.kernel/1961049 . I applied 1 and 2. Looks like #3 should go through arm-soc at some later time? Agreed (that is also the patch that must be correctly ordered w.r.t. Maxime's patches). Thanks. Daniel. -- 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 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
On 2015/06/20, 10:58 AM, "Julia Lawall" wrote:
>!x is more normal for kzalloc failure in the kernel.
While "!x" might be more normal for kzalloc(), I don't see that as an
improvement over explicitly checking against NULL, which is what kzalloc()
and other memory-allocating functions return on error.
I've found in the past that developers can introduce bugs when they treat
return values as boolean when they really aren't. I'd prefer that the
code is kept with explicit comparisons against NULL, as it is today.
Most of the cases that are now using "!x" are from your previous patches.
Cheers, Andreas
>Signed-off-by: Julia Lawall
>
>---
> drivers/staging/lustre/lustre/fid/fid_request.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff -u -p a/drivers/staging/lustre/lustre/fid/fid_request.c
>b/drivers/staging/lustre/lustre/fid/fid_request.c
>--- a/drivers/staging/lustre/lustre/fid/fid_request.c
>+++ b/drivers/staging/lustre/lustre/fid/fid_request.c
>@@ -498,11 +498,11 @@ int client_fid_init(struct obd_device *o
> int rc;
>
> cli->cl_seq = kzalloc(sizeof(*cli->cl_seq), GFP_NOFS);
>- if (cli->cl_seq == NULL)
>+ if (!cli->cl_seq)
> return -ENOMEM;
>
> prefix = kzalloc(MAX_OBD_NAME + 5, GFP_NOFS);
>- if (prefix == NULL) {
>+ if (!prefix) {
> rc = -ENOMEM;
> goto out_free_seq;
> }
>
>
Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel High Performance Data Division
--
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] trace/events: add chip name and hwirq to irq entry tracepoint
On Mon, 22 Jun 2015, Ankit Gupta wrote:
> Add chip name and hw-irq number to the trace_irq_handler_entry()
> tracepoint. When tracing interrupt events the chip-name and hw-irq
> numbers are stable and known in advance. This makes them a better
> choice as a filtering criteria for the trace buffer dump. On the
> flipside, the os-irq numbers are dynamically allocated which makes
> them difficult to use for the same purpose.
>
> Dump messages will look like:
> ...irq_handler_entry: irq=22 name=msm_serial0 domain=GIC hwirq=140
I can't see the domain name being captured/printed in the code below.
> - TP_printk("irq=%d name=%s", __entry->irq, __get_str(name))
> + TP_printk("irq=%d name=%s chip_name=%s hwirq=%ld", __entry->irq,
> + __get_str(name), show_chip_name(__entry->irq),
> + show_hwirq(__entry->irq))
> );
Thanks,
tglx
--
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 2/3] clk: stm32: Add clock driver for STM32F4[23]xxx devices
On 23/06/15 00:21, Stephen Boyd wrote: On 06/10, Daniel Thompson wrote: The driver supports decoding and statically modelling PLL state (i.e. we inherit state from bootloader) and provides support for all peripherals that support simple one-bit gated clocks. The covers all peripherals whose clocks come from the AHB, APB1 or APB2 buses. It has been tested on an STM32F429I-Discovery board. The clock counts for TIM2, USART1 and SYSTICK are all set correctly and the wall clock looks OK when checked with a stopwatch. I have also tested a prototype driver for the RNG hardware. The RNG clock is correctly enabled by the framework (also did inverse test and proved that by changing DT to configure the wrong clock bit then we observe the RNG driver to fail). Signed-off-by: Daniel Thompson Reviewed-by: Maxime Coquelin I also squashed in some sparse fixes. Please check. That was extremely generous! Thanks. The changes all eyeball OK but I'll double check things tonight just in case. Daniel. -- 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 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 23-06-15, 08:16, Lee Jones wrote:
> > Thanks for your timely review Viresh.
>
> Your welcome Lee :)
>
> > On Tue, 23 Jun 2015, Viresh Kumar wrote:
> > > On 22-06-15, 16:43, Lee Jones wrote:
> > > > +config ARM_ST_CPUFREQ
> > > > + bool "ST CPUFreq support"
> > >
> > > Isn't using ST just too generic? There are multiple SoCs ST has been
> > > involved with, I have worked on a completely different series.
> > > Probably a more relative string is required here, like stih407 ?
> >
> > This is ST's only CPUFreq implementation and is pretty board
> > agnostic. This particular driver only currently supports the STiH407
> > family, but internally it supports some others too. I'll have a chat
> > and see if we can make it more specific somehow.
>
> So, SPEAr is also from ST. And it already have a driver for itself.
Sure. I will use STI as suggested by Maxime.
> > > > + if (!ddata->dvfs_tab_count) {
> > > > + dev_err(&pdev->dev, "No suitable AVS table found\n");
> > >
> > > Why is this an error? I thought in this case you will go ahead with
> > > the normal OPP-table.
> >
> > I've written it so it's an error within this function, as it makes the
> > function fail, but is downgraded by the caller to a warning and
> > gracefully bypassed to still allow frequency scaling.
>
> Not that, I was asking about the print. I thought we will still try to
> find OPP from the CPU node and a warning or a error might not be the
> right choice. You can surely add a debug print. Currently you are
> doing a dev_err() here, followed by a dev_warn() I think..
Okay, but the reasoning is the same. I consider the function to have
failed, but the over-all failure culminates in just a warning that
voltage scaling has indeed failed, but we can still go on with
frequency scaling.
Unless his is a big blocker for you, I would like to keep these
semantics.
> > > So you have added new OPPs here, but cpufreq-dt will try to add old
> > > OPPs. You must be getting lots of warnings ?
> >
> > Yes, we recieve the 'duplicate OPPs detected' warning, but there is
> > nothing we can do about that.
>
> :)
>
> OPP-v2 will get that solved too..
I'll take another look at them to see if there is anything we can
use.
> > > > + if (ddata->substrate < 0)
> > > > + goto set_default;
> > >
> > > Maybe:
> > >
> > > if (ddata->substrate >= 0)
> > > return;
> >
> > 0 is a valid substrate value.
>
> I had >= in the comparison. Wasn't that right?
Oh, you reversed the condition, I see now.
> And I was just suggesting that a single return can be used instead of
So technically you are correct, but it makes the code slightly more
confusing IMHO. Yes, it's one more line of code, but it's worth it to
add clarity.
> if (xyz)
> goto set_default;
> return;
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
On Tue, 23 Jun 2015, Paul Bolle wrote:
> On Mon, 2015-06-22 at 16:43 +0100, Lee Jones wrote:
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
>
> > +config ARM_ST_CPUFREQ
> > +> > bool "ST CPUFreq support"
> > +> > depends on SOC_STIH407
> > +> > help
> > +> > OPP list for cpufreq-dt driver can be provided through DT or can be
> > +> > created at runtime. Select this if you want create OPP list at
> > runtime.
>
>
> > --- a/drivers/cpufreq/Makefile
> > +++ b/drivers/cpufreq/Makefile
>
> > +obj-$(CONFIG_ARM_ST_CPUFREQ) += st-cpufreq.o
>
> > --- /dev/null
> > +++ b/drivers/cpufreq/st-cpufreq.c
>
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
>
> > +#include
>
> > +MODULE_DEVICE_TABLE(of, sti_cpufreq_of_match);
> >
> > +module_platform_driver(sti_cpufreq);
>
> >
> > +MODULE_AUTHOR("Ajitpal Singh ");
> > +MODULE_DESCRIPTION("Creates an OPP list for cpufreq-cpu0 at runtime");
> > +MODULE_LICENSE("GPL v2");
>
>
> (There's a mismatch between the license used in the comment at the top
> of this file and the ident used in the MODULE_LICENSE() macro. See
> include/linux/module.h.)
>
> st-cpufreq.o can only be built-in. But the code contains of few lines
> that are only useful if the code can be modular. Was ARM_ST_CPUFREQ
> perhaps meant to be tristate?
All noted. Will fix. Thanks Paul.
BTW, do you have a script that does this now, or are you still
hand-rolling these?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: lustre: LIBCFS_ALLOC
On Jun 23, 2015, at 2:23 AM, Julia Lawall wrote: > It seems that libcfs_kvzalloc doesn't use any particular threshold or > switchingbetween kzalloc and vmalloc, so can be replaced by ths function > too? If you mean to replace all instances of LIBCFS_ALLOC with libcfs_kvzalloc (and all frees with kvfree) then yes, that could be done I think. Bye, Oleg-- 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 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
On 23-06-15, 09:27, Lee Jones wrote: > Okay, but the reasoning is the same. I consider the function to have > failed, but the over-all failure culminates in just a warning that > voltage scaling has indeed failed, but we can still go on with > frequency scaling. Ahh, I thought that the other opp-table will also have voltages. > Unless his is a big blocker for you, I would like to keep these > semantics. No, the print is actually fine. > So technically you are correct, but it makes the code slightly more > confusing IMHO. Yes, it's one more line of code, but it's worth it to > add clarity. Your call :) -- viresh -- 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 11/15] KVM: MTRR: sort variable MTRRs
On 06/23/2015 04:00 PM, Paolo Bonzini wrote: On 23/06/2015 04:29, Xiao Guangrong wrote: If so, can you look at kvm/queue and see if it is okay for you (so that we can get the series in 4.2)? Ping? If I don't get testing results before Wednesday, I'll drop this series from the 4.2 pull request. Paolo, sorry for the delay. Your changes are good to me. Thanks! Is this a Tested-by? :) Yes! :) -- 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/3] locking/qrwlock: Don't contend with readers when setting _QW_WAITING
On Tue, Jun 23, 2015 at 03:57:48AM +0100, Waiman Long wrote:
> On 06/22/2015 12:21 PM, Will Deacon wrote:
> > On Fri, Jun 19, 2015 at 04:50:02PM +0100, Waiman Long wrote:
> >> The current cmpxchg() loop in setting the _QW_WAITING flag for writers
> >> in queue_write_lock_slowpath() will contend with incoming readers
> >> causing possibly extra cmpxchg() operations that are wasteful. This
> >> patch changes the code to do a byte cmpxchg() to eliminate contention
> >> with new readers.
> > [...]
> >
> >> diff --git a/arch/x86/include/asm/qrwlock.h
> >> b/arch/x86/include/asm/qrwlock.h
> >> index a8810bf..5678b0a 100644
> >> --- a/arch/x86/include/asm/qrwlock.h
> >> +++ b/arch/x86/include/asm/qrwlock.h
> >> @@ -7,8 +7,7 @@
> >> #define queued_write_unlock queued_write_unlock
> >> static inline void queued_write_unlock(struct qrwlock *lock)
> >> {
> >> -barrier();
> >> -ACCESS_ONCE(*(u8 *)&lock->cnts) = 0;
> >> + smp_store_release(&lock->wmode, 0);
> >> }
> >> #endif
> > I reckon you could actually use this in the asm-generic header and remove
> > the x86 arch version altogether. Most architectures support single-copy
> > atomic byte access and those that don't (alpha?) can just not use qrwlock
> > (or override write_unlock with atomic_sub).
> >
> > I already have a patch making this change, so I'm happy either way.
>
> Yes, I am aware of that. If you have a patch to make that change, I am
> fine with that too.
Tell you what; I'll rebase my patches on top of yours and post them after
the merge window.
Will
--
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 8/8] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 23-06-15, 08:06, Lee Jones wrote:
> > > [Adding Rob]
> >
> > Rob is not the only DT Maintainer, there are many of them. The DT
> > list was CC'ed, which they are all part of. Adding them all
> > separately is not required IMO.
>
> I didn't Cc him because you missed him, but because we have been
> discussing opp-v2 bindings recently and this was somehow related to
> that. :)
Okay, fair point.
> > > On 22-06-15, 16:43, Lee Jones wrote:
> > >
> > > At least some description was required here on why you need additional
> > > bindings are what are they.
> >
> > Sure, I can do that.
> >
> > > Over that, this patch should have been present before any other
> > > patches using these bindings.
> >
> > I've never heard that one before, but it's easy to re-order the set.
>
> I don't know, but it seems obvious to me: Bindings first and then the
> code.
Do you always write your documentation before implementing a
feature?
Surely it goes;
Requirements Gathering
Plan and Prepare
Implement
Test
Document
Deliver
;)
... but as I say, I can re-order if required. It's really not a problem.
> > > > +Required properties:
> > > > +---
> > > > +- compatible : Supported values are:
> > > > + "st,stih407-cpufreq"
> > >
> > > Nodes for virtual devices aren't allowed in DT.
> >
> > Then why do Exynos, Spear, HREF and Snowball have CPUFreq nodes?
> >
> > One rule for one ... ?
>
> Not really, but I got a bit confused now with your reply.
>
> So, what I meant when I wrote: "Nodes for virtual devices aren't
> allowed in DT", was that we aren't supposed to do something like:
>
> cpufreq {
> ...
> }
>
> in DT as cpufreq isn't a device here. A CPU is a device and that can
> contain whatever property we feel is reasonable.
>
> What SPEAr and Exyons did was putting something in the cpu-node. Not a
> node for cpufreq device itself. Couldn't find HREF and snowball's
> bindings though..
That's not what it looks like to me:
git grep -C20 "compatible.*cpufreq" -- arch
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v7] NET: Add ezchip ethernet driver
From: Noam Camus
Simple LAN device for debug or management purposes.
Device supports interrupts for RX and TX(completion).
Device does not have DMA ability.
Signed-off-by: Noam Camus
Signed-off-by: Tal Zilcer
Acked-by: Alexey Brodkin
---
Change log for v7:
1) Update nps_enet_open() comment header. (Rami Rosen)
2) fix return value of nps_enet_probe() when register_netdev() fails. (Rami
Rosen)
3) Fix Kconfig Help and add dependencies. (Paul Gortmaker)
NOTE: with new dependencies,OF && OF_NET need to be in your configuration.
Otherwise the driver will not be chosen and built.
---
.../devicetree/bindings/net/ezchip_enet.txt| 15 +
drivers/net/ethernet/Kconfig |1 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/ezchip/Kconfig| 26 +
drivers/net/ethernet/ezchip/Makefile |1 +
drivers/net/ethernet/ezchip/nps_enet.c | 658
drivers/net/ethernet/ezchip/nps_enet.h | 336 ++
7 files changed, 1038 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/ezchip_enet.txt
create mode 100644 drivers/net/ethernet/ezchip/Kconfig
create mode 100644 drivers/net/ethernet/ezchip/Makefile
create mode 100644 drivers/net/ethernet/ezchip/nps_enet.c
create mode 100644 drivers/net/ethernet/ezchip/nps_enet.h
diff --git a/Documentation/devicetree/bindings/net/ezchip_enet.txt
b/Documentation/devicetree/bindings/net/ezchip_enet.txt
new file mode 100644
index 000..4e29b2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ezchip_enet.txt
@@ -0,0 +1,15 @@
+* EZchip NPS Management Ethernet port driver
+
+Required properties:
+- compatible: Should be "ezchip,nps-mgt-enet"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the ENET interrupt
+
+Examples:
+
+ ethernet@f0003000 {
+ compatible = "ezchip,nps-mgt-enet";
+ reg = <0xf0003000 0x44>;
+ interrupts = <7>;
+ mac-address = [ 00 11 22 33 44 55 ];
+ };
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index eadcb05..1a6b1ba 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -66,6 +66,7 @@ config DNET
source "drivers/net/ethernet/dec/Kconfig"
source "drivers/net/ethernet/dlink/Kconfig"
source "drivers/net/ethernet/emulex/Kconfig"
+source "drivers/net/ethernet/ezchip/Kconfig"
source "drivers/net/ethernet/neterion/Kconfig"
source "drivers/net/ethernet/faraday/Kconfig"
source "drivers/net/ethernet/freescale/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 1367afc..489f9cc 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_NET_VENDOR_DEC) += dec/
obj-$(CONFIG_NET_VENDOR_DLINK) += dlink/
obj-$(CONFIG_NET_VENDOR_EMULEX) += emulex/
+obj-$(CONFIG_NET_VENDOR_EZCHIP) += ezchip/
obj-$(CONFIG_NET_VENDOR_EXAR) += neterion/
obj-$(CONFIG_NET_VENDOR_FARADAY) += faraday/
obj-$(CONFIG_NET_VENDOR_FREESCALE) += freescale/
diff --git a/drivers/net/ethernet/ezchip/Kconfig
b/drivers/net/ethernet/ezchip/Kconfig
new file mode 100644
index 000..48ecbc8
--- /dev/null
+++ b/drivers/net/ethernet/ezchip/Kconfig
@@ -0,0 +1,26 @@
+#
+# EZchip network device configuration
+#
+
+config NET_VENDOR_EZCHIP
+ bool "EZchip devices"
+ default y
+ ---help---
+ If you have a network (Ethernet) device belonging to this class, say
Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about EZchip devices. If you say Y, you will be asked
for
+ your specific device in the following questions.
+
+if NET_VENDOR_EZCHIP
+
+config EZCHIP_NPS_MANAGEMENT_ENET
+ tristate "EZchip NPS management enet support"
+ depends on OF_IRQ && OF_NET
+ ---help---
+ Simple LAN device for debug or management purposes.
+ Device supports interrupts for RX and TX(completion).
+ Device does not have DMA ability.
+
+endif
diff --git a/drivers/net/ethernet/ezchip/Makefile
b/drivers/net/ethernet/ezchip/Makefile
new file mode 100644
index 000..e490176
--- /dev/null
+++ b/drivers/net/ethernet/ezchip/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EZCHIP_NPS_MANAGEMENT_ENET) += nps_enet.o
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
new file mode 100644
index 000..24a85b2
--- /dev/null
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -0,0 +1,658 @@
+/*
+ * Copyright(c) 2015 EZchip Technologies.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * T
Re: [PATCH v2 20/28] ARCv2: barriers
Hi Vineet, On Tue, Jun 23, 2015 at 08:58:03AM +0100, Vineet Gupta wrote: > ARCv2 based HS38 cores are weakly ordered and thus explicit barriers for > kernel proper. > > SMP barrier is provided by DMB instruction which also guarantees local > barrier hence used as backend of smp_*mb() as well as *mb() APIs > > Also hookup barriers into MMIO accessors to avoid ordering issues in IO > > Cc: Peter Zijlstra (Intel) > Cc: Will Deacon > Signed-off-by: Vineet Gupta > --- > Changes since v1 > * Better changelog and comments > * local/mandatory barriers to NOT use DSYNC, but DMB > * define DMB based mandatory barriers even for !SMP > --- Functionally, all looks good to me. However, my comment is completely misleading ;) > +/* > + * MMIO can also get buffered/optimized in micro-arch, so barriers needed > + * Based on ARM model for the typical use case > + * > + * > + * > + * or: > + * > + * The writel_relaxed/readl_relaxed parts here would actually just be bog-standard loads and stores to an in-memory buffer. I was trying too hard to show the barrier semantics and accidentally turned the DMA buffers into __iomem regions. If you fix the comment: Reviewed-by: Will Deacon Sorry for messing you about. Will -- 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 8/8] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
Hello Lee and Viresh, On Tue, Jun 23, 2015 at 10:38 AM, Lee Jones wrote: > On Tue, 23 Jun 2015, Viresh Kumar wrote: >> On 23-06-15, 08:06, Lee Jones wrote: >> > >> > > Over that, this patch should have been present before any other >> > > patches using these bindings. >> > >> > I've never heard that one before, but it's easy to re-order the set. >> >> I don't know, but it seems obvious to me: Bindings first and then the >> code. > > Do you always write your documentation before implementing a > feature? > > Surely it goes; > Requirements Gathering > Plan and Prepare > Implement > Test > Document > Deliver > > ;) > > ... but as I say, I can re-order if required. It's really not a problem. > This is actually documented in Documentation/devicetree/bindings/submitting-patches.txt: ... 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. The rationale AFAIU is that it is easier to review the implementation of a binding after reading the DT binding doc since then you can see if the code matches what the DT binding describes. Best regards, Javier -- 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/
Formatting of /proc/meminfo
Hi! My eyes just discovered this mis-alignment for x86_64 machines: --- # cat /proc/meminfo MemTotal: 81366016 kB MemFree:36484504 kB Buffers: 1018764 kB Cached: 38230264 kB [...] VmallocTotal: 34359738367 kB VmallocUsed: 92792 kB VmallocChunk: 34359544432 kB HardwareCorrupted: 0 kB DirectMap4k:132623356 kB DirectMap2M: 0 kB --- It seems the very big numbers for "Vmalloc" are OK, so I suggest to update the formatting. The current code looks like this (/usr/src/linux/fs/proc/meminfo.c): --- seq_printf(m, "MemTotal: %8lu kB\n" "MemFree:%8lu kB\n" "Buffers:%8lu kB\n" [...] --- So the field should be widened by three digits at least (%11lu kB). Maybe one could make the field width variable, depending on 32/64 bit (it would look like a waste on 32 bit platforms). Maybe the code would be friendlier to changes if there was one seq_printf() per value. Then one could use something like seq_printf(m, "%-16s%8lu kB\n", "MemTotal:", K(i.totalram)) instead, I guess... You could put the format (%-16s%8lu kB\n) in a constant also, allowing a change at one point to affect every item... Probably gcc will optimize the code anyway, so there won't be much difference regarding performance. Regards, Ulrich Windl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/14] notifiers: Assert that RCU is watching in notify_die
* Borislav Petkov wrote: > On Mon, Jun 22, 2015 at 09:26:13AM -0700, Andy Lutomirski wrote: > > > notify_die is misnamed and has little to do with death. It's really just > > notifying about an exception, and we might end up oopsing, sending a > > signal, > > or neither. > > But if we oops and wedge solid afterwards, it might happen that only the > first > splat comes out on the console, no? And that will be the lockdep splat which > would be useless for debugging the actual problem... So I think the theory is that crashes do happen, and that any RCU warning only matters to (usually) small race windows. So by the time a difficult crash truly happens, exactly in that race window, we'd have fixed the RCU warning long ago. I.e. the placement of the RCU warning isn't really relevant in the long run, as it should not trigger. In the short run it's probably more important to have it first, because if we have that RCU race then we don't know whether we can trust anything that happens after executing the (flawed) notifier chain. Does that logic make sense to you? 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 6/8] Staging: sm750fb: ddk750_sii164.c: Place braces on previous lines
On Sat, Jun 20, 2015 at 12:54:02PM +0530, Sudip Mukherjee wrote:
> On Fri, Jun 19, 2015 at 12:48:19PM -0700, Isaac Assegai wrote:
> > Place braces on previous lines in ddk750_sii164.c to
> > rectify the following checkpatch errors:
> > ERROR: that open brace { should be on the previous line
> >
> > Signed-off-by: Isaac Assegai
> > ---
> > drivers/staging/sm750fb/ddk750_sii164.c | 16 +---
> > 1 file changed, 5 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/staging/sm750fb/ddk750_sii164.c
> > b/drivers/staging/sm750fb/ddk750_sii164.c
> > index 7f58fbe..64d4291 100644
> > --- a/drivers/staging/sm750fb/ddk750_sii164.c
> > +++ b/drivers/staging/sm750fb/ddk750_sii164.c
> > @@ -136,8 +136,7 @@ long sii164InitChip(
> > #endif
> >
> > /* Check if SII164 Chip exists */
> > - if ((sii164GetVendorID() == SII164_VENDOR_ID) && (sii164GetDeviceID()
> > == SII164_DEVICE_ID))
> > - {
> > + if ((sii164GetVendorID() == SII164_VENDOR_ID) && (sii164GetDeviceID()
> > == SII164_DEVICE_ID) {
>
>
> you have not build tested it :(
> In function ‘sii164InitChip’:
> error: expected ‘)’ before ‘{’ token
>
I never get Isaac's emails. I think gmail is still sending them to the
Spam folder? I searched my spam folder and don't see them though...
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 1/2] x86/mm/pat, drivers/infiniband/ipath: replace WARN() with pr_warn()
On Tue, Jun 23, 2015 at 12:39 AM, Ingo Molnar wrote: > Same observation as for the other patch: please only warn if the hardware is > present and the driver tries to activate. No need to annoy others. Will fix, and respin. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmaengine: imx-sdma: Add device to device support
This patch adds DEV_TO_DEV support for i.MX SDMA driver to support data
transfer between two peripheral FIFOs.
The per_2_per script requires two peripheral addresses and two DMA
requests, and it need to check the src addr and dst addr is in the SPBA
bus space or in the AIPS bus space.
Signed-off-by: Shengjiu Wang
---
drivers/dma/imx-sdma.c | 137 +++-
1 file changed, 124 insertions(+), 13 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 77b6aab..5e44821 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -259,8 +260,9 @@ struct sdma_channel {
struct sdma_buffer_descriptor *bd;
dma_addr_t bd_phys;
unsigned intpc_from_device, pc_to_device;
+ unsigned intdevice_to_device;
unsigned long flags;
- dma_addr_t per_address;
+ dma_addr_t per_address, per_address2;
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
@@ -328,6 +330,8 @@ struct sdma_engine {
u32 script_number;
struct sdma_script_start_addrs *script_addrs;
const struct sdma_driver_data *drvdata;
+ u32 spba_start_addr;
+ u32 spba_end_addr;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -705,6 +709,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
+ sdmac->device_to_device = 0;
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
@@ -780,6 +785,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
+ sdmac->device_to_device = per_2_per;
}
static int sdma_load_context(struct sdma_channel *sdmac)
@@ -792,11 +798,12 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
- if (sdmac->direction == DMA_DEV_TO_MEM) {
+ if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
- } else {
+ else if (sdmac->direction == DMA_DEV_TO_DEV)
+ load_address = sdmac->device_to_device;
+ else
load_address = sdmac->pc_to_device;
- }
if (load_address < 0)
return load_address;
@@ -851,6 +858,75 @@ static int sdma_disable_channel(struct dma_chan *chan)
return 0;
}
+static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
+{
+ struct sdma_engine *sdma = sdmac->sdma;
+
+ int lwml = sdmac->watermark_level & 0xff;
+ int hwml = (sdmac->watermark_level >> 16) & 0xff;
+
+ if (sdmac->event_id0 > 31) {
+ sdmac->event_mask[0] |= 0;
+ __set_bit(28, &sdmac->watermark_level);
+ sdmac->event_mask[1] |=
+ BIT(sdmac->event_id0 % 32);
+ } else {
+ sdmac->event_mask[0] |= 0;
+ sdmac->event_mask[1] |=
+ BIT(sdmac->event_id0 % 32);
+ }
+ if (sdmac->event_id1 > 31) {
+ sdmac->event_mask[1] |= 0;
+ __set_bit(29, &sdmac->watermark_level);
+ sdmac->event_mask[0] |=
+ BIT(sdmac->event_id1 % 32);
+ } else {
+ sdmac->event_mask[1] |= 0;
+ sdmac->event_mask[0] |=
+ BIT(sdmac->event_id1 % 32);
+ }
+
+ /*
+* If LWML(src_maxburst) > HWML(dst_maxburst), we need
+* swap LWML and HWML of INFO(A.3.2.5.1), also need swap
+* r0(event_mask[1]) and r1(event_mask[0]).
+*/
+ if (lwml > hwml) {
+ sdmac->watermark_level &= ~0xff00ff;
+ sdmac->watermark_level |= hwml;
+ sdmac->watermark_level |= lwml << 16;
+ swap(sdmac->event_mask[0], sdmac->event_mask[1]);
+ }
+ /* BIT 11:
+* 1 : Source on SPBA
+* 0 : Source on AIPS
+*/
+ if (sdmac->per_address >= sdma->spba_start_addr &&
+ sdmac->per_address <= sdma->spba_end_addr)
+ __set_bit(11, &sdmac->watermark_level);
+ /* BIT 12:
+* 1 : Destination on SPBA
+* 0 : Destination on AIPS
+*/
+ if (sdmac->per_address2 >= sdma->spba_start_addr &&
+ sdmac->per_address2 <= sdma->spba_end_addr)
+ __set_bit(12, &sdmac->watermark_level);
+
+ __set_bit(31, &sdmac->watermark_level);
+ /* BIT 31:
+* 1 : Amount of samples to be transferred is
+
Re: [PATCH 8/8] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
On Tue, 23 Jun 2015, Javier Martinez Canillas wrote: > Hello Lee and Viresh, > > On Tue, Jun 23, 2015 at 10:38 AM, Lee Jones wrote: > > On Tue, 23 Jun 2015, Viresh Kumar wrote: > >> On 23-06-15, 08:06, Lee Jones wrote: > >> > > >> > > Over that, this patch should have been present before any other > >> > > patches using these bindings. > >> > > >> > I've never heard that one before, but it's easy to re-order the set. > >> > >> I don't know, but it seems obvious to me: Bindings first and then the > >> code. > > > > Do you always write your documentation before implementing a > > feature? > > > > Surely it goes; > > Requirements Gathering > > Plan and Prepare > > Implement > > Test > > Document > > Deliver > > > > ;) > > > > ... but as I say, I can re-order if required. It's really not a problem. > > > > This is actually documented in > Documentation/devicetree/bindings/submitting-patches.txt: > ... > > 3) The Documentation/ portion of the patch should come in the series before > the code implementing the binding. > > > > The rationale AFAIU is that it is easier to review the implementation > of a binding after reading the DT binding doc since then you can see > if the code matches what the DT binding describes. Fair enough. Can't argue with that. :) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 00/14] ARM: shmobile: Add CPG Clock Domains
Hi Mike,
On Mon, Jun 22, 2015 at 10:46 PM, Michael Turquette
wrote:
>> The MSTP block provides two functions:
>> 1. Module Standby: "Clock supply to specified modules is stopped by
>> setting the module stop control register bits."
>> However, the clock supply to a module is not stopped until all CPUs
>> in the SoC agree. Indeed, there are separate MSTP registers for
>> application (Cortex-A) and real-time (SH and/or Cortex-R) cores.
>> 2. Reset control. to perform a software reset of a specific module.
>>
>> Given the second function, perhaps the MSTP bits shouldn't have been
>> moduled as clocks, but it made sense at the time of introduction, and
>> IMHO it still does.
>
> Does the clk.enable_count refcount for an MSTP "clock" mirror your
> statement, "the clock supply to a module is not stopped until all CPUs
> in the SoC agree"? Put another way, is it possble in a shmobile system
> for an MSTP "clock" to have an enable_count of zero, but still by
> physically enabled in hardware?
Yes. The enable_count only matches the bit in the application core MSTP
control register. The real-time core MSTP control register may still have the
same module clock enabled (i.e. module not put in standby).
On some SoCs (e.g. R-Mobile APE6) there can be 3 sets of control registers
(for application, real-time, and baseband core).
Most (not all) module clocks have a status register to check if the module
clock is actually enabled or not. This shows that the module clock is stopped
iff all cores agree to stop it.
However, I found a few module clocks that never can be stopped, according to
the status register. Perhaps there's another set of control registers for an
undocumented core...
In addition, there are many undocumented bits in the MSTP control registers,
which may represent existing but undocumented clocks. Disabling such bits
may lock up the system.
As Linux doesn't touch the control registers for other CPU cores (they're
not described in DT), a module clock may be enabled (read: not stopped) in
a control registers meant for another CPU core, depending on reset state or
on the boot loader. Or by another OS running on another CPU core.
I've been running for quite some time with extra code that disables all module
clocks (for all cores) at early boot time, which let me find lots of drivers
that relied on implicit module clocks. Most got fixed, the only major
offender left is the module clock for the GIC ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 8/8] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
On 23-06-15, 09:38, Lee Jones wrote: > Do you always write your documentation before implementing a > feature? > > Surely it goes; > Requirements Gathering > Plan and Prepare > Implement > Test > Document > Deliver > > ;) DT bindings aren't just simple documentation of how things are working. I do things in the way you wrote earlier though :) > That's not what it looks like to me: > > git grep -C20 "compatible.*cpufreq" -- arch Yeah, that's wrong. They got in much earlier and the bindings weren't well thought through. But they are discouraged today .. -- viresh -- 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 7/8] cpufreq: st: Provide runtime initialised driver for ST's platforms
On Tue, 23 Jun 2015, Viresh Kumar wrote: > On 23-06-15, 09:27, Lee Jones wrote: > > Okay, but the reasoning is the same. I consider the function to have > > failed, but the over-all failure culminates in just a warning that > > voltage scaling has indeed failed, but we can still go on with > > frequency scaling. > > Ahh, I thought that the other opp-table will also have voltages. Nope. See patch 1. > > Unless his is a big blocker for you, I would like to keep these > > semantics. > > No, the print is actually fine. Perfect, thanks. > > So technically you are correct, but it makes the code slightly more > > confusing IMHO. Yes, it's one more line of code, but it's worth it to > > add clarity. > > Your call :) Thanks again. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/3] mm, x86: Remove region_is_ram() call from ioremap
* Mike Travis wrote: > <<< > We have a large university system in the UK that is experiencing > very long delays modprobing the driver for a specific I/O device. > The delay is from 8-10 minutes per device and there are 31 devices > in the system. This 4 to 5 hour delay in starting up those I/O > devices is very much a burden on the customer. > ... > The problem was tracked down to a very slow IOREMAP operation and > the excessively long ioresource lookup to insure that the user is > not attempting to ioremap RAM. These patches provide a speed up > to that function. > >>> > > The speed up was pretty dramatic, I think to about 15-20 minutes > (the test was done by our local CS person in the UK). I think this > would prove the function was working since it would have fallen > back to the previous page_is_ram function and the 4 to 5 hour > startup. Btw., I think even 15-20 minutes is still in the 'ridiculously slow' category. Any chance to fix all of this properly, not just hack by hack? 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/
[GIT PULL] s390 patches for the 4.2 merge window
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
Pretty boring for a merge window pull.
One change in behaviour is the patch for dasd driver, the module which
provides the diagnose discipline is now loaded automatically.
The SCLP code got a nice cleanup, a new global structure replaces a
bunch of accessor functions.
And a couple of random, small improvements.
David Hildenbrand (4):
s390/sclp: prepare smp_fill_possible_mask for global "struct sclp"
s390/sclp: unify basic sclp access by exposing "struct sclp"
s390/sclp: get rid of sclp_get_mtid() and sclp_get_mtid_max()
s390/sclp: move sclp_facilities into "struct sclp"
Geert Uytterhoeven (1):
s390/mm: s/specifiation/specification/, s/an specification/a
specification/
Jan Kara (1):
s390/keyboard: avoid off-by-one when using strnlen_user()
Joe Perches (1):
s390/sclp: Use DECLARE_BITMAP
Nicholas Mc Guire (1):
s390/sclp: pass timeout as HZ independent value
Peter Oberparleiter (1):
s390/dasd: Enable automatic loading of dasd_diag_mod
Sebastian Ott (2):
s390/setup: fix DMA_API_DEBUG warnings
s390/pci: improve handling of hotplug event 0x301
Vaishali Thakkar (1):
s390/zcrypt: remove obsolete __constant
arch/s390/hypfs/hypfs_sprp.c | 4 +-
arch/s390/include/asm/pgtable.h| 4 +-
arch/s390/include/asm/sclp.h | 34 ++-
arch/s390/kernel/crash_dump.c | 8 +--
arch/s390/kernel/setup.c | 23 +---
arch/s390/kernel/smp.c | 13 ++--
arch/s390/kvm/interrupt.c | 4 +-
arch/s390/kvm/kvm-s390.c | 8 +--
arch/s390/mm/init.c| 2 +-
arch/s390/mm/mem_detect.c | 4 +-
arch/s390/pci/pci_event.c | 8 ++-
drivers/s390/block/dasd.c | 17 ++
drivers/s390/char/keyboard.c | 13 ++--
drivers/s390/char/sclp.c | 2 +-
drivers/s390/char/sclp.h | 15 ++---
drivers/s390/char/sclp_cmd.c | 29 -
drivers/s390/char/sclp_early.c | 118 +++--
drivers/s390/char/sclp_sdias.c | 3 +-
drivers/s390/char/zcore.c | 10 ++--
drivers/s390/crypto/zcrypt_pcicc.c | 8 +--
drivers/s390/kvm/kvm_virtio.c | 4 +-
21 files changed, 141 insertions(+), 190 deletions(-)
diff --git a/arch/s390/hypfs/hypfs_sprp.c b/arch/s390/hypfs/hypfs_sprp.c
index f043c3c..dd42a26 100644
--- a/arch/s390/hypfs/hypfs_sprp.c
+++ b/arch/s390/hypfs/hypfs_sprp.c
@@ -128,14 +128,14 @@ static struct hypfs_dbfs_file hypfs_sprp_file = {
int hypfs_sprp_init(void)
{
- if (!sclp_has_sprp())
+ if (!sclp.has_sprp)
return 0;
return hypfs_dbfs_create_file(&hypfs_sprp_file);
}
void hypfs_sprp_exit(void)
{
- if (!sclp_has_sprp())
+ if (!sclp.has_sprp)
return;
hypfs_dbfs_remove_file(&hypfs_sprp_file);
}
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index fc64239..9a04717 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1565,9 +1565,9 @@ static inline int has_transparent_hugepage(void)
/*
* 64 bit swap entry format:
* A page-table entry has some bits we have to treat in a special way.
- * Bits 52 and bit 55 have to be zero, otherwise an specification
+ * Bits 52 and bit 55 have to be zero, otherwise a specification
* exception will occur instead of a page translation exception. The
- * specifiation exception has the bad habit not to store necessary
+ * specification exception has the bad habit not to store necessary
* information in the lowcore.
* Bits 54 and 63 are used to indicate the page type.
* A swap pte is indicated by bit pattern (pte & 0x201) == 0x200
diff --git a/arch/s390/include/asm/sclp.h b/arch/s390/include/asm/sclp.h
index f1096ba..c891f41 100644
--- a/arch/s390/include/asm/sclp.h
+++ b/arch/s390/include/asm/sclp.h
@@ -46,33 +46,39 @@ struct sclp_cpu_info {
struct sclp_cpu_entry cpu[MAX_CPU_ADDRESS + 1];
};
+struct sclp_info {
+ unsigned char has_linemode : 1;
+ unsigned char has_vt220 : 1;
+ unsigned char has_siif : 1;
+ unsigned char has_sigpif : 1;
+ unsigned char has_cpu_type : 1;
+ unsigned char has_sprp : 1;
+ unsigned int ibc;
+ unsigned int mtid;
+ unsigned int mtid_cp;
+ unsigned int mtid_prev;
+ unsigned long long rzm;
+ unsigned long long rnmax;
+ unsigned long long hamax;
+ unsigned int max_cpu;
+ unsigned long hsa_size;
+ unsigned long long facilities;
+};
+extern struct sclp_info sclp;
+
int sclp_get_cpu_info(struct sclp_cpu_info *info);
int sclp_cpu_configure(u8 cpu);
int sclp_cpu_deconfigure(u8 cpu);
-unsigned long long sclp_get_rnmax(void);
-unsigned long long sclp_get_rzm(void);
-unsigned int sclp_get_max_cpu
Re: [PATCH v2 20/28] ARCv2: barriers
Hi Will, On Tuesday 23 June 2015 02:19 PM, Will Deacon wrote: >> +/* >> > + * MMIO can also get buffered/optimized in micro-arch, so barriers needed >> > + * Based on ARM model for the typical use case >> > + * >> > + * >> > + * >> > + * or: >> > + * >> > + * > The writel_relaxed/readl_relaxed parts here would actually just be > bog-standard loads and stores to an in-memory buffer. I was trying too hard > to show the barrier semantics and accidentally turned the DMA buffers into > __iomem regions. Not sure if I follow you completely :-) IMHO, It doesn't matter if we are dealing with a typical DMA buffer (cached) or a buffer descriptor (typically uncached unless there's hardware IO-coh or some such). Both the cases assume a vanilla ld/st to buffer (using relaxed API) with a surrounding MMIO access. > > If you fix the comment: Does this look better ? - * + * > > Reviewed-by: Will Deacon > > Sorry for messing you about. NP. -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 v2 2/3] IRQ/Gic-V3: Change arm-gic-its to support the Mbigen interrupt
在 2015/6/19 7:52, Thomas Gleixner 写道: > On Mon, 15 Jun 2015, majun (F) wrote: >> 在 2015/6/12 18:48, Thomas Gleixner 写道: >>> Can you please provide a proper description of this mbigen chip and >>> explain WHY you think that it needs all this special hackery? > > You carefully avoided to provide a proper description of this mbigen > chip and how it needs to be integrated into the GIC/ITS whatever > scenario. > Mbigen means Message Based Interrupt Generator. Its a kind of interrupt controller collects the interrupts from external devices and generate msi interrupt. Mbigen is applied to reduce the number of wire connected interrupts. As the peripherals increasing, the interrupts lines needed is increasing much, especially on the Arm64 server soc. Therefore, the interrupt pin in gic is not enought for so many perpherals. Mbigen is designed to fix this problem. Mbigen chip locates in ITS or outside of ITS. The working flow of Mbigen shows as below: external devices --> MBIGEN --->ITS The devices connect to Mbigen chip through wire connecting way. Mbigen detects and collectes the interrupts from the these devices. Then, Mbigen generats the MBI interrupts by writting the ITS Translator register. -- 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: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi Neil,
Am 01.06.2015 um 23:37 schrieb NeilBrown :
> On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I
> wrote:
>
>> Hi,
>>
>> On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
>>> From: NeilBrown
>>>
>>> The twl4030 phy can measure, with low precision, the
>>> resistance-to-ground of the ID pin.
>>>
>>> Add a function to read the value, and export the result
>>> via sysfs.
>>
>> Little sceptical about adding new sysfs entries. Do you have a good reason
>> to
>> add this?
>
> The hardware can report the value, so why not present it to user-space?
I just had another idea how to present the value to user space.
The TWL6030 has connected the USB ID pin to one of the GPADC channels:
http://lxr.free-electrons.com/source/drivers/iio/adc/twl6030-gpadc.c#L235
And therefore automatically presents the ID pin voltage through iio.
Would it be possible and useful to provide an iio interface for the
resistance-to-ground
of the tw4030 ID pin as well?
This would resemble a 6 or 7 level ADC with non-linear scale, but better than
nothing.
And to avoid the “floating” issue, it could also present some voltage value
(assuming
a defined current).
So that “floating” is reported as some maximum voltage (e.g. 3.3V) and “ground”
as 0V.
What do you think?
BR,
Nikolaus
>
> I originally used this with a udev rule which would configure the maximum
> current based on the resistance measure - to work with the particular charger
> hardware I have.
>
> More recent patches try to do all of the max-current configuration in the
> kernel, so I could live without exporting the value via sysfs if that is a
> show-stopper.
>
> I can't see where the scepticism comes from though. It is a well defined
> and cleary documented feature of the hardware. Why not expose it?
>
> Thanks,
> NeilBrown
>
>
>>
>> Thanks
>> Kishon
>>>
>>> If the read fails, which it does sometimes, try again in 50msec.
>>>
>>> Acked-by: Pavel Machek
>>> Signed-off-by: NeilBrown
>>> ---
>>> .../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
>>> drivers/phy/phy-twl4030-usb.c | 63
>>>
>>> 2 files changed, 85 insertions(+)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> index 512c51be64ae..425d23676f8a 100644
>>> --- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> +++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> @@ -6,3 +6,25 @@ Description:
>>> Possible values: "on", "off".
>>>
>>> Changes are notified via select/poll.
>>> +
>>> +What: /sys/bus/platform/devices/*twl4030-usb/id
>>> +Description:
>>> + Read-only report on measurement of USB-OTG ID pin.
>>> +
>>> + The ID pin may be floating, grounded, or pulled to
>>> + ground by a resistor.
>>> +
>>> + A very course grained reading of the resistance is
>>> + available. The numbers given in kilo-ohms are roughly
>>> + the center-point of the detected range.
>>> +
>>> + Possible values are:
>>> + ground
>>> + 102k
>>> + 200k
>>> + 440k
>>> + floating
>>> + unknown
>>> +
>>> + "unknown" indicates a problem with trying to detect
>>> + the resistance.
>>> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
>>> index 3a707dd14238..1d6f3e70193e 100644
>>> --- a/drivers/phy/phy-twl4030-usb.c
>>> +++ b/drivers/phy/phy-twl4030-usb.c
>>> @@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb
>>> *twl, int on)
>>> }
>>> }
>>>
>>> +enum twl4030_id_status {
>>> + TWL4030_GROUND,
>>> + TWL4030_102K,
>>> + TWL4030_200K,
>>> + TWL4030_440K,
>>> + TWL4030_FLOATING,
>>> + TWL4030_ID_UNKNOWN,
>>> +};
>>> +static char *twl4030_id_names[] = {
>>> + "ground",
>>> + "102k",
>>> + "200k",
>>> + "440k",
>>> + "floating",
>>> + "unknown"
>>> +};
>>> +
>>> +enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
>>> +{
>>> + int ret;
>>> +
>>> + pm_runtime_get_sync(twl->dev);
>>> + if (twl->usb_mode == T2_USB_MODE_ULPI)
>>> + twl4030_i2c_access(twl, 1);
>>> + ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
>>> + if (ret < 0 || !(ret & ULPI_OTG_ID_PULLUP)) {
>>> + /* Need pull-up to read ID */
>>> + twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
>>> +ULPI_OTG_ID_PULLUP);
>>> + mdelay(50);
>>> + }
>>> + ret = twl4030_usb_read(twl, ID_STATUS);
>>> + if (ret < 0 || (ret & 0x1f) == 0) {
>>> + mdelay(50);
>>> + ret = twl4030_usb_read(twl, ID_STATUS);
>>> + }
>>> +
>>> + if (twl->usb_mode == T2_USB_MODE_ULPI)
>>> + twl4030_i2c_access(twl, 0);
>>> + pm_runtime_put_autosuspend(twl->dev);
>>> +
>>> + if (ret < 0)
>>> + return TWL4030_ID_UNKNOWN;
>>> + ret = ffs(ret) - 1;
>>> + if (ret < TWL4030_GROUND || ret > TWL4030_FLOATING)
>>> + re
Re: kdbus: to merge or not to merge?
On Mon, Jun 22, 2015 at 11:41:40PM -0700, Greg KH wrote: > On Mon, Jun 22, 2015 at 11:06:09PM -0700, Andy Lutomirski wrote: > > Hi Linus, > > > > Can you opine as to whether you think that kdbus should be merged? > > Ah, a preemptive pull request denial, how nice. I think you're misunderstanding Andy. IMO, he's asking whether he should invest time in reviewing it as kdbus is not trivial to go through. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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/
#pragma GCC warnings (was: Re: [PATCH] crypto: drbg - use pragmas for disabling optimization)
On Tue, Jun 9, 2015 at 6:31 AM, Guenter Roeck wrote: > On 06/08/2015 07:08 PM, Stephan Mueller wrote: >> ---8<--- >> Replace the global -O0 compiler flag from the Makefile with GCC >> pragmas to mark only the functions required to be compiled without >> optimizations. >> >> This patch also adds a comment describing the rationale for the >> functions chosen to be compiled without optimizations. >> >> Signed-off-by: Stephan Mueller > > With openrisc, I get: > > CC [M] crypto/jitterentropy.o > crypto/jitterentropy.c:266:9: warning: #pragma GCC target is not supported > for this machine > > which may not be perfect, but is better than a compile error ;-). I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0. With m68k-linux-gnu-gcc-4.1, which is still my default cross-compiler due to the good unused warning reporting, I get: crypto/jitterentropy.c:235: warning: ignoring #pragma GCC push_options crypto/jitterentropy.c:236: warning: ignoring #pragma GCC optimize crypto/jitterentropy.c:266: warning: ignoring #pragma GCC pop_options crypto/jitterentropy.c:295: warning: ignoring #pragma GCC push_options crypto/jitterentropy.c:296: warning: ignoring #pragma GCC optimize crypto/jitterentropy.c:336: warning: ignoring #pragma GCC pop_options crypto/jitterentropy.c:385: warning: ignoring #pragma GCC push_options crypto/jitterentropy.c:386: warning: ignoring #pragma GCC optimize crypto/jitterentropy.c:416: warning: ignoring #pragma GCC pop_options crypto/jitterentropy.c:517: warning: ignoring #pragma GCC push_options crypto/jitterentropy.c:518: warning: ignoring #pragma GCC optimize crypto/jitterentropy.c:580: warning: ignoring #pragma GCC pop_options If you want to reproduce with a simple test case, you need -Wall. Which gcc versions introduced support for these pragmas? I tried all my cross-compilers from https://www.kernel.org/pub/tools/crosstool/, and it seems I get warnings for all of them, except for powerpc and x86_64: /opt/cross/gcc-4.2.4-nolibc/avr32-linux/bin/avr32-linux-gcc : warning: ignoring #pragma GCC push_options warning: ignoring #pragma GCC optimize warning: ignoring #pragma GCC pop_options /opt/cross/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc : warning: #pragma GCC target is not supported for this machine /opt/cross/gcc-4.6.2-nolibc/tilegx-linux/bin/tilegx-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/alpha-linux/bin/alpha-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/am33_2.0-linux/bin/am33_2.0-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/crisv32-linux/bin/crisv32-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/frv-linux/bin/frv-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/hppa64-linux/bin/hppa64-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/ia64-linux/bin/ia64-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/m32r-linux/bin/m32r-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/mips64-linux/bin/mips64-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/s390x-linux/bin/s390x-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/sh4-linux/bin/sh4-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/sparc64-linux/bin/sparc64-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.6.3-nolibc/xtensa-linux/bin/xtensa-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] /opt/cross/gcc-4.8.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc : warning: #pragma GCC target is not supported for this machine [-Wpragmas] #pragma GCC pop_options ^ /opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc : /opt/cross/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc :
Re: #pragma GCC warnings (was: Re: [PATCH] crypto: drbg - use pragmas for disabling optimization)
On Tue, Jun 23, 2015 at 11:17:23AM +0200, Geert Uytterhoeven wrote: > > I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0. > > With m68k-linux-gnu-gcc-4.1, which is still my default cross-compiler due > to the good unused warning reporting, I get: > > crypto/jitterentropy.c:235: warning: ignoring #pragma GCC push_options > crypto/jitterentropy.c:236: warning: ignoring #pragma GCC optimize > crypto/jitterentropy.c:266: warning: ignoring #pragma GCC pop_options > crypto/jitterentropy.c:295: warning: ignoring #pragma GCC push_options > crypto/jitterentropy.c:296: warning: ignoring #pragma GCC optimize > crypto/jitterentropy.c:336: warning: ignoring #pragma GCC pop_options > crypto/jitterentropy.c:385: warning: ignoring #pragma GCC push_options > crypto/jitterentropy.c:386: warning: ignoring #pragma GCC optimize > crypto/jitterentropy.c:416: warning: ignoring #pragma GCC pop_options > crypto/jitterentropy.c:517: warning: ignoring #pragma GCC push_options > crypto/jitterentropy.c:518: warning: ignoring #pragma GCC optimize > crypto/jitterentropy.c:580: warning: ignoring #pragma GCC pop_options Stephan, could you look into moving the relevant functions into its own file which can then be compiled with -O0? Obviously any dependency on kernel header files would have to be hidden using functions outside of this file. Thanks, -- 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/
Re: [PATCH] mvneta: add forgotten initialization of autonegotiation bits
From: Stas Sergeev
Date: Thu, 18 Jun 2015 18:36:03 +0300
>
> The commit 898b2970e2c9 ("mvneta: implement SGMII-based in-band link state
> signaling")
> changed mvneta_adjust_link() so that it does not clear the auto-negotiation
> bits in MVNETA_GMAC_AUTONEG_CONFIG register. This was necessary for
> auto-negotiation mode to work.
> Unfortunately I haven't checked if these bits are ever initialized.
> It appears they are not.
> This patch adds the missing initialization of the auto-negotiation bits
> in the MVNETA_GMAC_AUTONEG_CONFIG register.
> It fixes the following regression:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg67928.html
>
> Since the patch was tested to fix a regression, it should be applied to
> stable tree.
>
> Tested-by: Arnaud Ebalard
>
> CC: Thomas Petazzoni
> CC: Florian Fainelli
> CC: net...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> CC: sta...@vger.kernel.org
>
> Signed-off-by: Stas Sergeev
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
On Tue, Jun 23, 2015 at 08:25:05AM +, Dilger, Andreas wrote: > I've found in the past that developers can introduce bugs when they treat > return values as boolean when they really aren't. I can imagine a bug like that where a function can return 0-2 and people do: if (ret) instead of: if (ret == 1) but that bug is something else besides pointers so it doesn't apply here. What someone should do is try to measure it scientifically where we flash some code on the screen and you have to press J for NULL and K for non-NULL and we time it to the hundredth of a second. I have a feeling that (NULL != foo) is the worst way to write it because of the double negative Yoda code. Yoda code is the most useless thing ever. I have actually measured this and we introduce about 2 = vs == bugs per year. It's probably less now that we have so many static checks against it. But people decided that Yoda code was a good idea based on their gut instead of using statistics and measurements and science. 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 0/2] FTDI CBUS GPIO support
On Mon, Jun 22, 2015 at 10:11:35PM +0200, Stefan Agner wrote: > On 2015-06-22 19:26, Johan Hovold wrote: > > Instead, hang the gpio chip directly off the usb interface (not the > > port), add a new config option, and keep the gpio implementation under > > drivers/usb/serial (possibly in its own file ftdi_sio-gpio.c). > > Agreed sounds like a good plan. Will try this approach in v2. > > Except I don't think hanging it directly to the USB interface is the > right thing to do. > > Looking at the block diagram of FT232R or FT232H, the CBUS pins seem to > be part of the UART/FIFO controller. And I think the dual UART FT2232D > actually supports controlling the CBUS pins of the two UART controllers > individually, at least the block diagram thereof suggests so. The port is a Linux abstraction, and for FTDI we happen to have exactly one port child device per USB interface. As I see it, the gpio controller for the CBUS pins should be a sibling rather than a child device to the port. Note that we'd still have two gpio-controllers on FT2232D (one per USB interface). I'm aware that this requires some restructuring of the ftdi_sio-driver (e.g. the device type and ftdi-interface number should be a feature of the usb-serial rather than usb-serial-port device). Thanks, Johan -- 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 0/3] clk: stm32: Add clock driver for STM32F4[23]xxx devices
2015-06-23 10:22 GMT+02:00 Daniel Thompson : > On 22/06/15 23:48, Stephen Boyd wrote: >> >> On 06/10, Daniel Thompson wrote: >>> >>> This patchset implements a clock driver for STM32F42xxx and STM32F43xxx >>> series devices. It supports decoding the state configured by the >>> bootloader (PLL, clock select, bus dividers) and all the gates clocks. >>> It does not currently support the I2S and SAI PLLs. >>> >>> Relies on "Add support to STMicroeletronics STM32 family" v9 by Maxime >>> Coquelin: http://thread.gmane.org/gmane.linux.kernel/1961049 . >>> >> >> I applied 1 and 2. Looks like #3 should go through arm-soc at >> some later time? > > > Agreed (that is also the patch that must be correctly ordered w.r.t. > Maxime's patches). Indeed, I will take care of patch 3. Thanks, 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/
[git pull] IOMMU Updates for Linux v4.2
Hi Linus, The IOMMU changes have conflicts this time with IRQ related patches coming from the tip tree. Some of the IRQ patches there also touch the Intel and AMD interrupt remapping code in drivers/iommu, which conflicts with the Intel VT-d kdump fixes. I attached my resolution of the conflicts to this pull-request and compiled and run-time tested my resolution on an Intel VT-d and an AMD IOMMU machine. If you want me to send you another pull-request with the conflicts already solved, please let me know. So with that notice in front, here comes the pull-request: The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27: Linux 4.1-rc8 (2015-06-14 15:51:10 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v4.2 for you to fetch changes up to 5ffde2f67181195d457b95df44b8f88e8d969d89: Merge branches 'arm/rockchip', 'arm/exynos', 'arm/smmu', 'x86/vt-d', 'x86/amd', 'default-domains' and 'core' into next (2015-06-19 17:17:47 +0200) IOMMU Updates for Linux v4.2 This time with bigger changes than usual: * A new IOMMU driver for the ARM SMMUv3. This IOMMU is pretty different from SMMUv1 and v2 in that it is configured through in-memory structures and not through the MMIO register region. The ARM SMMUv3 also supports IO demand paging for PCI devices with PRI/PASID capabilities, but this is not implemented in the driver yet. * Lots of cleanups and device-tree support for the Exynos IOMMU driver. This is part of the effort to bring Exynos DRM support upstream. * Introduction of default domains into the IOMMU core code. The rationale behind this is to move functionalily out of the IOMMU drivers to common code to get to a unified behavior between different drivers. The patches here introduce a default domain for iommu-groups (isolation groups). A device will now always be attached to a domain, either the default domain or another domain handled by the device driver. The IOMMU drivers have to be modified to make use of that feature. So long the AMD IOMMU driver is converted, with others to follow. * Patches for the Intel VT-d drvier to fix DMAR faults that happen when a kdump kernel boots. When the kdump kernel boots it re-initializes the IOMMU hardware, which destroys all mappings from the crashed kernel. As this happens before the endpoint devices are re-initialized, any in-flight DMA causes a DMAR fault. These faults cause PCI master aborts, which some devices can't handle properly and go into an undefined state, so that the device driver in the kdump kernel fails to initialize them and the dump fails. This is now fixed by copying over the mapping structures (only context tables and interrupt remapping tables) from the old kernel and keep the old mappings in place until the device driver of the new kernel takes over. This emulates the the behavior without an IOMMU to the best degree possible. * A couple of other small fixes and cleanups. Colin Cross (1): iommu/exynos: Tell kmemleak to ignore 2nd level page tables Dan Carpenter (1): iommu: Checking for NULL instead of IS_ERR Heiko Stuebner (1): iommu/rockchip: Silence attaching and detaching of devices Joerg Roedel (45): iommu/amd: Handle integer overflow in dma_ops_area_alloc iommu: Remove function name from pr_fmt() iommu: Add a few printk messages to group handling code iommu: Propagate error in add_iommu_group iommu: Clean up after a failed bus initialization iommu: Call remove_device call-back after driver release iommu: Allocate a default domain for iommu groups iommu: Limit iommu_attach/detach_device to devices with their own group iommu: Make sure a device is always attached to a domain iommu: Add iommu_get_domain_for_dev function iommu: Introduce direct mapped region handling iommu: Create direct mappings in default domains iommu: Add function to query the default domain of a group iommu: Introduce iommu_request_dm_for_dev() iommu/amd: Implement dm_region call-backs iommu/amd: Use default domain if available for DMA-API iommu/amd: Implement add_device and remove_device iommu/amd: Support IOMMU_DOMAIN_DMA type allocation iommu/amd: Support IOMMU_DOMAIN_IDENTITY type allocation iommu/amd: Put IOMMUv2 devices in a direct mapped domain iommu/amd: Get rid of device_dma_ops_init() iommu/amd: Remove unused fields from struct dma_ops_domain i
Re: [PATCH v2 20/28] ARCv2: barriers
On Tue, Jun 23, 2015 at 01:28:03PM +0530, Vineet Gupta wrote: > +/* > + * MMIO can also get buffered/optimized in micro-arch, so barriers needed > + * Based on ARM model for the typical use case > + * > + * > + * > + * or: > + * > + * > + * > + * http://www.spinics.net/lists/kernel/msg2018397.html http://lkml.kernel.org/r/20150622133656.gg1...@arm.com Might I suggest you use the above link. Since we control kernel.org we have redirect that URL to a archive of our choosing. This keeps the links working even if spinics.net or marc.info were to go belly up. -- 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 7/9] nvmem: qfprom: Add bindings for qfprom
[]..
+Example:
+
+ qfprom: qfprom@0070 {
+ compatible = "qcom,qfprom";
+ reg = <0x0070 0x8000>;
+ ...
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x4404 0x10>;
+ };
+ };
+
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+ tsens {
+ ...
+ nvmem-cell = <&tsens_calibration>;
Shouldn't this be nvmem-cells instead?
+ nvmem-cell-names = "calibration";
+ };
--
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 20/28] ARCv2: barriers
On Tue, Jun 23, 2015 at 10:03:25AM +0100, Vineet Gupta wrote: > On Tuesday 23 June 2015 02:19 PM, Will Deacon wrote: > >> +/* > >> > + * MMIO can also get buffered/optimized in micro-arch, so barriers > >> > needed > >> > + * Based on ARM model for the typical use case > >> > + * > >> > + * > >> > + * > >> > + * or: > >> > + * > >> > + * > > The writel_relaxed/readl_relaxed parts here would actually just be > > bog-standard loads and stores to an in-memory buffer. I was trying too hard > > to show the barrier semantics and accidentally turned the DMA buffers into > > __iomem regions. > > Not sure if I follow you completely :-) D'oh, sorry. > IMHO, It doesn't matter if we are dealing with a typical DMA buffer (cached) > or a > buffer descriptor (typically uncached unless there's hardware IO-coh or some > such). Both the cases assume a vanilla ld/st to buffer (using relaxed API) > with a > surrounding MMIO access. It's more that you should only pass __iomem pointers (i.e. stuff you got back from something like ioremap) to readl_relaxed/writel_relaxed and that's not typically how you would allocate your DMA buffer. > > If you fix the comment: > > Does this look better ? > > - * > + * I'd just replace 'writel_relaxed' with whatever your store instruction is (ST)? Will -- 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: kdbus: to merge or not to merge?
Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger: > On Tue, Jun 23, 2015 at 8:41 AM, Greg KH wrote: > >> The current state of uncertainty is problematic, I think. The kdbus > >> team is spending a lot of time making things compatible with kdbus, > >> and the latest systemd release makes kdbus userspace support > >> mandatory. > > > > I stopped here in this email, as this is just flat out totally wrong, > > and I don't want to waste my time trying to refute other totally wrong > > statements as that would just somehow give them some validation that > > they could possibly be correct. > > For the guys who not follow systemd development, this is the > announcement in question: > http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html > > * kdbus support is no longer compile-time optional. It is now > always built-in. However, it can still be disabled at > runtime using the kdbus=0 kernel command line setting, and > that setting may be changed to default to off, by specifying > --disable-kdbus at build-time. Note though that the kernel > command line setting has no effect if the kdbus.ko kernel > module is not installed, in which case kdbus is (obviously) > also disabled. We encourage all downstream distributions to > begin testing kdbus by adding it to the kernel images in the > development distributions, and leaving kdbus support in > systemd enabled. > > Now kdbus is opt-out instead of opt-in. > Although I didn't test it so far, systemd should work just fine if > kdbus is not present > as it can fall back to dbus. Andy, I think it was partly this what triggered your mail. I wrote a mail about asking for a careful review of dbus exactly due to this some days ago, but didn´t include any Ccs. In that I wrote: - I hope you kernel developers will still review kdbus carefully as you did so far, instead of giving in to any downstream pressure by distros. It is exactly this attitude and this approach of systemd upstream that I feel uneasy about. Instead of humbly waiting and working towards having kdbus accepted to the kernel, systemd developers seem to use any means to create indirect pressure to have it included eventually. I hope that it will still be technical excellence as entry barrier for anything that goes into the kernel. Please note: I do not judge upon the technical quality of kdbus. I think others are more knowledgeable to do it. - I think the move of systemd developers is able to create downstream pressure to include kdbus into the kernel and Andy´s mail is partly a reaction to that. I personally wouldn´t ask for it not to be included into the kernel, but I just ask for a careful review instead of giving in to any downstream pressure the move of systemd developers may trigger. But unlike Andy I did not review kdbus for technical quality. It seems that Andy has strong technical concerns about it. But you Greg, write that these are not correct without any explaination on why you think this is so. You outrightly write that these are invalid without any explaination at all. Greg, if you do not want any preemptive decision not to merge kdbus before your next pull request, I kindly also ask for for no preemptive decision to actually merge it then, as it may be included in Fedora or other distro kernels already. Having it in distros can be good for testing things, but it does not necessarily say anything about technical qualification of the patches for the upstream kernel. So no argument like in "but, look, its in the distros" in my view is enough reason to merge it into the upstream kernel. On the next time you do your pull request, if Andy or anyone else posts technical concerns, for a careful review process I think it is important that you or someone else actually addresses them instead of just telling that these are invalid (in your point of view!). Cause this is exactly again an attitude I found with systemd upstream. "I am right, you are wrong, go away". It is this kind of attitude – I have seen it on both sides of this discussion – that creates most of the friction and energy blockage and polarity around this topic. I tried to bring this up in systemd-devel once, but in the end I unsubscribed after having been called "being a dick" there. From Lennart himself who on the other hand whines about perceived rudeness in kernel community. So again I ask: What is it what you actually want to create? And how can you create it (instead of creating something, like this friction and energy blockage, that you probably didn´t want to create at all)? I ask this to anyone involved. Thank you, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82
Re: [PATCH v6 1/9] nvmem: Add a simple NVMEM framework for nvmem providers
Hi Joe, > On Jun 23, 2015, at 05:52 , Joe Perches wrote: > > On Tue, 2015-06-23 at 00:08 +0100, Srinivas Kandagatla wrote: >> This patch adds just providers part of the framework just to enable easy >> review. > [] >> include/linux/nvmem-provider.h | 54 ++ > > Unless there are going to be users of nvmem-provider.h > outside of the drivers/nvmem directory, perhaps that > file (and nvmem-consumer.h) should be in drivers/nvmem/ > > nvmem-consumer.h should be accessible from any driver, no? And unfortunately nvmem-provider should be accessible too. There are already eeprom drivers in the eeprom/misc directory that cannot be moved yet to drivers/nvmem (like at24). They need the provider definitions while they provide both the old style interface, and the new NVMEM based one. When we move them to the drivers/nvmem directory, then yes the provider header file should move there. Regards — Pantelis -- 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 2/3] IRQ/Gic-V3: Change arm-gic-its to support the Mbigen interrupt
On Tue, 23 Jun 2015, majun (F) wrote: > 在 2015/6/19 7:52, Thomas Gleixner 写道: > > On Mon, 15 Jun 2015, majun (F) wrote: > >> 在 2015/6/12 18:48, Thomas Gleixner 写道: > >>> Can you please provide a proper description of this mbigen chip and > >>> explain WHY you think that it needs all this special hackery? > > > > You carefully avoided to provide a proper description of this mbigen > > chip and how it needs to be integrated into the GIC/ITS whatever > > scenario. > > > Mbigen means Message Based Interrupt Generator. > Its a kind of interrupt controller collects > the interrupts from external devices and generate msi interrupt. > > Mbigen is applied to reduce the number of wire connected interrupts. > > As the peripherals increasing, the interrupts lines needed is increasing > much, especially on the Arm64 server soc. > > Therefore, the interrupt pin in gic is not enought for so many perpherals. > > Mbigen is designed to fix this problem. > > Mbigen chip locates in ITS or outside of ITS. > > The working flow of Mbigen shows as below: > > external devices --> MBIGEN --->ITS > > The devices connect to Mbigen chip through wire connecting way. > Mbigen detects and collectes the interrupts from the these devices. > > Then, Mbigen generats the MBI interrupts by writting the ITS > Translator register. So it's nothing else than a non PCI based MSI implementation which means it can simply use the generic MSI infrastructure and implement a interrupt domain/chip which implements the MBI specific parts and has the ITS as its parent domain. No hackery in ITS and no extra functionality in the core irq code. It just can use the existing infrastructure. The only extra you need is a proper way to retrieve the pointer to the ITS domain. Everything else just falls in place. Thanks, tglx
Re: [RFC][PATCH 00/13] percpu rwsem -v2
On 06/22/2015 09:05 PM, Peter Zijlstra wrote: > On Mon, Jun 22, 2015 at 08:11:14PM +0200, Daniel Wagner wrote: >> On 06/22/2015 02:16 PM, Peter Zijlstra wrote: >>> Also, since Linus thinks lglocks is a failed locking primitive (which I >>> whole >>> heartedly agree with, its preempt-disable latencies are an abomination), it >>> also converts the global part of fs/locks's usage of lglock over to a >>> percpu-rwsem and uses a per-cpu spinlock for the local part. This both >>> provides >>> another (4th) percpu-rwsem users and removes an lglock user. >> >> I did a quick lockperf run with these patches on a 4 socket E5-4610 machine. >> These microbenches execercise the fs' locks a bit. >> >> I suspect I got the wrong tree. The patches did not apply cleanly. The >> resulting >> kernel boots fine and doesn't explode... so far... > > Its against tip/master, although I expect the locking/core bits that > were sent to Linus earlier today to be the biggest missing piece. > > All I really did was build a kernel with lockdep enabled and boot + > build a kernel to see it didn't go belly up. > >> The results aren't looking too bad. Though building a kernel with 'make >> -j200' >> was extreme slow. I'll look into it tomorrow. So this turns out to be false alarm. I had icecream installed/actived and that interfered with gcc. Stupid me. The machine has 0.5TB memory and doesn't seem to be really concerned about 'make -j200' make clean && time make -j200 mainline 4.1.0 2nd run real1m7.595s user28m43.125s sys 3m48.189s tip v4.1-2756-ge3d06bd 2nd run real1m6.871s user28m50.803s sys 3m50.223s 3rd run real1m6.974s user28m52.093s sys 3m50.259s tip v4.1-2769-g6ce2591 (percpu-rwsem) 2nd run real1m7.847s user29m0.439s sys 3m51.181s 3rd run real1m7.113s user29m3.127s sys 3m51.516s Compared to 'make -j64' on tip v4.1-2756-ge3d06bd 2nd run real1m7.605s user28m3.121s sys 3m52.541s >> https://git.samba.org/jlayton/linux.git/?p=jlayton/lockperf.git;a=summary > > Sweet, I wasn't aware these existed. I'll go have a play. > >> posix01 >> mean variance sigmamaxmin >> 4.1.0 121.9020 27882.5260 166.9806 603.5509 >> 0.0063 >> percpu-rwsem 185.3981 38474.3836 196.1489 580.6532 >> 0.0073 >> >> >> posix02 >> mean variance sigmamaxmin >> 4.1.012.7461 3.1802 1.783315.5411 >> 8.1018 >> percpu-rwsem16.2341 4.3038 2.074619.3271 >> 11.1751 >> > > These two seem to hurt, lemme go look at what they do. Now here the same tests with tip and tip+percpu-rwsem. The patches applied cleanly :) I put all the raw data here[1] in case someone is interested. Some of the test behave a bit strange, running extremely fast compared to the other runs. That is probably the result of me trying to reduce the run time to the min. flock01 mean variance sigmamaxmin 4.1.011.7075 816.334128.5716 125.6552 0.0021 4.1.0+percpu-rwsem11.4614 760.134527.5705 132.5030 0.0026 tip 6.8390 329.303718.146781.0373 0.0021 tip+percpu-rwsem10.0870 546.743523.3825 106.2396 0.0026 flock02 mean variance sigmamaxmin 4.1.0 7.0197 1.1812 1.086810.6188 5.1706 4.1.0+percpu-rwsem 9.3194 1.3443 1.159411.5902 6.6138 tip 7.1057 1.6719 1.293011.2362 5.1434 tip+percpu-rwsem 9.0357 1.9874 1.409714.0254 6.4380 lease01 mean variance sigmamaxmin 4.1.041.836123.8462 4.883351.349328.5859 4.1.0+percpu-rwsem40.273820.8323 4.564249.603728.0704 tip30.261713.0900 3.618036.639820.2085 tip+percpu-rwsem31.273017.9787 4.240137.898119.2944 lease02 mean variance sigmamaxmin 4.1.071.215912.7763 3.574477.843258.0390 4.1.0+percpu-rwsem71.431214.7688 3.843076.503657.8615 tip20.2019 5.2042 2.281323.107113.4647 tip+percpu-rwsem20.8305 6.6631 2.581323.803411.2815 posix01 mean variance sigmamaxmin 4.1.0 121.9020 27882.5260 166.9806 603.5509 0.0063
Re: [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
On Tue, 23 Jun 2015, Dan Carpenter wrote: > On Tue, Jun 23, 2015 at 08:25:05AM +, Dilger, Andreas wrote: > > I've found in the past that developers can introduce bugs when they treat > > return values as boolean when they really aren't. > > I can imagine a bug like that where a function can return 0-2 and people > do: > > if (ret) > > instead of: > > if (ret == 1) > > but that bug is something else besides pointers so it doesn't apply > here. > > What someone should do is try to measure it scientifically where we > flash some code on the screen and you have to press J for NULL and K for > non-NULL and we time it to the hundredth of a second. I have a feeling > that (NULL != foo) is the worst way to write it because of the double > negative Yoda code. > > Yoda code is the most useless thing ever. I have actually measured this > and we introduce about 2 = vs == bugs per year. It's probably less now > that we have so many static checks against it. But people decided that > Yoda code was a good idea based on their gut instead of using statistics > and measurements and science. In 2007, Al Viro said (https://lkml.org/lkml/2007/7/27/103): Idiomatic form for "has allocation succeeded?" is neither "if (p != 0)" nor "if (p != NULL)". It's simply "if (p)". >From the point of view of looking at kernel code, x == NULL for the result of kmalloc etc looks verbose and distracting. julia -- 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: kdbus: to merge or not to merge?
Am Dienstag, 23. Juni 2015, 11:25:49 schrieb Martin Steigerwald: > Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger: > > On Tue, Jun 23, 2015 at 8:41 AM, Greg KH > > wrote: > > >> The current state of uncertainty is problematic, I think. The kdbus > > >> team is spending a lot of time making things compatible with kdbus, > > >> and the latest systemd release makes kdbus userspace support > > >> mandatory. > > > > > > I stopped here in this email, as this is just flat out totally wrong, > > > and I don't want to waste my time trying to refute other totally wrong > > > statements as that would just somehow give them some validation that > > > they could possibly be correct. > > > > For the guys who not follow systemd development, this is the > > announcement in question: > > http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.htm > > l > > > > * kdbus support is no longer compile-time optional. It is now > > > > always built-in. However, it can still be disabled at > > runtime using the kdbus=0 kernel command line setting, and > > that setting may be changed to default to off, by specifying > > --disable-kdbus at build-time. Note though that the kernel > > command line setting has no effect if the kdbus.ko kernel > > module is not installed, in which case kdbus is (obviously) > > also disabled. We encourage all downstream distributions to > > begin testing kdbus by adding it to the kernel images in the > > development distributions, and leaving kdbus support in > > systemd enabled. > > > > Now kdbus is opt-out instead of opt-in. > > Although I didn't test it so far, systemd should work just fine if > > kdbus is not present > > as it can fall back to dbus. > > Andy, I think it was partly this what triggered your mail. I wrote a mail > about asking for a careful review of dbus exactly due to this some days > ago, but didn´t include any Ccs. > > In that I wrote: > > - > I hope you kernel developers will still review kdbus carefully as you did > so far, instead of giving in to any downstream pressure by distros. > > It is exactly this attitude and this approach of systemd upstream that I > feel uneasy about. Instead of humbly waiting and working towards having > kdbus accepted to the kernel, systemd developers seem to use any means to > create indirect pressure to have it included eventually. > > I hope that it will still be technical excellence as entry barrier for > anything that goes into the kernel. > > Please note: I do not judge upon the technical quality of kdbus. I think > others are more knowledgeable to do it. > - > > I think the move of systemd developers is able to create downstream > pressure to include kdbus into the kernel and Andy´s mail is partly a > reaction to that. > > I personally wouldn´t ask for it not to be included into the kernel, but I > just ask for a careful review instead of giving in to any downstream > pressure the move of systemd developers may trigger. > > But unlike Andy I did not review kdbus for technical quality. It seems > that Andy has strong technical concerns about it. But you Greg, write > that these are not correct without any explaination on why you think this > is so. You outrightly write that these are invalid without any > explaination at all. > > Greg, if you do not want any preemptive decision not to merge kdbus before > your next pull request, I kindly also ask for for no preemptive decision > to actually merge it then, as it may be included in Fedora or other > distro kernels already. Having it in distros can be good for testing > things, but it does not necessarily say anything about technical > qualification of the patches for the upstream kernel. So no argument like > in "but, look, its in the distros" in my view is enough reason to merge > it into the upstream kernel. > > On the next time you do your pull request, if Andy or anyone else posts > technical concerns, for a careful review process I think it is important > that you or someone else actually addresses them instead of just telling > that these are invalid (in your point of view!). > > Cause this is exactly again an attitude I found with systemd upstream. "I > am right, you are wrong, go away". It is this kind of attitude – I have > seen it on both sides of this discussion – that creates most of the > friction and energy blockage and polarity around this topic. I tried to > bring this up in systemd-devel once, but in the end I unsubscribed after > having been called "being a dick" there. From Lennart himself who on the > other hand whines about perceived rudeness in kernel community. Let me take some judgement out of what I wrote and have an attempt to describe instead: >From Lennart himsel
[FRC PATCH v2] mmc: core: Optimize case for exactly one erase-group budget TRIM
In the (not so unlikely) case that the mmc controller timeout budget is
enough for exactly one erase-group, the simplification of allowing one
sector has an enormous performance penalty. We optimize this special case
by introducing a flag that prohibits erase-group boundary crossing, so
that we can allow trimming more than one sector at a time.
Signed-off-by: David Jander
---
Changes since v1:
- Added more comment
drivers/mmc/core/core.c | 38 ++
include/linux/mmc/card.h | 1 +
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 92e7671..2771391 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2089,6 +2089,7 @@ int mmc_erase(struct mmc_card *card, unsigned int from,
unsigned int nr,
unsigned int arg)
{
unsigned int rem, to = from + nr;
+ int err;
if (!(card->host->caps & MMC_CAP_ERASE) ||
!(card->csd.cmdclass & CCC_ERASE))
@@ -2139,6 +2140,23 @@ int mmc_erase(struct mmc_card *card, unsigned int from,
unsigned int nr,
/* 'from' and 'to' are inclusive */
to -= 1;
+ /*
+* Special case where only one erase-group fits in the timeout budget:
+* If the region crosses an erase-group boundary on this particular
+* case, we will be trimming more than one erase-group which, does not
+* fit in the timeout budget of the controller, so we need to split it
+* and call mmc_do_erase() twice if necessary. This special case is
+* identified by the card->eg_boundary flag.
+*/
+ if ((arg & MMC_TRIM_ARGS) && (card->eg_boundary) &&
+ (from % card->erase_size)) {
+ rem = card->erase_size - (from % card->erase_size);
+ err = mmc_do_erase(card, from, from + rem - 1, arg);
+ from += rem;
+ if ((err) || (to <= from))
+ return err;
+ }
+
return mmc_do_erase(card, from, to, arg);
}
EXPORT_SYMBOL(mmc_erase);
@@ -2234,16 +2252,28 @@ static unsigned int mmc_do_calc_max_discard(struct
mmc_card *card,
if (!qty)
return 0;
+ /*
+* When specifying a sector range to trim, chances are we might cross
+* an erase-group boundary even if the amount of sectors is less than
+* one erase-group.
+* If we can only fit one erase-group in the controller timeout budget,
+* we have to care that erase-group boundaries are not crossed by a
+* single trim operation. We flag that special case with "eg_boundary".
+* In all other cases we can just decrement qty and pretend that we
+* always touch (qty + 1) erase-groups as a simple optimization.
+*/
if (qty == 1)
- return 1;
+ card->eg_boundary = 1;
+ else
+ qty--;
/* Convert qty to sectors */
if (card->erase_shift)
- max_discard = --qty << card->erase_shift;
+ max_discard = qty << card->erase_shift;
else if (mmc_card_sd(card))
- max_discard = qty;
+ max_discard = qty + 1;
else
- max_discard = --qty * card->erase_size;
+ max_discard = qty * card->erase_size;
return max_discard;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 19f0175..704b60d 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -282,6 +282,7 @@ struct mmc_card {
unsigned interase_size; /* erase size in sectors */
unsigned interase_shift;/* if erase unit is power 2 */
unsigned intpref_erase; /* in sectors */
+ unsigned integ_boundary;/* don't cross erase-group
boundaries */
u8 erased_byte;/* value of erased bytes */
u32 raw_cid[4]; /* raw card CID */
--
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: #pragma GCC warnings (was: Re: [PATCH] crypto: drbg - use pragmas for disabling optimization)
Am Dienstag, 23. Juni 2015, 17:21:06 schrieb Herbert Xu: Hi Herbert, >On Tue, Jun 23, 2015 at 11:17:23AM +0200, Geert Uytterhoeven wrote: >> I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0. >> >> With m68k-linux-gnu-gcc-4.1, which is still my default cross-compiler due >> to the good unused warning reporting, I get: >> >> crypto/jitterentropy.c:235: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:236: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:266: warning: ignoring #pragma GCC pop_options >> crypto/jitterentropy.c:295: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:296: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:336: warning: ignoring #pragma GCC pop_options >> crypto/jitterentropy.c:385: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:386: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:416: warning: ignoring #pragma GCC pop_options >> crypto/jitterentropy.c:517: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:518: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:580: warning: ignoring #pragma GCC pop_options > >Stephan, could you look into moving the relevant functions into >its own file which can then be compiled with -O0? Obviously any >dependency on kernel header files would have to be hidden using >functions outside of this file. I will look into it. Thanks Ciao Stephan -- 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: Linux 4.1 WARNING in drm_ioctl.c
On Tue, Jun 23, 2015 at 08:27:13AM +0100, Daniel Stone wrote: > Hi, > > On 23 June 2015 at 07:39, Daniel Vetter wrote: > > Which drm driver are you using? I didn't spot anything in your module list > > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg > > will tell us for sure. > > That'd be vgem. If so then the below diff should help. -Daniel diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 7a207ca547be..b491fb32cddb 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -328,6 +328,8 @@ static int __init vgem_init(void) goto out; } + drm_dev_set_unique(drm, "vgem"); + ret = drm_dev_register(vgem_device, 0); if (ret) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- 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 4/4] acpi, apei: use EFI memmap to map GHES memory
On Mon, 22 Jun, at 06:11:31AM, Matt Fleming wrote: > > Right, but see my previous comment about x86 discarding a bunch of > attributes for memory regions because the kernel "knows better". > > And in most places, yes, the kernel really does know better. But this > APEI case is special because irrespective of what the kernel says we > want to be compatible with the firmware's memory map. > > And we don't have an API for that. Maybe what we want is a new PAGE_* protection that is compatible with any firmware mappings? That'd be nice because we wouldn't have to introduce a whole new API for this GHES case and ioremap_* could do whatever it wanted under the hood. Thougts? -- Matt Fleming, Intel Open Source Technology Center -- 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] ext4: replace open coded nofail allocation
ext4_free_blocks is looping around the allocation request and mimics
__GFP_NOFAIL behavior without any allocation fallback strategy. Let's
remove the open coded loop and replace it with __GFP_NOFAIL. Without
the flag the allocator has no way to find out never-fail requirement
and cannot help in any way.
Signed-off-by: Michal Hocko
---
Hi Ted,
I am sorry for seding these changes one at the time but I haven't found
a proper way to find all of them automatically. So I am discovering
them as I check the code due to other reasons.
Thanks!
fs/ext4/mballoc.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 8d1e60214ef0..41260489d3bc 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4800,18 +4800,12 @@ void ext4_free_blocks(handle_t *handle, struct inode
*inode,
/*
* blocks being freed are metadata. these blocks shouldn't
* be used until this transaction is committed
+*
+* We use __GFP_NOFAIL because ext4_free_blocks() is not allowed
+* to fail.
*/
- retry:
- new_entry = kmem_cache_alloc(ext4_free_data_cachep, GFP_NOFS);
- if (!new_entry) {
- /*
-* We use a retry loop because
-* ext4_free_blocks() is not allowed to fail.
-*/
- cond_resched();
- congestion_wait(BLK_RW_ASYNC, HZ/50);
- goto retry;
- }
+ new_entry = kmem_cache_alloc(ext4_free_data_cachep,
+ GFP_NOFS|__GFP_NOFAIL);
new_entry->efd_start_cluster = bit;
new_entry->efd_group = block_group;
new_entry->efd_count = count_clusters;
--
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/
