Re: [PATCH] hugepage: allow parallelization of the hugepage fault path
On 07/18/2013 03:50 AM, Davidlohr Bueso wrote:
From: David Gibson
At present, the page fault path for hugepages is serialized by a
single mutex. This is used to avoid spurious out-of-memory conditions
when the hugepage pool is fully utilized (two processes or threads can
race to instantiate the same mapping with the last hugepage from the
pool, the race loser returning VM_FAULT_OOM). This problem is
specific to hugepages, because it is normal to want to use every
single hugepage in the system - with normal pages we simply assume
there will always be a few spare pages which can be used temporarily
until the race is resolved.
Unfortunately this serialization also means that clearing of hugepages
cannot be parallelized across multiple CPUs, which can lead to very
long process startup times when using large numbers of hugepages.
This patch improves the situation by replacing the single mutex with a
table of mutexes, selected based on a hash, which allows us to know
which page in the file we're instantiating. For shared mappings, the
hash key is selected based on the address space and file offset being faulted.
Similarly, for private mappings, the mm and virtual address are used.
From: Anton Blanchard
[https://lkml.org/lkml/2011/7/15/31]
Forward ported and made a few changes:
- Use the Jenkins hash to scatter the hash, better than using just the
low bits.
- Always round num_fault_mutexes to a power of two to avoid an
expensive modulus in the hash calculation.
I also tested this patch on a large POWER7 box using a simple parallel
fault testcase:
http://ozlabs.org/~anton/junkcode/parallel_fault.c
Command line options:
parallel_fault
Could you explain the meaning of here?
First the time taken to fault 128GB of 16MB hugepages:
40.68 seconds
I can't get any time result after running prallel_fault, how can you get
the number?
Now the same test with 64 concurrent threads:
39.34 seconds
Hardly any speedup. Finally the 64 concurrent threads test with
this patch applied:
0.85 seconds
We go from 40.68 seconds to 0.85 seconds, an improvement of 47.9x
This was tested with the libhugetlbfs test suite, and the PASS/FAIL
count was the same before and after this patch.
From: Davidlohr Bueso
- Cleaned up and forward ported to Linus' latest.
- Cache aligned mutexes.
- Keep non SMP systems using a single mutex.
It was found that this mutex can become quite contended
during the early phases of large databases which make use of huge pages - for
instance
startup and initial runs. One clear example is a 1.5Gb Oracle database, where
lockstat
reports that this mutex can be one of the top 5 most contended locks in the
kernel during
the first few minutes:
hugetlb_instantiation_mutex: 10678 10678
---
hugetlb_instantiation_mutex10678 []
hugetlb_fault+0x9e/0x340
---
hugetlb_instantiation_mutex10678 []
hugetlb_fault+0x9e/0x340
contentions: 10678
acquisitions: 99476
waittime-total: 76888911.01 us
With this patch we see a much less contention and wait time:
&htlb_fault_mutex_table[i]: 383
--
&htlb_fault_mutex_table[i]383 []
hugetlb_fault+0x1eb/0x440
--
&htlb_fault_mutex_table[i]383 []
hugetlb_fault+0x1eb/0x440
contentions:383
acquisitions:120546
waittime-total: 1381.72 us
Signed-off-by: David Gibson
Signed-off-by: Anton Blanchard
Tested-by: Eric B Munson
Signed-off-by: Davidlohr Bueso
---
mm/hugetlb.c | 87 ++--
1 file changed, 73 insertions(+), 14 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 83aff0a..1f6e564 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -52,6 +53,13 @@ static unsigned long __initdata default_hstate_size;
*/
DEFINE_SPINLOCK(hugetlb_lock);
+/*
+ * Serializes faults on the same logical page. This is used to
+ * prevent spurious OOMs when the hugepage pool is fully utilized.
+ */
+static int num_fault_mutexes;
+static struct mutex *htlb_fault_mutex_table cacheline_aligned_in_smp;
+
static inline void unlock_or_release_subpool(struct hugepage_subpool *spool)
{
bool free = (spool->count == 0) && (spool->used_hpages == 0);
@@ -1896,13 +1904,15 @@ static void __exit hugetlb_exit(void)
for_each_hstate(h) {
kobject_put(hstate_kobjs[hstate_index(h)]);
}
-
+ kfree(htlb_fault_mutex_table);
kobject_put(hugepages_kobj);
}
module_exit(hugetlb_exit);
static int __init hugetlb_init(void)
{
+ int i;
+
/* Some platform decide whether they support huge pages at boot
* time. On these, such as powerpc, HPAGE_SHIFT is set t
Re: [PATCH 0/30] ACPI / hotplug / PCI: Major rework + Thunderbolt workarounds
On Wed, Jul 17, 2013 at 4:05 PM, Rafael J. Wysocki wrote: > Hi All, > > Now the series has been rebased on top of current linux-pm.git/linux-next > and tested on two systems with Thunderbolt. Some changes have been made too. > -> > > On Friday, July 12, 2013 01:34:20 AM Rafael J. Wysocki wrote: >> Hi, >> >> I've made some progress with my ACPIPHP rework since I posted the series last >> time and here goes an update. >> >> First off, the previous series was somewhat racy, which should be fixed now. >> Apart from this there's quite some new material on top of the patches I >> posted >> last time (or rather on top of their new versions) and I integrated the >> Thunderbolt series from Mika with that. As a result, >> >> https://patchwork.kernel.org/patch/2817341/ >> >> is required to be applied. >> >> Still untested, still based on 3.10 with ACPI+PM 3.11 material merged on top, >> but this time I don't have any plans to add more patches to the series for >> the >> time being. Also 3.11-rc1 should be out in a couple of days, so I'll be able >> to integrate this work with the previous cleanups series from Gerry and >> myself >> on top of it. >> >> I did my best not to change too much at a time and some steps add stuff that >> is removed by the subsequent ones, so hopefully it is bisectable. >> >> If anyone finds something questionable or outright bogus in these patches, >> please let me know before it's too late. ;-) >> >> [ 1/30] Make bus registration and unregistration symmetric. [Resend] >> [ 2/30] Consolidate acpiphp_enumerate_slots(). [Resend] >> [ 3/30] Fix error code path in register_slot(). [Resend] >> [ 4/30] Introduce hotplug context objects for ACPI device objects >> corresponding >> to PCI hotplug devices. [Update] >> [ 5/30] Unified notify handler for hotplug events. [Update] >> [ 6/30] Drop acpiphp_handle_to_bridge() and use context objects instead of >> it. [Update] >> [ 7/30] Pass entire hotplug context objects (instead of their fields >> individually) to event handling work functions. [Update] >> [ 8/30] Merge hotplug event handling functions. [Update] >> [ 9/30] Drop func field from struct acpiphp_bridge. >> [10/30] Refactor slot allocation code in register_slot(). >> [11/30] Make acpiphp_enumerate_slots() to register all devices on the given >> bus >> and install the notification handler for all of them. >> [12/30] Drop sun field from struct acpiphp_slot. >> [13/30] Use common slot count variable in register_slot(). > > -> The one above has been dropped, because it might cause regressions to > appear > on some systems, but that's not a big deal. > > The numbering of the patches below has changed as a result, so the next one is > [13/30] now and so on. > >> [14/30] Drop flags field from struct acpiphp_bridge. >> [15/30] Embed function structure into struct acpiphp_context. >> [16/30] Drop handle field from struct acpiphp_func. >> [17/30] Drop handle field from struct acpiphp_bridge. >> [18/30] Store parent bridge pointer in function objects and bus pointer in >> slot >> objects. >> [19/30] Rework ACPI namespace scanning and trimming routines. >> [20/30] Drop redundant checks from check_hotplug_bridge(). >> [21/30] Consolidate slot disabling and ejecting >> [22/30] Do not queue up event handling work items for non-hotplug events. >> [23/30] Do not execute _PS0 and _PS3 directly. > > This one was fixed after Mika had reported a problem with it. > >> [24/30] Do not check SLOT_ENABLED in enable_device(). [Thunderbolt series] >> [25/30] Allow slots without new devices to be rescanned. [Thunderbolt >> series] >> [26/30] Check for new devices on enabled slots. [Thunderbolt series, TBD] > > This one was reworked to use acpi_bus_trim() on ACPI device objects > corresponding to PCI devices being removed (it also uses _STA to check the > status of those devices if available). > >> [27/30] Get rid of unused constands in acpiphp.h. [Thunderbolt series] >> [28/30] Sanitize acpiphp_get_(latch)|(adapter)_status(). [Thunderbolt >> series] >> [29/30] Redefine enable_device() and disable_device() (rename and change to >> void). >> [30/30] Clean up the usage of bridge_mutex. > > The one above is [29/30] now and we have added one more patch: > > [30/30] Drop check_sub_bridges() which isn't necessary any more. > > The updated patches follow. > > If you don't hate this stuff, I'll put it into linux-next over the weekend for > further testing. pm/linux-next with those patches breaks acpi root bus hotplug. it is kvm guest: 10:~ # echo "PCI0 3" > /sys/kernel/debug/acpi/sci_notify [ 92.549508] ACPI: ACPI device name is , event code is <3> [ 92.552433] ACPI: Notify event is queued 10:~ # [ 92.554279] ACPI: \_SB_.PCI0: Device eject notify on _handle_hotplug_event_root [ 92.677696] ACPI: Device :00:03.0 -x-> \_SB_.PCI0.S03_ [ 92.679229] ACPI: Device :00:02.0 -x-> \_SB_.PCI0.VGA_ [ 92.680684] ACPI: Device :00:01.3 -x-> \_SB_.PCI0.PX13 [ 9
Re: [PATCH 05/16] usb: musb: dsps: use proper child nodes
On 7/22/2013 11:39 PM, Sebastian Andrzej Siewior wrote:
This moves the two instances from the big node into two child nodes. The
glue layer ontop does almost nothing.
There is one devices containing the (2) phy, (2) usb and later the dma
engine. The usb device is the "glue device" which contains the musb
device as a child. This is what we do ever since.
The new file musb_am335x is just here to prob the new bus and populate
child devices.
There are a lot of changes to the dsps file as a result of the changes:
- musb_core_offset
This is gone. The device tree provides memory ressources information
for the device there is no need to "fix" things
- instances
This is gone as well. If we have two instances then we have have two
child enabled nodes in the device tree. For instance the SoC in beagle
bone has two USB instances but only one has been wired up so there is
no need to load and init the second instance since it won't be used.
- dsps_glue is now per glue device
In the past there was one of this structs but with an array of two and
each instance accessed its variable depending on the platform device
id.
- no unneeded copy of structs
I do not know why struct dsps_musb_wrapper is copied but it is not
necessary. The same goes for musb_hdrc_platform_data which allocated
on demand and then again by platform_device_add_data(). One copy is
enough.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/boot/dts/am335x-bone.dts | 12 ++
arch/arm/boot/dts/am335x-evm.dts | 20 +++
arch/arm/boot/dts/am335x-evmsk.dts | 12 ++
arch/arm/boot/dts/am33xx.dtsi | 89 +++--
drivers/usb/musb/Kconfig | 4 +
drivers/usb/musb/Makefile | 3 +
drivers/usb/musb/musb_am335x.c | 55
drivers/usb/musb/musb_dsps.c | 255 ++---
8 files changed, 279 insertions(+), 171 deletions(-)
create mode 100644 drivers/usb/musb/musb_am335x.c
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 444b4ed..2c2ac84 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,18 @@
status = "okay";
};
+ musb: usb@4740 {
+ status = "okay";
+
+ phy@47401300 {
+ status = "okay";
+ };
+
+ usb@47401000 {
+ status = "okay";
+ };
+ };
+
i2c0: i2c@44e0b000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..a3a642a 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -171,6 +171,26 @@
};
};
+ musb: usb@4740 {
+ status = "okay";
+
+ phy@47401300 {
+ status = "okay";
+ };
+
+ phy@47401b00 {
+ status = "okay";
+ };
+
+ usb@47401000 {
+ status = "no";
+ };
Any reason usb0 is disabled for am33xx evm? Just for testing?
+
+ usb@47401800 {
+ status = "okay";
+ };
+ };
+
i2c1: i2c@4802a000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..766c23a 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -207,6 +207,18 @@
};
};
+ musb: usb@4740 {
+ status = "okay";
+
+ phy@47401300 {
+ status = "okay";
+ };
+
+ usb@47401000 {
+ status = "okay";
+ };
+ };
+
epwmss2: epwmss@48304000 {
status = "okay";
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..81afb27 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -26,6 +26,10 @@
serial5 = &uart5;
d_can0 = &dcan0;
d_can1 = &dcan1;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ phy0 = &usb0_phy;
+ phy1 = &usb1_phy;
};
cpus {
@@ -333,21 +337,78 @@
status = "disabled";
};
- usb@4740 {
- compatible =
Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part
Hi, On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote: > On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote: >> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote: >>> Exynos PCIe IP consists of Synopsys specific part and Exynos >>> specific part. Only core block is a Synopsys designware part; >>> other parts are Exynos specific. >>> Also, the Synopsys designware part can be shared with other >>> platforms; thus, it can be split two parts such as Synopsys >>> designware part and Exynos specific part. >> >> some more queries and comments.. > . . . . >>> + of_pci_range_to_resource(&range, np, &pp->cfg); >>> + pp->config.cfg0_size = resource_size(&pp->cfg)/2; >>> + pp->config.cfg1_size = resource_size(&pp->cfg)/2; >>> + } >>> + } >>> + >>> + pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start, >>> + resource_size(&pp->cfg)); >> >> Why is configuraion space divided into two? > > Sorry, I don't know the exact reason. :( > Pratyush Anand may know about this. > Pratyush Anand, could you answer the question? > > Also, if you find some problems, please let me know. > > >> Why should it be same as dbi_base? >> AFAIK, jacinto6 has a dedicated configuration/io/memory space that is >> entirely >> different from dbi_base. > > According to the Synopsys designware PCIe datasheet, > in chapter 5.1.1 Register Space Layout, > 'Port Logic Registers' are placed between (config space 0x0 + 0x700) > and (config space 0x0 + 0xFFF). > 'dbi_base' is used for reading/writing 'Port Logic Registers'. > Exynos are using 'dbi_base' like this. Thus, the base addresses of > both 'dbi_base' and configuration/io/memory space are same. > > Just now, I looked at Spear PCIe driver. > However, in the case of Spear, the base address of configuration/io/memory > space is defined as 0x8000. The base address of 'Port Logic Registers' > is defined as 0xb100. > I think that the situation of 'jacinto6' is similar with Spear, right? > > Then, I will move pp->dbi_base mapping code from pcie-designware.c > to pci-exynos.c. I think you need not move this to exynos (since registers in dbi_base is common for all platforms) but modify the pcie-designware.c to use different address space for dbi_base. In your case, you'll duplicate the address space for dbi_base and configuration space. Also I have one more query. In your dt binding, your pci address and cpu address is the same. But the pci address should start at 0x and end at 0x (for 32bit). Shouldn't the cpu address map to something within this range of pci address? Thanks Kishon -- 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: 3.11-rc regression bisected: s2disk does not work (was Re: [PATCH v3 13/16] futex: use freezable blocking call)
On Mon, Jul 22, 2013 at 6:41 PM, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 05:42:49 PM Colin Cross wrote:
>> On Mon, Jul 22, 2013 at 5:32 PM, Linus Torvalds
>> wrote:
>> > On Mon, Jul 22, 2013 at 4:55 PM, Colin Cross wrote:
>> >>
>> >> I think the right solution is to add a flag to the freezing task that
>> >> marks it unfreezable. I think PF_NOFREEZE would work, although it is
>> >> normally used on kernel threads, can you see if the attached patch
>> >> helps?
>> >
>> > Hmm. That does seem to be the right thing to do, but I wonder about
>> > the *other* callers of freeze_processes() IOW, kexec and friends.
>> >
>> > So maybe we should do this in {freeze|thaw}_processes() itself, and
>> > just make the rule be that the caller of freeze_processes() itself is
>> > obviously not frozen, and has to be the same one that then thaws
>> > things?
>> >
>> > Colin? Rafael? Comments?
>> >
>> > Linus
>>
>> I was worried about clearing the flag in thaw_processes(). If a
>> kernel thread with PF_NOFREEZE set ever called thaw_processes(), which
>> autosleep might do, it would clear the flag. Or if a different thread
>> called freeze_processes() and thaw_processes().
>
> Is that legitimate?
Nothing precludes it today, but I don't see any need for it. I'll add
a comment when I add the flag.
>> All the other callers besides the SNAPSHOT_FREEZE ioctl stay in the kernel
>> between freeze_processes() and thaw_processes(), which makes the fanout of
>> places that could call try_to_freeze() much more controllable.
>>
>> Using a new flag that operates like PF_NOFREEZE but doesn't conflict
>> with it, or a nofreeze_depth counter, would also work.
>
> Well, that would be robust enough. At least if the purpose of that new flag
> is clearly specified, people hopefully won't be tempted to optimize it away in
> the future.
>
> Thanks,
> Rafael
OK, I'll add a new flag.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A
On Mon, 2013-07-22 at 20:47 +0100, Ben Hutchings wrote: > On Mon, 2013-07-22 at 11:47 -0700, Eric Dumazet wrote: > > On Mon, 2013-07-22 at 19:38 +0100, Ben Hutchings wrote: > > > On Mon, 2013-07-22 at 11:29 -0700, Grant Grundler wrote: > > > > On Mon, Jul 22, 2013 at 10:07 AM, Eric Dumazet > > > > wrote: > > > > ... > > > > > I guess that if a driver does not advertise NETIF_F_SG, this > > > > > skb_linearize() call is not needed : All frames reaching your xmit > > > > > function should already be linear > > > > > > > > As Ben Hutchings pointed out, hw_features is still setting this...but > > > > I'm not sure how that matters. > > > > > > > > ax88179_set_features() doesn't allow setting SG or TSO features. But > > > > I expect it would be "not too difficult" to add such that ethtool > > > > could set those features after boot. > > > [...] > > > > > > It already can. That's what putting feature flags in hw_features does. > > > > My original concern, that inspired this patch, was to remove SG support, > > as this driver does not have SG support at all. > > > > Linearize a full TSO packet needs order-5 allocations, thats likely to > > fail and lead to very slow TCP performance, because it will only rely on > > retransmits. > > The driver could set gso_max_size to reduce that problem. But I rather > doubt that TSO followed by skb_linearize() significantly improves > throughput or CPU-efficiency. (If the device has a 1G link but is > connected to the host through a USB 2.0 port, then USB is the bottleneck > and TSO could improve throughput a few percent. But that's a silly > configuration.) > > The real solution would be for someone to add SG support to the usbnet > core. Trying to support 1GbE with only linear skbs is not a great > idea... and it can only be a matter of time before there is USB ultra > speed (or whatever comes after 'super') with 10GbE devices... > This sounds a good idea. Is anybody working on adding SG to usbnet ? -- 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 06/16] usb: musb: dsps: rename ti81xx_driver_data to am33xx_driver_data
Hi Sebastian, On 7/22/2013 11:39 PM, Sebastian Andrzej Siewior wrote: This patch renames the type struct from ti81xx_driver_data to am33xx_driver_data since it is not used for ti81xx anymore. The EOI member is also removed since the am33xx SoC does not have such register. The interrupt is acknowledged by writting into the stat register. AM335X TRM Section 16.6.5 and 16.7.5 describes about EOI registers. Its at offset 0x24. Or is it that the interrupts are acknowledged even without writing to eoi register? -- -George -- 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] tools, perf: Add a precise event qualifier v2
On Tue, Jul 23, 2013 at 01:40:40AM -0400, Vince Weaver wrote: > On Mon, 22 Jul 2013, Andi Kleen wrote: > > > From: Andi Kleen > > > > Add a precise qualifier, like cpu/event=0x3c,precise=1/ > > So you're adding this to "events/" but not to "format/"? Fair point, but note that precise_ip is a bitfield. Since there is no way to express that currently the parser would need to special case it anyways. So it could be just added as precise_ip: precise_ip in events/, but I have some doubts that really helps anyone. Or invent some new syntax to abstract the bitfields, but that also would need changes. > This will break various existing programs. Like what? -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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: [tip:perf/core] perf tools: Make Power7 events available for perf
On Tue, 2013-07-23 at 01:33 -0400, Vince Weaver wrote: > On Fri, 19 Jul 2013, tip-bot for Runzhen Wang wrote: > > > perf tools: Make Power7 events available for perf > > > > This patch makes all the POWER7 events available in sysfs. So we can > > instead specify these as: > > > > $ size arch/powerpc/perf/power7-pmu.o > >text data bss dec hex filename > >3073 2720 0579316a1 arch/powerpc/perf/power7-pmu.o > > > > and after the patch is applied, it is: > > > > $ size arch/powerpc/perf/power7-pmu.o > >text data bss dec hex filename > > 15950 31112 0 47062b7d6 arch/powerpc/perf/power7-pmu.o > > > so we're really going down this road? _We_ are going down this road, at least until there is a better solution. You'll notice I haven't merged any events for power8. > If x86 follows this precedent we're going to end up with 300k+ of > event names in the kernel. And as a reminder, perf_event cannot > be disabled on x86, nor can it be compiled as a module. So that would > be 300k of event names in every kernel for everyone, even those not using > perf. x86 can do what it wants. I don't think anyone in x86 land has proposed putting all the events in the kernel, so you can stop worrying about your 300k of memory. I thought it was pretty clear from the last thread that folks agreed the event _lists_ should be in userspace. The discovery of the PMUs should be done in the kernel, and that should be communicated to userspace via something in sys. What it needs now is someone with some free time to actually code it up. Right now that's not me. cheers -- 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] mm: kill one if in loop of __free_pages_bootmem
On Mon, Jul 22, 2013 at 07:17:42PM -0700, Yinghai Lu wrote: > We should not check loop+1 with loop end in loop body. > Just duplicate two lines code to avoid it. > > That will help a bit when we have huge amount of pages on > system with 16TiB memory. > > Signed-off-by: Yinghai Lu > Cc: Mel Gorman Disassembly looks good, thanks! Acked-by: Johannes Weiner -- 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/15] drivers: phy: add generic PHY framework
Hi,
On Monday 22 July 2013 08:14 PM, Alan Stern wrote:
> On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
>
>>> The PHY and the controller it is attached to are both physical
>>> devices.
>>>
>>> The connection between them is hardwired by the system
>>> manufacturer and cannot be changed by software.
>>>
>>> PHYs are generally described by fixed system-specific board
>>> files or by Device Tree information. Are they ever discovered
>>> dynamically?
>>
>> No. They are created just like any other platform devices are created.
>
> Okay. Are PHYs _always_ platform devices?
Not always. It can be any other device also.
>
>>> Is the same true for the controllers attached to the PHYs?
>>> If not -- if both a PHY and a controller are discovered
>>> dynamically -- how does the kernel know whether they are
>>> connected to each other?
>>
>> No differences here. Both PHY and controller will have dt information or
>> hwmod
>> data using which platform devices will be created.
>>>
>>> The kernel needs to know which controller is attached to which
>>> PHY. Currently this information is represented by name or ID
>>> strings embedded in platform data.
>>
>> right. It's embedded in the platform data of the controller.
>
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?
>
>>> The PHY's driver (the supplier) uses the platform data to
>>> construct a platform_device structure that represents the PHY.
>>
>> Currently the driver assigns static labels (corresponding to the label used
>> in
>> the platform data of the controller).
>>> Until this is done, the controller's driver (the client) cannot
>>> use the PHY.
>>
>> right.
>>>
>>> Since there is no parent-child relation between the PHY and the
>>> controller, there is no guarantee that the PHY's driver will be
>>> ready when the controller's driver wants to use it. A deferred
>>> probe may be needed.
>>
>> right.
>>>
>>> The issue (or one of the issues) in this discussion is that
>>> Greg does not like the idea of using names or IDs to associate
>>> PHYs with controllers, because they are too prone to
>>> duplications or other errors. Pointers are more reliable.
>>>
>>> But pointers to what? Since the only data known to be
>>> available to both the PHY driver and controller driver is the
>>> platform data, the obvious answer is a pointer to platform data
>>> (either for the PHY or for the controller, or maybe both).
>>
>> hmm.. it's not going to be simple though as the platform device for the PHY
>> and
>> controller can be created in entirely different places. e.g., in some cases
>> the
>> PHY device is a child of some mfd core device (the device will be created in
>> drivers/mfd) and the controller driver (usually) is created in board file. I
>> guess then we have to come up with something to share a pointer in two
>> different files.
>
> The ability for two different source files to share a pointer to a data
> item defined in a third source file has been around since long before
> the C language was invented. :-)
>
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is. Let's take a simple
> example. Suppose the system design includes a PHY named "foo". Then
> the board file could contain:
>
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
>
> and a header file would contain:
>
> extern struct phy_info phy_foo;
>
> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> client could call phy_find(&phy_foo). Or something like that; make up
> your own structure tags and function names.
Alright. Thanks for the hint :-)
Thanks
Kishon
--
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] um: change defconfig to stop spawning xterm
Adding Al again, someone dropped him from the CC list... On Tue, Jul 23, 2013 at 7:40 AM, Richard Weinberger wrote: > Lennart, > > Am 23.07.2013 00:32, schrieb Lennart Poettering: >> On Mon, 22.07.13 16:13, Ramkumar Ramachandra (artag...@gmail.com) wrote: >> >>> >>> [Corrected Lennart's email ID] >>> >>> Richard Weinberger wrote: CC'ing Lennart. Am 22.07.2013 11:45, schrieb Ramkumar Ramachandra: > Ramkumar Ramachandra wrote: >> [1]: >> http://lists.freedesktop.org/archives/systemd-devel/2013-July/012152.html > > ... and the patches were rejected. Lennart says that UML providing > /dev/tty* is wrong, and that UML should call them /dev/hvc* (or > something). Can we do something about the situation? Can we remove > /dev/tty*, and provide /dev/hvc*? Will we be breaking existing users? > > Thanks. > > Lennart Poettering wrote: >> UML shouldn't be penalized for not implementing some terminal emulation, >> but it should be penalized for doing so under the label of "VT support", >> which it simply is not providing. >> >> They can call their ttys any way they want. If the call them >> /dev/tty[1..64] however, then they need to implement the VC >> interfaces. All of them. Lennart, can you please explain us why /dev/tty[1..64] is forced to have virtual console support? >> >> /dev/tty[1..64] is the userspace API to the kernel VT subsystem. If you >> support it you need to match up all /dev/tty[1..64] with a >> /dev/vcs[1..64] + /dev/vcsa[1..64]. You need to expose a tty that >> understands TERM=linux and the ioctls listed on console_ioctl(4). You >> need /dev/tty0 as something that behaves like a symlink to the fg >> VT. You should also support files like /sys/class/tty/tty0/active with >> its POLLHUP iface. > > I sightly disagree with you. > /dev/tty[1..64] is not directly bound to VT. > You can have systems with CONFIG_VT=n and still have /dev/tty[1..64]. > Linux supports this perfectly. > UML does not have VT because having virtual consoles makes no sense. > (Same like on s390) > > Thanks, > //richard > -- > 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/ -- Thanks, //richard -- 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] um: change defconfig to stop spawning xterm
Lennart, Am 23.07.2013 00:32, schrieb Lennart Poettering: > On Mon, 22.07.13 16:13, Ramkumar Ramachandra (artag...@gmail.com) wrote: > >> >> [Corrected Lennart's email ID] >> >> Richard Weinberger wrote: >>> CC'ing Lennart. >>> >>> Am 22.07.2013 11:45, schrieb Ramkumar Ramachandra: Ramkumar Ramachandra wrote: > [1]: > http://lists.freedesktop.org/archives/systemd-devel/2013-July/012152.html ... and the patches were rejected. Lennart says that UML providing /dev/tty* is wrong, and that UML should call them /dev/hvc* (or something). Can we do something about the situation? Can we remove /dev/tty*, and provide /dev/hvc*? Will we be breaking existing users? Thanks. Lennart Poettering wrote: > UML shouldn't be penalized for not implementing some terminal emulation, > but it should be penalized for doing so under the label of "VT support", > which it simply is not providing. > > They can call their ttys any way they want. If the call them > /dev/tty[1..64] however, then they need to implement the VC > interfaces. All of them. >>> >>> Lennart, can you please explain us why /dev/tty[1..64] is forced to >>> have virtual console support? > > /dev/tty[1..64] is the userspace API to the kernel VT subsystem. If you > support it you need to match up all /dev/tty[1..64] with a > /dev/vcs[1..64] + /dev/vcsa[1..64]. You need to expose a tty that > understands TERM=linux and the ioctls listed on console_ioctl(4). You > need /dev/tty0 as something that behaves like a symlink to the fg > VT. You should also support files like /sys/class/tty/tty0/active with > its POLLHUP iface. I sightly disagree with you. /dev/tty[1..64] is not directly bound to VT. You can have systems with CONFIG_VT=n and still have /dev/tty[1..64]. Linux supports this perfectly. UML does not have VT because having virtual consoles makes no sense. (Same like on s390) Thanks, //richard -- 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] tools, perf: Add a precise event qualifier v2
On Mon, 22 Jul 2013, Andi Kleen wrote: > From: Andi Kleen > > Add a precise qualifier, like cpu/event=0x3c,precise=1/ So you're adding this to "events/" but not to "format/"? This breaks the ABI, which specifies that the only fields that can appear in a sysfs events specifier must exist under the format directory. This was what I worried about when I said people are going to start leaking perf tool specific events into the kernel sysfs tree. This will break various existing programs. Vince -- 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/15] drivers: phy: add generic PHY framework
Hi, On Monday 22 July 2013 08:34 PM, Greg KH wrote: > On Mon, Jul 22, 2013 at 12:55:18PM +0530, Kishon Vijay Abraham I wrote: >>> The issue (or one of the issues) in this discussion is that >>> Greg does not like the idea of using names or IDs to associate >>> PHYs with controllers, because they are too prone to >>> duplications or other errors. Pointers are more reliable. >>> >>> But pointers to what? Since the only data known to be >>> available to both the PHY driver and controller driver is the >>> platform data, the obvious answer is a pointer to platform data >>> (either for the PHY or for the controller, or maybe both). >> >> hmm.. it's not going to be simple though as the platform device for the PHY >> and >> controller can be created in entirely different places. e.g., in some cases >> the >> PHY device is a child of some mfd core device (the device will be created in >> drivers/mfd) and the controller driver (usually) is created in board file. I >> guess then we have to come up with something to share a pointer in two >> different files. > > What's wrong with using the platform_data structure that is unique to > all boards (see include/platform_data/ for examples)? Isn't that what > this structure is there for? Alright. I got some ideas from Alan Stern. I'll use it with platform_data and repost the series. Thanks Kishon -- 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: [tip:perf/core] perf tools: Make Power7 events available for perf
On Fri, 19 Jul 2013, tip-bot for Runzhen Wang wrote: > perf tools: Make Power7 events available for perf > > This patch makes all the POWER7 events available in sysfs. So we can > instead specify these as: > > $ size arch/powerpc/perf/power7-pmu.o >text data bss dec hex filename >3073 2720 0579316a1 arch/powerpc/perf/power7-pmu.o > > and after the patch is applied, it is: > > $ size arch/powerpc/perf/power7-pmu.o >text data bss dec hex filename > 15950 31112 0 47062b7d6 arch/powerpc/perf/power7-pmu.o so we're really going down this road? If x86 follows this precedent we're going to end up with 300k+ of event names in the kernel. And as a reminder, perf_event cannot be disabled on x86, nor can it be compiled as a module. So that would be 300k of event names in every kernel for everyone, even those not using perf. This belongs in userspace. Vince -- 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/5] drm/i915: Add async page flip support for IVB
On Mon, Jul 22, 2013 at 06:50:01PM -0700, Keith Packard wrote:
> This adds the necesary register defines for async page flipping
> through the command ring, and then hooks those up for Ivybridge (gen7)
> page flipping.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_display.c | 40
> ++--
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dc3d6a7..029cfb0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -209,6 +209,7 @@
> #define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
> #define MI_DISPLAY_FLIP MI_INSTR(0x14, 2)
> #define MI_DISPLAY_FLIP_I915 MI_INSTR(0x14, 1)
> +#define MI_DISPLAY_FLIP_ASYNC_INDICATOR(1 << 22)
> #define MI_DISPLAY_FLIP_PLANE(n) ((n) << 20)
> /* IVB has funny definitions for which plane to flip. */
> #define MI_DISPLAY_FLIP_IVB_PLANE_A (0 << 19)
> @@ -217,6 +218,11 @@
> #define MI_DISPLAY_FLIP_IVB_SPRITE_B (3 << 19)
> #define MI_DISPLAY_FLIP_IVB_PLANE_C (4 << 19)
> #define MI_DISPLAY_FLIP_IVB_SPRITE_C (5 << 19)
> +/* These go in the bottom of the base address value */
> +#define MI_DISPLAY_FLIP_TYPE_SYNC(0 << 0)
> +#define MI_DISPLAY_FLIP_TYPE_ASYNC (1 << 0)
> +#define MI_DISPLAY_FLIP_TYPE_STEREO (2 << 0)
> +#define MI_DISPLAY_FLIP_TYPE_SYNCHRONOUS (0 << 0)
> #define MI_ARB_ON_OFFMI_INSTR(0x08, 0)
> #define MI_ARB_ENABLE (1<<0)
> #define MI_ARB_DISABLE (0<<0)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bdb8854..1bcc6b4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7514,6 +7514,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> struct intel_ring_buffer *ring = &dev_priv->ring[BCS];
> uint32_t plane_bit = 0;
> + uint32_t cmd;
> + uint32_t base;
> int ret;
>
> ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
> @@ -7536,13 +7538,43 @@ static int intel_gen7_queue_flip(struct drm_device
> *dev,
> goto err_unpin;
> }
>
> + cmd = MI_DISPLAY_FLIP_I915 | plane_bit;
> + base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
> +
> + if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
> +
> + /* XXX check limitations for async flip here */
> +
> + if (fb->pitches[0] != I915_READ(DSPSTRIDE(intel_crtc->plane))) {
> + WARN_ONCE(1, "mismatching stride in async plane flip
> (%d != %d)\n",
> + fb->pitches[0],
> I915_READ(DSPSTRIDE(intel_crtc->plane)));
> + ret = -EINVAL;
> + goto err_unpin;
> + }
> +
> + if (obj->tiling_mode != I915_TILING_X) {
> + WARN_ONCE(1, "async plane flip requires X tiling\n");
> + ret = -EINVAL;
> + goto err_unpin;
> + }
Matching tiling modes is actually already a requirement on gen4+ (since
the tiling bit and the linear/tiled offset registers can't be changed with
a MI_DISPLAY_FLIP command). But atm we fail to check that in the common
code, so imo better to move that to there.
We already check for matching strides in common code, so with the tile
check added we could drop this all here.
-Daniel
> +
> + if ((I915_READ(DSPCNTR(intel_crtc->plane)) & DISPPLANE_TILED)
> == 0) {
> + WARN_ONCE(1, "display not currently tiled in async
> plane flip\n");
> + ret = -EINVAL;
> + goto err_unpin;
> + }
> +
> + cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
> + base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
> + }
> +
> ret = intel_ring_begin(ring, 4);
> if (ret)
> goto err_unpin;
>
> - intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
> + intel_ring_emit(ring, cmd);
> intel_ring_emit(ring, (fb->pitches[0] | obj->tiling_mode));
> - intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) +
> intel_crtc->dspaddr_offset);
> + intel_ring_emit(ring, base);
> intel_ring_emit(ring, (MI_NOOP));
>
> intel_mark_page_flip_active(intel_crtc);
> @@ -9705,6 +9737,10 @@ void intel_modeset_init(struct drm_device *dev)
> dev->mode_config.max_width = 8192;
> dev->mode_config.max_height = 8192;
> }
> +
> + if (IS_GEN7(dev))
> + dev->mode_config.async_page_flip = true;
> +
> dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
>
> DRM_DEBUG_KMS("%d display pipe%s available.\n",
> --
> 1.8.3.2
>
> ___
> dri-devel mail
Re: [PATCH 01/18] MAINTAINERS: EXYNOS - Remove board files
On Mon, Jul 22, 2013 at 9:15 AM, Joe Perches wrote:
> ommit ca9143501c30 ("ARM: EXYNOS: Remove unused board files")
> removed the files, remove the patterns too.
>
> Signed-off-by: Joe Perches
> cc: Tomasz Figa
> cc: Kyungmin Park
Acked-by: Kyungmin Park
> cc: Kukjin Kim
> ---
> MAINTAINERS | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf61e04..2124104 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1154,8 +1154,6 @@ L:linux-arm-ker...@lists.infradead.org
> (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/mach-s5pv210/mach-aquila.c
> F: arch/arm/mach-s5pv210/mach-goni.c
> -F: arch/arm/mach-exynos/mach-universal_c210.c
> -F: arch/arm/mach-exynos/mach-nuri.c
>
> ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
> M: Kyungmin Park
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
> --
> 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/
--
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/
WARNING: CPU: 3 PID: 2701 at drivers/gpu/drm/nouveau/nouveau_gem.c:54 nouveau_gem_object_del+0xa8/0xc0()
Moin,
I got this on 3.11-rc1+ when halting the box:
[ 883.476242] [ cut here ]
[ 883.480927] WARNING: CPU: 3 PID: 2701 at
drivers/gpu/drm/nouveau/nouveau_gem.c:54 nouveau_gem_object_del+0xa8/0xc0()
[ 883.491545] Modules linked in: ntfs msdos dm_mod ext2 vfat fat loop fuse
usbhid snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp kvm_intel kvm
snd_hda_codec_realtek snd_hda_intel snd_hda_codec crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel ehci_pci xhci_hcd iTCO_wdt acpi_cpufreq
snd_hwdep aesni_intel ehci_hcd aes_x86_64 mperf glue_helper button snd_pcm
i2c_i801 iTCO_vendor_support snd_page_alloc usbcore dcdbas lrw gf128mul
processor snd_timer pcspkr sb_edac ablk_helper evdev edac_core usb_common
lpc_ich cryptd snd mfd_core soundcore microcode
[ 883.542505] CPU: 3 PID: 2701 Comm: Xorg Not tainted 3.11.0-rc1+ #4
[ 883.548746] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08
01/24/2013
[ 883.556214] 0009 88043b087ca0 815fc47d
[ 883.563735] 88043b087cd8 81047e6c 8804302a8800
88043c2cc600
[ 883.571252] 88043d6da000 0009 88043b087d70
88043b087ce8
[ 883.578780] Call Trace:
[ 883.581265] [] dump_stack+0x54/0x74
[ 883.586463] [] warn_slowpath_common+0x8c/0xc0
[ 883.592523] [] warn_slowpath_null+0x1a/0x20
[ 883.598408] [] nouveau_gem_object_del+0xa8/0xc0
[ 883.604657] [] drm_gem_object_free+0x2a/0x30
[ 883.610630] [] drm_gem_object_release_handle+0xa8/0xd0
[ 883.617497] [] idr_for_each+0xb6/0x110
[ 883.622952] [] ? drm_gem_vm_close+0x80/0x80
[ 883.628851] [] ? mutex_unlock+0xe/0x10
[ 883.634304] [] drm_gem_release+0x20/0x30
[ 883.639933] [] drm_release+0x5ba/0x650
[ 883.645397] [] __fput+0xff/0x250
[ 883.650317] [] fput+0xe/0x10
[ 883.655244] [] task_work_run+0xb5/0xe0
[ 883.660706] [] do_exit+0x2b3/0xa40
[ 883.665808] [] ? retint_swapgs+0xe/0x13
[ 883.671343] [] do_group_exit+0x49/0xc0
[ 883.676803] [] SyS_exit_group+0x17/0x20
[ 883.682351] [] system_call_fastpath+0x1a/0x1f
[ 883.688418] ---[ end trace 9e774929633864b2 ]---
[ 883.693096]
[ 883.694609] ==
[ 883.700852] [ INFO: possible circular locking dependency detected ]
[ 883.707204] 3.11.0-rc1+ #4 Tainted: GW
[ 883.711955] ---
[ 883.718292] Xorg/2701 is trying to acquire lock:
[ 883.722969] (reservation_ww_class_mutex){+.+.+.}, at: []
nouveau_bo_unpin+0x3c/0x120
[ 883.732548]
[ 883.732548] but task is already holding lock:
[ 883.738446] (&dev->struct_mutex){+.+.+.}, at: []
drm_gem_object_release_handle+0x7a/0xd0
[ 883.748387]
[ 883.748387] which lock already depends on the new lock.
[ 883.748387]
[ 883.756649]
[ 883.756649] the existing dependency chain (in reverse order) is:
[ 883.764211]
-> #1 (&dev->struct_mutex){+.+.+.}:
[ 883.769051][] lock_acquire+0x8a/0x120
[ 883.775066][] mutex_lock_nested+0x75/0x380
[ 883.781516][] validate_fini_list.isra.7+0xde/0x130
[ 883.788662][] validate_fini_no_ticket+0x20/0x50
[ 883.79][] validate_fini+0x12/0x50
[ 883.801566][]
nouveau_gem_ioctl_pushbuf+0x3a2/0x16a0
[ 883.808887][] drm_ioctl+0x559/0x690
[ 883.814721][] do_vfs_ioctl+0x97/0x590
[ 883.820737][] SyS_ioctl+0x50/0x90
[ 883.826382][] system_call_fastpath+0x1a/0x1f
[ 883.832999]
-> #0 (reservation_ww_class_mutex){+.+.+.}:
[ 883.838523][] __lock_acquire+0x1c54/0x1d40
[ 883.844963][] lock_acquire+0x8a/0x120
[ 883.850965][] mutex_lock_nested+0x75/0x380
[ 883.857401][] nouveau_bo_unpin+0x3c/0x120
[ 883.864402][] nouveau_gem_object_del+0x95/0xc0
[ 883.871831][] drm_gem_object_free+0x2a/0x30
[ 883.878998][]
drm_gem_object_release_handle+0xa8/0xd0
[ 883.887030][] idr_for_each+0xb6/0x110
[ 883.893659][] drm_gem_release+0x20/0x30
[ 883.900456][] drm_release+0x5ba/0x650
[ 883.907060][] __fput+0xff/0x250
[ 883.913113][] fput+0xe/0x10
[ 883.919163][] task_work_run+0xb5/0xe0
[ 883.925738][] do_exit+0x2b3/0xa40
[ 883.931959][] do_group_exit+0x49/0xc0
[ 883.938520][] SyS_exit_group+0x17/0x20
[ 883.945170][] system_call_fastpath+0x1a/0x1f
[ 883.952349]
[ 883.952349] other info that might help us debug this:
[ 883.952349]
[ 883.962128] Possible unsafe locking scenario:
[ 883.962128]
[ 883.969252]CPU0CPU1
[ 883.974396]
[ 883.979532] lock(&dev->struct_mutex);
[ 883.984013]lock(reservation_ww_class_mutex);
[ 883.991723]lock(&dev->struct_mutex);
[ 883.998725] lock(reservation_ww_class_mutex);
[ 884.003888]
[ 884.003888] *** DEADLOCK ***
[ 884.003888]
[ 884
Re: [PATCH] RTC: Add an alarm disable quirk
On Mon, Jul 22, 2013 at 03:17:33PM -0700, John Stultz wrote: > Thanks again for your interest in hunting this down. Yeah, "interest" is a good euphemism for "it pisses the h*ll out of me" :-) Btw, the failing box runs a SLED11 kernel (3.0.x + a lot of patches) while the good box will run latest upstream. Let's see how relevant that would be wrt rtc-cmos. Let me start playing and see how far we can go... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] decompressors: fix "no limit" output buffer length
On 07/23/2013 12:32 PM, Stephen Warren wrote: On 07/22/2013 07:15 PM, Alex Courbot wrote: ... Although the patch seems ok to me in its current form, there are two points for which I still have small doubts: 1) Whether size_t and pointers will have the same size on all platforms. ptrsize_t? Do you mean ptrdiff_t? (I cannot find ptrsize_t anywhere in the kernel) Looking further about the uses of size_t and ptrdiff_t, it seems like size_t is designed to store the maximum addressable member of an array, whereas ptrdiff_t is used to store a substraction of two pointers. In effect, they translate to the unsigned (size_t) and signed (ptrdiff_t) variants of the same type. But since here we know that the result of the substraction will always be positive and potentially big (for devices with memory in the lower half of the address space) using size_t sounds safer to avoid overflows and sign-conversion issues (strm->avail_out, where the value of out_len eventually ends, is an unsigned int). So point 1) at least seems to be handled correctly with size_t. Point 2) might still be of concern, but if your uncompressed kernel image ends up overflowing your addressable memory, I guess you have a bigger problem to start with. :) Andrew, do you think you can merge this as-is? Sorry if you are not the right person to ask, but there is no clear maintainer for this part of the code and you appear to have handled the latest patches that affect the same file. Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpuidle/pseries: Fix kernel command line parameter smt-snooze-delay
smt-snooze-delay is a tun-able provided currently on powerpc to delay the
entry of an idle cpu to NAP state. By default, the value is 100us,
which is entry criteria for NAP state i.e only if the idle period is
above 100us it would enter NAP. Value of -1 disables entry into NAP.
This value can be set either through sysfs, ppc64_cpu util or by
passing it via kernel command line. Currently this feature is broken
when the value is passed via the kernel command line.
This patch aims to fix this, by taking the appropriate action
based on the value after the pseries driver is registered.
This check is carried on in the back-end driver rather than
setup_smt_snooze_delay(), as one is not sure if the cpuidle driver
is even registered when setup routine is executed.
Also, this fixes re-enabling of NAP states by setting appropriate
value without having to reboot using smt-snooze-delay parameter.
Also, to note is, smt-snooze-delay is per-cpu variable.
This can be used to enable/disable NAP on per-cpu
basis using sysfs but when this variable is passed
via kernel command line or using the smt-snooze-delay
it applies to all the cpus. Per-cpu tuning can
only be done via sysfs.
Signed-off-by: Deepthi Dharwar
---
arch/powerpc/platforms/pseries/processor_idle.c | 34 ++-
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index 4644efa0..8133f50 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -170,18 +170,36 @@ static struct cpuidle_state
shared_states[MAX_IDLE_STATE_COUNT] = {
void update_smt_snooze_delay(int cpu, int residency)
{
struct cpuidle_driver *drv = cpuidle_get_driver();
- struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
+ struct cpuidle_device *dev;
if (cpuidle_state_table != dedicated_states)
return;
- if (residency < 0) {
- /* Disable the Nap state on that cpu */
- if (dev)
- dev->states_usage[1].disable = 1;
- } else
- if (drv)
+ if (!drv)
+ return;
+
+ if (cpu == -1) {
+ if (residency < 0) {
+ /* Disable NAP on all cpus */
+ drv->states[1].disabled = true;
+ } else {
drv->states[1].target_residency = residency;
+ drv->states[1].disabled = false;
+ }
+ return;
+ }
+
+ dev = per_cpu(cpuidle_devices, cpu);
+ if (!dev)
+ return;
+
+ if (residency < 0)
+ dev->states_usage[1].disable = 1;
+ else {
+ drv->states[1].target_residency = residency;
+ drv->states[1].disabled = false;
+ dev->states_usage[1].disable = 0;
+ }
}
static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
@@ -331,6 +349,8 @@ static int __init pseries_processor_idle_init(void)
return retval;
}
+ update_smt_snooze_delay(-1, per_cpu(smt_snooze_delay, 0));
+
retval = pseries_idle_devices_init();
if (retval) {
pseries_idle_devices_uninit();
Regards,
Deepthi
--
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-3.11-rc1: Internal error: Oops - undefined instruction: 0 [#1] SMP ARM on OMAP3/AM335x
Hi Roger, On Mon, Jul 22, 2013 at 6:30 AM, Roger Quadros wrote: > Hi, > > I observe the following problem on booting v3.11-rc1 on OMAP3 beagle board. > > [5.888946] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > [5.896057] Modules linked in: > [5.899322] CPU: 0 PID: 9 Comm: rcu_sched Not tainted > 3.11.0-rc2-1-g1ea701a #876 > [5.907501] task: ce0720c0 ti: ce07a000 task.ti: ce07a000 > [5.913208] PC is at check_and_switch_context+0x130/0x4dc > [5.918914] LR is at check_and_switch_context+0xd8/0x4dc Got the same issue on a mx53 and prepared a fix. Will submit it shortly. Regards, Fabio Estevam -- 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] pci: exynos: split into two parts such as Synopsys part and Exynos part
On 7/23/2013 6:44 AM, Jingoo Han wrote:
+ if (restype == IORESOURCE_MEM) {
> >+ of_pci_range_to_resource(&range, np, &pp->mem);
> >+ pp->mem.name = "MEM";
> >+ pp->config.mem_size = resource_size(&pp->mem);
> >+ pp->config.mem_bus_addr = range.pci_addr;
> >+ }
> >+ if (restype == 0) {
> >+ of_pci_range_to_resource(&range, np, &pp->cfg);
> >+ pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> >+ pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> >+ }
> >+ }
> >+
> >+ pp->dbi_base = devm_ioremap(pp->dev, pp->cfg.start,
> >+ resource_size(&pp->cfg));
>
>Why is configuraion space divided into two?
Sorry, I don't know the exact reason.:(
Pratyush Anand may know about this.
Pratyush Anand, could you answer the question?
CfgRd1 and CfgWr1 transactions are needed when an EP is not directly
connected to RC, rather connected through a bridge. For more detail see
PCIe specs.
Now, if we wish to generate a CfgRd/Wr1 transaction using SNPS
controller then we can not use same programmed viewport as that for
CfgRd/Wr0. However, a viewport can be reprogrammed using same physical
cfg address to generate either cfg0 or cfg1. So, in that case we can do
with only one cfg area and no reason to divide it into two.
Current code assumes that there are only 4 viewports available (2 in
outbound and 2 in inbound direction) and it always programs viewport
dynamically for cfg0/1 as per need. But same can not be true for all
implementations. There can be a case where hardware has sufficient
number of viewports and software does not need to reprogram it
dynamically. In that situation different physical memory area for each
type of TLP would make the execution faster.
Also, if you find some problems, please let me know.
>Why should it be same as dbi_base?
>AFAIK, jacinto6 has a dedicated configuration/io/memory space that is entirely
>different from dbi_base.
According to the Synopsys designware PCIe datasheet,
in chapter 5.1.1 Register Space Layout,
'Port Logic Registers' are placed between (config space 0x0 + 0x700)
and (config space 0x0 + 0xFFF).
'dbi_base' is used for reading/writing 'Port Logic Registers'.
Exynos are using 'dbi_base' like this. Thus, the base addresses of
both 'dbi_base' and configuration/io/memory space are same.
Yes address space are same, but at any moment they work either as dbi
space or as configuration/io/memory space depending on the dbi_enable
bit of application register. Similar functionality was there in one
older SPEAr implementation.
Just now, I looked at Spear PCIe driver.
However, in the case of Spear, the base address of configuration/io/memory
space is defined as 0x8000. The base address of 'Port Logic Registers'
is defined as 0xb100.
I think that the situation of 'jacinto6' is similar with Spear, right?
In SPEAr1340 PCIe memory layout is as follows:
DBI base (0xB100 to 0xB1001FFF): This space is used to read/write
own PCI Configuration Header, Capability and Port Logic(PL) Registers.
ELBI space (0xB1002000 to 0xB17F): These are completely SPEAr
specific application registers.
configuration/io/memory space(0x8000 to 0x8FFF): These can be
used in viewport programming to generate different type of outbound
transaction.
Regards
Pratyush
Then, I will move pp->dbi_base mapping code from pcie-designware.c
to pci-exynos.c.
--
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: [ 00/19] 3.10.1-stable review
Mike, I do want to partially apologize to Sarah for my first email. That was really much tongue in cheek to express what happens when things get too polite and professional and hope she wasn't too offended. I saw Sarah's last post http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg471360.html and see she's changed her tune a bit which is a lot more agreeable to me and I suspect others. However I still thinks she's a little bit too pendantic to the point of being really annoying and seeming like she's memorized the book of conduct quoting things like " The book "No Assholes Rule" cites research that shows only 1% of subordinates bully their superiors" and is ready to throw it in peoples faces if they infringe on the rules. Those rules are way too long to follow. Why can't you guys just trust your insticts and if you are relaly worried about Linus -- just make it a rule "If anybody thinks X is acting as a jerk at this very moment -- call it out" Honestly do yo guys even have time to read 20 pages of what is and ISN'T and insult. I also suspect the public viewers aren't going to be looking up at an Org Chart "Hmm let me check if Linus is allowed to insult this guy :) " When you are at the party since she's probably going to miss this note because its on a dead thread if you could convey my sentiments. Thanks, Regina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm fixes
Hi Linus, This is just a regular fixes pull, mostly nouveau and i915, the i915 ones fix RC6 on Sandybridge after suspend/resume, which I think people have be wanting for quite a while! Now you shouldn't wish for more patches, as the new mutex/reservation code found a number of problems with the qxl driver, and it currently makes lockdep angry, I'm working on a set of fixes for it, but its a bit large, I'll submit them separately later today or tomorrow once I've banged on them a bit more, just warning you in advance :-) Dave. The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b: Linux 3.11-rc2 (2013-07-21 12:05:29 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 058ca4a22ebf22ea1cbedd6cc0340ed1e2e94ee1: Merge tag 'drm-intel-fixes-2013-07-22' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-22 16:14:26 +1000) Ben Skeggs (4): Merge remote-tracking branch 'airlied/drm-next' into drm-nouveau-next drm/nouveau: fix locking issues in page flipping paths drm/nv50/kms: fix pin refcnt leaks drm/nouveau: use dedicated channel for async moves on GT/GF chipsets. Chris Wilson (2): drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() drm/i915: Serialize almost all register access Daniel Vetter (7): drm/i915: fix up readout of the lvds dither bit on gen2/3 drm/i915: fix pfit regression for non-autoscaled resolutions drm/i915: Sanitize shared dpll state Merge tag 'v3.10' into drm-intel-fixes drm/i915: correctly restore fences with objects attached drm/i915: fix up gt init sequence fallout drm/crtc-helper: explicit DPMS on after modeset Dave Airlie (2): Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 Merge tag 'drm-intel-fixes-2013-07-22' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Kamal Mostafa (1): drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight Konstantin Khlebnikov (1): drm/i915: fix long-standing SNB regression in power consumption after resume v2 Maarten Lankhorst (5): drm/nouveau: fix some error-path leaks in fbcon handling code drm/nouveau: do not unpin in nouveau_gem_object_del drm/nouveau: bump fence timeout to 15 seconds drm/nouveau: add falcon interrupt handler drm/nouveau: do not allow negative sizes for now Stéphane Marchesin (1): drm/i915: Preserve the DDI_A_4_LANES bit from the bios drivers/gpu/drm/drm_crtc_helper.c | 27 - drivers/gpu/drm/i915/i915_dma.c| 18 +++--- drivers/gpu/drm/i915/i915_drv.c| 13 ++-- drivers/gpu/drm/i915/i915_drv.h| 3 +- drivers/gpu/drm/i915/i915_gem.c| 18 +- drivers/gpu/drm/i915/intel_ddi.c | 10 ++-- drivers/gpu/drm/i915/intel_display.c | 69 -- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 12 ++-- drivers/gpu/drm/i915/intel_panel.c | 6 +- drivers/gpu/drm/i915/intel_pm.c| 8 ++- drivers/gpu/drm/nouveau/core/engine/bsp/nvc0.c | 1 + drivers/gpu/drm/nouveau/core/engine/bsp/nve0.c | 1 + drivers/gpu/drm/nouveau/core/engine/falcon.c | 19 ++ drivers/gpu/drm/nouveau/core/engine/ppp/nvc0.c | 1 + drivers/gpu/drm/nouveau/core/engine/vp/nvc0.c | 1 + drivers/gpu/drm/nouveau/core/engine/vp/nve0.c | 1 + .../gpu/drm/nouveau/core/include/engine/falcon.h | 2 + drivers/gpu/drm/nouveau/nouveau_bo.c | 21 +-- drivers/gpu/drm/nouveau/nouveau_display.c | 69 ++ drivers/gpu/drm/nouveau/nouveau_drm.c | 15 - drivers/gpu/drm/nouveau/nouveau_fbcon.c| 1 + drivers/gpu/drm/nouveau/nouveau_fence.c| 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 6 -- drivers/gpu/drm/nouveau/nv50_display.c | 46 +++ 25 files changed, 242 insertions(+), 130 deletions(-)
Re: [PATCH 2/2] mm: page_alloc: avoid slowpath for more than MAX_ORDER allocation.
On Mon, Jul 22, 2013 at 07:01:18PM -0700, PINTU KUMAR wrote: > >Lastly, order >= MAX_ORDER is not supported by the page allocator, and > >we do not want to punish 99.999% of all legitimate page allocations in > >the fast path in order to catch an unlikely situation like this. [...] > >Having the check only in the slowpath is a good thing. > > > Sorry, I could not understand, why adding this check in slowpath is only good. > We could have returned failure much before that. > Without this check, we are actually allowing failure of "first allocation > attempt" and then returning the cause of failure in slowpath. > I thought it will be better to track the unlikely failure in the system as > early as possible, at least from the embedded system prospective. > Let me know your opinion. This is a trade-off between two cases: we expect (almost) all allocations to be order < MAX_ORDER, so we want that path as lightweight as possible. On the other hand, we expect that only very rarely an allocation will specify order >= MAX_ORDER. By doing the check late, we make the common case faster at the expense of the rare case. That's the whole point of having a fast path and a slow path. What you are proposing would punish 99.999% of all cases in order to speed up the 0.001% cases. In addition, these 0.001% of all cases will fail the allocation, so performance is the least of their worries. It's a bad trade-off. -- 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 07/10] mm, hugetlb: do not use a page in page cache for cow optimization
On Mon, Jul 22, 2013 at 05:36:28PM +0900, Joonsoo Kim wrote:
> Currently, we use a page with mapped count 1 in page cache for cow
> optimization. If we find this condition, we don't allocate a new
> page and copy contents. Instead, we map this page directly.
> This may introduce a problem that writting to private mapping overwrite
> hugetlb file directly. You can find this situation with following code.
>
> size = 20 * MB;
> flag = MAP_SHARED;
> p = mmap(NULL, size, PROT_READ|PROT_WRITE, flag, fd, 0);
> if (p == MAP_FAILED) {
> fprintf(stderr, "mmap() failed: %s\n", strerror(errno));
> return -1;
> }
> p[0] = 's';
> fprintf(stdout, "BEFORE STEAL PRIVATE WRITE: %c\n", p[0]);
> munmap(p, size);
>
> flag = MAP_PRIVATE;
> p = mmap(NULL, size, PROT_READ|PROT_WRITE, flag, fd, 0);
> if (p == MAP_FAILED) {
> fprintf(stderr, "mmap() failed: %s\n", strerror(errno));
> }
> p[0] = 'c';
> munmap(p, size);
>
> flag = MAP_SHARED;
> p = mmap(NULL, size, PROT_READ|PROT_WRITE, flag, fd, 0);
> if (p == MAP_FAILED) {
> fprintf(stderr, "mmap() failed: %s\n", strerror(errno));
> return -1;
> }
> fprintf(stdout, "AFTER STEAL PRIVATE WRITE: %c\n", p[0]);
> munmap(p, size);
>
> We can see that "AFTER STEAL PRIVATE WRITE: c", not "AFTER STEAL
> PRIVATE WRITE: s". If we turn off this optimization to a page
> in page cache, the problem is disappeared.
Looks good to me. Thanks for the fix.
Reviewed-by: Naoya Horiguchi
> Reviewed-by: Wanpeng Li
> Signed-off-by: Joonsoo Kim
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 7ca8733..8a61638 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2508,7 +2508,6 @@ static int hugetlb_cow(struct mm_struct *mm, struct
> vm_area_struct *vma,
> {
> struct hstate *h = hstate_vma(vma);
> struct page *old_page, *new_page;
> - int avoidcopy;
> int outside_reserve = 0;
> unsigned long mmun_start; /* For mmu_notifiers */
> unsigned long mmun_end; /* For mmu_notifiers */
> @@ -2518,10 +2517,8 @@ static int hugetlb_cow(struct mm_struct *mm, struct
> vm_area_struct *vma,
> retry_avoidcopy:
> /* If no-one else is actually using this page, avoid the copy
>* and just make the page writable */
> - avoidcopy = (page_mapcount(old_page) == 1);
> - if (avoidcopy) {
> - if (PageAnon(old_page))
> - page_move_anon_rmap(old_page, vma, address);
> + if (page_mapcount(old_page) == 1 && PageAnon(old_page)) {
> + page_move_anon_rmap(old_page, vma, address);
> set_huge_ptep_writable(vma, address, ptep);
> return 0;
> }
> --
> 1.7.9.5
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
>
--
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/2] [BUGFIX] virtio/console: Fix two bugs of splice_write
Amit Shah writes: > On (Mon) 22 Jul 2013 [13:00:43], Yoshihiro YUNOMAE wrote: >> Hi, >> >> This patch set fixes two bugs of splice_write in the virtio-console driver. >> >> [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. >>=> This induces oops in sg_init_table(). >> >> [BUG2] No lock for competition of splice_write. >>=> This induces oops in splice_from_pipe_feed() by bug of any user >> application. >> >> These reports are written in each patch. >> >> Changes in V2: >> - Fix a locking problem for error >> >> Changes in V3: >> - Add Reviewed-by lines and stable@ line in sign-off area > > Thank you! > > Rusty, please pick this up. Both applied, thankyou. Cheers, Rusty. -- 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: [QUERY] lguest64
"H. Peter Anvin" writes: > On 07/19/2013 02:06 AM, Ramkumar Ramachandra wrote: >> Hi, >> >> I tried building lguest to play with it, but was disappointed to find >> this in the Kconfig: >> >> depends on X86_32 >> >> Why is this [1]? What is so hard about supporting 64-bit machines? I >> found a five-year old tree that claims to do lguest64 [2], but didn't >> investigate further. >> > > Please don't have us deal with another lguest unless there is a use case > for it. We want to reduce pvops and pvops users, not increase them... > > -hpa Yes, the subset of x86-64 machines for which there isn't hardware virtualization support is pretty uninteresting. Cheers, Rusty. -- 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: scatterlist: sg_set_buf() argument must be in linear mapping (sha1: ac4e97abce9b80c020e7113325f49e58b7b15e3f)
Michal Simek writes:
> + Ohad
>
> On 07/22/2013 03:47 AM, Rusty Russell wrote:
>> Michal Simek writes:
>>> Hi Rusty and Jens,
>>>
>>> I am getting problem with your patch which you have added to the kernel.
>>> The problem is with my arm zynq remoteproc driver where
>>> I use dma_declare_coherent_memory() to specify memory for remoteproc
>>> which is ioremap to the vmalloc area.
>>>
>>> Based on that buf addr is not inside ram even this coherent memory is in
>>> ram.
>>> That's why virt_addr_valid(buf) is failing.
>>
>> But sg_set_buf() calls virt_to_page(buf). So does that work?
>>
>> I would think calling sg_set_page() directly would be what you want
>> here...
>
> Let me take some code from virtio_rpmsg_bus.c to show that problematic part.
>
> bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
> RPMSG_TOTAL_BUF_SPACE,
> &vrp->bufs_dma, GFP_KERNEL);
> vrp->rbufs = bufs_va;
> for (i = 0; i < RPMSG_NUM_BUFS / 2; i++) {
> struct scatterlist sg;
> void *cpu_addr = vrp->rbufs + i * RPMSG_BUF_SIZE;
>
> sg_init_one(&sg, cpu_addr, RPMSG_BUF_SIZE);
> }
Hmm. Looking at arch/arm/include/asm/memory.h:
#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
#define virt_addr_valid(kaddr) ((unsigned long)(kaddr) >= PAGE_OFFSET &&
(unsigned long)(kaddr) < (unsigned long)high_memory)
pfn_to_page in ARM seems to be the asm-generic one, which depends on
CONFIG_SPARSEMEM/CONFIG_DISCONTIGMEM/CONFIG_FLATMEM etc.
Perhaps virt_addr_valid() is wrong for your config? It's pretty clear
that you shouldn't call virt_to_page() on something for which
!virt_addr_valid().
Cheers,
Rusty.
--
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: [ 10/18] ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan
On Mon, 2013-07-22 at 17:13 +0100, Luis Henriques wrote:
> Greg Kroah-Hartman writes:
>
> > 3.0-stable review patch. If anyone has any objections, please let me know.
>
> Sorry for the late review, but this patch is actually tagged for
> stable kernels >= 3.9 ("Cc: 3.9+ "). But it
> is probably harmless and not worth the trouble of reverting them from
> 3.0 and 3.4.
I don't think it does any good without the preceding fix (commit
2fa97feb4406c546b52e35b6b6c50cb8f63425d2) which unfortunately requires
3.9. I don't know whether it will make things any worse.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
RE: [ 00/19] 3.10.1-stable review
> Which means you're likely not invited to the annual mud-wrestling and toga party where this topic has been scheduled for further discussion. > This thread and its offspring have been declared dead on LKML, we're in kernel development mode again. > -Mike That's okay. Just wanted to express my comments. Regina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 23
Hi all, Changes since 20130719: The wireless-next tree gained a build failure so I used the version from next-20130722. The sound-asoc tree gained a build failure for which I reverted a commit. The imx-mxs tree gained a conflict against the arm tree. 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" as mentioned in the FAQ on the wiki (see below). 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. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 230 trees (counting Linus' and 33 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3b2f64d Linux 3.11-rc2) Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n) Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arc-current/for-curr (ad81f05 Linux 3.11-rc1) Merging arm-current/fixes (ab8d46c0 ARM: 7788/1: elf: fix lpae hwcap feature reporting in proc/cpuinfo) Merging m68k-current/for-linus (ad81f05 Linux 3.11-rc1) Merging metag-fixes/fixes (dfe248b MAINTAINERS: add linux-metag mailing list) Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for single-dev-PE) Merging sparc/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging net/master (f0e6160 net: pch_gbe depends on x86) Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling) Merging sound-current/for-linus (be2f93a ALSA: usb-audio: 6fire: return correct XRUN indication) Merging pci-current/for-linus (ad81f05 Linux 3.11-rc1) Merging wireless/master (23d412a brcmfmac: bail out of brcmf_txflowblock_if() for non-netdev interface) Merging driver-core.current/driver-core-linus (3b2f64d Linux 3.11-rc2) Merging tty.current/tty-linus (3b2f64d Linux 3.11-rc2) Merging usb.current/usb-linus (47a64a1 USB: EHCI: Fix resume signalling on remote wakeup) Merging staging.current/staging-linus (3b2f64d Linux 3.11-rc2) Merging char-misc.current/char-misc-linus (ed4bb97 Tools: hv: KVP: Fix a bug in IPV6 subnet enumeration) Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus) Merging md-current/for-linus (ff9db74 md/raid1: fix bio handling problems in process_checks()) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9c23b7d crypto: caam - Fixed the memory out of bound overwrite issue) Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (d94ea3f irqchip: Return -EPERM for reserved IRQs) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging gpio-current/gpio/merge (397eada gpio/omap: don't use linear domain mapping for OMAP1) Merging rr-fixes/fixes (6407d75 virtio_console: fix uapi header) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without pdata) Merging vfio-fixes/for-lin
linux-next: build failure after merge of the final tree (sound-asoc tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
sound/soc/mxs/mxs-saif.c: In function 'mxs_saif_mclk_init':
sound/soc/mxs/mxs-saif.c:668:2: error: implicit declaration of function
'clk_register_divider' [-Werror=implicit-function-declaration]
clk = clk_register_divider(&pdev->dev, "mxs_saif_mclk",
^
sound/soc/mxs/mxs-saif.c:669:8: error: implicit declaration of function
'__clk_get_name' [-Werror=implicit-function-declaration]
__clk_get_name(saif->clk), 0,
^
sound/soc/mxs/mxs-saif.c:668:6: warning: assignment makes pointer from integer
without a cast [enabled by default]
clk = clk_register_divider(&pdev->dev, "mxs_saif_mclk",
^
sound/soc/mxs/mxs-saif.c:681:2: error: implicit declaration of function
'of_clk_add_provider' [-Werror=implicit-function-declaration]
ret = of_clk_add_provider(np, of_clk_src_simple_get, clk);
^
sound/soc/mxs/mxs-saif.c:681:32: error: 'of_clk_src_simple_get' undeclared
(first use in this function)
ret = of_clk_add_provider(np, of_clk_src_simple_get, clk);
^
sound/soc/mxs/mxs-saif.c:681:32: note: each undeclared identifier is reported
only once for each function it appears in
Probably caused (or at least exposed) by commit 8ccbc3ebe9a7 ("ASoC: mxs:
Enable COMPILE_TEST builds").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpMYnfmlE2Qi.pgp
Description: PGP signature
[PATCH v2] AHCI: fix Null pointer dereference in achi_host_active()
commit b29900e6 (AHCI: Make distinct names for ports in /proc/interrupts)
introuded a regression, which resulted Null pointer dereference for achi
host with dummy ports. For ahci ports, when the port is dummy port, its
private_data will be NULL, as ata_dummy_port_ops doesn't support ->port_start.
changes in v2: use pp to check dummy ports, update comments
Reported-and-tested-by: Alex Williamson
Signed-off-by: Xiaotian Feng
Cc: Alexander Gordeev
Cc: Tejun Heo
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/ata/ahci.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5064f3e..db4380d 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1146,11 +1146,18 @@ int ahci_host_activate(struct ata_host *host, int irq,
unsigned int n_msis)
return rc;
for (i = 0; i < host->n_ports; i++) {
+ const char* desc;
struct ahci_port_priv *pp = host->ports[i]->private_data;
+ /* pp is NULL for dummy ports */
+ if (pp)
+ desc = pp->irq_desc;
+ else
+ desc = dev_driver_string(host->dev);
+
rc = devm_request_threaded_irq(host->dev,
irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
- pp->irq_desc, host->ports[i]);
+ desc, host->ports[i]);
if (rc)
goto out_free_irqs;
}
--
1.7.9.6 (Apple Git-31.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: [ 00/19] 3.10.1-stable review
On Mon, 2013-07-22 at 21:42 -0400, Regina Obe wrote: > Linus, > I want to start off by saying, though I'm mostly a windows developer, Which means you're likely not invited to the annual mud-wrestling and toga party where this topic has been scheduled for further discussion. This thread and its offspring have been declared dead on LKML, we're in kernel development mode again. -Mike -- 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] decompressors: fix "no limit" output buffer length
On 07/22/2013 07:15 PM, Alex Courbot wrote: ... > Although the patch seems ok to me in its current form, there are two > points for which I still have small doubts: > > 1) Whether size_t and pointers will have the same size on all platforms. ptrsize_t? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership
On Mon, Jul 22, 2013 at 4:36 PM, Jon Loeliger wrote: >> >> My own selfish desire is to easily separate emails for DT bindings and >> DT core code. I suppose I could do that with a suffix on my email address. > > And I've had the reverse problem: Sorting out the DTC > and libfdt patches from the noise. :-) Noise to you is rock-n-roll to me. ;) It's only going to get harder if lots of email to devicetree-discuss was getting dropped waiting for moderator approval. Yours is the harder problem since there is not really a way to use kernel MAINTAINERS for dtc. Perhaps the kernel maintainer for dtc could be "Send Your Patch Upstream ". Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] Minor Alpha updates for 3.11
On Mon, Jul 22, 2013 at 09:31:41PM -0500, Rob Landley wrote: > On 07/16/2013 07:03:47 PM, Michael Cree wrote: > >On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote: > >> On 07/16/2013 12:04:33 PM, Richard Henderson wrote: > >> >Here's a set of minor updates for arch/alpha that should not > >> >be controversial. > >> > >> I also note that I had to do this to get busybox to build against > >> uClibc: > >> -#define __NR_umount22 > >> +#define __NR_umount2 22 > >> -#define __NR_oldumount321 > >> +#define __NR_umount 321 > > > >I anticipate that this will likely break userspace. > > Haven't seen it so far. It's the same semantics all the other > targets have. Haven't built the whole of linux from scratch against > it yet though. (Most of my package builds are native and I'm still > tweaking my build environment to get a native toolchain built.) [snip] > I.E. nobody's tried to build busybox umount for Alpha (except me) > for thirteen years. That appears false to me. Busybox builds OK on Debian-Ports [1], and it looks like in the build log that umount is built. A search in Debian busybox sources does not return any hits for __NR_umount or __NR_umount2, but does for umount2 which are library calls (admittedly ones that are just wrappers for the kernel syscall). I also don't see any Debian patches in busybox that change behaviour of busybox specifically for Alpha. But IIRC Debian links against glibc even for the installer where busybox is used. So maybe the problem is in uClibc? Yes, a quick look at the source shows that uClibc does not test __NR_oldumount so presumably does not compile correct umount and umount2 library calls on Alpha. Maybe it's the case noone has compiled uClibc on Alpha until now? > There are way more busybox installations out there than even > _emulated_ alpha systems, and this is trivial to fix with a local > patch to the kernel. So I'll just do that. Your idea of the > "correct" thing to do to "fix" this seems entirely backwards to me. I wondered if your proposal will break glibc as glibc checks for __NR_oldumount and does different things based on that. But maybe your fix will not adversely affect glibc (I did not look particularly closely to see if so), but even so, there is no guarantee that other software does not directly access the oldumount syscall when compiled on Alpha, and your change would likely break any such software. Cheers Michael [1] http://buildd.debian-ports.org/status/package.php?p=busybox -- 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:] 3.11-rc2: WARNING: at kernel/time/tick-broadcast.c:667
And one for 3.11-rc2, … ACPI: Low-level resume complete PM: Restoring platform NVS memory PCI-DMA: Resuming GART IOMMU PCI-DMA: Restoring GART aperture settings Enabling non-boot CPUs ... smpboot: Booting Node 0 Processor 1 APIC 0x1 [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #1 process: Switch to broadcast mode on CPU1 CPU1 is up smpboot: Booting Node 0 Processor 2 APIC 0x2 [ cut here ] 3.11-rc2: WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x170/0x180() Modules linked in: raid1 nouveau video mxm_wmi i2c_algo_bit drm_kms_helper ttm drm i2c_core wmi CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-0.rc2.git0.1.fc20.x86_64 #1 Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010 0009 880129b27df0 8164df84 880129b27e28 810670bd 0001 0004 88012fc4dc80 0002 81c238c0 880129b27e38 Call Trace: [] dump_stack+0x45/0x56 [] warn_slowpath_common+0x7d/0xa0 [] warn_slowpath_null+0x1a/0x20 [] tick_broadcast_oneshot_control+0x170/0x180 [] clockevents_notify+0x178/0x1a0 [] amd_e400_idle+0x75/0x100 [] arch_cpu_idle+0x26/0x30 [] cpu_startup_entry+0xce/0x280 [] ? clockevents_register_device+0xbc/0x120 [] start_secondary+0x217/0x2c0 ---[ end trace c4f6f2078bf43f3e ]--- [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #2 process: Switch to broadcast mode on CPU2 CPU2 is up smpboot: Booting Node 0 Processor 3 APIC 0x3 [Firmware Bug]: cpu 3, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #3 process: Switch to broadcast mode on CPU3 CPU3 is up ACPI: Waking up from system sleep state S3 … CONF. http://kojipkgs.fedoraproject.org//packages/kernel/3.11.0/0.rc2.git0.1.fc20/data/logs/x86_64/build.log poma -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the imx-mxs tree with the arm tree
Hi Shawn,
Today's linux-next merge of the imx-mxs tree got a conflict in
arch/arm/Kconfig.debug between commit 5e33abe38413 ("ARM: debug: move
PL01X debug include into arch/arm/include/debug/") from the arm tree and
commit d1814df976f2 ("ARM: imx: add low-level debug for vybrid") from the
imx-mxs tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/Kconfig.debug
index 6638398,0aa5b9d..000
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@@ -879,12 -782,30 +886,13 @@@ config DEBUG_LL_INCLUD
DEBUG_IMX53_UART ||\
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART
- default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
-DEBUG_KEYSTONE_UART1
- default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
- DEBUG_MVEBU_UART_ALTERNATE
- default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
- default "debug/nomadik.S" if DEBUG_NOMADIK_UART
- default "debug/nspire.S" if DEBUG_NSPIRE_CX_UART || \
- DEBUG_NSPIRE_CLASSIC_UART
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
- default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
- default "debug/pxa.S" if DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || \
- DEBUG_MMP_UART3
- default "debug/rockchip.S" if DEBUG_ROCKCHIP_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 ||
DEBUG_SIRFMARCO_UART1
- default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
default "debug/sti.S" if DEBUG_STI_UART
- default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1
default "debug/tegra.S" if DEBUG_TEGRA_UART
- default "debug/u300.S" if DEBUG_U300_UART
default "debug/ux500.S" if DEBUG_UX500_UART
- default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \
- DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1 || \
- DEBUG_VEXPRESS_UART0_CRX
+ default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT
+ default "debug/vf.S" if DEBUG_VF_UART
default "debug/vt8500.S" if DEBUG_VT8500_UART0
default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
default "mach/debug-macro.S"
pgpd5HXxgaOI1.pgp
Description: PGP signature
Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Mon, 2013-07-22 at 19:47 -0700, James Bottomley wrote:
> On Tue, 2013-07-23 at 02:40 +, Myklebust, Trond wrote:
> > On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
> > > The solution, to me, looks simple: Let's co-opt a process we already
> > > know how to do: mailing list review and tree handling. So the proposal
> > > is simple:
> > >
> > > 1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
> > > reviewed patch to stable
> > > 2. All patches to stable should follow current review rules: They
> > > should go to the mailing list the original patch was sent to
> > > once the original is upstream as a request for stable.
> > > 3. Following debate on the list, the original maintainer would be
> > > responsible for collecting the patches (including the upstream
> > > commit) adjudicating on them and passing them on to stable after
> > > list review (either by git tree pull or email to stable@).
> > >
> > > I contend this raises the bar for adding patches to stable much higher,
> > > which seems to be needed, and adds a review stage which involves all the
> > > original reviewers.
> >
> > Could we keep the Cc: stable tag itself, since the dependency
> > information ("Cc: # 3.3.x: a1f84a3: sched:
> > Check for idle") is actually very useful? If we discard that, then we
> > really should revise the whole stable system, since it would mean that
> > we are in effect discarding the 'upstream first' rule.
>
> The two don't follow. No-one's proposing to dump the must be upstream
> rule. The proposal is to modify the automatic behaviour that leads to
> over tagging for stable and consequently too many "stable" patches that
> aren't really.
My point was that the _tag_ is useful as a list of dependencies for
something that we thing might need to be backported to older kernels.
I'd like to see us keep that information somehow.
Whether or not we interpret it as being an automatic "for stable"
request is a different matter. I'd be quite happy to see the "propose
for stable" step as reverting to being a manual step that occurs only
after we've upstreamed the fix.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
Re: [PATCH] hashtable: add hash_for_each_possible_rcu_notrace()
On Tue, 2013-07-23 at 12:43 +1000, Alexey Kardashevskiy wrote: > On 07/23/2013 12:41 PM, Joe Perches wrote: > > On Tue, 2013-07-23 at 12:28 +1000, Alexey Kardashevskiy wrote: > >> Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks! > >> Is there any "trivial patches" list? Could not find it on vger. [] > > MAINTAINERS has an entry: > > TRIVIAL PATCHES > > M: Jiri Kosina > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git [] > Cool, thanks! But is that patch really trivial? :) :) Was that the question? Anyway, you cc'd all the right people already. If no one responds after a couple weeks, either send it to Jiri or directly to Linus. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Tue, 2013-07-23 at 02:40 +, Myklebust, Trond wrote:
> On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
> > The solution, to me, looks simple: Let's co-opt a process we already
> > know how to do: mailing list review and tree handling. So the proposal
> > is simple:
> >
> > 1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
> > reviewed patch to stable
> > 2. All patches to stable should follow current review rules: They
> > should go to the mailing list the original patch was sent to
> > once the original is upstream as a request for stable.
> > 3. Following debate on the list, the original maintainer would be
> > responsible for collecting the patches (including the upstream
> > commit) adjudicating on them and passing them on to stable after
> > list review (either by git tree pull or email to stable@).
> >
> > I contend this raises the bar for adding patches to stable much higher,
> > which seems to be needed, and adds a review stage which involves all the
> > original reviewers.
>
> Could we keep the Cc: stable tag itself, since the dependency
> information ("Cc: # 3.3.x: a1f84a3: sched:
> Check for idle") is actually very useful? If we discard that, then we
> really should revise the whole stable system, since it would mean that
> we are in effect discarding the 'upstream first' rule.
The two don't follow. No-one's proposing to dump the must be upstream
rule. The proposal is to modify the automatic behaviour that leads to
over tagging for stable and consequently too many "stable" patches that
aren't really.
James
--
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 RFC V11 0/18] Paravirtualized ticket spinlocks
On 07/23/2013 01:06 AM, Konrad Rzeszutek Wilk wrote: github link: https://github.com/ktraghavendra/linux/tree/pvspinlock_v11 And chance you have a backup git tree? I get: This repository is temporarily unavailable. I only have it on local apart from there :(. Hope it was a temporary github problem. working for me now. Please note that we set SPIN_THRESHOLD = 32k with this series, that would eatup little bit of overcommit performance of PLE machines and overall performance of non-PLE machines. The older series[3] was tested by Attilio for Xen implementation. Note that Konrad needs to revert below two patches to enable xen on hvm 70dd4998, f10cd522c We could add that to the series. But let me first test it out - and that gets back to the repo :-) okay. -- 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] hashtable: add hash_for_each_possible_rcu_notrace()
On 07/23/2013 12:41 PM, Joe Perches wrote: > On Tue, 2013-07-23 at 12:28 +1000, Alexey Kardashevskiy wrote: >> Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks! >> >> Is there any "trivial patches" list? Could not find it on vger. > > Jiri Kosina has triv...@kernel.org > > Also, there's kernel-janitors > > http://vger.kernel.org/vger-lists.html#kernel-janitors > http://kernelnewbies.org/KernelJanitors > > MAINTAINERS has an entry: > > TRIVIAL PATCHES > M:Jiri Kosina > T:git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git > S:Maintained > K:^Subject:.*(?i)trivial Cool, thanks! But is that patch really trivial? :) -- Alexey -- 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] hashtable: add hash_for_each_possible_rcu_notrace()
On Tue, 2013-07-23 at 12:28 +1000, Alexey Kardashevskiy wrote: > Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks! > > Is there any "trivial patches" list? Could not find it on vger. Jiri Kosina has triv...@kernel.org Also, there's kernel-janitors http://vger.kernel.org/vger-lists.html#kernel-janitors http://kernelnewbies.org/KernelJanitors MAINTAINERS has an entry: TRIVIAL PATCHES M: Jiri Kosina T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git S: Maintained K: ^Subject:.*(?i)trivial -- 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 v1 1/3] ipc: Added platform data structure
Since the same ipc driver can be used by many platforms, using
macros for defining ipc_base and i2c_base addresses is not
a scalable approach. So added a platform data structure to pass
this information.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/intel_scu_ipc.c | 37 ++
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/intel_scu_ipc.c
b/drivers/platform/x86/intel_scu_ipc.c
index 9215ed7..93c1b57 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -58,12 +58,29 @@
*message handler is called within firmware.
*/
-#define IPC_BASE_ADDR 0xFF11C000 /* IPC1 base register address */
-#define IPC_MAX_ADDR 0x100/* Maximum IPC regisers */
#define IPC_WWBUF_SIZE20 /* IPC Write buffer Size */
#define IPC_RWBUF_SIZE20 /* IPC Read buffer Size */
-#define IPC_I2C_BASE 0xFF12B000 /* I2C control register base address */
-#define IPC_I2C_MAX_ADDR 0x10 /* Maximum I2C regisers */
+
+enum {
+ SCU_IPC_LINCROFT,
+};
+
+/* intel scu ipc driver data*/
+struct intel_scu_ipc_pdata_t {
+ u32 ipc_base;
+ u32 i2c_base;
+ u32 ipc_len;
+ u32 i2c_len;
+};
+
+static struct intel_scu_ipc_pdata_t intel_scu_ipc_pdata[] = {
+ [SCU_IPC_LINCROFT] = {
+ .ipc_base = 0xff11c000,
+ .i2c_base = 0xff12b000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
+};
static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id);
static void ipc_remove(struct pci_dev *pdev);
@@ -504,12 +521,16 @@ static irqreturn_t ioc(int irq, void *dev_id)
*/
static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
- int err;
+ int err, pid;
+ struct intel_scu_ipc_pdata_t *pdata;
resource_size_t pci_resource;
if (ipcdev.pdev)/* We support only one SCU */
return -EBUSY;
+ pid = id->driver_data;
+ pdata = &intel_scu_ipc_pdata[pid];
+
ipcdev.pdev = pci_dev_get(dev);
err = pci_enable_device(dev);
@@ -527,11 +548,11 @@ static int ipc_probe(struct pci_dev *dev, const struct
pci_device_id *id)
if (request_irq(dev->irq, ioc, 0, "intel_scu_ipc", &ipcdev))
return -EBUSY;
- ipcdev.ipc_base = ioremap_nocache(IPC_BASE_ADDR, IPC_MAX_ADDR);
+ ipcdev.ipc_base = ioremap_nocache(pdata->ipc_base, pdata->ipc_len);
if (!ipcdev.ipc_base)
return -ENOMEM;
- ipcdev.i2c_base = ioremap_nocache(IPC_I2C_BASE, IPC_I2C_MAX_ADDR);
+ ipcdev.i2c_base = ioremap_nocache(pdata->i2c_base, pdata->i2c_len);
if (!ipcdev.i2c_base) {
iounmap(ipcdev.ipc_base);
return -ENOMEM;
@@ -564,7 +585,7 @@ static void ipc_remove(struct pci_dev *pdev)
}
static DEFINE_PCI_DEVICE_TABLE(pci_ids) = {
- {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x082a)},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x082a), SCU_IPC_LINCROFT},
{ 0,}
};
MODULE_DEVICE_TABLE(pci, pci_ids);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On Mon, 2013-07-15 at 23:27 +0400, James Bottomley wrote:
> Before the "3.10.1-stable review" thread degenerated into a disagreement
> about habits of politeness, there were some solid points being made
> which, I think, bear consideration and which may now be lost.
>
> The problem, as Jiří Kosina put is succinctly is that the distributions
> are finding stable less useful because it contains to much stuff they'd
> classify as not stable material.
>
> The question that arises from this is who is stable aiming at ...
> because if it's the distributions (and that's what people seem to be
> using it for) then we need to take this feedback seriously.
>
> The next question is how should we, the maintainers, be policing commits
> to stable. As I think has been demonstrated in the discussion the
> "stable rules" are more sort of guidelines (apologies for the pirates
> reference). In many ways, this is as it should be, because people
> should have enough taste to know what constitutes a stable fix. The
> real root cause of the problem is that the cc: stable tag can't be
> stripped once it's in the tree, so maintainers only get to police things
> they put in the tree. Stuff they pull from others is already tagged and
> that tag can't be changed. This effectively pushes the problem out to
> the lowest (and possibly more inexperienced) leaves of the Maintainer
> tree. In theory we have a review stage for stable, but the review
> patches don't automatically get routed to the right mailing list and the
> first round usually comes out in the merge window when Maintainers'
> attention is elsewhere.
>
> The solution, to me, looks simple: Let's co-opt a process we already
> know how to do: mailing list review and tree handling. So the proposal
> is simple:
>
> 1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
> reviewed patch to stable
> 2. All patches to stable should follow current review rules: They
> should go to the mailing list the original patch was sent to
> once the original is upstream as a request for stable.
> 3. Following debate on the list, the original maintainer would be
> responsible for collecting the patches (including the upstream
> commit) adjudicating on them and passing them on to stable after
> list review (either by git tree pull or email to stable@).
>
> I contend this raises the bar for adding patches to stable much higher,
> which seems to be needed, and adds a review stage which involves all the
> original reviewers.
Could we keep the Cc: stable tag itself, since the dependency
information ("Cc: # 3.3.x: a1f84a3: sched:
Check for idle") is actually very useful? If we discard that, then we
really should revise the whole stable system, since it would mean that
we are in effect discarding the 'upstream first' rule.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
[PATCH v1 2/3] ipc: Enabled ipc support for additional intel platforms
Enabled ipc support for penwell, clovertrail & tangier platforms.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/intel_scu_ipc.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/intel_scu_ipc.c
b/drivers/platform/x86/intel_scu_ipc.c
index 93c1b57..aaaf1c1 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -63,6 +63,9 @@
enum {
SCU_IPC_LINCROFT,
+ SCU_IPC_PENWELL,
+ SCU_IPC_CLOVERVIEW,
+ SCU_IPC_TANGIER,
};
/* intel scu ipc driver data*/
@@ -80,6 +83,24 @@ static struct intel_scu_ipc_pdata_t intel_scu_ipc_pdata[] = {
.ipc_len = 0x100,
.i2c_len = 0x10,
},
+ [SCU_IPC_PENWELL] = {
+ .ipc_base = 0xff11c000,
+ .i2c_base = 0xff12b000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
+ [SCU_IPC_CLOVERVIEW] = {
+ .ipc_base = 0xff11c000,
+ .i2c_base = 0xff12b000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
+ [SCU_IPC_TANGIER] = {
+ .ipc_base = 0xff009000,
+ .i2c_base = 0xff00d000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
};
static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id);
@@ -586,6 +607,9 @@ static void ipc_remove(struct pci_dev *pdev)
static DEFINE_PCI_DEVICE_TABLE(pci_ids) = {
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x082a), SCU_IPC_LINCROFT},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x080e), SCU_IPC_PENWELL},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x08ea), SCU_IPC_CLOVERVIEW},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x11a0), SCU_IPC_TANGIER},
{ 0,}
};
MODULE_DEVICE_TABLE(pci, pci_ids);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 0/3] IPC driver patches
Following patches adds IPC support for addional intel platforms and provides default interrupt mode support. Please let me know your review comments. Kuppuswamy Sathyanarayanan (3): ipc: Added platform data structure ipc: Enabled ipc support for additional intel platforms ipc: Add support for default interrupt mode drivers/platform/x86/Kconfig | 15 + drivers/platform/x86/intel_scu_ipc.c | 114 ++ 2 files changed, 118 insertions(+), 11 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 3/3] ipc: Add support for default interrupt mode
Added intel scu ipc access mode config option.
Also, This patch adds support to enable ipc command interrupt
mode by default. This functionality is enabled by following
config option.
CONFIG_INTEL_SCU_IPC_INTR_MODE=y
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/Kconfig | 15 ++
drivers/platform/x86/intel_scu_ipc.c | 53 --
2 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 36a9e60..26921ce 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -654,6 +654,21 @@ config INTEL_SCU_IPC
some embedded Intel x86 platforms. This is not needed for PC-type
machines.
+choice
+ prompt "IPC access mode"
+ depends on INTEL_SCU_IPC
+ default INTEL_SCU_IPC_INTR_MODE
+ ---help---
+ Select the desired access mode for IPC call.
+
+config INTEL_SCU_IPC_INTR_MODE
+ bool "Intel SCU IPC interrupt mode"
+
+config INTEL_SCU_IPC_POLL_MODE
+ bool "Intel SCU IPC polling mode"
+
+endchoice
+
config INTEL_SCU_IPC_UTIL
tristate "Intel SCU IPC utility driver"
depends on INTEL_SCU_IPC
diff --git a/drivers/platform/x86/intel_scu_ipc.c
b/drivers/platform/x86/intel_scu_ipc.c
index aaaf1c1..6683ee0 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -60,6 +60,7 @@
#define IPC_WWBUF_SIZE20 /* IPC Write buffer Size */
#define IPC_RWBUF_SIZE20 /* IPC Read buffer Size */
+#define IPC_IOC 0x100 /* IPC command register IOC bit
*/
enum {
SCU_IPC_LINCROFT,
@@ -110,6 +111,9 @@ struct intel_scu_ipc_dev {
struct pci_dev *pdev;
void __iomem *ipc_base;
void __iomem *i2c_base;
+#ifdef CONFIG_INTEL_SCU_IPC_INTR_MODE
+ struct completion cmd_complete;
+#endif
};
static struct intel_scu_ipc_dev ipcdev; /* Only one for now */
@@ -136,7 +140,12 @@ static DEFINE_MUTEX(ipclock); /* lock used to prevent
multiple call to SCU */
*/
static inline void ipc_command(u32 cmd) /* Send ipc command */
{
+#ifdef CONFIG_INTEL_SCU_IPC_INTR_MODE
+ INIT_COMPLETION(ipcdev.cmd_complete);
+ writel(cmd | IPC_IOC, ipcdev.ipc_base);
+#else
writel(cmd, ipcdev.ipc_base);
+#endif
}
/*
@@ -194,6 +203,37 @@ static inline int busy_loop(void) /* Wait till scu status
is busy */
return 0;
}
+#ifdef CONFIG_INTEL_SCU_IPC_INTR_MODE
+/* Wait till ipc ioc interrupt is received or timeout in 3 HZ */
+static inline int ipc_wait_for_interrupt(void)
+{
+ int status;
+ int ret = 0;
+
+ if (!wait_for_completion_timeout(&ipcdev.cmd_complete, 3 * HZ)) {
+ ret = -ETIMEDOUT;
+ goto end;
+ }
+
+ status = ipc_read_status();
+
+ if ((status >> 1) & 1)
+ ret = -EIO;
+
+end:
+ return ret;
+}
+#endif
+
+int intel_scu_ipc_check_status(void)
+{
+#ifdef CONFIG_INTEL_SCU_IPC_INTR_MODE
+ return ipc_wait_for_interrupt();
+#else
+ return busy_loop();
+#endif
+}
+
/* Read/Write power control(PMIC in Langwell, MSIC in PenWell) registers */
static int pwr_reg_rdwr(u16 *addr, u8 *data, u32 count, u32 op, u32 id)
{
@@ -234,7 +274,7 @@ static int pwr_reg_rdwr(u16 *addr, u8 *data, u32 count, u32
op, u32 id)
ipc_command(4 << 16 | id << 12 | 0 << 8 | op);
}
- err = busy_loop();
+ err = intel_scu_ipc_check_status();
if (id == IPC_CMD_PCNTRL_R) { /* Read rbuf */
/* Workaround: values are read as 0 without memcpy_fromio */
memcpy_fromio(cbuf, ipcdev.ipc_base + 0x90, 16);
@@ -429,7 +469,7 @@ int intel_scu_ipc_simple_command(int cmd, int sub)
return -ENODEV;
}
ipc_command(sub << 12 | cmd);
- err = busy_loop();
+ err = intel_scu_ipc_check_status();
mutex_unlock(&ipclock);
return err;
}
@@ -463,7 +503,7 @@ int intel_scu_ipc_command(int cmd, int sub, u32 *in, int
inlen,
ipc_data_writel(*in++, 4 * i);
ipc_command((inlen << 16) | (sub << 12) | cmd);
- err = busy_loop();
+ err = intel_scu_ipc_check_status();
for (i = 0; i < outlen; i++)
*out++ = ipc_data_readl(4 * i);
@@ -529,6 +569,9 @@ EXPORT_SYMBOL(intel_scu_ipc_i2c_cntrl);
*/
static irqreturn_t ioc(int irq, void *dev_id)
{
+#ifdef CONFIG_INTEL_SCU_IPC_INTR_MODE
+ complete(&ipcdev.cmd_complete);
+#endif
return IRQ_HANDLED;
}
@@ -566,6 +609,10 @@ static int ipc_probe(struct pci_dev *dev, const struct
pci_device_id *id)
if (!pci_resource)
return -ENOMEM;
+#ifdef CONFIG_INTEL_SCU_IPC_INTR_MODE
+ init_completion(&ipcdev.cmd_complete);
+#endif
+
if (request_irq(dev->irq, ioc, 0, "intel_scu_ipc", &ipcdev))
return -EBUSY;
--
1.7.9.5
--
To unsubscribe from this list: sen
Re: [PATCH v2 2/2] ARM: STi: Set correct ARM ERRATAs.
On Tue, Jul 09, 2013 at 08:26:33AM +0100, Srinivas KANDAGATLA wrote: > From: Srinivas Kandagatla > > Some of the ARM_ERRATA selection is not done in the initial SOC support > patches. This patch selects 2 new ARM_ERRATA's and removes one which was > actually fixed. These entries should be sorted, and you inserted in random order. I'll rearrange the order when applying. (Patch applied with that change). Thanks, -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] ARM: dts: STi: Fix pinconf setup for STiH416 serial2
On Tue, Jul 09, 2013 at 08:26:24AM +0100, Srinivas KANDAGATLA wrote: > From: Srinivas Kandagatla > > This patch fixes a bug in pinctrl setup of serial2 device, Some of the > pins in the pinctrl node of serial2 do not belong to that > pin-controller. This patch divides them in the pins into there > respective pin controller nodes. > > Without this patch serial on StiH416-B2000 Board will not work as it > fails with: > > "st-pinctrl pin-controller-rear.3: failed to get pin(99) name > st-pinctrl pin-controller-rear.3: maps: function serial2 group serial2-0 > num 4 > pinconfig core: failed to register map default (3): no group/pin given" > > Signed-off-by: Srinivas Kandagatla Applied to fixes, thanks. -Olof -- 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/7] Minor Alpha updates for 3.11
On 07/16/2013 07:03:47 PM, Michael Cree wrote: On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote: > On 07/16/2013 12:04:33 PM, Richard Henderson wrote: > >Here's a set of minor updates for arch/alpha that should not > >be controversial. > > I also note that I had to do this to get busybox to build against > uClibc: > -#define __NR_umount22 > +#define __NR_umount2 22 > -#define __NR_oldumount321 > +#define __NR_umount 321 I anticipate that this will likely break userspace. Haven't seen it so far. It's the same semantics all the other targets have. Haven't built the whole of linux from scratch against it yet though. (Most of my package builds are native and I'm still tweaking my build environment to get a native toolchain built.) busybox should be fixed to test for __NR_oldumount and then call the correct functions, namely oldumount and umount if __NR_oldumount is defined and umount and umount2 if it is not defined. The man page for umount and umount2 doesn't mention "oldumount": $ man 2 umount | grep old $ Only three kernel targets mention it, alpha, powerpc, and x86: $ find arch/*/include -type f | xargs grep oldumount arch/alpha/include/uapi/asm/unistd.h:#define __NR_oldumount 321 arch/powerpc/include/asm/systbl.h:SYSX(sys_ni_syscall,sys_oldumount,sys_oldumount) arch/x86/include/generated/asm/syscalls_32.h:__SYSCALL_I386(22, sys_oldumount, sys_oldumount) And the other two export umount2: $ find arch/*/include -type f | xargs grep umount2 | egrep "powerpc|x86" arch/powerpc/include/uapi/asm/unistd.h:#define __NR_umount2 52 arch/x86/include/generated/asm/unistd_32_ia32.h:#define __NR_ia32_umount2 52 arch/x86/include/generated/uapi/asm/unistd_x32.h:#define __NR_umount2 (__X32_SYSCALL_BIT + 166) arch/x86/include/generated/uapi/asm/unistd_32.h:#define __NR_umount2 52 arch/x86/include/generated/uapi/asm/unistd_64.h:#define __NR_umount2 166 So really what you're saying is busybox should #ifdef alpha/workaround target-specific breakage/#unifdef, and what this says to _me_ is that nobody's tried to build busybox on Alpha since it started using umount2(). How long ago was that? commit 6c5f2c602174c7fe0830a1fc4fe5b3dde5ed7068 Author: Erik Andersen Date: Fri May 5 19:49:33 2000 + I.E. nobody's tried to build busybox umount for Alpha (except me) for thirteen years. There are way more busybox installations out there than even _emulated_ alpha systems, and this is trivial to fix with a local patch to the kernel. So I'll just do that. Your idea of the "correct" thing to do to "fix" this seems entirely backwards to me. Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag
On 2013/7/23 5:24, KOSAKI Motohiro wrote: >> I review what I can, but recently have often missed the 2 day review >> period. >> >> Review from the authors and maintainers is probably more valuable than >> that from generalists on the stable list. > >>From point of subsystem developers view, the problem is there are too many > stable branches. I can't memorize what is different each other. > Currently www.kernel.org > lists two stable and five longterm branches. Who know all of them? > Eventually I only > checked them when I have enough much spare time. I only check those maintained by Greg. -- 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] hashtable: add hash_for_each_possible_rcu_notrace()
Anyone, ping. Is it good, bad, ugly (ack/nack)? Thanks! Is there any "trivial patches" list? Could not find it on vger. On 07/15/2013 08:04 PM, Alexey Kardashevskiy wrote: > Anyone, ping? > > On 07/06/2013 02:16 PM, Alexey Kardashevskiy wrote: >> This adds hash_for_each_possible_rcu_notrace() which is basically >> a notrace clone of hash_for_each_possible_rcu() which cannot be >> used in real mode due to its tracing/debugging capability. >> >> Signed-off-by: Alexey Kardashevskiy >> --- >> include/linux/hashtable.h | 15 +++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h >> index a9df51f..af8b169 100644 >> --- a/include/linux/hashtable.h >> +++ b/include/linux/hashtable.h >> @@ -174,6 +174,21 @@ static inline void hash_del_rcu(struct hlist_node *node) >> member) >> >> /** >> + * hash_for_each_possible_rcu_notrace - iterate over all possible objects >> hashing >> + * to the same bucket in an rcu enabled hashtable in a rcu enabled hashtable >> + * @name: hashtable to iterate >> + * @obj: the type * to use as a loop cursor for each entry >> + * @member: the name of the hlist_node within the struct >> + * @key: the key of the objects to iterate over >> + * >> + * This is the same as hash_for_each_possible_rcu() except that it does >> + * not do any RCU debugging or tracing. >> + */ >> +#define hash_for_each_possible_rcu_notrace(name, obj, member, key) \ >> +hlist_for_each_entry_rcu_notrace(obj, &name[hash_min(key, >> HASH_BITS(name))],\ >> +member) >> + >> +/** >> * hash_for_each_possible_safe - iterate over all possible objects hashing >> to the >> * same bucket safe against removals >> * @name: hashtable to iterate >> > > -- Alexey -- 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 03/10] vfio: add external user support
On Tue, 2013-07-16 at 10:53 +1000, Alexey Kardashevskiy wrote:
> VFIO is designed to be used via ioctls on file descriptors
> returned by VFIO.
>
> However in some situations support for an external user is required.
> The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to
> use the existing VFIO groups for exclusive access in real/virtual mode
> on a host to avoid passing map/unmap requests to the user space which
> would made things pretty slow.
>
> The protocol includes:
>
> 1. do normal VFIO init operation:
> - opening a new container;
> - attaching group(s) to it;
> - setting an IOMMU driver for a container.
> When IOMMU is set for a container, all groups in it are
> considered ready to use by an external user.
>
> 2. User space passes a group fd to an external user.
> The external user calls vfio_group_get_external_user()
> to verify that:
> - the group is initialized;
> - IOMMU is set for it.
> If both checks passed, vfio_group_get_external_user()
> increments the container user counter to prevent
> the VFIO group from disposal before KVM exits.
>
> 3. The external user calls vfio_external_user_iommu_id()
> to know an IOMMU ID. PPC64 KVM uses it to link logical bus
> number (LIOBN) with IOMMU ID.
>
> 4. When the external KVM finishes, it calls
> vfio_group_put_external_user() to release the VFIO group.
> This call decrements the container user counter.
> Everything gets released.
>
> The "vfio: Limit group opens" patch is also required for the consistency.
>
> Signed-off-by: Alexey Kardashevskiy
This looks fine to me. Is the plan to add this through the ppc tree
again? Thanks,
Alex
> ---
> Changes:
> 2013/07/11:
> * added vfio_group_get()/vfio_group_put()
> * protocol description changed
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> drivers/vfio/vfio.c | 62
>
> include/linux/vfio.h | 7 ++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index c488da5..58b034b 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1370,6 +1370,68 @@ static const struct file_operations vfio_device_fops =
> {
> };
>
> /**
> + * External user API, exported by symbols to be linked dynamically.
> + *
> + * The protocol includes:
> + * 1. do normal VFIO init operation:
> + * - opening a new container;
> + * - attaching group(s) to it;
> + * - setting an IOMMU driver for a container.
> + * When IOMMU is set for a container, all groups in it are
> + * considered ready to use by an external user.
> + *
> + * 2. User space passes a group fd to an external user.
> + * The external user calls vfio_group_get_external_user()
> + * to verify that:
> + * - the group is initialized;
> + * - IOMMU is set for it.
> + * If both checks passed, vfio_group_get_external_user()
> + * increments the container user counter to prevent
> + * the VFIO group from disposal before KVM exits.
> + *
> + * 3. The external user calls vfio_external_user_iommu_id()
> + * to know an IOMMU ID.
> + *
> + * 4. When the external KVM finishes, it calls
> + * vfio_group_put_external_user() to release the VFIO group.
> + * This call decrements the container user counter.
> + */
> +struct vfio_group *vfio_group_get_external_user(struct file *filep)
> +{
> + struct vfio_group *group = filep->private_data;
> +
> + if (filep->f_op != &vfio_group_fops)
> + return ERR_PTR(-EINVAL);
> +
> + if (!atomic_inc_not_zero(&group->container_users))
> + return ERR_PTR(-EINVAL);
> +
> + if (!group->container->iommu_driver ||
> + !vfio_group_viable(group)) {
> + atomic_dec(&group->container_users);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + vfio_group_get(group);
> +
> + return group;
> +}
> +EXPORT_SYMBOL_GPL(vfio_group_get_external_user);
> +
> +void vfio_group_put_external_user(struct vfio_group *group)
> +{
> + vfio_group_put(group);
> + vfio_group_try_dissolve_container(group);
> +}
> +EXPORT_SYMBOL_GPL(vfio_group_put_external_user);
> +
> +int vfio_external_user_iommu_id(struct vfio_group *group)
> +{
> + return iommu_group_id(group->iommu_group);
> +}
> +EXPORT_SYMBOL_GPL(vfio_external_user_iommu_id);
> +
> +/**
> * Module/class support
> */
> static char *vfio_devnode(struct device *dev, umode_t *mode)
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index ac8d488..24579a0 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -90,4 +90,11 @@ extern void vfio_unregister_iommu_driver(
> TYPE tmp; \
> offsetof(TYPE, MEMBER) + sizeof(tmp.MEMBER); }) \
>
> +/*
> + * External user API
> + */
> +extern struct vfio_group *vfio_group_get_external_user(struct file *filep);
> +extern void vfio_group_put_external_user(struct vfio_group *group);
> +extern int vfio_external_user_i
Re: [PATCH 04/10] powerpc: Prepare to support kernel handling of IOMMU map/unmap
Ping, anyone, please?
Ben needs ack from any of MM people before proceeding with this patch. Thanks!
On 07/16/2013 10:53 AM, Alexey Kardashevskiy wrote:
> The current VFIO-on-POWER implementation supports only user mode
> driven mapping, i.e. QEMU is sending requests to map/unmap pages.
> However this approach is really slow, so we want to move that to KVM.
> Since H_PUT_TCE can be extremely performance sensitive (especially with
> network adapters where each packet needs to be mapped/unmapped) we chose
> to implement that as a "fast" hypercall directly in "real
> mode" (processor still in the guest context but MMU off).
>
> To be able to do that, we need to provide some facilities to
> access the struct page count within that real mode environment as things
> like the sparsemem vmemmap mappings aren't accessible.
>
> This adds an API to increment/decrement page counter as
> get_user_pages API used for user mode mapping does not work
> in the real mode.
>
> CONFIG_SPARSEMEM_VMEMMAP and CONFIG_FLATMEM are supported.
>
> Cc: linux...@kvack.org
> Reviewed-by: Paul Mackerras
> Signed-off-by: Paul Mackerras
> Signed-off-by: Alexey Kardashevskiy
>
> ---
>
> Changes:
> 2013/07/10:
> * adjusted comment (removed sentence about virtual mode)
> * get_page_unless_zero replaced with atomic_inc_not_zero to minimize
> effect of a possible get_page_unless_zero() rework (if it ever happens).
>
> 2013/06/27:
> * realmode_get_page() fixed to use get_page_unless_zero(). If failed,
> the call will be passed from real to virtual mode and safely handled.
> * added comment to PageCompound() in include/linux/page-flags.h.
>
> 2013/05/20:
> * PageTail() is replaced by PageCompound() in order to have the same checks
> for whether the page is huge in realmode_get_page() and realmode_put_page()
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> arch/powerpc/include/asm/pgtable-ppc64.h | 4 ++
> arch/powerpc/mm/init_64.c| 76
> +++-
> include/linux/page-flags.h | 4 +-
> 3 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
> b/arch/powerpc/include/asm/pgtable-ppc64.h
> index 46db094..aa7b169 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -394,6 +394,10 @@ static inline void mark_hpte_slot_valid(unsigned char
> *hpte_slot_array,
> hpte_slot_array[index] = hidx << 4 | 0x1 << 3;
> }
>
> +struct page *realmode_pfn_to_page(unsigned long pfn);
> +int realmode_get_page(struct page *page);
> +int realmode_put_page(struct page *page);
> +
> static inline char *get_hpte_slot_array(pmd_t *pmdp)
> {
> /*
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index d0cd9e4..dcbb806 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -300,5 +300,79 @@ void vmemmap_free(unsigned long start, unsigned long end)
> {
> }
>
> -#endif /* CONFIG_SPARSEMEM_VMEMMAP */
> +/*
> + * We do not have access to the sparsemem vmemmap, so we fallback to
> + * walking the list of sparsemem blocks which we already maintain for
> + * the sake of crashdump. In the long run, we might want to maintain
> + * a tree if performance of that linear walk becomes a problem.
> + *
> + * Any of realmode_ functions can fail due to:
> + * 1) As real sparsemem blocks do not lay in RAM continously (they
> + * are in virtual address space which is not available in the real mode),
> + * the requested page struct can be split between blocks so get_page/put_page
> + * may fail.
> + * 2) When huge pages are used, the get_page/put_page API will fail
> + * in real mode as the linked addresses in the page struct are virtual
> + * too.
> + */
> +struct page *realmode_pfn_to_page(unsigned long pfn)
> +{
> + struct vmemmap_backing *vmem_back;
> + struct page *page;
> + unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
> + unsigned long pg_va = (unsigned long) pfn_to_page(pfn);
>
> + for (vmem_back = vmemmap_list; vmem_back; vmem_back = vmem_back->list) {
> + if (pg_va < vmem_back->virt_addr)
> + continue;
> +
> + /* Check that page struct is not split between real pages */
> + if ((pg_va + sizeof(struct page)) >
> + (vmem_back->virt_addr + page_size))
> + return NULL;
> +
> + page = (struct page *) (vmem_back->phys + pg_va -
> + vmem_back->virt_addr);
> + return page;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
> +
> +#elif defined(CONFIG_FLATMEM)
> +
> +struct page *realmode_pfn_to_page(unsigned long pfn)
> +{
> + struct page *page = pfn_to_page(pfn);
> + return page;
> +}
> +EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
> +
> +#endif /* CONFIG_SPARSEMEM_VMEMMAP/CONFIG_FLATMEM */
> +
> +#if defined
[PATCH] mm: kill one if in loop of __free_pages_bootmem
We should not check loop+1 with loop end in loop body.
Just duplicate two lines code to avoid it.
That will help a bit when we have huge amount of pages on
system with 16TiB memory.
Signed-off-by: Yinghai Lu
Cc: Mel Gorman
---
mm/page_alloc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -750,19 +750,19 @@ static void __free_pages_ok(struct page
void __init __free_pages_bootmem(struct page *page, unsigned int order)
{
unsigned int nr_pages = 1 << order;
+ struct page *p = page;
unsigned int loop;
- prefetchw(page);
- for (loop = 0; loop < nr_pages; loop++) {
- struct page *p = &page[loop];
-
- if (loop + 1 < nr_pages)
- prefetchw(p + 1);
+ prefetchw(p);
+ for (loop = 0; loop < (nr_pages - 1); loop++, p++) {
+ prefetchw(p + 1);
__ClearPageReserved(p);
set_page_count(p, 0);
}
+ __ClearPageReserved(p);
+ set_page_count(p, 0);
- page_zone(page)->managed_pages += 1 << order;
+ page_zone(page)->managed_pages += nr_pages;
set_page_refcounted(page);
__free_pages(page, order);
}
--
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] decompressors: fix "no limit" output buffer length
On 07/23/2013 03:08 AM, Jon Medhurst (Tixy) wrote:
On Mon, 2013-07-22 at 15:56 +0900, Alexandre Courbot wrote:
When decompressing into memory, the output buffer length is set to some
arbitrarily high value (0x7fff) to indicate the output is,
virtually, unlimited in size.
The problem with this is that some platforms have their physical memory
at high physical addresses (0x8000 or more), and that the output
buffer address and its "unlimited" length cannot be added without
overflowing. An example of this can be found in inflate_fast():
/* next_out is the output buffer address */
out = strm->next_out - OFF;
/* avail_out is the output buffer size. end will overflow if the output
* address is >= 0x8104 */
end = out + (strm->avail_out - 257);
This has huge consequences on the performance of kernel decompression,
since the following exit condition of inflate_fast() will be always
true:
} while (in < last && out < end);
Indeed, "end" has overflowed and is now always lower than "out". As a
result, inflate_fast() will return after processing one single byte of
input data, and will thus need to be called an unreasonably high number
of times. This probably went unnoticed because kernel decompression is
fast enough even with this issue.
Nonetheless, adjusting the output buffer length in such a way that the
above pointer arithmetic never overflows results in a kernel
decompression that is about 3 times faster on affected machines.
Signed-off-by: Alexandre Courbot
This speeds up booting of my Versatile Express TC2 by 15 seconds when
starting on the A7 cluster :-)
Tested-by: Jon Medhurst
Good to hear! Thanks for taking the time to test this.
Although the patch seems ok to me in its current form, there are two
points for which I still have small doubts:
1) Whether size_t and pointers will have the same size on all platforms.
It not we might end up with some funny behaviors. My limited research on
the topic did not end up with evidence that their size may differ, but I
don't have a definite case that they do neither.
2) Whether all platforms have their address space ending at (~0). I do
not have a concrete example in mind, but can imagine, say, a platform
which represents its addresses as 32-bit pointers but has a smaller
physical bus. In this case the current calculation could cause overflows
again.
If one (or both) of these points are to be concerned about, there may
exist macros I am not aware of that better represent the actual limits
of pointers in the kernel.
Thanks,
Alex.
---
lib/decompress_inflate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index 19ff89e..d619b28 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -48,7 +48,7 @@ STATIC int INIT gunzip(unsigned char *buf, int len,
out_len = 0x8000; /* 32 K */
out_buf = malloc(out_len);
} else {
- out_len = 0x7fff; /* no limit */
+ out_len = ((size_t)~0) - (size_t)out_buf; /* no limit */
}
if (!out_buf) {
error("Out of memory while allocating output buffer");
--
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: [Panic - Bisected] f1a18a10566081abfce1649c2f3884b28fff7372 cases panic on boot
On 22 July 2013 21:45, Kevin Winchester wrote: > I have found that the new CPU Package temperature thermal driver introduced > in this merge window causes my HP laptop to panic on boot. I just merged Zhang's pull request that should contain a fix for this, but was planning on the allmoconfig build finishing before pushing it out. Give me a few minutes.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch net-next 7/7] selinux: use generic union inet_addr
On Mon, 2013-07-22 at 16:36 -0400, Paul Moore wrote: > > These changes are going to affect Smack as well. You either need to respin > this patch to include all of the LSMs (Smack should be the only other > affected > LSM) or add a new patch to the patchset. > Yeah, I will include the Smack part as well. 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 V2] USB: EHCI: make ehci-w90X900 a separate driver
2013/7/22 Manjunath Goudar :
> Separate the W90X900(W90P910) on-chip host controller driver from
> ehci-hcd host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> however, note that other changes are still needed before W90X900(W90P910)
> can be booted with a multi-platform kernel
>
> and an ehci driver that only works on one of them.
>
> With the infrastructure added by Alan Stern in patch 3e0232039
> "USB: EHCI: prepare to make ehci-hcd a library module", we can
> avoid this problem by turning a bus glue into a separate
> module, as we do here for the w90X900 bus glue.
>
> Signed-off-by: Manjunath Goudar
> Acked-by: Arnd Bergmann
> Cc: Greg KH
> Cc: Alan Stern
> Cc: Wan ZongShun
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
Manjunath,
Thanks for your patch, it is good to me.
Acked-by: Wan Zongshun
> V2:
> -Arranged #include's in alphabetical order.
> -Replaced "w90p910" by "w90x900" because it is supports
> all series of w90x900.
> ---
> drivers/usb/host/Kconfig|2 +-
> drivers/usb/host/Makefile |1 +
> drivers/usb/host/ehci-hcd.c |5 ---
> drivers/usb/host/ehci-w90x900.c | 85
> ---
> 4 files changed, 37 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index ba52912..7bc598b 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -244,7 +244,7 @@ config USB_EHCI_MV
> SoCs, see USB_EHCI_HCD_ORION for those.
>
> config USB_W90X900_EHCI
> - bool "W90X900(W90P910) EHCI support"
> + tristate "W90X900(W90P910) EHCI support"
> depends on ARCH_W90X900
> ---help---
> Enables support for the W90X900 USB controller
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 7664db8..28adb3f 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
> obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o
> obj-$(CONFIG_USB_EHCI_MV) += ehci-mv.o
> +obj-$(CONFIG_USB_W90X900_EHCI) += ehci-w90x900.o
>
> obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
> obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 5717dcd..4a5644e 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL");
> #define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver
> #endif
>
> -#ifdef CONFIG_USB_W90X900_EHCI
> -#include "ehci-w90x900.c"
> -#definePLATFORM_DRIVER ehci_hcd_w90x900_driver
> -#endif
> -
> #ifdef CONFIG_USB_OCTEON_EHCI
> #include "ehci-octeon.c"
> #define PLATFORM_DRIVERehci_octeon_driver
> diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c
> index 59e0e24..4d6631d 100644
> --- a/drivers/usb/host/ehci-w90x900.c
> +++ b/drivers/usb/host/ehci-w90x900.c
> @@ -11,13 +11,28 @@
> *
> */
>
> +#include
> +#include
> +#include
> +#include
> +#include
> #include
> +#include
> +#include
> +
> +#include "ehci.h"
>
> /* enable phy0 and phy1 for w90p910 */
> #defineENPHY (0x01<<8)
> #define PHY0_CTR (0xA4)
> #define PHY1_CTR (0xA8)
>
> +#define DRIVER_DESC "EHCI w90x900 driver"
> +
> +static const char hcd_name[] = "ehci-w90x900 ";
> +
> +static struct hc_driver __read_mostly ehci_w90x900_hc_driver;
> +
> static int usb_w90x900_probe(const struct hc_driver *driver,
> struct platform_device *pdev)
> {
> @@ -99,54 +114,6 @@ void usb_w90x900_remove(struct usb_hcd *hcd, struct
> platform_device *pdev)
> usb_put_hcd(hcd);
> }
>
> -static const struct hc_driver ehci_w90x900_hc_driver = {
> - .description = hcd_name,
> - .product_desc = "Nuvoton w90x900 EHCI Host Controller",
> - .hcd_priv_size = sizeof(struct ehci_hcd),
> -
> - /*
> -* generic hardware linkage
> -*/
> - .irq = ehci_irq,
> - .flags = HCD_USB2|HCD_MEMORY,
> -
> - /*
> -* basic lifecycle operations
> -*/
> - .reset = ehci_setup,
> - .start = ehci_run,
> -
> - .stop = ehci_stop,
> - .shutdown = ehci_shutdown,
> -
> - /*
> -* managing i/o requests and associated device resources
> -*/
> - .urb_enqueue = ehci_urb_enqueue,
> - .urb_dequeue = ehci_urb_dequeue,
> - .endpoint_disable = ehci_endpoint_disable,
> - .endpoint_reset = ehci_endpoint_reset,
> -
> - /*
> -* scheduling support
> -*/
> - .get_frame_number = ehci_get_frame,
> -
> - /*
> -* root hub support
> -*/
> - .hub_status_data = ehci_hub_status_data,
> - .hub_control = ehci_hub_control
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On 2013/7/23 9:39, Steven Rostedt wrote: > On Tue, 2013-07-23 at 09:26 +0800, Li Zefan wrote: > >> IT companies in China, they try to make sure there's at least one (most the >> time the result is just one) female developer/tester in a team, and a team >> is ~10 people. Even if it's a kernel team, but it's harder to meet. >> >> Don't know if the same strategy is applied in other countries. > > Just my observation, but it seems that I see more women in tech from the > Asian countries than from the US. > > Watching my two teenage daughters grow up here as well as their friends, > the focus of our schools still seem more bent on being good in sports > than in academics, and even worse for science. Sports for girls happen > to be much more serious than when I was in school. Being a "nerd" for a > boy is starting to get a bit more acceptance (see Big Bang Theory), but > for girls they seem a bit more harsh. At least from what I can tell by > watching how things are with my kids and their friends. One of the > friends of my daughter, who does very well in school, hides her grades > and "pretends" to be stupid. This is really a sad state of affairs if > you ask me :-( > In china we are in the opposite. In college girls like to stay in school library to study, and in general they get better scores than boys, and they don't like sports. But being good in study is not the same as being good at programming, and in fact they are not keen in coding! And I think IT companies in China tend to lower their requirements when the job interviewee is a female. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] drm: Pass page flip ioctl flags to driver
This lets drivers see the flags requested by the application
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++--
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 23 +++
drivers/gpu/drm/nouveau/nouveau_display.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_display.h | 3 ++-
drivers/gpu/drm/omapdrm/omap_crtc.c | 3 ++-
drivers/gpu/drm/radeon/radeon_display.c | 3 ++-
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 ++-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 3 ++-
include/drm/drm_crtc.h| 3 ++-
13 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..989072c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3587,7 +3587,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
old_fb = crtc->fb;
- ret = crtc->funcs->page_flip(crtc, fb, e);
+ ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->flags);
if (ret) {
if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
spin_lock_irqsave(&dev->event_lock, flags);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 9a35d17..14f5c1d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -184,8 +184,9 @@ static struct drm_crtc_helper_funcs
exynos_crtc_helper_funcs = {
};
static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event)
+struct drm_framebuffer *fb,
+struct drm_pending_vblank_event *event,
+uint32_t page_flip_flags)
{
struct drm_device *dev = crtc->dev;
struct exynos_drm_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cef35d3..c7cb2de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -380,7 +380,8 @@ struct drm_i915_display_funcs {
void (*init_clock_gating)(struct drm_device *dev);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- struct drm_i915_gem_object *obj);
+ struct drm_i915_gem_object *obj,
+ uint32_t flags);
int (*update_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
int x, int y);
void (*hpd_irq_setup)(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ae3dc5d..bdb8854 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7320,7 +7320,8 @@ inline static void intel_mark_page_flip_active(struct
intel_crtc *intel_crtc)
static int intel_gen2_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+uint32_t flags)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -7364,7 +7365,8 @@ err:
static int intel_gen3_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+uint32_t flags)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -7405,7 +7407,8 @@ err:
static int intel_gen4_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+uint32_t flags)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -7453,7 +7456,8 @@ err:
static int intel_gen6_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffe
[PATCH 2/5] drm: Add DRM_MODE_PAGE_FLIP_ASYNC flag definition
This requests that the driver perform the page flip as soon as
possible, not necessarily waiting for vblank.
Signed-off-by: Keith Packard
---
include/uapi/drm/drm_mode.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..5508117 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -412,7 +412,8 @@ struct drm_mode_crtc_lut {
};
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
-#define DRM_MODE_PAGE_FLIP_FLAGS DRM_MODE_PAGE_FLIP_EVENT
+#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
+#define DRM_MODE_PAGE_FLIP_FLAGS
(DRM_MODE_PAGE_FLIP_EVENT|DRM_MODE_PAGE_FLIP_ASYNC)
/*
* Request a page flip on the specified crtc.
@@ -426,11 +427,14 @@ struct drm_mode_crtc_lut {
* flip is already pending as the ioctl is called, EBUSY will be
* returned.
*
- * The ioctl supports one flag, DRM_MODE_PAGE_FLIP_EVENT, which will
- * request that drm sends back a vblank event (see drm.h: struct
- * drm_event_vblank) when the page flip is done. The user_data field
- * passed in with this ioctl will be returned as the user_data field
- * in the vblank event struct.
+ * Flag DRM_MODE_PAGE_FLIP_EVENT requests that drm sends back a vblank
+ * event (see drm.h: struct drm_event_vblank) when the page flip is
+ * done. The user_data field passed in with this ioctl will be
+ * returned as the user_data field in the vblank event struct.
+ *
+ * Flag DRM_MODE_PAGE_FLIP_ASYNC requests that the flip happen
+ * 'as soon as possible', meaning that it not delay waiting for vblank.
+ * This may cause tearing on the screen.
*
* The reserved field must be zero until we figure out something
* clever to use it for.
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] drm/i915: Add async page flip support for IVB
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 40 ++--
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc3d6a7..029cfb0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -209,6 +209,7 @@
#define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
#define MI_DISPLAY_FLIPMI_INSTR(0x14, 2)
#define MI_DISPLAY_FLIP_I915 MI_INSTR(0x14, 1)
+#define MI_DISPLAY_FLIP_ASYNC_INDICATOR (1 << 22)
#define MI_DISPLAY_FLIP_PLANE(n) ((n) << 20)
/* IVB has funny definitions for which plane to flip. */
#define MI_DISPLAY_FLIP_IVB_PLANE_A (0 << 19)
@@ -217,6 +218,11 @@
#define MI_DISPLAY_FLIP_IVB_SPRITE_B (3 << 19)
#define MI_DISPLAY_FLIP_IVB_PLANE_C (4 << 19)
#define MI_DISPLAY_FLIP_IVB_SPRITE_C (5 << 19)
+/* These go in the bottom of the base address value */
+#define MI_DISPLAY_FLIP_TYPE_SYNC(0 << 0)
+#define MI_DISPLAY_FLIP_TYPE_ASYNC (1 << 0)
+#define MI_DISPLAY_FLIP_TYPE_STEREO (2 << 0)
+#define MI_DISPLAY_FLIP_TYPE_SYNCHRONOUS (0 << 0)
#define MI_ARB_ON_OFF MI_INSTR(0x08, 0)
#define MI_ARB_ENABLE(1<<0)
#define MI_ARB_DISABLE (0<<0)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bdb8854..1bcc6b4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7514,6 +7514,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_ring_buffer *ring = &dev_priv->ring[BCS];
uint32_t plane_bit = 0;
+ uint32_t cmd;
+ uint32_t base;
int ret;
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
@@ -7536,13 +7538,43 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
goto err_unpin;
}
+ cmd = MI_DISPLAY_FLIP_I915 | plane_bit;
+ base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
+
+ if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
+
+ /* XXX check limitations for async flip here */
+
+ if (fb->pitches[0] != I915_READ(DSPSTRIDE(intel_crtc->plane))) {
+ WARN_ONCE(1, "mismatching stride in async plane flip
(%d != %d)\n",
+ fb->pitches[0],
I915_READ(DSPSTRIDE(intel_crtc->plane)));
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if (obj->tiling_mode != I915_TILING_X) {
+ WARN_ONCE(1, "async plane flip requires X tiling\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if ((I915_READ(DSPCNTR(intel_crtc->plane)) & DISPPLANE_TILED)
== 0) {
+ WARN_ONCE(1, "display not currently tiled in async
plane flip\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
+ base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
+ }
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err_unpin;
- intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
+ intel_ring_emit(ring, cmd);
intel_ring_emit(ring, (fb->pitches[0] | obj->tiling_mode));
- intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) +
intel_crtc->dspaddr_offset);
+ intel_ring_emit(ring, base);
intel_ring_emit(ring, (MI_NOOP));
intel_mark_page_flip_active(intel_crtc);
@@ -9705,6 +9737,10 @@ void intel_modeset_init(struct drm_device *dev)
dev->mode_config.max_width = 8192;
dev->mode_config.max_height = 8192;
}
+
+ if (IS_GEN7(dev))
+ dev->mode_config.async_page_flip = true;
+
dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
DRM_DEBUG_KMS("%d display pipe%s available.\n",
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] drm/i915: Add async page flip support for SNB
Just copies the IVB code
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 39
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1bcc6b4..9d7919b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7463,20 +7463,51 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_ring_buffer *ring = &dev_priv->ring[RCS];
uint32_t pf, pipesrc;
+ uint32_t cmd;
+ uint32_t base;
int ret;
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
if (ret)
goto err;
+ cmd = MI_DISPLAY_FLIP | MI_DISPLAY_FLIP_PLANE(intel_crtc->plane);
+ base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
+
+ if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
+
+ /* XXX check limitations for async flip here */
+
+ if (fb->pitches[0] != I915_READ(DSPSTRIDE(intel_crtc->plane))) {
+ WARN_ONCE(1, "mismatching stride in async plane flip
(%d != %d)\n",
+ fb->pitches[0],
I915_READ(DSPSTRIDE(intel_crtc->plane)));
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if (obj->tiling_mode != I915_TILING_X) {
+ WARN_ONCE(1, "async plane flip requires X tiling\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if ((I915_READ(DSPCNTR(intel_crtc->plane)) & DISPPLANE_TILED)
== 0) {
+ WARN_ONCE(1, "display not currently tiled in async
plane flip\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
+ base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
+ }
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err_unpin;
- intel_ring_emit(ring, MI_DISPLAY_FLIP |
- MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
+ intel_ring_emit(ring, cmd);
intel_ring_emit(ring, fb->pitches[0] | obj->tiling_mode);
- intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) +
intel_crtc->dspaddr_offset);
+ intel_ring_emit(ring, base);
/* Contrary to the suggestions in the documentation,
* "Enable Panel Fitter" does not seem to be required when page
@@ -9738,7 +9769,7 @@ void intel_modeset_init(struct drm_device *dev)
dev->mode_config.max_height = 8192;
}
- if (IS_GEN7(dev))
+ if (IS_GEN6(dev) || IS_GEN7(dev))
dev->mode_config.async_page_flip = true;
dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] drm: Advertise async page flip ability through GETCAP ioctl
Let applications know whether the kernel supports asynchronous page
flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c | 3 +++
drivers/gpu/drm/drm_ioctl.c | 3 +++
include/drm/drm_crtc.h | 3 +++
include/uapi/drm/drm.h | 1 +
4 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 989072c..0909af6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3514,6 +3514,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
page_flip->reserved != 0)
return -EINVAL;
+ if ((page_flip->flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
!dev->mode_config.async_page_flip)
+ return -EINVAL;
+
obj = drm_mode_object_find(dev, page_flip->crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj)
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ffd7a7b..7602177 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -303,6 +303,9 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
case DRM_CAP_TIMESTAMP_MONOTONIC:
req->value = drm_timestamp_monotonic;
break;
+ case DRM_CAP_ASYNC_PAGE_FLIP:
+ req->value = dev->mode_config.async_page_flip;
+ break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0820ab6..13d215f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -845,6 +845,9 @@ struct drm_mode_config {
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
+
+ /* whether async page flip is supported or not */
+ bool async_page_flip;
};
#define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 238a166..2adfaa5 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -780,6 +780,7 @@ struct drm_event_vblank {
#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
#define DRM_CAP_PRIME 0x5
#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
+#define DRM_CAP_ASYNC_PAGE_FLIP 0x7
#define DRM_PRIME_CAP_IMPORT 0x1
#define DRM_PRIME_CAP_EXPORT 0x2
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drm: Asynchronouse page flipping interface and Intel implementation
Here's a sequence of five patches that exposes an interface to request of the driver that the page flipping request be executed without waiting for vblank. It's optional, and drivers can expose whether it is supported through the existing GETCAP ioctl. This supports only Ivybridge and Sandybridge Intel graphics chips as that's what I've got to test on; of course all of the other drivers have been modified so that they still compile cleanly. -- keith.pack...@intel.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 2/2] mm: page_alloc: avoid slowpath for more than MAX_ORDER allocation.
Hi Johannes,
Thank you for your reply.
This is my first kernel patch, sorry for the small mistakes.
Please find my comments inline.
>
> From: Johannes Weiner
>To: Pintu Kumar
>Cc: a...@linux-foundation.org; mgor...@suse.de; jiang@huawei.com;
>minc...@kernel.org; c...@linux.vnet.ibm.com; linux...@kvack.org;
>linux-kernel@vger.kernel.org; c...@samsung.com; pintu_agar...@yahoo.com
>Sent: Monday, 22 July 2013 10:08 PM
>Subject: Re: [PATCH 2/2] mm: page_alloc: avoid slowpath for more than
>MAX_ORDER allocation.
>
>
>Hi Pintu,
>
>On Mon, Jul 22, 2013 at 05:02:42PM +0530, Pintu Kumar wrote:
>> It was observed that if order is passed as more than MAX_ORDER
>> allocation in __alloc_pages_nodemask, it will unnecessarily go to
>> slowpath and then return failure.
>> Since we know that more than MAX_ORDER will anyways fail, we can
>> avoid slowpath by returning failure in nodemask itself.
>>
>> Signed-off-by: Pintu Kumar
>> ---
>> mm/page_alloc.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 202ab58..6d38e75 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -1564,6 +1564,10 @@ __setup("fail_page_alloc=", setup_fail_page_alloc);
>>
>> static bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int order)
>> {
>> + if (order >= MAX_ORDER) {
>> + WARN_ON(!(gfp_mask & __GFP_NOWARN));
>> + return false;
>> + }
>
>I don't see how this solves what you describe (should return true?)
>
Ok, sorry, I will correct this.
>It would also not be a good place to put performance optimization,
>because this function is only called as part of a debugging mechanism
>that is usually disabled.
>
Ok, so you mean, we should add this check directly at the top of
__alloc_pages_nodemask() ??
>Lastly, order >= MAX_ORDER is not supported by the page allocator, and
>we do not want to punish 99.999% of all legitimate page allocations in
>the fast path in order to catch an unlikely situation like this.
So, is it fine if we add an unlikely condition like below:
if (unlikely(order >= MAX_ORDER))
>Having the check only in the slowpath is a good thing.
>
Sorry, I could not understand, why adding this check in slowpath is only good.
We could have returned failure much before that.
Without this check, we are actually allowing failure of "first allocation
attempt" and then returning the cause of failure in slowpath.
I thought it will be better to track the unlikely failure in the system as
early as possible, at least from the embedded system prospective.
Let me know your opinion.
>--
>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>the body to majord...@kvack.org. For more info on Linux MM,
>see: http://www.linux-mm.org/ .
>Don't email: mailto:"d...@kvack.org";> em...@kvack.org
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/8] x86/PCI: prevent re-allocation of already existing bridge and ROM resources
On Monday, July 22, 2013 07:33:32 PM Bjorn Helgaas wrote:
> On Mon, Jul 22, 2013 at 7:18 PM, Bjorn Helgaas wrote:
> > On Mon, Jul 22, 2013 at 6:08 PM, Bjorn Helgaas wrote:
> >> On Wed, Jul 3, 2013 at 8:04 AM, Mika Westerberg
> >> wrote:
> >>> In hotplug case (especially with Thunderbolt enabled systems) we might
> >>> need
> >>> to call pcibios_resource_survey_bus() several times for a bus. The
> >>> function
> >>> ends up calling pci_claim_resource() for each bridge resource that then
> >>> fails claiming that the resource exists already (which it does). Once this
> >>> happens the resource is invalidated thus preventing devices behind the
> >>> bridge to allocate their resources.
> >>>
> >>> To fix this we do what has been done in pcibios_allocate_dev_resources()
> >>> and check 'parent' of the given resource. If it is non-NULL it means that
> >>> the resource has been allocated already and we can skip it. We do the same
> >>> for ROM resources as well.
> >>>
> >>> Signed-off-by: Mika Westerberg
> >>
> >> This looks reasonable to me.
> >
> > Acked-by: Bjorn Helgaas
> >
> >> However, the use of "r->parent" to determine whether the resource is
> >> already allocated is nothing specific to x86. So I think we might be
> >> missing an opportunity to make this more consistent across
> >> architectures. I looked at other callers of pci_claim_resource() for
> >> bridge and ROM resources, and it looks like we might be able to make
> >> similar changes in:
> >>
> >> frv pcibios_allocate_bus_resources()
> >> ia64 pcibios_fixup_resources() (via pcibios_fixup_bridge_resources())
> >> mn10300 pcibios_allocate_bus_resources()
> >> mn10300 pcibios_assign_resources() (ROM)
> >> mn10300 pcibios_fixup_device_resources()
> >> parisc lba_fixup_bus()
> >>
> >> I really hate the idea of fixing something for x86 but not for other
> >> arches, so maybe somebody could take a deeper look at this and see if
> >> it would make sense to change the other arches, too.
>
> I misspoke here. The change below helps fix an issue on x86. It's
> only an issue on x86 because only x86 has acpiphp and
> pcibios_resource_survey_bus(). Other arches *do* call
> pci_claim_resource(), but making similar changes on other arches does
> not fix similar issues there, so it's not really a matter of "fixing
> only x86."
>
> My motivation is to move toward unification of how we claim resources.
> There's nothing inherently arch-specific about calling
> pci_claim_resource(), but arches use a variety of tests involving
> "r->flags", "r->parent", and "r->start" to decide whether to do so.
> Ideally we would call pci_claim_resource() from the core, not from
> arch code, and we would use a set of tests that work for all arches
> and situations.
Agreed.
Do you think we can discuss that at the miniconf during the LPC?
We have resources handling on our agenda anyway.
> We can always do the minimum of changing only what's absolutely
> required, but the result is divergence and increased maintenance work
> in the long term. I'm trying to counter that a little bit by
> encouraging people to consider refactorings that fix the current issue
> while reducing maintenance effort.
I understand the motivation, but I also think that such changes should be
coordinated, for example so that we know that they have been tested on all
architectures in question before they go to the mainline for good.
Thanks,
Rafael
> >>> ---
> >>> arch/x86/pci/i386.c | 4
> >>> 1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
> >>> index 94919e3..db6b1ab 100644
> >>> --- a/arch/x86/pci/i386.c
> >>> +++ b/arch/x86/pci/i386.c
> >>> @@ -210,6 +210,8 @@ static void pcibios_allocate_bridge_resources(struct
> >>> pci_dev *dev)
> >>> r = &dev->resource[idx];
> >>> if (!r->flags)
> >>> continue;
> >>> + if (r->parent) /* Already allocated */
> >>> + continue;
> >>> if (!r->start || pci_claim_resource(dev, idx) < 0) {
> >>> /*
> >>> * Something is wrong with the region.
> >>> @@ -318,6 +320,8 @@ static void pcibios_allocate_dev_rom_resource(struct
> >>> pci_dev *dev)
> >>> r = &dev->resource[PCI_ROM_RESOURCE];
> >>> if (!r->flags || !r->start)
> >>> return;
> >>> + if (r->parent) /* Already allocated */
> >>> + return;
> >>>
> >>> if (pci_claim_resource(dev, PCI_ROM_RESOURCE) < 0) {
> >>> r->end -= r->start;
> >>> --
> >>> 1.8.3.2
> >>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscrib
Re: [ 00/19] 3.10.1-stable review
I wanted to take Sarah up on her offer to pay my respects for the great work she is doing to bring civility to the LKLM community as detailed in http://marc.info/?l=linux-kernel&m=137390362508794 Linus, I want to start off by saying, though I'm mostly a windows developer, I've gained a whole new level of appreciation for you, with the very professional way you have handled Sarah's pleas for civility and professionalism. I hope you don't think of "professionalism" and "civility" as dirty words, because I certainly did not mean it that way. I have tried to express my own feelings in the most professional and civil way I could muster in this article http://www.postgresonline.com/journal/archives/311-In-defense-of-being-blunt-and-to-the-point.html . I want to first say that while Sarah does not speak for me, and I suspect she does not speak for all minorities, females, and the poor down-trodden developers in your ranks that have had their feelings torn apart by your less than kind words, I do still appreciate her great efforts to bring civility to LKML. You go girl, Sarah -- keep fighting the good fight, we are with you - both men and women. I do hope your efforts do not make it difficult for women to distinguish criticism from platitudes. Perhaps some day, Sarah, your dream will come true and you can be a top tier committer as you stated in your moving up the career rank comment. http://sarah.thesharps.us/2013/07/15/no-more-verbal-abuse/#comments You won't even have to work for it, because Linus will be so scared of you he'll just hand it over to you and accept any patch you give him. Please don't take my above statement as an accusation that that is what you are doing. That is not at all what I meant. I just meant to say that if you wanted to exercise that option, you are in a good position to. Consider it just my suggested career advice just like the wonderful career advice you have given to other women in your blog http://sarah.thesharps.us/2013/06/23/dont-be-a-jerk/ . I do have one final request. If you do succeed in your quest for civility and professionalism, please do try to keep the office politics where they belong, in the office. I'd still like to think there is still some semblance of openness after you are done with your restructuring. I want to thank you one more time for the great work you have done bringing this GREAT INJUSTICE to our attention. I certainly would not have discovered it without all the great accolades you have won for this from both men and women http://www.wired.co.uk/news/archive/2013-07/22/sarah-sharp . You must be some kind of wonder woman. I am so very very appreciative that there is a woman out there willing to stand up to Linus verbal abuse and fight for those who are too afraid to stand up for themselves. You are just SO *fucking* cool. YOU GO GIRL SARAH. Thanks, Regina Obe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/8] x86/PCI: prevent re-allocation of already existing bridge and ROM resources
On Monday, July 22, 2013 07:18:38 PM Bjorn Helgaas wrote:
> On Mon, Jul 22, 2013 at 6:08 PM, Bjorn Helgaas wrote:
> > On Wed, Jul 3, 2013 at 8:04 AM, Mika Westerberg
> > wrote:
> >> In hotplug case (especially with Thunderbolt enabled systems) we might need
> >> to call pcibios_resource_survey_bus() several times for a bus. The function
> >> ends up calling pci_claim_resource() for each bridge resource that then
> >> fails claiming that the resource exists already (which it does). Once this
> >> happens the resource is invalidated thus preventing devices behind the
> >> bridge to allocate their resources.
> >>
> >> To fix this we do what has been done in pcibios_allocate_dev_resources()
> >> and check 'parent' of the given resource. If it is non-NULL it means that
> >> the resource has been allocated already and we can skip it. We do the same
> >> for ROM resources as well.
> >>
> >> Signed-off-by: Mika Westerberg
> >
> > This looks reasonable to me.
>
> Acked-by: Bjorn Helgaas
Thanks a lot!
> > However, the use of "r->parent" to determine whether the resource is
> > already allocated is nothing specific to x86. So I think we might be
> > missing an opportunity to make this more consistent across
> > architectures. I looked at other callers of pci_claim_resource() for
> > bridge and ROM resources, and it looks like we might be able to make
> > similar changes in:
> >
> > frv pcibios_allocate_bus_resources()
> > ia64 pcibios_fixup_resources() (via pcibios_fixup_bridge_resources())
> > mn10300 pcibios_allocate_bus_resources()
> > mn10300 pcibios_assign_resources() (ROM)
> > mn10300 pcibios_fixup_device_resources()
> > parisc lba_fixup_bus()
> >
> > I really hate the idea of fixing something for x86 but not for other
> > arches, so maybe somebody could take a deeper look at this and see if
> > it would make sense to change the other arches, too.
> >
> > Bjorn
> >
> >> ---
> >> arch/x86/pci/i386.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
> >> index 94919e3..db6b1ab 100644
> >> --- a/arch/x86/pci/i386.c
> >> +++ b/arch/x86/pci/i386.c
> >> @@ -210,6 +210,8 @@ static void pcibios_allocate_bridge_resources(struct
> >> pci_dev *dev)
> >> r = &dev->resource[idx];
> >> if (!r->flags)
> >> continue;
> >> + if (r->parent) /* Already allocated */
> >> + continue;
> >> if (!r->start || pci_claim_resource(dev, idx) < 0) {
> >> /*
> >> * Something is wrong with the region.
> >> @@ -318,6 +320,8 @@ static void pcibios_allocate_dev_rom_resource(struct
> >> pci_dev *dev)
> >> r = &dev->resource[PCI_ROM_RESOURCE];
> >> if (!r->flags || !r->start)
> >> return;
> >> + if (r->parent) /* Already allocated */
> >> + return;
> >>
> >> if (pci_claim_resource(dev, PCI_ROM_RESOURCE) < 0) {
> >> r->end -= r->start;
> >> --
> >> 1.8.3.2
> >>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, 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/
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Tue, 2013-07-23 at 09:26 +0800, Li Zefan wrote: > IT companies in China, they try to make sure there's at least one (most the > time the result is just one) female developer/tester in a team, and a team > is ~10 people. Even if it's a kernel team, but it's harder to meet. > > Don't know if the same strategy is applied in other countries. Just my observation, but it seems that I see more women in tech from the Asian countries than from the US. Watching my two teenage daughters grow up here as well as their friends, the focus of our schools still seem more bent on being good in sports than in academics, and even worse for science. Sports for girls happen to be much more serious than when I was in school. Being a "nerd" for a boy is starting to get a bit more acceptance (see Big Bang Theory), but for girls they seem a bit more harsh. At least from what I can tell by watching how things are with my kids and their friends. One of the friends of my daughter, who does very well in school, hides her grades and "pretends" to be stupid. This is really a sad state of affairs if you ask me :-( -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] x86, acpi: Fix wrong checking condition in acpi_register_lapic().
Reviewed-by: Len Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] x86, acpi: Fix wrong checking condition in acpi_register_lapic().
We wanted to check if the acpi id is out of range. It should be:
if (id >= (MAX_LOCAL_APIC)).
Signed-off-by: Tang Chen
---
arch/x86/kernel/acpi/boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index d81a972..2a15ae7 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -199,7 +199,7 @@ static void __cpuinit acpi_register_lapic(int id, u8
enabled)
{
unsigned int ver = 0;
- if (id >= (MAX_LOCAL_APIC-1)) {
+ if (id >= (MAX_LOCAL_APIC)) {
printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
return;
}
--
1.7.10.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 2/2] input/uinput: add UI_GET_SYSPATH ioctl to retrieve the sysfs path
On Mon, Jul 15, 2013 at 03:37:09PM +0200, Benjamin Tissoires wrote:
> Evemu [1] uses uinput to replay devices traces it has recorded. However,
> the way evemu uses uinput is slightly different from how uinput is
> supposed to be used.
> Evemu creates the device node through uinput, bu inject events through
> the input device node directly (and skipping the uinput node).
>
> Currently, evemu relies on an heuristic to guess which input node was
> created. The problem is that is heuristic is subjected to races between
> different uinput devices or even with physical devices. Having a way
> to retrieve the sysfs path allows us to find the event node without
> having to rely on this heuristic.
>
> [1] http://www.freedesktop.org/wiki/Evemu/
>
> Signed-off-by: Benjamin Tissoires
Tested-by: Peter Hutterer
I'd really appreciate a comment above the ioctl define stating what the
ioctl actually returns. only comment regarding the code:
> +static int uinput_str_to_user(const char *str, unsigned int maxlen,
> + void __user *p)
I'd do this with a signature of the type (dest, src, len).
Cheers,
Peter
> ---
> drivers/input/misc/uinput.c | 37 -
> include/linux/uinput.h | 1 +
> include/uapi/linux/uinput.h | 3 +++
> 3 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 7d518b4..49a9f7d 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -22,6 +22,7 @@
> * Changes/Revisions:
> * 0.4 12/07/2013 (Peter Hutterer )
> * - update uinput_user_dev struct to allow abs resolution
> + * - add UI_GET_SYSPATH ioctl
> * 0.3 09/04/2006 (Anssi Hannula )
> * - updated ff support for the changes in kernel interface
> * - added MODULE_VERSION
> @@ -667,6 +668,21 @@ static int uinput_ff_upload_from_user(const char __user
> *buffer,
> __ret; \
> })
>
> +static int uinput_str_to_user(const char *str, unsigned int maxlen,
> + void __user *p)
> +{
> + int len;
> +
> + if (!str)
> + return -ENOENT;
> +
> + len = strlen(str) + 1;
> + if (len > maxlen)
> + len = maxlen;
> +
> + return copy_to_user(p, str, len) ? -EFAULT : len;
> +}
> +
> static long uinput_ioctl_handler(struct file *file, unsigned int cmd,
>unsigned long arg, void __user *p)
> {
> @@ -676,6 +692,8 @@ static long uinput_ioctl_handler(struct file *file,
> unsigned int cmd,
> struct uinput_ff_erase ff_erase;
> struct uinput_request *req;
> char*phys;
> + const char *path;
> + unsigned intsize;
>
> retval = mutex_lock_interruptible(&udev->mutex);
> if (retval)
> @@ -828,7 +846,24 @@ static long uinput_ioctl_handler(struct file *file,
> unsigned int cmd,
> break;
>
> default:
> - retval = -EINVAL;
> + retval = -EAGAIN;
> + }
> +
> + if (retval == -EAGAIN) {
> + size = _IOC_SIZE(cmd);
> +
> + /* Now check variable-length commands */
> + switch (cmd & ~IOCSIZE_MASK) {
> + case UI_GET_SYSPATH(0):
> + path = kobject_get_path(&udev->dev->dev.kobj,
> + GFP_KERNEL);
> + retval = uinput_str_to_user(path, size, p);
> + kfree(path);
> + break;
> +
> + default:
> + retval = -EINVAL;
> + }
> }
>
> out:
> diff --git a/include/linux/uinput.h b/include/linux/uinput.h
> index 6291a22..64fab81 100644
> --- a/include/linux/uinput.h
> +++ b/include/linux/uinput.h
> @@ -22,6 +22,7 @@
> * Changes/Revisions:
> * 0.4 12/07/2013 (Peter Hutterer )
> * - update uinput_user_dev struct to allow abs resolution
> + * - add UI_GET_SYSPATH ioctl
> * 0.3 24/05/2006 (Anssi Hannula )
> * - update ff support for the changes in kernel interface
> * - add UINPUT_VERSION
> diff --git a/include/uapi/linux/uinput.h b/include/uapi/linux/uinput.h
> index f6a393b..d826409 100644
> --- a/include/uapi/linux/uinput.h
> +++ b/include/uapi/linux/uinput.h
> @@ -22,6 +22,7 @@
> * Changes/Revisions:
> * 0.4 12/07/2013 (Peter Hutterer )
> * - update uinput_user_dev struct to allow abs resolution
> + * - add UI_GET_SYSPATH ioctl
> * 0.3 24/05/2006 (Anssi Hannula )
> * - update ff support for the changes in kernel interface
> * - add UINPUT_VERSION
> @@ -75,6 +76,8 @@ struct uinput_ff_erase {
> #define UI_BEGIN_FF_ERASE_IOWR(UINPUT_IOCTL_BASE, 202,
Re: [PATCH v2 1/8] x86/PCI: prevent re-allocation of already existing bridge and ROM resources
On Mon, Jul 22, 2013 at 7:18 PM, Bjorn Helgaas wrote:
> On Mon, Jul 22, 2013 at 6:08 PM, Bjorn Helgaas wrote:
>> On Wed, Jul 3, 2013 at 8:04 AM, Mika Westerberg
>> wrote:
>>> In hotplug case (especially with Thunderbolt enabled systems) we might need
>>> to call pcibios_resource_survey_bus() several times for a bus. The function
>>> ends up calling pci_claim_resource() for each bridge resource that then
>>> fails claiming that the resource exists already (which it does). Once this
>>> happens the resource is invalidated thus preventing devices behind the
>>> bridge to allocate their resources.
>>>
>>> To fix this we do what has been done in pcibios_allocate_dev_resources()
>>> and check 'parent' of the given resource. If it is non-NULL it means that
>>> the resource has been allocated already and we can skip it. We do the same
>>> for ROM resources as well.
>>>
>>> Signed-off-by: Mika Westerberg
>>
>> This looks reasonable to me.
>
> Acked-by: Bjorn Helgaas
>
>> However, the use of "r->parent" to determine whether the resource is
>> already allocated is nothing specific to x86. So I think we might be
>> missing an opportunity to make this more consistent across
>> architectures. I looked at other callers of pci_claim_resource() for
>> bridge and ROM resources, and it looks like we might be able to make
>> similar changes in:
>>
>> frv pcibios_allocate_bus_resources()
>> ia64 pcibios_fixup_resources() (via pcibios_fixup_bridge_resources())
>> mn10300 pcibios_allocate_bus_resources()
>> mn10300 pcibios_assign_resources() (ROM)
>> mn10300 pcibios_fixup_device_resources()
>> parisc lba_fixup_bus()
>>
>> I really hate the idea of fixing something for x86 but not for other
>> arches, so maybe somebody could take a deeper look at this and see if
>> it would make sense to change the other arches, too.
I misspoke here. The change below helps fix an issue on x86. It's
only an issue on x86 because only x86 has acpiphp and
pcibios_resource_survey_bus(). Other arches *do* call
pci_claim_resource(), but making similar changes on other arches does
not fix similar issues there, so it's not really a matter of "fixing
only x86."
My motivation is to move toward unification of how we claim resources.
There's nothing inherently arch-specific about calling
pci_claim_resource(), but arches use a variety of tests involving
"r->flags", "r->parent", and "r->start" to decide whether to do so.
Ideally we would call pci_claim_resource() from the core, not from
arch code, and we would use a set of tests that work for all arches
and situations.
We can always do the minimum of changing only what's absolutely
required, but the result is divergence and increased maintenance work
in the long term. I'm trying to counter that a little bit by
encouraging people to consider refactorings that fix the current issue
while reducing maintenance effort.
Bjorn
>>> ---
>>> arch/x86/pci/i386.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
>>> index 94919e3..db6b1ab 100644
>>> --- a/arch/x86/pci/i386.c
>>> +++ b/arch/x86/pci/i386.c
>>> @@ -210,6 +210,8 @@ static void pcibios_allocate_bridge_resources(struct
>>> pci_dev *dev)
>>> r = &dev->resource[idx];
>>> if (!r->flags)
>>> continue;
>>> + if (r->parent) /* Already allocated */
>>> + continue;
>>> if (!r->start || pci_claim_resource(dev, idx) < 0) {
>>> /*
>>> * Something is wrong with the region.
>>> @@ -318,6 +320,8 @@ static void pcibios_allocate_dev_rom_resource(struct
>>> pci_dev *dev)
>>> r = &dev->resource[PCI_ROM_RESOURCE];
>>> if (!r->flags || !r->start)
>>> return;
>>> + if (r->parent) /* Already allocated */
>>> + return;
>>>
>>> if (pci_claim_resource(dev, PCI_ROM_RESOURCE) < 0) {
>>> r->end -= r->start;
>>> --
>>> 1.8.3.2
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/22] ARM: shmobile: r8a7779: Remove '0x's from R8A7779 DTS file
On Mon, Jul 22, 2013 at 11:52:38AM +0100, Lee Jones wrote:
> Cc: Simon Horman
> Signed-off-by: Lee Jones
Acked-by: Simon Horman
Let me know if you want me to take this through the renesas tree.
> ---
> arch/arm/boot/dts/r8a7779.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> index 7f146c6..86bd487 100644
> --- a/arch/arm/boot/dts/r8a7779.dtsi
> +++ b/arch/arm/boot/dts/r8a7779.dtsi
> @@ -65,7 +65,7 @@
> sense-bitfield-width = <2>;
> };
>
> - i2c0: i2c@0xffc7 {
> + i2c0: i2c@ffc7 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "renesas,rmobile-iic";
> @@ -74,7 +74,7 @@
> interrupts = <0 79 0x4>;
> };
>
> - i2c1: i2c@0xffc71000 {
> + i2c1: i2c@ffc71000 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "renesas,rmobile-iic";
> @@ -83,7 +83,7 @@
> interrupts = <0 82 0x4>;
> };
>
> - i2c2: i2c@0xffc72000 {
> + i2c2: i2c@ffc72000 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "renesas,rmobile-iic";
> @@ -92,7 +92,7 @@
> interrupts = <0 80 0x4>;
> };
>
> - i2c3: i2c@0xffc73000 {
> + i2c3: i2c@ffc73000 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "renesas,rmobile-iic";
> --
> 1.8.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the wireless-next tree
Hi John,
After merging the wireless-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/ethernet/broadcom/bgmac.c:19:27: fatal error: bcm47xx_nvram.h: No
such file or directory
#include
^
That file only exists for the MIPS architecture ...
Caused by commit 6ffdead8027c ("bcma: make it possible to select SoC
support without mips").
I have used the version of the wireless-next tree from next-20130722 for
today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpb1v0v2ntRN.pgp
Description: PGP signature
Re: 3.11-rc regression bisected: s2disk does not work (was Re: [PATCH v3 13/16] futex: use freezable blocking call)
On Monday, July 22, 2013 05:42:49 PM Colin Cross wrote:
> On Mon, Jul 22, 2013 at 5:32 PM, Linus Torvalds
> wrote:
> > On Mon, Jul 22, 2013 at 4:55 PM, Colin Cross wrote:
> >>
> >> I think the right solution is to add a flag to the freezing task that
> >> marks it unfreezable. I think PF_NOFREEZE would work, although it is
> >> normally used on kernel threads, can you see if the attached patch
> >> helps?
> >
> > Hmm. That does seem to be the right thing to do, but I wonder about
> > the *other* callers of freeze_processes() IOW, kexec and friends.
> >
> > So maybe we should do this in {freeze|thaw}_processes() itself, and
> > just make the rule be that the caller of freeze_processes() itself is
> > obviously not frozen, and has to be the same one that then thaws
> > things?
> >
> > Colin? Rafael? Comments?
> >
> > Linus
>
> I was worried about clearing the flag in thaw_processes(). If a
> kernel thread with PF_NOFREEZE set ever called thaw_processes(), which
> autosleep might do, it would clear the flag. Or if a different thread
> called freeze_processes() and thaw_processes().
Is that legitimate?
> All the other callers besides the SNAPSHOT_FREEZE ioctl stay in the kernel
> between freeze_processes() and thaw_processes(), which makes the fanout of
> places that could call try_to_freeze() much more controllable.
>
> Using a new flag that operates like PF_NOFREEZE but doesn't conflict
> with it, or a nofreeze_depth counter, would also work.
Well, that would be robust enough. At least if the purpose of that new flag
is clearly specified, people hopefully won't be tempted to optimize it away in
the future.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, 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/
A4 paper here
Dear Purchasing manager:
Nice time to you
It is my big pleasure to hear you need A4 paper
If you still need that pls tell me
Then i can send you our best price
Best wishes
Ida
Ida Chen
SALES MANAGER
East Siweite industry Co., Ltd
www.dfswtpaper.com
SKYPE: siweite
Email:s...@swtindustry.comn�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�&j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [PATCH v3 07/15] DMA: shdma: add sh73a0 DMAC data to the device ID table
On Sat, Jul 20, 2013 at 01:28:48PM +0200, Guennadi Liakhovetski wrote: > This configuration data will be re-used, when DMAC DT support is added to > sh73a0, DMAC platform data in setup-sh73a0.c will be removed. > > Signed-off-by: Guennadi Liakhovetski > --- > > v3: also add an of_device_id entry for sh73a0. Please don't post an update for just one patch in a series. Please repost the entire series, even if only one patch is changed. > > drivers/dma/sh/Kconfig|4 + > drivers/dma/sh/Makefile |1 + > drivers/dma/sh/shdma-sh73a0.c | 181 > + > drivers/dma/sh/shdma.h|7 ++ > drivers/dma/sh/shdmac.c |2 + > 5 files changed, 195 insertions(+), 0 deletions(-) > create mode 100644 drivers/dma/sh/shdma-sh73a0.c -- 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] f2fs: add the missing delection of orphan inode entry in write_orphan_inodes()
On 07/22/2013 08:51 PM, Jaegeuk Kim wrote: > Hi, > > 2013-07-19 (금), 16:18 +0800, Gu Zheng: >> After writing orphan inode entry in jornal block, we need to delete each >> entry from the orphan entry list, and release them. >> >> >> Signed-off-by: Gu Zheng >> --- >> fs/f2fs/checkpoint.c |4 >> 1 files changed, 4 insertions(+), 0 deletions(-) >> >> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c >> index 66a6b85..290db04 100644 >> --- a/fs/f2fs/checkpoint.c >> +++ b/fs/f2fs/checkpoint.c >> @@ -337,6 +337,10 @@ static void write_orphan_inodes(struct f2fs_sb_info >> *sbi, block_t start_blk) >> memset(orphan_blk, 0, sizeof(*orphan_blk)); >> page_exist: >> orphan_blk->ino[nentries++] = cpu_to_le32(orphan->ino); >> + >> +list_del(&orphan->list); >> +kmem_cache_free(orphan_entry_slab, orphan); >> +sbi->n_orphans--; > > NAK. > We should not release them here. > Only f2fs_evict_inode can do it. Yeah, f2fs_evict_inode can do this job safely, sorry for my mistake, please ignore this patch.:) Regards, Gu > >> } >> if (!page) >> goto end; > -- 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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On 2013/7/21 21:22, Ric Wheeler wrote: > On 07/20/2013 01:04 PM, Ben Hutchings wrote: >> n Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote: >>> >On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar wrote: > > > >* Felipe Contreras wrote: >>> > > > >>As Linus already pointed out, not everybody has to work with > > >>everybody. > > > >That's not the point though, the point is to potentially roughly double > >the creative brain capacity of the Linux kernel project. >>> > >>> >Unfortunately that's impossible; we all know there aren't as many >>> >women programmers as there are men. >> In some countries, though not all. >> >> But we also know (or should realise) that the gender ratio among >> programmers in general is much less unbalanced than in some free >> software communities including the Linux kernel developers. >> > > Just a couple of data points to add. > > When I was in graduate school in Israel, we had more women doing their phd > then men. Not a huge sample, but it was interesting. > > The counter sample is the number of coding women we have at Red Hat in the > kernel team. We are around zero per cent. Certainly a sign that we need to do > better, regardless of the broader community challenges... > IT companies in China, they try to make sure there's at least one (most the time the result is just one) female developer/tester in a team, and a team is ~10 people. Even if it's a kernel team, but it's harder to meet. Don't know if the same strategy is applied in other countries. -- 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: Re: [PATCH -tip/x86/jumplabel] x86: call out into int3 handler directly instead of using notifier
(2013/07/23 6:00), Jiri Kosina wrote:
> On Mon, 22 Jul 2013, H. Peter Anvin wrote:
>
>> What is the baseline for this patch?
>
> Hi!
>
> it's x86/jumplabel branch, as a followup to commit
> fd4363fff3d96 ("x86: Introduce int3 (breakpoint)-based instruction
> patching") sitting there.
AFAICS, tip/master already merged Jiri's works on tip/x86/jumplabel.
Thus both branches need this. (especially, since this is actual
bugfix, it should go into tip/master.)
> This branch however seems to be broken by Ingo's mismerge; this e-mail
> from earlier today:
>
> https://lkml.org/lkml/2013/7/22/147
>
> implied that he fixed this ("all is fine"), however x86/jumplabel still
> contains just 3/3 of Masami's series, and therefore is broken; 3/3 is not
> enough, it needs also
>
> kprobes/x86: Remove an incorrect comment about int3 in NMI/MCE
> kprobes/x86: Use text_poke_bp() instead of text_poke_smp*()
>
> included or
>
> kprobes/x86: Remove unused text_poke_smp() and text_poke_smp_batch()
> functions
>
> dropped to be in consistent state again.
I hope to pull entire of this series in :)
>
> I pinged Ingo about this:
>
> https://lkml.org/lkml/2013/7/22/281
>
> but the branch still seems to be in an odd state, containing last patch of
> Masami's series.
>
> Thanks in advance for fixing this and applying mi fix as well,
>
Thanks!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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: workqueue, pci: INFO: possible recursive locking detected
On 07/23/2013 05:32 AM, Tejun Heo wrote:
> On Mon, Jul 22, 2013 at 07:52:34PM +0800, Lai Jiangshan wrote:
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index f02c4a4..b021a45 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -4731,6 +4731,7 @@ struct work_for_cpu {
>> long (*fn)(void *);
>> void *arg;
>> long ret;
>> +struct completion done;
>> };
>>
>> static void work_for_cpu_fn(struct work_struct *work)
>> @@ -4738,6 +4739,7 @@ static void work_for_cpu_fn(struct work_struct *work)
>> struct work_for_cpu *wfc = container_of(work, struct work_for_cpu,
>> work);
>>
>> wfc->ret = wfc->fn(wfc->arg);
>> +complete(&wfc->done);
>> }
>>
>> /**
>> @@ -4755,8 +4757,9 @@ long work_on_cpu(int cpu, long (*fn)(void *), void
>> *arg)
>> struct work_for_cpu wfc = { .fn = fn, .arg = arg };
>>
>> INIT_WORK_ONSTACK(&wfc.work, work_for_cpu_fn);
>> +init_completion(&wfc.done);
>> schedule_work_on(cpu, &wfc.work);
>> -flush_work(&wfc.work);
>> +wait_for_completion(&wfc.done);
>
> Hmmm... it's kinda nasty. Given how infrequently work_on_cpu() users
> nest, I think it'd be cleaner to have work_on_cpu_nested() which takes
> @subclass. It requires extra work on the caller's part but I think
> that actually is useful as nested work_on_cpu()s are pretty weird
> things.
>
The problem is that the userS may not know their work_on_cpu() nested,
especially when work_on_cpu()s are on different subsystems and the call depth
is deep enough but the nested work_on_cpu() depends on some conditions.
I prefer to change the user instead of introducing work_on_cpu_nested(), and
I accept to change the user only instead of change work_on_cpu() since there is
only
one nested-calls case found.
But I'm thinking, since nested work_on_cpu() don't have any problem,
Why workqueue.c don't offer a more friendly API/behavior?
Thanks,
Lai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/8] x86/PCI: prevent re-allocation of already existing bridge and ROM resources
On Mon, Jul 22, 2013 at 6:08 PM, Bjorn Helgaas wrote:
> On Wed, Jul 3, 2013 at 8:04 AM, Mika Westerberg
> wrote:
>> In hotplug case (especially with Thunderbolt enabled systems) we might need
>> to call pcibios_resource_survey_bus() several times for a bus. The function
>> ends up calling pci_claim_resource() for each bridge resource that then
>> fails claiming that the resource exists already (which it does). Once this
>> happens the resource is invalidated thus preventing devices behind the
>> bridge to allocate their resources.
>>
>> To fix this we do what has been done in pcibios_allocate_dev_resources()
>> and check 'parent' of the given resource. If it is non-NULL it means that
>> the resource has been allocated already and we can skip it. We do the same
>> for ROM resources as well.
>>
>> Signed-off-by: Mika Westerberg
>
> This looks reasonable to me.
Acked-by: Bjorn Helgaas
> However, the use of "r->parent" to determine whether the resource is
> already allocated is nothing specific to x86. So I think we might be
> missing an opportunity to make this more consistent across
> architectures. I looked at other callers of pci_claim_resource() for
> bridge and ROM resources, and it looks like we might be able to make
> similar changes in:
>
> frv pcibios_allocate_bus_resources()
> ia64 pcibios_fixup_resources() (via pcibios_fixup_bridge_resources())
> mn10300 pcibios_allocate_bus_resources()
> mn10300 pcibios_assign_resources() (ROM)
> mn10300 pcibios_fixup_device_resources()
> parisc lba_fixup_bus()
>
> I really hate the idea of fixing something for x86 but not for other
> arches, so maybe somebody could take a deeper look at this and see if
> it would make sense to change the other arches, too.
>
> Bjorn
>
>> ---
>> arch/x86/pci/i386.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
>> index 94919e3..db6b1ab 100644
>> --- a/arch/x86/pci/i386.c
>> +++ b/arch/x86/pci/i386.c
>> @@ -210,6 +210,8 @@ static void pcibios_allocate_bridge_resources(struct
>> pci_dev *dev)
>> r = &dev->resource[idx];
>> if (!r->flags)
>> continue;
>> + if (r->parent) /* Already allocated */
>> + continue;
>> if (!r->start || pci_claim_resource(dev, idx) < 0) {
>> /*
>> * Something is wrong with the region.
>> @@ -318,6 +320,8 @@ static void pcibios_allocate_dev_rom_resource(struct
>> pci_dev *dev)
>> r = &dev->resource[PCI_ROM_RESOURCE];
>> if (!r->flags || !r->start)
>> return;
>> + if (r->parent) /* Already allocated */
>> + return;
>>
>> if (pci_claim_resource(dev, PCI_ROM_RESOURCE) < 0) {
>> r->end -= r->start;
>> --
>> 1.8.3.2
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc 0/4 3.11] Fix mei suspend/resume failure
On 07/22/2013 04:24 PM, Shuah Khan wrote: > On 07/22/2013 03:36 PM, Winkler, Tomas wrote: >>> >>> This series should fix the long standing reset storm issue in mei suspend/resume failure >> >> Can you guys confirm these fixes the issue for you. >> Thanks >> Tomas > > Yes. I am getting started with testing. Will let you know in a bit. > > -- Shuah > > Did several suspend to disk tests (reboot, platform, and suspend) and didn't see the mei reset problem. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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 3.11-rc2
On Tue, 2013-07-23 at 03:04 +0200, rydb...@euromail.se wrote:
> Hi Trond, Linus,
>
> On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote:
> > So it's been another week, and -rc2 is out there.
>
> This one happens to break nfs in a rather blunt-instrument fashion -
> creating files on a nfs4 partition [1] no longer works. Bisection
> yields this commit as the culprit:
>
> commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd
> Author: Trond Myklebust
> Date: Wed Jul 17 16:43:16 2013 -0400
>
> NFSv4: Fix a regression against the FreeBSD server
>
> Technically, the Linux client is allowed by the NFSv4 spec to send
> 3 word bitmaps as part of an OPEN request. However, this causes the
> current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors.
>
> Fix the regression by making the Linux client use a 2 word bitmap unless
> doing NFSv4.2 with labeled NFS.
>
> Signed-off-by: Trond Myklebust
>
> Reverting the patch returns things to normal.
- Can you please provide me with a binary tcpdump or wireshark dump that
demonstrates the problem?
- What server is this?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: mistakes in code vs. maintainer flow mistakes
On Tue, 2013-07-23 at 09:07 +0800, Li Zefan wrote: > > Perhaps what might help here is a kernel organizational chart. [] > the complete chart will in no doubt break 80 > characters limit. Actually as the hierarchy is quite flat, I can't > image how long the longest line will be. I think it really doesn't matter unless you want to generate that from the same information that is available via git, scripts/get_maintainer.pl and the MAINTAINERS file. -- 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] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote:
> On Thursday 18 July 2013 10:51 AM, Jingoo Han wrote:
> > Exynos PCIe IP consists of Synopsys specific part and Exynos
> > specific part. Only core block is a Synopsys designware part;
> > other parts are Exynos specific.
> > Also, the Synopsys designware part can be shared with other
> > platforms; thus, it can be split two parts such as Synopsys
> > designware part and Exynos specific part.
>
> some more queries and comments..
Hi Kishon,
Thank you for your comments. :)
Hi Pratyush Anand,
Please, answer one question mentioned below. :)
> >
> > Signed-off-by: Jingoo Han
> > Cc: Pratyush Anand
> > Cc: Mohit KUMAR
> > ---
> > Changes since v2:
> .
> .
>
> .
> .
> > +
> > +static struct pcie_host_ops exynos_pcie_host_ops = {
> > + .readl_rc = exynos_pcie_readl_rc,
> > + .writel_rc = exynos_pcie_writel_rc,
> > + .rd_own_conf = exynos_pcie_rd_own_conf,
> > + .wr_own_conf = exynos_pcie_wr_own_conf,
> > + .link_up = exynos_pcie_link_up,
> > + .host_init = exynos_pcie_host_init,
> > +};
> > +
> > +static int add_pcie_port(struct pcie_port *pp, struct platform_device
> > *pdev)
> > +{
> > + struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
>
> We can move the exynos_pcie specific initialization to probe and leave only
> pcie_port initialization here.
OK, I will move the exynos_pcie specific initialization to probe
as you mentioned.
> > + struct resource *elbi_base;
> > + struct resource *phy_base;
> > + struct resource *block_base;
> > + int ret;
> > +
> > + elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!elbi_base) {
> > + dev_err(&pdev->dev, "couldn't get elbi base resource\n");
> > + return -EINVAL;
> > + }
> > + exynos_pcie->elbi_base = devm_ioremap_resource(&pdev->dev, elbi_base);
> > + if (IS_ERR(exynos_pcie->elbi_base))
> > + return PTR_ERR(exynos_pcie->elbi_base);
> > +
> > + phy_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + if (!phy_base) {
> > + dev_err(&pdev->dev, "couldn't get phy base resource\n");
> > + return -EINVAL;
> > + }
> > + exynos_pcie->phy_base = devm_ioremap_resource(&pdev->dev, phy_base);
> > + if (IS_ERR(exynos_pcie->phy_base))
> > + return PTR_ERR(exynos_pcie->phy_base);
> > +
> > + block_base = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> > + if (!block_base) {
> > + dev_err(&pdev->dev, "couldn't get block base resource\n");
> > + return -EINVAL;
> > + }
> > + exynos_pcie->block_base = devm_ioremap_resource(&pdev->dev, block_base);
> > + if (IS_ERR(exynos_pcie->block_base))
> > + return PTR_ERR(exynos_pcie->block_base);
>
> So all this till here can be moved to probe.
As above mentioned, I will move it to probe.
> > +
> > + pp->irq = platform_get_irq(pdev, 1);
> > + if (!pp->irq) {
> > + dev_err(&pdev->dev, "failed to get irq\n");
> > + return -ENODEV;
> > + }
> > + ret = devm_request_irq(&pdev->dev, pp->irq, exynos_pcie_irq_handler,
> > + IRQF_SHARED, "exynos-pcie", pp);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to request irq\n");
> > + return ret;
> > + }
> > +
> > + pp->root_bus_nr = -1;
> > + pp->ops = &exynos_pcie_host_ops;
> > +
> > + spin_lock_init(&pp->conf_lock);
> > + ret = dw_pcie_host_init(pp);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to initialize host\n");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int __init exynos_pcie_probe(struct platform_device *pdev)
> > +{
> > + struct exynos_pcie *exynos_pcie;
> > + struct pcie_port *pp;
> > + struct device_node *np = pdev->dev.of_node;
> > + int ret;
> > +
> > + exynos_pcie = devm_kzalloc(&pdev->dev, sizeof(*exynos_pcie),
> > + GFP_KERNEL);
> > + if (!exynos_pcie) {
> > + dev_err(&pdev->dev, "no memory for exynos pcie\n");
> > + return -ENOMEM;
> > + }
> > +
> > + pp = &exynos_pcie->pp;
> > +
> > + pp->dev = &pdev->dev;
> > +
> > + exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> > +
> > + exynos_pcie->clk = devm_clk_get(&pdev->dev, "pcie");
> > + if (IS_ERR(exynos_pcie->clk)) {
> > + dev_err(&pdev->dev, "Failed to get pcie rc clock\n");
> > + return PTR_ERR(exynos_pcie->clk);
> > + }
> > + ret = clk_prepare_enable(exynos_pcie->clk);
> > + if (ret)
> > + return ret;
> > +
> > + exynos_pcie->bus_clk = devm_clk_get(&pdev->dev, "pcie_bus");
> > + if (IS_ERR(exynos_pcie->bus_clk)) {
> > + dev_err(&pdev->dev, "Failed to get pcie bus clock\n");
> > + ret = PTR_ERR(exynos_pcie->bus_clk);
> > + goto fail_clk;
> > + }
> > + ret = clk_prepare_enable(exynos_pcie->bus_clk);
> > + if (ret)
> > + goto fail_clk;
> > +
> > + ret = add_pcie_port(pp,
3.10.2: WARNING: at kernel/time/tick-broadcast.c:585
Hi, Resume from S3 generates WARNING: … ACPI: Low-level resume complete PM: Restoring platform NVS memory PCI-DMA: Resuming GART IOMMU PCI-DMA: Restoring GART aperture settings Enabling non-boot CPUs ... smpboot: Booting Node 0 Processor 1 APIC 0x1 [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #1 process: Switch to broadcast mode on CPU1 CPU1 is up smpboot: Booting Node 0 Processor 2 APIC 0x2 [ cut here ] 3.10.2: WARNING: at kernel/time/tick-broadcast.c:585 tick_broadcast_oneshot_control+0x170/0x180() Modules linked in: raid1 nouveau video mxm_wmi i2c_algo_bit drm_kms_helper ttm drm i2c_core wmi CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.2-301.fc19.x86_64 #1 Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010 0009 880129b2fd68 81642886 880129b2fda0 8105c211 0001 0004 88012fc4dbc0 0002 81c21c40 880129b2fdb0 8105c2ea Call Trace: [] dump_stack+0x19/0x1b [] warn_slowpath_common+0x61/0x80 [] warn_slowpath_null+0x1a/0x20 [] tick_broadcast_oneshot_control+0x170/0x180 [] tick_notify+0x2fd/0x440 [] notifier_call_chain+0x4c/0x70 [] raw_notifier_call_chain+0x16/0x20 [] clockevents_notify+0x39/0x140 [] amd_e400_idle+0x75/0x100 [] arch_cpu_idle+0x26/0x30 [] cpu_startup_entry+0xce/0x280 [] ? clockevents_register_device+0xb5/0x120 [] start_secondary+0x24e/0x250 ---[ end trace b32aec91b6f72d81 ]--- [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #2 process: Switch to broadcast mode on CPU2 CPU2 is up smpboot: Booting Node 0 Processor 3 APIC 0x3 [Firmware Bug]: cpu 3, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #3 process: Switch to broadcast mode on CPU3 CPU3 is up ACPI: Waking up from system sleep state S3 … With an additional four patches[1] WARNING persists. CONF. http://kojipkgs.fedoraproject.org//packages/kernel/3.10.2/301.fc19/data/logs/x86_64/build.log poma [1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/kernel/time/tick-broadcast.c - tick: Make oneshot broadcast robust vs. CPU offlining - tick: Prevent uncontrolled switch to oneshot mode - tick: Sanitize broadcast control logic - tick: broadcast: Check broadcast mode on CPU hotplug -- 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] f2fs: use list_for_each rather than list_for_each_safe, in remove_orphan_inode()
On 07/22/2013 11:36 PM, Nikola Pajkovsky wrote:
> Gu Zheng writes:
>
>> As we remove the target single node, so list_for_each is enought, in order to
>> clean up, we use list_for_each_entry instead.
>>
>> Signed-off-by: Gu Zheng
>> ---
>> fs/f2fs/checkpoint.c |5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index 290db04..87f7bc2 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -237,13 +237,12 @@ out:
>>
>> void remove_orphan_inode(struct f2fs_sb_info *sbi, nid_t ino)
>> {
>> -struct list_head *this, *next, *head;
>> +struct list_head *head;
>> struct orphan_inode_entry *orphan;
>>
>> mutex_lock(&sbi->orphan_inode_mutex);
>> head = &sbi->orphan_inode_list;
>> -list_for_each_safe(this, next, head) {
>> -orphan = list_entry(this, struct orphan_inode_entry, list);
>> +list_for_each_entry(orphan, head, list) {
>> if (orphan->ino == ino) {
>> list_del(&orphan->list);
>> kmem_cache_free(orphan_entry_slab, orphan);
>
> you have meant list_for_each_entry_safe, haven't you?
No that, here list_for_each_entry is suitable, because we delete only one entry.
Thanks,
Gu
>
--
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: mistakes in code vs. maintainer flow mistakes
> Perhaps what might help here is a kernel organizational chart. A graph > of who sends pull requests to Linus, and their subsystem maintainers. > For example, in the USB "branch" there would be: > > Linus Torvalds > (Linux kernel release engineer) > | > | > Greg Kroah-Hartman > (USB) > | > | > - > | | | | > | | | | > Sarah Sharp | | Oliver Neukum > (USB3 and USB core) | | (USB NCM and > auto-suspend) > | | > Alan Stern | > (EHCI/UHCI/OHCI and USB core) | > | > | > Felipe Balbi > (USB3 plat and USB gadget) > Nice chart, exccept that the complete chart will in no doubt break 80 characters limit. Actually as the hierarchy is quite flat, I can't image how long the longest line will be. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/10] mm, hugetlb: fix and clean-up node iteration code to alloc or free
Michal Hocko writes:
> On Mon 22-07-13 17:36:26, Joonsoo Kim wrote:
>> Current node iteration code have a minor problem which do one more
>> node rotation if we can't succeed to allocate. For example,
>> if we start to allocate at node 0, we stop to iterate at node 0.
>> Then we start to allocate at node 1 for next allocation.
>>
>> I introduce new macros "for_each_node_mask_to_[alloc|free]" and
>> fix and clean-up node iteration code to alloc or free.
>> This makes code more understandable.
>
> I don't know but it feels like you are trying to fix an awkward
> interface with another one. Why hstate_next_node_to_alloc cannot simply
> return MAX_NUMNODES once the loop is done and start from first_node next
> time it is called? We wouldn't have the bug you are mentioning and you
> do not need scary looking macros.
>
Even though the macros looks confusing, the changes do help rest of the
code. for ex: I liked how it made alloc simpler.
+ for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
+ page = alloc_fresh_huge_page_node(h, node);
-aneesh
--
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 3.11-rc2
Hi Trond, Linus, On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote: > So it's been another week, and -rc2 is out there. This one happens to break nfs in a rather blunt-instrument fashion - creating files on a nfs4 partition [1] no longer works. Bisection yields this commit as the culprit: commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd Author: Trond Myklebust Date: Wed Jul 17 16:43:16 2013 -0400 NFSv4: Fix a regression against the FreeBSD server Technically, the Linux client is allowed by the NFSv4 spec to send 3 word bitmaps as part of an OPEN request. However, this causes the current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors. Fix the regression by making the Linux client use a 2 word bitmap unless doing NFSv4.2 with labeled NFS. Signed-off-by: Trond Myklebust Reverting the patch returns things to normal. Thanks, Henrik [1] type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.10,local_lock=none,addr=192.168.0.142) -- 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/
