Re: [PATCH 11/24] cfq-iosched: add leaf_weight
Hello, Vivek. On Tue, Jan 08, 2013 at 10:34:48AM -0500, Vivek Goyal wrote: > How does it help to map leaf weight to weight in root group. Old programs > anyway don't know about leaf_weight. So nobody is going to update it. And > if they update it, they better know what does it do. Because what cfq does before this patchset in flat hierarchy is basically treating root weight as the leaf weight. R:500 / \ A:250 B:750 Ratio of R is computed as 500 / (500 + 250 + 750). The root blkcg's tasks are competinig with the children blkcgs. This is currently the only supported config and we don't want to break existing users, so keeping root's weight and leaf_weight synchronized and ignoring root's weight, which BTW can't mean anything anyway as it doesn't have a parent or siblings, keeps the behavior unchanged for flat configs. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()
On Tue, Jan 8, 2013 at 9:17 AM, Jeff Chua wrote:
>
> Interesting, but there are 54 lines under the kernel directories that
> use "dma_alloc_coherent(NULL," followed by "dma_free_coherent(NULL,"
As mentioned, it works on some platforms. That doesn't make it right.
> So, shouldn't they be fixed as well? ... unless they are so old that
> nobody cares anymore ...
Some of the ones I saw are in MIPS or blackfin. Others probably *are*
so old that nobody cares, and happen to work because there's iommu's
or other things that simply don't care about the device.
> # find . -exec grep -H "dma_alloc_coherent(NULL" {} \; | wc -l
> 54
>
> #find . -exec grep -H "dma_free_coherent(NULL" {} \; | wc -l
> 72
Let me tell you about "git grep", so that you never need to do that
disgusting "find -exec grep" ever again.
It does threading, it's fast, and it just works.
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 UPDATED 15/24] cfq-iosched: enable full blkcg hierarchy support
Hey, Vivek. On Tue, Jan 08, 2013 at 09:42:40AM -0500, Vivek Goyal wrote: > > +A has children and further distributes its 57% among the children and > > +the implicit leaf node. The total active weight at this level is > > +AA:500 + AB:1000 + A-leaf:750 = 2250. > > + > > + A-leaf: ( 750 / 2250) * A =~ 19% > > + AA(-leaf) : ( 500 / 2250) * A =~ 12% > > + AB(-leaf) : (1000 / 2250) * A =~ 25% > > Hi Tejun, > > What does (-leaf) is supposed to signify? I can understand that A-leaf > tells the share of A's tasks which are effectively in A-leaf group. It's saying that the weight for AA and AA-leaf are the same. > Will just plain AA and AB be more clear? I don't know, maybe. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Only reset e820 once, even with multiple memmap=exactmap params
On Tue, Jan 8, 2013 at 8:47 AM, Thomas Renninger wrote:
> On Tuesday, January 08, 2013 04:04:56 AM Yinghai Lu wrote:
>> On Mon, Jan 7, 2013 at 4:42 PM, Thomas Renninger wrote:
>> > memmap=256M$3584M
>>
>> may need to change to:
>>
>> memmap=256M\$\$3584M
> The problem is (beside the special char $) that
> memmap=exactmap boot param resets all e820 maps every time the
> parameter is processed.
> And:
> /sbin/kexec -p xy --append="..." --initrd yx
> seem to magically add (append):
> memmap=exactmap memmap=640K@0K memmap=392556K@115328K elfcorehdr=507884K
> memmap=252K#3099760K
>
> therefore all memmap= I try to pass are voided out by:
> memmap=exactmap
> which is always added by kexec after my params.
>
> I could come around with attached patch and passing:
> /sbin/kexec -p xy --append='... memmap=exactmap memmap=256M$3584M' --initrd yx
>
> Now mmconfig is working in kdump kernel.
> This would mean mmconfig is broken by design in kexec?
>
> Only way to fix this I can think of is to export
> mmconfig area through /sys (../kernel/debug/mmconfig?, possibly
> already in X$Y format?) in the productive kernel and make kexec add it
> like the other memmap= params automatically.
>
> I'll attach the output in a separate mail.
>
>Thomas
>
> ---
>
> x86 e820: Do not reset e820 map twice, even if memmap=exactmap is passed as
> boot param several times
>
> This is needed to be able to explicitly pass (debug) e820
> modifications through kexec via memmap=.
> Otherwise those get voided by kexec appending memmap=exactmap always
> after the user defined boot parameters.
>
> Signed-off-by: Thomas Renninger
>
> linux-2.6_t/arch/x86/kernel/e820.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Index: git/linux-2.6_t/arch/x86/kernel/e820.c
> ===
> --- git.orig/linux-2.6_t/arch/x86/kernel/e820.c
> +++ git/linux-2.6_t/arch/x86/kernel/e820.c
> @@ -845,7 +845,9 @@ static int __init parse_memmap_opt(char
>
> if (!strncmp(p, "exactmap", 8)) {
> #ifdef CONFIG_CRASH_DUMP
> - /*
> + /* memmap=exactmap passed twice, do not reset tables again */
> + if (saved_max_pfn)
> + return 0; /*
> * If we are doing a crash dump, we still need to know
> * the real mem size before original memory map is
> * reset.
that exactmap logic still have problem:
We need to check exactmap at first, aka need to scan the whole comand line to
see if exactmap is there at first and reset e820 tables then handle
other memmap opt.
Also please update your patch after
tip/x86/mm2
I have one patch that process memmap= with "," there.
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=9710f581bb4c35589ac046b0cfc0deb7f369fc85
We could put exactmap scanning in new parse_memmap_opt.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()
On Wed, Jan 9, 2013 at 12:39 AM, Linus Torvalds
wrote:
> On Tue, Jan 8, 2013 at 7:51 AM, Jeff Chua wrote:
>> No response so far ... I'm sure someone know this stuff ... Thanks, Jeff.
>>
>> I'm trying to understand how this oops in the diva driver and it's just a
>> simple dma_alloc_coherent() followed by dma_free_coherent(), but it oops.
>> Why?
>
> Umm. You're using a NULL 'dev' pointer?
>
> iommu_no_mapping() will look if the device is a PCI device, and that's
> where it oopses.
>
> Now, it looks like some users "know" that the device doesn't matter
> (which is true on some platforms), but that's bogus. The device is how
> you even find out what the rules for DMA access are (see for example
> dma_set_mask() etc), so giving a NULL device is insane.
>
> Linus
Interesting, but there are 54 lines under the kernel directories that
use "dma_alloc_coherent(NULL," followed by "dma_free_coherent(NULL,"
So, shouldn't they be fixed as well? ... unless they are so old that
nobody cares anymore ...
# find . -exec grep -H "dma_alloc_coherent(NULL" {} \; | wc -l
54
#find . -exec grep -H "dma_free_coherent(NULL" {} \; | wc -l
72
Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 8/9] zswap: add to mm/
On 01/07/2013 12:24 PM, Seth Jennings wrote:
> +struct zswap_tree {
> + struct rb_root rbroot;
> + struct list_head lru;
> + spinlock_t lock;
> + struct zs_pool *pool;
> +};
BTW, I spent some time trying to get this lock contended. You thought
the anon_vma locks would dominate and this spinlock would not end up
very contended.
I figured that if I hit zswap from a bunch of CPUs that _didn't_ use
anonymous memory (and thus the anon_vma locks) that some more contention
would pop up. I did that with a bunch of CPUs writing to tmpfs, and
this lock was still well down below anon_vma. The anon_vma contention
was obviously coming from _other_ anonymous memory around.
IOW, I feel a bit better about this lock. I only tested on 16 cores on
a system with relatively light NUMA characteristics, and it might be the
bottleneck if all the anonymous memory on the system is mlock()'d and
you're pounding on tmpfs, but that's pretty contrived.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v12 0/9] LSM: Multiple concurrent LSMs
On 1/8/2013 1:12 AM, James Morris wrote: > On Mon, 7 Jan 2013, Casey Schaufler wrote: > >> There has been an amazing amount of development in system security >> over the past three years. Almost none of it has been in the kernel. >> One important reason that it is not getting done in the kernel is >> that the current single LSM restriction requires an all or nothing >> approach to security. Either you address all your needs with a single >> LSM or you have to go with a user space solution, in which case you >> may as well do everything in user space. > This sounds like a very spurious argument. If the development is better > done in userspace, then do it there. When the security scheme is better implemented in user space because it requires information available in user space I agree. When the security scheme is implemented in user space because the environment for building it in the kernel is not up to modern development paradigms I disagree. If you can't work on two aspects of your security independently you're not going to keep up with the Jones'. > There's no way to address all your security needs with an LSM in any case, > for any practical system. Please review the arguments made in support of dropping the LSM entirely in favor of SELinux as *the* Linux security infrastructure. I certainly agree that no one LSM covers all need today. I also agree that no single LSM will ever meet everyone's needs. My solution is to allow multiple LSMs so that it is easier to approach the goal. > LSM is an API for making security decisions > about kernel flow, usually as part of implementing access control > mechanisms. It is not meant to provide any kind of total security > solution, and the argument that you can't do some security in userspace is > totally illogical. What I was hoping to say, and apparently didn't, is that people are developing "total" solutions in user space, when some of the work ought to be done in an LSM. Work that is appropriate to the kernel is being done in user space. Often badly, because the kernel provides too many mechanisms to circumvent user space based access controls. > Development should be done in userspace unless it must be done in the > kernel. And we'll be arguing what "must" means long after penguins get the vote. User space code does not have the opportunity to control the objects that the kernel manages. Nor should it. Files, sockets, network packets and signals all must be managed in the kernel. Some of the user space attempts we're seeing are pretty scary. >> Multiple concurrent LSMs allows a system to be developed incrementally >> and to combine a variety of approaches that meet new and interesting >> needs. It allows for systems that are based on an LSM that does not >> meet all of the requirements but that can be supplemented by another >> LSM that fills the gaps. It allows an LSM like Smack that implements >> label based access controls to remain true to its purpose even in the >> face of pressure to add controls based on other mechanisms. >> >> I have had requests for running Smack and AppArmor together Tetsuo has >> long had need to put SELinux and TOMOYO on the same box. Yama was >> recently special cased for stackability. > I'd say we need to see the actual use-case for Smack and Apparmor being > used together, along with at least one major distro committing to support > this. Or SELinux and TOMOYO. Or AppArmor and TOMOYO. And before we get too far, distros are no longer the driving force for Linux development. I suggest that "operating systems", including ChromiumOS, Android and Tizen are every bit as important. I suggest that if Android wants to use SELinux and AppArmor those wild and crazy folks in Mountain View ought to be able to do so. > Yama is special-cased and can stay that way. Yama is *not* a special case, it is an example. It is the kind of new thing that provides security that is not access control. It was special cased at the request of distros because there was no general mechanism for including it along with the primary LSM. > SELinux and Tomoyo together makes no sense to me, and similarly, I would > like to see the specific use-case for it and distro commitment to support > it. I'm not the advocate for that particular combination. The point is that there are advocates. And distros are not the only drivers. I agree that some consumer (distro, "OS") needs to step forward. >> We are looking at security from different directions than ever before. >> What good is a UID on a cell phone? I hear complaints about Android's >> "abuse" of the UID. > What is the UID issue and how does LSM stacking address it? Android utilizes UIDs in a way that has often been referred to as "hijacking". The UID mechanism supports much of what they want, but clearly isn't complete. Now that Android is moving to multi-user support they're hitting conflicts with their use of the UID attribute. They really ought to be using an LSM that implements
Re: PTRACE_SYSCALL && vsyscall (Was: arch_check_bp_in_kernelspace: fix the range check)
On 12/04/2012 05:59 PM, Oleg Nesterov wrote: > But If we want to allow to trace vsyscall's, hw bp doesn't look very > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all. Irrespective of the whole syscall tracing issue, allowing HW bkpts in the vsyscall just seems like a bug fix to me. > That is why I think PTRACE_SYSCALL should "simply work" somehow. And > so far I think that "just report syscall_exit with orig_ax = -1" is > the best (and simple) solution. If you report exit alone, you'll confuse current GDB into mistaking it for an enter, and all following enter/exits end up swapped/confused. GDB assumes trap/sysgood alternates between enter/exit, and always starts with enter. (Mildly related, GDB has an old comment in the code (linux-nat.c) that says: "However, most architectures can't handle a syscall being traced on the way out if it wasn't traced on the way in." I've no clue if that's still true nowadays.) > OK. We can do more. We can report both syscall_enter/exit and we can > change orig_ax/ax temporary to "fool" the tracer, so that everything > will look as a "normal" syscall. Like vsyscall_seccomp() does. > > But this needs much more changes. I'd just like to add, that if any new syscall related option is to be added, can we please just go all the way and add PTRACE_EVENT_SYSCALL_ENTER|PTRACE_EVENT_SYSCALL_EXIT instead? http://sourceware.org/gdb/wiki/LinuxKernelWishList -- Pedro Alves -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI: Make pci_find_upstream_pcie_bridge() handle non PCIE VFs well
On 01/08/2013 09:32 AM, tadeusz.st...@intel.com wrote:
pci_find_upstream_pcie_bridge() doesn't handle well non PCIE VFs
that are part of a PCIE PF device.
Signed-off-by: Tadeusz Struk
---
drivers/pci/search.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index bf969ba..8ecdab2 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -23,6 +23,8 @@ EXPORT_SYMBOL_GPL(pci_bus_sem);
* if the device isn't connected to a PCIe bridge (that is its parent is a
* legacy PCI bridge and the bridge is directly connected to bus 0), return
its
* parent
+ * if the device is a VF that doesn't have PCIe cap,
+ * but the PF is a PCIE, return NULL
*/
struct pci_dev *
pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
@@ -31,6 +33,10 @@ pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
if (pci_is_pcie(pdev))
return NULL;
+
+ if (pdev->is_virtfn&& pci_is_pcie(pdev->physfn))
+ return NULL;
+
while (1) {
if (pci_is_root_bus(pdev->bus))
break;
The verbage/description is confusing, and
the comment doesn't match the code:
(a) no such thing as a non-PCIe VF -- all VFs
are PCIe-based.
(b) code says to return null if VF doesn't have PCIe cap,
but the code checks if pdev is VF and if PF is PCIe,
which it must be! ...
nack until a better &/or matching explanation of what
the real problem is, and what the solution is trying to do.
- Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 18/24] blkcg: s/blkg_rwstat_sum()/blkg_rwstat_total()/
On Fri, Dec 28, 2012 at 12:35:40PM -0800, Tejun Heo wrote:
> Rename blkg_rwstat_sum() to blkg_rwstat_total(). sum will be used for
> summing up stats from multiple blkgs.
>
> Signed-off-by: Tejun Heo
Acked-by: Vivek Goyal
Vivek
> ---
> block/blk-cgroup.h | 4 ++--
> block/cfq-iosched.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/block/blk-cgroup.h b/block/blk-cgroup.h
> index 678e89e..586c0ac 100644
> --- a/block/blk-cgroup.h
> +++ b/block/blk-cgroup.h
> @@ -461,14 +461,14 @@ static inline struct blkg_rwstat
> blkg_rwstat_read(struct blkg_rwstat *rwstat)
> }
>
> /**
> - * blkg_rwstat_sum - read the total count of a blkg_rwstat
> + * blkg_rwstat_total - read the total count of a blkg_rwstat
> * @rwstat: blkg_rwstat to read
> *
> * Return the total count of @rwstat regardless of the IO direction. This
> * function can be called without synchronization and takes care of u64
> * atomicity.
> */
> -static inline uint64_t blkg_rwstat_sum(struct blkg_rwstat *rwstat)
> +static inline uint64_t blkg_rwstat_total(struct blkg_rwstat *rwstat)
> {
> struct blkg_rwstat tmp = blkg_rwstat_read(rwstat);
>
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index e8f3106..d43145cc 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -536,7 +536,7 @@ static void cfqg_stats_set_start_empty_time(struct
> cfq_group *cfqg)
> {
> struct cfqg_stats *stats = >stats;
>
> - if (blkg_rwstat_sum(>queued))
> + if (blkg_rwstat_total(>queued))
> return;
>
> /*
> @@ -580,7 +580,7 @@ static void cfqg_stats_update_avg_queue_size(struct
> cfq_group *cfqg)
> struct cfqg_stats *stats = >stats;
>
> blkg_stat_add(>avg_queue_size_sum,
> - blkg_rwstat_sum(>queued));
> + blkg_rwstat_total(>queued));
> blkg_stat_add(>avg_queue_size_samples, 1);
> cfqg_stats_update_group_wait_time(stats);
> }
> --
> 1.8.0.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 17/24] blkcg: implement blkcg_policy->on/offline_pd_fn() and blkcg_gq->online
On Fri, Dec 28, 2012 at 12:35:39PM -0800, Tejun Heo wrote: > Add two blkcg_policy methods, ->online_pd_fn() and ->offline_pd_fn(), > which are invoked as the policy_data gets activated and deactivated > while holding both blkcg and q locks. > > Also, add blkcg_gq->online bool, which is set and cleared as the > blkcg_gq gets activated and deactivated. This flag also is toggled > while holding both blkcg and q locks. > > These will be used to implement hierarchical stats. > > Signed-off-by: Tejun Heo > --- Acked-by: Vivek Goyal Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/6] PCI/acpiphp: update ACPI hotplug slot information when PCI hotplug happens
Currently the acpiphp driver fails to update hotplug slot information under
several conditions, such as:
1) The bridge device is removed through /sys/bus/pci/devices/.../remove
2) The bridge device is added/removed by PCI hotplug driver other than the
acpiphp driver itself. For example, if an IO expansion box with ACPI
hotplug slots available is hot-added by the pciehp driver, all ACPI
hotplug slots won't be discovered by the acpiphp driver.
So hook the BUS_NOTIFY_ADD_DEVICE/BUS_NOTIFY_DEL_DEVICE events to
update ACPI hotplug slot information when PCI hotplug event happens.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/pci/hotplug/acpiphp_glue.c | 62 ++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index 3d6d4fd..16fe692 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -61,6 +61,7 @@ static void handle_hotplug_event_bridge (acpi_handle, u32,
void *);
static void acpiphp_sanitize_bus(struct pci_bus *bus);
static void acpiphp_set_hpp_values(struct pci_bus *bus);
static void handle_hotplug_event_func(acpi_handle handle, u32 type, void
*context);
+static struct acpiphp_bridge *acpiphp_handle_to_bridge(acpi_handle handle);
/* callback routine to check for the existence of a pci dock device */
static acpi_status
@@ -420,12 +421,14 @@ static void add_host_bridge(struct acpi_pci_root *root)
init_bridge_misc(bridge);
}
-
/* allocate and initialize PCI-to-PCI bridge data structure */
-static void add_p2p_bridge(acpi_handle *handle)
+static void add_p2p_bridge(acpi_handle handle)
{
struct acpiphp_bridge *bridge;
+ if (acpiphp_handle_to_bridge(handle))
+ return;
+
bridge = kzalloc(sizeof(struct acpiphp_bridge), GFP_KERNEL);
if (bridge == NULL) {
err("out of memory\n");
@@ -1428,6 +1431,58 @@ find_root_bridges(acpi_handle handle, u32 lvl, void
*context, void **rv)
return AE_OK ;
}
+static void acpiphp_hp_notify_add(struct pci_dev *dev)
+{
+ acpi_handle handle = DEVICE_ACPI_HANDLE(>dev);
+
+ if (!dev->subordinate || !handle)
+ return;
+
+ /* check if this bridge has ejectable slots */
+ if (detect_ejectable_slots(handle) > 0) {
+ dbg("found PCI-to-PCI bridge at PCI %s\n", pci_name(dev));
+ add_p2p_bridge(handle);
+ }
+}
+
+static void acpiphp_hp_notify_del(struct pci_dev *dev)
+{
+ struct acpiphp_bridge *bridge, *tmp;
+ struct pci_bus *bus = dev->subordinate;
+
+ if (!bus)
+ return;
+
+ list_for_each_entry_safe(bridge, tmp, _list, list)
+ if (bridge->pci_bus == bus) {
+ cleanup_bridge(bridge);
+ break;
+ }
+}
+
+static int acpi_pci_hp_notify_fn(struct notifier_block *nb,
+unsigned long event, void *data)
+{
+ struct device *dev = data;
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ acpiphp_hp_notify_add(to_pci_dev(dev));
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ acpiphp_hp_notify_del(to_pci_dev(dev));
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block acpi_pci_hp_notifier = {
+ .notifier_call = _pci_hp_notify_fn,
+};
+
static struct acpi_pci_driver acpi_pci_hp_driver = {
.add = add_bridge,
.remove = remove_bridge,
@@ -1448,6 +1503,8 @@ int __init acpiphp_glue_init(void)
else
acpi_pci_register_driver(_pci_hp_driver);
+ bus_register_notifier(_bus_type, _pci_hp_notifier);
+
return 0;
}
@@ -1459,6 +1516,7 @@ int __init acpiphp_glue_init(void)
*/
void acpiphp_glue_exit(void)
{
+ bus_unregister_notifier(_bus_type, _pci_hp_notifier);
acpi_pci_unregister_driver(_pci_hp_driver);
}
--
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 v3 2/6] PCI: split registration of PCI bus devices into two stages
When handling BUS_NOTIFY_ADD_DEVICE event for a PCI bridge device,
the notification handler can't hold reference count to the new PCI bus
because the device object for the new bus (pci_dev->subordinate->dev)
hasn't been initialized yet.
Split the registration of PCI bus device into two stages as below,
so that the event handler could hold reference count to the new PCI bus
when handling BUS_NOTIFY_ADD_DEVICE event.
1) device_initialize(_dev->dev)
2) device_initialize(_dev->subordinate->dev)
3) notify BUS_NOTIFY_ADD_DEVICE event for pci_dev
4) device_add(_dev->dev)
5) device_add(_dev->subordinate->dev)
Signed-off-by: Jiang Liu
Signed-off-by: Yinghai Lu
---
drivers/pci/bus.c|2 +-
drivers/pci/probe.c |4 +++-
drivers/pci/remove.c | 10 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index ad6a8b6..2fea481 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -198,7 +198,7 @@ int pci_bus_add_child(struct pci_bus *bus)
if (bus->bridge)
bus->dev.parent = bus->bridge;
- retval = device_register(>dev);
+ retval = device_add(>dev);
if (retval)
return retval;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e557d6f..a8315c2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -642,6 +642,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus
*parent,
*/
child->dev.class = _class;
dev_set_name(>dev, "%04x:%02x", pci_domain_nr(child), busnr);
+ device_initialize(>dev);
/*
* Set up the primary, secondary and subordinate
@@ -1678,7 +1679,8 @@ struct pci_bus *pci_create_root_bus(struct device
*parent, int bus,
b->dev.class = _class;
b->dev.parent = b->bridge;
dev_set_name(>dev, "%04x:%02x", pci_domain_nr(b), bus);
- error = device_register(>dev);
+ device_initialize(>dev);
+ error = device_add(>dev);
if (error)
goto class_dev_reg_err;
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index fc38c48..a1fdd0f 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -48,11 +48,11 @@ void pci_remove_bus(struct pci_bus *bus)
list_del(>node);
pci_bus_release_busn_res(bus);
up_write(_bus_sem);
- if (!bus->is_added)
- return;
-
- pci_remove_legacy_files(bus);
- device_unregister(>dev);
+ if (bus->is_added) {
+ pci_remove_legacy_files(bus);
+ device_del(>dev);
+ }
+ put_device(>dev);
}
EXPORT_SYMBOL(pci_remove_bus);
--
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 v3 0/6] Update PCI notification patchset to latest kernel version
Hi Bjorn, Rafael has developed a patchset targetting 3.9 merging window which outdates the fourth and fifth patches in my previous version, so I have just drop those two patches and updated the others to the latest code from your pci-next branch. Thanks! Jiang Liu (5): PCI: make PCI device create/destroy logic symmetric PCI: split registration of PCI bus devices into two stages ACPI/pci_slot: update PCI slot information when PCI hotplug event happens PCI/acpiphp: update ACPI hotplug slot information when PCI hotplug happens PCI/acpiphp: serialize access to the bridge_list list Yijing Wang (1): PCI/AER: update AER configuration when PCI hotplug event happens drivers/acpi/pci_slot.c| 86 drivers/pci/bus.c |2 +- drivers/pci/hotplug/acpiphp_glue.c | 73 +- drivers/pci/pcie/aer/aerdrv.c | 63 +- drivers/pci/probe.c|5 ++- drivers/pci/remove.c | 14 +++--- 6 files changed, 222 insertions(+), 21 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 v3 1/6] PCI: make PCI device create/destroy logic symmetric
According to device model documentation, the way to create/destroy PCI
devices should be symmetric.
/**
* device_del - delete device from system.
* @dev: device.
*
* This is the first part of the device unregistration
* sequence. This removes the device from the lists we control
* from here, has it removed from the other driver model
* subsystems it was added to in device_add(), and removes it
* from the kobject hierarchy.
*
* NOTE: this should be called manually _iff_ device_add() was
* also called manually.
*/
The rule is to either use
1) device_register()/device_unregister()
or
2) device_initialize()/device_add()/device_del()/put_device().
So change PCI core logic to follow the rule and get rid of the redundant
pci_dev_get()/pci_dev_put() pair.
Signed-off-by: Jiang Liu
Acked-by: Bjorn Helgaas
Reviewed-by: Yinghai Lu
---
drivers/pci/probe.c |1 -
drivers/pci/remove.c |4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6186f03..e557d6f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1299,7 +1299,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
*bus)
{
device_initialize(>dev);
dev->dev.release = pci_release_dev;
- pci_dev_get(dev);
dev->dev.dma_mask = >dma_mask;
dev->dev.dma_parms = >dma_parms;
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 7c0fd92..fc38c48 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -22,7 +22,7 @@ static void pci_stop_dev(struct pci_dev *dev)
if (dev->is_added) {
pci_proc_detach_device(dev);
pci_remove_sysfs_dev_files(dev);
- device_unregister(>dev);
+ device_del(>dev);
dev->is_added = 0;
}
@@ -37,7 +37,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
up_write(_bus_sem);
pci_free_resources(dev);
- pci_dev_put(dev);
+ put_device(>dev);
}
void pci_remove_bus(struct pci_bus *bus)
--
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 v3 6/6] PCI/AER: update AER configuration when PCI hotplug event happens
From: Yijing Wang
The AER driver only configures downstream PCIe devices at driver
binding time and all hot-added PCIe devices won't be managed by
the AER driver. So hook PCIe device hotplug events to setup AER
configuration for hot-added PCIe devices.
Signed-off-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/pci/pcie/aer/aerdrv.c | 63 -
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/aer/aerdrv.c b/drivers/pci/pcie/aer/aerdrv.c
index 76ef634..d825c46 100644
--- a/drivers/pci/pcie/aer/aerdrv.c
+++ b/drivers/pci/pcie/aer/aerdrv.c
@@ -408,6 +408,55 @@ static void aer_error_resume(struct pci_dev *dev)
pci_write_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, status);
}
+static void acpi_pcie_aer_notify_dev(struct pcie_device *dev, bool enable)
+{
+ int rc, pos;
+ u32 val = 0;
+ struct pci_dev *pdev = dev->port;
+
+ if (dev->service != PCIE_PORT_SERVICE_AER)
+ return;
+ if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
+ return;
+ while (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT) {
+ pdev = pdev->bus->self;
+ if (!pdev)
+ return;
+ }
+
+ pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR);
+ if (!pos)
+ return;
+ rc = pci_read_config_dword(pdev, pos + PCI_ERR_ROOT_COMMAND, );
+ if (rc || val == 0x || !(val & ROOT_PORT_INTR_ON_MESG_MASK))
+ return;
+
+ set_device_error_reporting(dev->port, );
+}
+
+static int acpi_pcie_aer_notify(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct device *dev = data;
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ acpi_pcie_aer_notify_dev(to_pcie_device(dev), true);
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ acpi_pcie_aer_notify_dev(to_pcie_device(dev), false);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block acpi_pcie_aer_notifier = {
+ .notifier_call = _pcie_aer_notify,
+};
+
/**
* aer_service_init - register AER root service driver
*
@@ -415,9 +464,20 @@ static void aer_error_resume(struct pci_dev *dev)
*/
static int __init aer_service_init(void)
{
+ int ret;
+
if (!pci_aer_available() || aer_acpi_firmware_first())
return -ENXIO;
- return pcie_port_service_register();
+
+ ret = pcie_port_service_register();
+ if (!ret) {
+ ret = bus_register_notifier(_port_bus_type,
+ _pcie_aer_notifier);
+ if (ret)
+ pcie_port_service_unregister();
+ }
+
+ return ret;
}
/**
@@ -427,6 +487,7 @@ static int __init aer_service_init(void)
*/
static void __exit aer_service_exit(void)
{
+ bus_unregister_notifier(_port_bus_type, _pcie_aer_notifier);
pcie_port_service_unregister();
}
--
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 v3 5/6] PCI/acpiphp: serialize access to the bridge_list list
Serialize access to the bridge_list in the acpiphp driver.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/pci/hotplug/acpiphp_glue.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index 16fe692..884cbf4 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -53,6 +53,7 @@
#include "../pci.h"
#include "acpiphp.h"
+static DEFINE_MUTEX(bridge_mutex);
static LIST_HEAD(bridge_list);
#define MY_NAME "acpiphp_glue"
@@ -519,8 +520,10 @@ static int add_bridge(struct acpi_pci_root *root)
}
/* search P2P bridges under this host bridge */
+ mutex_lock(_mutex);
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
find_p2p_bridge, NULL, NULL, NULL);
+ mutex_unlock(_mutex);
if (ACPI_FAILURE(status))
warn("find_p2p_bridge failed (error code = 0x%x)\n", status);
@@ -618,6 +621,8 @@ static void remove_bridge(struct acpi_pci_root *root)
struct acpiphp_bridge *bridge;
acpi_handle handle = root->device->handle;
+ mutex_lock(_mutex);
+
/* cleanup p2p bridges under this host bridge
in a depth-first manner */
acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
@@ -636,6 +641,8 @@ static void remove_bridge(struct acpi_pci_root *root)
else
acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
handle_hotplug_event_bridge);
+
+ mutex_unlock(_mutex);
}
static int power_on_slot(struct acpiphp_slot *slot)
@@ -1438,11 +1445,13 @@ static void acpiphp_hp_notify_add(struct pci_dev *dev)
if (!dev->subordinate || !handle)
return;
+ mutex_lock(_mutex);
/* check if this bridge has ejectable slots */
if (detect_ejectable_slots(handle) > 0) {
dbg("found PCI-to-PCI bridge at PCI %s\n", pci_name(dev));
add_p2p_bridge(handle);
}
+ mutex_unlock(_mutex);
}
static void acpiphp_hp_notify_del(struct pci_dev *dev)
@@ -1453,11 +1462,13 @@ static void acpiphp_hp_notify_del(struct pci_dev *dev)
if (!bus)
return;
+ mutex_lock(_mutex);
list_for_each_entry_safe(bridge, tmp, _list, list)
if (bridge->pci_bus == bus) {
cleanup_bridge(bridge);
break;
}
+ mutex_unlock(_mutex);
}
static int acpi_pci_hp_notify_fn(struct notifier_block *nb,
--
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: oops in copy_page_rep()
On Tue, Jan 8, 2013 at 8:31 AM, Kirill A. Shutemov wrote:
>>
>> Heh. I was more thinking about why do_huge_pmd_wp_page() needs it, but
>> do_huge_pmd_numa_page() does not.
>
> It does. The check should be moved up.
>
>> Also, do we actually need it for huge_pmd_set_accessed()? The
>> *placement* of that thing confuses me. And because it confuses me, I'd
>> like to understand it.
>
> We need it for huge_pmd_set_accessed() too.
>
> Looks like a mis-merge. The original patch for huge_pmd_set_accessed() was
> correct: http://lkml.org/lkml/2012/10/25/402
Not a merge error: the pmd_trans_splitting() check was removed by
commit d10e63f29488 ("mm: numa: Create basic numa page hinting
infrastructure").
Now, *why* it was removed, I can't tell. And it's not clear why the
original code just had it in a conditional, while the suggested patch
has that "goto repeat" thing. I suspect re-trying the fault (which I
assume the original code did) is actually better, because that way you
go through all the "should I reschedule as I return through the
exception" stuff. I dunno.
Mel, that original patch came from you , although it was based on
previous work by Peter/Ingo/Andrea. Can you walk us through the
history and thinking about the loss of pmd_trans_splitting(). Was it
purely a mistake? It looks intentional.
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/
[PATCH v3 3/6] ACPI/pci_slot: update PCI slot information when PCI hotplug event happens
Currently the pci_slot driver doesn't update PCI slot information
when PCI device hotplug event happens, which may cause memory leak
and returning stale information to user.
So hook the BUS_NOTIFY_ADD_DEVICE/BUS_NOTIFY_DEL_DEVICE events to
update PCI slot information when PCI hotplug event happens.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
---
drivers/acpi/pci_slot.c | 86 ++-
1 file changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/pci_slot.c b/drivers/acpi/pci_slot.c
index d22585f..e04ea8e 100644
--- a/drivers/acpi/pci_slot.c
+++ b/drivers/acpi/pci_slot.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
static bool debug;
@@ -123,12 +124,7 @@ struct callback_args {
/*
* register_slot
*
- * Called once for each SxFy object in the namespace. Don't worry about
- * calling pci_create_slot multiple times for the same pci_bus:device,
- * since each subsequent call simply bumps the refcount on the pci_slot.
- *
- * The number of calls to pci_destroy_slot from unregister_slot is
- * symmetrical.
+ * Called once for each SxFy object in the namespace.
*/
static acpi_status
register_slot(acpi_handle handle, u32 lvl, void *context, void **rv)
@@ -145,6 +141,15 @@ register_slot(acpi_handle handle, u32 lvl, void *context,
void **rv)
if (device < 0)
return AE_OK;
+ /* Avoid duplicated records for the same slot */
+ list_for_each_entry(slot, _list, list) {
+ pci_slot = slot->pci_slot;
+ if (pci_slot && pci_slot->bus == pci_bus &&
+ pci_slot->number == device) {
+ return AE_OK;
+ }
+ }
+
slot = kmalloc(sizeof(*slot), GFP_KERNEL);
if (!slot) {
err("%s: cannot allocate memory\n", __func__);
@@ -162,9 +167,7 @@ register_slot(acpi_handle handle, u32 lvl, void *context,
void **rv)
slot->root_handle = parent_context->root_handle;
slot->pci_slot = pci_slot;
INIT_LIST_HEAD(>list);
- mutex_lock(_list_lock);
list_add(>list, _list);
- mutex_unlock(_list_lock);
get_device(_bus->dev);
@@ -274,7 +277,9 @@ acpi_pci_slot_add(struct acpi_pci_root *root)
{
acpi_status status;
+ mutex_lock(_list_lock);
status = walk_root_bridge(root, register_slot);
+ mutex_unlock(_list_lock);
if (ACPI_FAILURE(status))
err("%s: register_slot failure - %d\n", __func__, status);
@@ -330,17 +335,82 @@ static struct dmi_system_id acpi_pci_slot_dmi_table[]
__initdata = {
{}
};
+static void acpi_pci_slot_notify_add(struct pci_dev *dev)
+{
+ acpi_handle handle;
+ struct callback_args context;
+
+ if (!dev->subordinate)
+ return;
+
+ mutex_lock(_list_lock);
+ handle = DEVICE_ACPI_HANDLE(>dev);
+ context.root_handle = acpi_find_root_bridge_handle(dev);
+ if (handle && context.root_handle) {
+ context.pci_bus = dev->subordinate;
+ context.user_function = register_slot;
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
+ register_slot, NULL, , NULL);
+ }
+ mutex_unlock(_list_lock);
+}
+
+static void acpi_pci_slot_notify_del(struct pci_dev *dev)
+{
+ struct acpi_pci_slot *slot, *tmp;
+ struct pci_bus *bus = dev->subordinate;
+
+ if (!bus)
+ return;
+
+ mutex_lock(_list_lock);
+ list_for_each_entry_safe(slot, tmp, _list, list)
+ if (slot->pci_slot && slot->pci_slot->bus == bus) {
+ list_del(>list);
+ pci_destroy_slot(slot->pci_slot);
+ put_device(>dev);
+ kfree(slot);
+ }
+ mutex_unlock(_list_lock);
+}
+
+static int acpi_pci_slot_notify_fn(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct device *dev = data;
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ acpi_pci_slot_notify_add(to_pci_dev(dev));
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
+ acpi_pci_slot_notify_del(to_pci_dev(dev));
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block acpi_pci_slot_notifier = {
+ .notifier_call = _pci_slot_notify_fn,
+};
+
static int __init
acpi_pci_slot_init(void)
{
dmi_check_system(acpi_pci_slot_dmi_table);
acpi_pci_register_driver(_pci_slot_driver);
+ bus_register_notifier(_bus_type, _pci_slot_notifier);
+
return 0;
}
static void __exit
acpi_pci_slot_exit(void)
{
+ bus_unregister_notifier(_bus_type, _pci_slot_notifier);
acpi_pci_unregister_driver(_pci_slot_driver);
}
--
1.7.9.5
--
To unsubscribe
Re: [PATCH 16/24] blkcg: add blkg_policy_data->plid
On Fri, Dec 28, 2012 at 12:35:38PM -0800, Tejun Heo wrote:
> Add pd->plid so that the policy a pd belongs to can be identified
> easily. This will be used to implement hierarchical blkg_[rw]stats.
>
> Signed-off-by: Tejun Heo
Acked-by: Vivek Goyal
Vivek
> ---
> block/blk-cgroup.c | 2 ++
> block/blk-cgroup.h | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index 10e1df9..3a8de32 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -113,6 +113,7 @@ static struct blkcg_gq *blkg_alloc(struct blkcg *blkcg,
> struct request_queue *q,
>
> blkg->pd[i] = pd;
> pd->blkg = blkg;
> + pd->plid = i;
>
> /* invoke per-policy init */
> if (pol->pd_init_fn)
> @@ -908,6 +909,7 @@ int blkcg_activate_policy(struct request_queue *q,
>
> blkg->pd[pol->plid] = pd;
> pd->blkg = blkg;
> + pd->plid = pol->plid;
> pol->pd_init_fn(blkg);
>
> spin_unlock(>blkcg->lock);
> diff --git a/block/blk-cgroup.h b/block/blk-cgroup.h
> index 2446225..40f5b97 100644
> --- a/block/blk-cgroup.h
> +++ b/block/blk-cgroup.h
> @@ -81,8 +81,9 @@ struct blkg_rwstat {
> * beginning and pd_size can't be smaller than pd.
> */
> struct blkg_policy_data {
> - /* the blkg this per-policy data belongs to */
> + /* the blkg and policy id this per-policy data belongs to */
> struct blkcg_gq *blkg;
> + int plid;
>
> /* used during policy activation */
> struct list_headalloc_node;
> --
> 1.8.0.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 29/32] block, aio: Batch completion for bios/kiocbs
On Tue, Jan 08, 2013 at 11:15:37AM -0500, Jeff Moyer wrote: > Kent Overstreet writes: > > > On Tue, Jan 08, 2013 at 10:33:18AM -0500, Jeff Moyer wrote: > >> Kent Overstreet writes: > >> > >> >> Is the rbtree really faster than a basic (l)list and a sort before > >> >> completing them? Would be simpler. > >> > > >> > Well, depends. With one or two kioctxs? The list would definitely be > >> > faster, but I'm loathe to use an O(n^2) algorithm anywhere where the > >> > input size isn't strictly controlled, and I know of applications out > >> > there that use tons of kioctxs. > >> > >> Out of curiosity, what applications do you know of that use tons of > >> kioctx's? > > > > "tons" is relative I suppose, but before this patch series sharing a > > kioctx between threads was really bad for performance and... you know > > how people can be with threads. > > I wasn't questioning the merits of the patch, I was simply curious to > know how aio is being (ab)used in the wild. So, is this some internal > tool, then, or what? Oh, didn't think you were, I just never looked for actual numbers. Yeah, some internal library code is what I was referring to, but from the story of how it evolved I don't think it's unusual. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Only reset e820 once, even with multiple memmap=exactmap params
On Tuesday, January 08, 2013 04:04:56 AM Yinghai Lu wrote:
> On Mon, Jan 7, 2013 at 4:42 PM, Thomas Renninger wrote:
> > memmap=256M$3584M
>
> may need to change to:
>
> memmap=256M\$\$3584M
The problem is (beside the special char $) that
memmap=exactmap boot param resets all e820 maps every time the
parameter is processed.
And:
/sbin/kexec -p xy --append="..." --initrd yx
seem to magically add (append):
memmap=exactmap memmap=640K@0K memmap=392556K@115328K elfcorehdr=507884K
memmap=252K#3099760K
therefore all memmap= I try to pass are voided out by:
memmap=exactmap
which is always added by kexec after my params.
I could come around with attached patch and passing:
/sbin/kexec -p xy --append='... memmap=exactmap memmap=256M$3584M' --initrd yx
Now mmconfig is working in kdump kernel.
This would mean mmconfig is broken by design in kexec?
Only way to fix this I can think of is to export
mmconfig area through /sys (../kernel/debug/mmconfig?, possibly
already in X$Y format?) in the productive kernel and make kexec add it
like the other memmap= params automatically.
I'll attach the output in a separate mail.
Thomas
---
x86 e820: Do not reset e820 map twice, even if memmap=exactmap is passed as
boot param several times
This is needed to be able to explicitly pass (debug) e820
modifications through kexec via memmap=.
Otherwise those get voided by kexec appending memmap=exactmap always
after the user defined boot parameters.
Signed-off-by: Thomas Renninger
linux-2.6_t/arch/x86/kernel/e820.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: git/linux-2.6_t/arch/x86/kernel/e820.c
===
--- git.orig/linux-2.6_t/arch/x86/kernel/e820.c
+++ git/linux-2.6_t/arch/x86/kernel/e820.c
@@ -845,7 +845,9 @@ static int __init parse_memmap_opt(char
if (!strncmp(p, "exactmap", 8)) {
#ifdef CONFIG_CRASH_DUMP
- /*
+ /* memmap=exactmap passed twice, do not reset tables again */
+ if (saved_max_pfn)
+ return 0; /*
* If we are doing a crash dump, we still need to know
* the real mem size before original memory map is
* reset.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next: build failure after merge of the staging tree
On Monday, January 07, 2013 9:30 PM, Stephen Rothwell wrote:
> On Mon, 7 Jan 2013 20:27:30 -0800 Greg KH wrote:
>> On Tue, Jan 08, 2013 at 01:23:52PM +1100, Stephen Rothwell wrote:
>>> After merging the staging tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> drivers/staging/comedi/comedi_fops.c: In function 'comedi_unlocked_ioctl':
>>> drivers/staging/comedi/comedi_fops.c:1665:4: error: 'dev_file_info'
>>> undeclared (first use in this function)
>>>
>>> Caused by commit 4da5fa9a439f ("staging: comedi: use comedi_dev_from_minor
>>> ()") interacting with commit 7d3135af399e ("staging: comedi: prevent
>>> auto-unconfig of manually configured devices") from the staging.current
>>> tree.
>>>
>>> I just reverted the latter commit in the hope that the bug is fixed in
>>> some other way in the staging tree.
>>
>> Yes, I had to do some manual fixup when merging the branches together to
>> get it to work properly, which is what I did in my staging-next tree.
>> As the fixup was done in the merge commit, maybe you didn't get it when
>> you did the pull?
>
> Presumably not (my top of staging-next is d7f9729f6e06) - it was changing
> pretty rapidly this morning as I was fetching trees ...
>
> At least it will be OK tomorrow.
Greg's staging tree on git.kernel.org looks correct.
If there is anything I need to do to help resolve this please let me know.
Thanks,
Hartley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/24] cfq-iosched: convert cfq_group_slice() to use cfqg->vfraction
On Fri, Dec 28, 2012 at 12:35:36PM -0800, Tejun Heo wrote: > cfq_group_slice() calculates slice by taking a fraction of > cfq_target_latency according to the ratio of cfqg->weight against > service_tree->total_weight. This currently works only because all > cfqgs are treated to be at the same level. > > To prepare for proper hierarchy support, convert cfq_group_slice() to > base the calculation on cfqg->vfraction. As cfqg->vfraction is always > a fraction of 1 and represents the fraction allocated to the cfqg with > hierarchy considered, the slice can be simply calculated by > multiplying cfqg->vfraction to cfq_target_latency (with fixed point > shift factored in). > > As vfraction calculation currently treats all non-root cfqgs as > children of the root cfqg, this patch doesn't introduce noticeable > behavior difference. > > Signed-off-by: Tejun Heo Acked-by: Vivek Goyal Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()
On Tue, Jan 8, 2013 at 7:51 AM, Jeff Chua wrote: > No response so far ... I'm sure someone know this stuff ... Thanks, Jeff. > > I'm trying to understand how this oops in the diva driver and it's just a > simple dma_alloc_coherent() followed by dma_free_coherent(), but it oops. > Why? Umm. You're using a NULL 'dev' pointer? iommu_no_mapping() will look if the device is a PCI device, and that's where it oopses. Now, it looks like some users "know" that the device doesn't matter (which is true on some platforms), but that's bogus. The device is how you even find out what the rules for DMA access are (see for example dma_set_mask() etc), so giving a NULL device is insane. 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: oops in copy_page_rep()
On Tue, Jan 08, 2013 at 07:37:06AM -0800, Linus Torvalds wrote: > On Tue, Jan 8, 2013 at 5:04 AM, Hillf Danton wrote: > > On Tue, Jan 8, 2013 at 1:34 AM, Linus Torvalds > > wrote: > >> > >> Hmm. Is there some reason we never need to worry about it for the > >> "pmd_numa()" case just above? > >> > >> A comment about this all might be a really good idea. > >> > > Yes Sir, added. > > Heh. I was more thinking about why do_huge_pmd_wp_page() needs it, but > do_huge_pmd_numa_page() does not. It does. The check should be moved up. > Also, do we actually need it for huge_pmd_set_accessed()? The > *placement* of that thing confuses me. And because it confuses me, I'd > like to understand it. We need it for huge_pmd_set_accessed() too. Looks like a mis-merge. The original patch for huge_pmd_set_accessed() was correct: http://lkml.org/lkml/2012/10/25/402 -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pps: hide more configuration symbols behind CONFIG_PPS
On Tue, Jan 08, 2013 at 01:59:22PM +0100, Florian Fainelli wrote: > This patch makes CONFIG_PPS_DEBUG and CONFIG_NTP_PPS be hidden if > CONFIG_PPS is not selected, such that we are not prompted for these > configuration options if CONFIG_PPS is not set. > > Signed-off-by: Florian Fainelli > --- > drivers/pps/Kconfig |4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/pps/Kconfig b/drivers/pps/Kconfig > index 982d16b..dc19fb4 100644 > --- a/drivers/pps/Kconfig > +++ b/drivers/pps/Kconfig > @@ -21,6 +21,8 @@ config PPS > To compile this driver as a module, choose M here: the module > will be called pps_core.ko. > > +if PPS > + If you add this "if" ... > config PPS_DEBUG > bool "PPS debugging messages" > depends on PPS ... then you should delete this redundant "depends". 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: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()
On Tue, 8 Jan 2013 23:51:59 +0800
Jeff Chua wrote:
> I'm trying to understand how this oops in the diva driver and it's just a
> simple dma_alloc_coherent() followed by dma_free_coherent(), but it oops.
> Why?
Hmm...from a quick look...
> static u32 *clock_data_addr;
> static dma_addr_t clock_data_bus_addr;
>
> if((clock_data_addr = dma_alloc_coherent(NULL, PAGE_SIZE,
> _data_bus_addr, GFP_KERNEL)) != 0) {
> printk(KERN_INFO "dma_alloc_coherent ok\n");
> memset (clock_data_addr, 0x00, PAGE_SIZE);
> } else
> printk(KERN_INFO "dma_alloc_coherent bad!!!\n");
> if(clock_data_addr) {
> printk(KERN_INFO "dma_free_coherent!!!\n");
> dma_free_coherent(NULL, PAGE_SIZE, clock_data_addr,
> clock_data_bus_addr);
> clock_data_addr = NULL;
> }
Perhaps passing NULL as your device structure pointer might just have
something to do with a crash due to a null pointer dereference? If you're
doing DMA, you should have a device. Try passing it and you might just
find that things work better.
(Incidentally, this:
> IP: [] iommu_no_mapping+0xc/0xee
is a fairly good clue as well - it's trying to dereference the device
structure pointer).
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Availability issues during kernel load and kernel error handling
Hi,
I send this mail as information/suggestion for improvements of Linux
kernel. I have identified and solved the problem below some years ago.
I think that it would be great if the changes could be part of generic
distributions in the future as the affects availability when using
Linux in embedded system:
1. PROBLEM: The low level kernel functions exit(), panic(), poweroff()
and halt() are implemented with endless loops.
2. DESCRIPTION: When a problem occurs during kernel initialisation or
during operation where the functions are called, the only way to resume
operation is to power off and on the unit. This works when the unit is
in places with personnel, but installed at remote locations it is a
problem.
3. KEYWORDS: exit(), halt(), panic(), poweroff(), error()
4. KERNEL VERSION: 2.4.20 to at least 2.6.9
5. OUTPUT: -
6. EXAMPLE: Give command "halt" alt. "shutdown -h" at prompt or
introduce a problem during boot process like checksum error of packed
kernel load image.
7. ENVIRONMENT: All
8. WORKAROUND: In our system, activation of board whatchdog that
reboots the unit as the CPU reset pin wasn't routed to a curcuit that
could be written from CPU.
My changes in arch/ppc/boot/common/misc-common.c:
void reset_eb860(void)
{
#ifdef CONFIG_EB860
puts("\n Rebooting in 5 seconds \n");
*(unsigned char *) EB860_REG_WDT_CTL|= 0x09;
*(unsigned char *) EB860_REG_WDT_CTL&= ~0x60;
*(unsigned char *) EB860_REG_CTRL_STAT1 |= EB860_TR_WDG |
EB860_EN_WDG;
#else
puts("EB860 HW watchdog reboot not available! \n");
#endif
}
void exit(void)
{
puts("exit \n");
reset_eb860();
while(1);
}
9. SUGGESTION: Make it possible to configure alternative error
resolving behavior instead of waiting for power-off in endless loops.
This could be make a core dump and then wait a configurable time before
calling restart() or just directly call restart().
10: CODING EXAMPLES: from linux-2.6.9 distribution.
arch/ppc/boot/common/misc-common.c
void exit(void)
{
puts("exit\n");
while(1);
}
void error(char *x)
{
puts("\n\n");
puts(x);
puts("\n\n -- System halted");
while(1);/* Halt */
}
from linux-2.6.9/arch/kernel/exit.c
asmlinkage NORET_TYPE void do_exit(long code)
{
struct task_struct *tsk = current;
profile_task_exit(tsk);
if (unlikely(in_interrupt()))
panic("Aiee, killing interrupt handler!");
if (unlikely(!tsk->pid))
panic("Attempted to kill the idle task!");
if (unlikely(tsk->pid == 1))
panic("Attempted to kill init!");
if (tsk->io_context)
exit_io_context();
tsk->flags |= PF_EXITING;
del_timer_sync(>real_timer);
if (unlikely(in_atomic()))
printk(KERN_INFO "note: %s[%d] exited with preempt_count %d\n",
current->comm, current->pid,
preempt_count());
if (unlikely(current->ptrace & PT_TRACE_EXIT)) {
current->ptrace_message = code;
ptrace_notify((PTRACE_EVENT_EXIT << 8) | SIGTRAP);
}
acct_process(code);
__exit_mm(tsk);
exit_sem(tsk);
__exit_files(tsk);
__exit_fs(tsk);
exit_namespace(tsk);
exit_thread();
if (tsk->signal->leader)
disassociate_ctty(1);
module_put(tsk->thread_info->exec_domain->module);
if (tsk->binfmt)
module_put(tsk->binfmt->module);
tsk->exit_code = code;
exit_notify(tsk);
#ifdef CONFIG_NUMA
mpol_free(tsk->mempolicy);
tsk->mempolicy = NULL;
#endif
schedule();
BUG();
/* Avoid "noreturn function does return". */
for (;;) ;
}
Have also seen an issue where the kernel code loaded into RAM was
affected by a random memory error that resulted in hang-up of a unit.
The problem is that there isn't any board supported supervision that
can reboot a unit from the time where the unit is powered on until the
kernel has enabled the timer interrupt handler. When the timer
interrupt is operational, a SW watchdog can be used to monitor that the
kernel and applications doesn't get stuck or enter eternal loops. To
solve this boot issue, an external timer relay is triggered by power
on. If the unit boots correctly to run level 0, an output signal is
used to deactivate the timer relay. If not deactivated, the relay
triggers a power off - on reset.
Best regards,
Leif Larsson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dw_dmac patches
On Mon, Jan 07, 2013 at 02:54:54PM +0200, Andy Shevchenko wrote: > Hi, Vinod. > > I noticed you missed the 3.8 merge window and I can't see any of my > recent patches [1] in your next branch. So, what is your plan regarding > to them? Yes i missed quite a few due to my travel, but now am back :) Can you please rebase below on my next and resend the below sequence. I can go thru them quickly tomorrow and do the needful -- ~Vinod > > [1] > pick 9f2b870 dw_dmac: call .probe after we have a device in place > pick 5bcd7fe dw_dmac: absence of pdata isn't critical when autocfg is > set > pick 2fbca14 dmaengine: introduce is_slave_xfer function > pick 6e98b1f dma: at_hdmac: check direction properly for cyclic > transfers > pick d1573d9 dma: dw_dmac: check direction properly in > dw_dma_cyclic_prep > pick f1071a3 dma: ep93xx_dma: reuse is_slave_xfer helper > pick 191347f dma: ipu_idmac: reuse is_slave_xfer helper > pick 4ec19c2 dma: ste_dma40: reuse is_slave_xfer helper > pick 757978e dw_dmac: store direction in the custom channel structure > pick 8e5ea839 dw_dmac: make usage of dw_dma_slave optional > pick d0da3f4 dw_dmac: backlink to dw_dma in dw_dma_chan is superfluous > pick ca7141d dw_dmac: check for mapping errors > pick 281c298 dw_dmac: remove redundant check > pick 217f956 dw_dmac: update tx_node_active in dwc_do_single_block > pick fd144bd dma: dw_dmac: add dwc_chan_pause and dwc_chan_resume > pick 59a6031 dma: dw_dmac: clear suspend bit during termination > > > -- > Andy Shevchenko > Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/24] cfq-iosched: implement hierarchy-ready cfq_group charge scaling
On Fri, Dec 28, 2012 at 12:35:35PM -0800, Tejun Heo wrote: > Currently, cfqg charges are scaled directly according to cfqg->weight. > Regardless of the number of active cfqgs or the amount of active > weights, a given weight value always scales charge the same way. This > works fine as long as all cfqgs are treated equally regardless of > their positions in the hierarchy, which is what cfq currently > implements. It can't work in hierarchical settings because the > interpretation of a given weight value depends on where the weight is > located in the hierarchy. > > This patch reimplements cfqg charge scaling so that it can be used to > support hierarchy properly. The scheme is fairly simple and > light-weight. > > * When a cfqg is added to the service tree, v(disktime)weight is > calculated. It walks up the tree to root calculating the fraction > it has in the hierarchy. At each level, the fraction can be > calculated as > > cfqg->weight / parent->level_weight > > By compounding these, the global fraction of vdisktime the cfqg has > claim to - vfraction - can be determined. > > * When the cfqg needs to be charged, the charge is scaled inversely > proportionally to the vfraction. > > The new scaling scheme uses the same CFQ_SERVICE_SHIFT for fixed point > representation as before; however, the smallest scaling factor is now > 1 (ie. 1 << CFQ_SERVICE_SHIFT). This is different from before where 1 > was for CFQ_WEIGHT_DEFAULT and higher weight would result in smaller > scaling factor. > > While this shifts the global scale of vdisktime a bit, it doesn't > change the relative relationships among cfqgs and the scheduling > result isn't different. > > cfq_group_notify_queue_add uses fixed CFQ_IDLE_DELAY when appending > new cfqg to the service tree. The specific value of CFQ_IDLE_DELAY > didn't have any relevance to vdisktime before and is unlikely to cause > any visible behavior difference now especially as the scale shift > isn't that large. > > As the new scheme now makes proper distinction between cfqg->weight > and ->leaf_weight, reverse the weight aliasing for root cfqgs. For > root, both weights are now mapped to ->leaf_weight instead of the > other way around. > > Because we're still using cfqg_flat_parent(), this patch shouldn't > change the scheduling behavior in any noticeable way. > > v2: Beefed up comments on vfraction as requested by Vivek. > > Signed-off-by: Tejun Heo > Cc: Vivek Goyal Looks good to me. Acked-by: Vivek Goyal Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 29/32] block, aio: Batch completion for bios/kiocbs
Kent Overstreet writes: > On Tue, Jan 08, 2013 at 10:33:18AM -0500, Jeff Moyer wrote: >> Kent Overstreet writes: >> >> >> Is the rbtree really faster than a basic (l)list and a sort before >> >> completing them? Would be simpler. >> > >> > Well, depends. With one or two kioctxs? The list would definitely be >> > faster, but I'm loathe to use an O(n^2) algorithm anywhere where the >> > input size isn't strictly controlled, and I know of applications out >> > there that use tons of kioctxs. >> >> Out of curiosity, what applications do you know of that use tons of >> kioctx's? > > "tons" is relative I suppose, but before this patch series sharing a > kioctx between threads was really bad for performance and... you know > how people can be with threads. I wasn't questioning the merits of the patch, I was simply curious to know how aio is being (ab)used in the wild. So, is this some internal tool, then, or what? Thanks! Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] capemgr: Beaglebone DT overlay based cape manager
On Tuesday 08 January 2013, Pantelis Antoniou wrote: > On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote: > > > On Tuesday 08 January 2013, Lee Jones wrote: > >>> If there is not, there is no way to automatically load the overlays; you > >>> can always > >>> use the kernel command line, or have the a user space application to > >>> request the loading > >>> of a specific board's overlay. > >> > >> Unfortunately, there is no way to probe the UIBs. :( > > > > I thought that some of the newer UIBs had it, just not the old ones. > > As Pantelis says, we could at least detect the ones that have an EEPROM > > on them, and use a command line option or device tree attribute for the > > others. > > > > Arnd > > So I gather the new ones have an eeprom? I don't remember the details unfortunately. Lee should be the one who can find out. IIRC there was at least a single integeger number on them. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dmaengine: imx-dma: Disable use of hw_chain to fix sg_dma transfers.
On Fri, Jan 04, 2013 at 04:37:44PM +0100, javier Martin wrote: > On 30 October 2012 16:58, Javier Martin > wrote: > > HW chaining is currently broken in imx-dma. It can be easily reproduced > > doing > > intensive accesses to a external MMC card and checking how the file system > > is corrupted. > > > > Preventing the driver to use HW chaining solves these issues. > > > > Applied now. Sorry for this miss & thanks for reminding -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ath9k_htc: Fix skb leaks
On 01/01/2013 11:26 PM, Sujith Manoharan wrote: Larry Finger wrote: My only counter argument is that none of the other paths that get to ath9k_htc_txcompletion_cb() leak the skb. It only happens for the path that goes through htc_connect_service(). Sure, but the TX completion handler would be invoked for every skb that is passed to the USB layer, including the ones that are allocated in htc_hst.c. When this skb goes down to hif_usb.c, a URB is allocated and I am not sure how freeing the skb before the USB layer invokes the completion handler for the URB is correct. I'll come up with a patch and see if kmemleak still complains. Did I miss your posting on this issue? Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 29/32] block, aio: Batch completion for bios/kiocbs
On Tue, Jan 08, 2013 at 10:33:18AM -0500, Jeff Moyer wrote: > Kent Overstreet writes: > > >> Is the rbtree really faster than a basic (l)list and a sort before > >> completing them? Would be simpler. > > > > Well, depends. With one or two kioctxs? The list would definitely be > > faster, but I'm loathe to use an O(n^2) algorithm anywhere where the > > input size isn't strictly controlled, and I know of applications out > > there that use tons of kioctxs. > > Out of curiosity, what applications do you know of that use tons of > kioctx's? "tons" is relative I suppose, but before this patch series sharing a kioctx between threads was really bad for performance and... you know how people can be with threads. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lib: cpu_rmap: avoid flushing all workqueues
On Thu, 2013-01-03 at 13:58 -0800, Andrew Morton wrote: > On Wed, 2 Jan 2013 23:46:46 + > Ben Hutchings wrote: [...] > > > drivers/net/ethernet/mellanox/mlx4/ appears to be using > > > msix_ctl.pool_lock for exclusion, but I didn't check for coverage. > > > > > > drivers/net/ethernet/sfc/efx.c seems to not need locking because > > > all its cpu_rmap operations are at module_init() time. > > > > > > The cpu_rmap code would be less of a hand grenade if each of its > > > interface functions documented the caller's locking requirements. > > > > This particular 'hand grenade' *was* documented. So I don't think > > documentation is the problem. > > Dunno what you're referring to here. There is no cpu_rmap() locking > documentation. [...] /** * free_irq_cpu_rmap - free a CPU affinity reverse-map used for IRQs * @rmap: Reverse-map allocated with alloc_irq_cpu_map(), or %NULL * * Must be called in process context, before freeing the IRQs, and * without holding any locks required by global workqueue items. */ Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: USB autosuspend vs. URB submission
On Tue, Jan 08, 2013 at 10:51:20AM -0500, Alan Stern wrote: > On Mon, 7 Jan 2013, Josh Boyer wrote: > > > Hi, > > > > We've had a few reports in Fedora of users hitting the WARN_ONCE in > > drivers/usb/core/urb.c that prints a warning about a usb_submit_urb > > being called on an active URB. One of them[1] is from the ums_realtek > > driver and the other[2] is from the uvcvideo driver. However, I noticed > > that in both instances it seems the devices were coming back from what I > > think is autosuspend. > > > > I didn't immediately find any similar reports, and to my rather > > inexperienced eyes the drivers didn't seem to be doing anything clearly > > wrong. I'm wondering if anyone has some possible ideas for debugging > > and whether or not this might be a general issue? > > I don't see anything wrong either. > > Can you ask the users to collect a usbmon trace covering the period > when the problem occurs? I'll certainly ask. I'm not particularly hopeful for great results though, as the problems seem to be rather intermittent. Thanks for taking a look. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: mxs-dma: Fix build warnings with W=1
On Mon, Jan 07, 2013 at 11:48:39PM -0200, Fabio Estevam wrote: > From: Fabio Estevam > > Fix the following warnings when building with W=1 option: > > drivers/dma/mxs-dma.c: In function 'mxs_dma_alloc_chan_resources': > drivers/dma/mxs-dma.c:368:25: warning: comparison between signed and unsigned > integer expressions [-Wsign-compare] > drivers/dma/mxs-dma.c: In function 'mxs_dma_prep_slave_sg': > drivers/dma/mxs-dma.c:481:17: warning: comparison between signed and unsigned > integer expressions [-Wsign-compare] > drivers/dma/mxs-dma.c:494:3: warning: comparison between signed and unsigned > integer expressions [-Wsign-compare] > drivers/dma/mxs-dma.c:515:14: warning: comparison between signed and unsigned > integer expressions [-Wsign-compare] > drivers/dma/mxs-dma.c: In function 'mxs_dma_prep_dma_cyclic': > drivers/dma/mxs-dma.c:563:13: warning: comparison between signed and unsigned > integer expressions [-Wsign-compare] > Applied thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] pwm: atmel: add Timer Counter Block PWM driver
Hi,
This patch adds a PWM driver based on Atmel Timer Counter Block.
Timer Counter Block is used in Waveform generator mode.
A Timer Counter Block provides up to 6 PWM devices grouped by 2:
* group 0 = PWM 0 and 1
* group 1 = PWM 2 and 3
* group 2 = PMW 4 and 5
PWM devices in a given group must be configured with the same
period value.
If a PWM device in a group tries to change the period value and
the other device is already configured with a different value an
error will be returned.
This driver requires device tree support.
The Timer Counter Block number used to create a PWM chip is
given by tc-block field in an "atmel,tcb-pwm" compatible node.
This patch was tested on kizbox board (at91sam9g20 SoC) with
pwm-leds.
Regards,
Boris
Signed-off-by: Boris BREZILLON
---
Changes since v1:
- Fix device tree binding Documentation
- Fix Kconfig issues (missing OF dependency,
deprecated HAVE_PWM select, ...)
- Fix various coding style issues.
- Cleanup code and add some comments.
Changes since v2:
- Replace kzalloc/kfree with managed versions
(devm_kzalloc/devm_kfree).
- Add one cell to device tree binding to support polarity
flag.
- Replace min computation (2 div -> 1 mul + 1 div).
Changes since v3:
- Fix device tree binding Documentation
- Fix Kconfig description
- Fix coding style issues (function parameters alignment)
- Replace 10 value with NSEC_PER_SEC macro
- Get rid of newcmr variable in enable/disable functions
- Remove unneeded devm_kfree
- Add missing atmel_tc_free
Changes since v4:
- Add missing comments
- Fix coding style issues (multi-line error string)
- Fix wrong MODULE_DEVICE_TABLE setting
- Remove unneeded MODULE_ALIAS declaration
.../devicetree/bindings/pwm/atmel-tcb-pwm.txt | 18 +
drivers/pwm/Kconfig| 12 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-atmel-tcb.c| 445
4 files changed, 476 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
create mode 100644 drivers/pwm/pwm-atmel-tcb.c
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
new file mode 100644
index 000..de0eaed
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -0,0 +1,18 @@
+Atmel TCB PWM controller
+
+Required properties:
+- compatible: should be "atmel,tcb-pwm"
+- #pwm-cells: Should be 3. The first cell specifies the per-chip index
+ of the PWM to use, the second cell is the period in nanoseconds and
+ bit 0 in the third cell is used to encode the polarity of PWM output.
+ Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity &
+ set to 0 for normal polarity.
+- tc-block: The Timer Counter block to use as a PWM chip.
+
+Example:
+
+pwm {
+ compatible = "atmel,tcb-pwm";
+ #pwm-cells = <3>;
+ tc-block = <1>;
+};
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e513cd9..10b6afc 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -37,6 +37,18 @@ config PWM_AB8500
To compile this driver as a module, choose M here: the module
will be called pwm-ab8500.
+config PWM_ATMEL_TCB
+ tristate "TC Block PWM"
+ depends on ATMEL_TCLIB && OF
+ help
+ Generic PWM framework driver for Atmel Timer Counter Block.
+
+ A Timer Counter Block provides 6 PWM devices grouped by 2.
+ Devices in a given group must have the same period.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel-tcb.
+
config PWM_BFIN
tristate "Blackfin PWM support"
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 62a2963..94ba21e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
+obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
new file mode 100644
index 000..16cb530
--- /dev/null
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -0,0 +1,445 @@
+/*
+ * Copyright (C) Overkiz SAS 2012
+ *
+ * Author: Boris BREZILLON
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NPWM 6
+
+#define ATMEL_TC_ACMR_MASK (ATMEL_TC_ACPA | ATMEL_TC_ACPC |
Re: 3.2.35 problem with M5A97 PRO ram: bad_page free_pages_prepare mem_init
On Tue, Jan 08, 2013 at 01:21:26AM +0100, l...@tigusoft.pl wrote: > On 08/01/13 01:13, l...@tigusoft.pl wrote: > > > linux kernel > > 3.2.0-0.bpo.4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.35-2~bpo60+1 x86_64 > > GNU/Linux > > will post later how it behaves on vanilla 3.2.36 and 3.7.1 Yes, also, if your DRAM supports ECC, try enabling it in the BIOS. This board should support ECC. Then, enable CONFIG_EDAC_AMD64 and CONFIG_EDAC_DECODE_MCE to check whether it catches any DRAM errors. If your DRAM is non-ECC, try consecutively swapping out a DIMM each time and booting to see whether removing one of the DIMMs makes the errors go away. HTH. -- 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 12/24] cfq-iosched: implement cfq_group->nr_active and ->children_weight
On Fri, Dec 28, 2012 at 12:35:34PM -0800, Tejun Heo wrote: > To prepare for blkcg hierarchy support, add cfqg->nr_active and > ->children_weight. cfqg->nr_active counts the number of active cfqgs > at the cfqg's level and ->children_weight is sum of weights of those > cfqgs. The level covers itself (cfqg->leaf_weight) and immediate > children. > > The two values are updated when a cfqg enters and leaves the group > service tree. Unless the hierarchy is very deep, the added overhead > should be negligible. > > Currently, the parent is determined using cfqg_flat_parent() which > makes the root cfqg the parent of all other cfqgs. This is to make > the transition to hierarchy-aware scheduling gradual. Scheduling > logic will be converted to use cfqg->children_weight without actually > changing the behavior. When everything is ready, > blkcg_weight_parent() will be replaced with proper parent function. > > This patch doesn't introduce any behavior chagne. > > v2: s/cfqg->level_weight/cfqg->children_weight/ as per Vivek. > > Signed-off-by: Tejun Heo > Cc: Vivek Goyal Looks good to me. Acked-by: Vivek Goyal Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: USB autosuspend vs. URB submission
On Mon, 7 Jan 2013, Josh Boyer wrote: > Hi, > > We've had a few reports in Fedora of users hitting the WARN_ONCE in > drivers/usb/core/urb.c that prints a warning about a usb_submit_urb > being called on an active URB. One of them[1] is from the ums_realtek > driver and the other[2] is from the uvcvideo driver. However, I noticed > that in both instances it seems the devices were coming back from what I > think is autosuspend. > > I didn't immediately find any similar reports, and to my rather > inexperienced eyes the drivers didn't seem to be doing anything clearly > wrong. I'm wondering if anyone has some possible ideas for debugging > and whether or not this might be a general issue? I don't see anything wrong either. Can you ask the users to collect a usbmon trace covering the period when the problem occurs? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] EDAC fixes for 3.8
Hi Linus, please pull the 3 fixes below. Thanks. The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_fixes_for_3.8 for you to fetch changes up to 44d22e2404b3ce93a314654962d31acc8afcdd62: EDAC: Cleanup device deregistering path (2013-01-07 17:43:00 +0100) Two error path fixes causing a crash and a Kconfig fix for an issue which spilled all EDAC suboptions into the 'Device Drivers' menu. Borislav Petkov (1): EDAC: Fix EDAC Kconfig menu Konstantin Khlebnikov (1): EDAC: Fix kernel panic on module unloading Lans Zhang (1): EDAC: Cleanup device deregistering path drivers/edac/Kconfig | 8 +++- drivers/edac/edac_mc_sysfs.c | 19 ++- 2 files changed, 9 insertions(+), 18 deletions(-) -- 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: oops in copy_page_rep()
On Tue, Jan 8, 2013 at 5:04 AM, Hillf Danton wrote: > On Tue, Jan 8, 2013 at 1:34 AM, Linus Torvalds > wrote: >> >> Hmm. Is there some reason we never need to worry about it for the >> "pmd_numa()" case just above? >> >> A comment about this all might be a really good idea. >> > Yes Sir, added. Heh. I was more thinking about why do_huge_pmd_wp_page() needs it, but do_huge_pmd_numa_page() does not. Also, do we actually need it for huge_pmd_set_accessed()? The *placement* of that thing confuses me. And because it confuses me, I'd like to understand it. 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 11/24] cfq-iosched: add leaf_weight
On Fri, Dec 28, 2012 at 12:35:33PM -0800, Tejun Heo wrote:
[..]
> +
> + /* on root, leaf_weight is mapped to weight */
> + {
> + .name = "leaf_weight_device",
> + .flags = CFTYPE_ONLY_ON_ROOT,
> + .read_seq_string = cfqg_print_weight_device,
> + .write_string = cfqg_set_weight_device,
> + .max_write_len = 256,
> + },
> + {
> + .name = "leaf_weight",
> + .flags = CFTYPE_ONLY_ON_ROOT,
> + .read_seq_string = cfq_print_weight,
> + .write_u64 = cfq_set_weight,
> + },
Hi Tejun,
How does it help to map leaf weight to weight in root group. Old programs
anyway don't know about leaf_weight. So nobody is going to update it. And
if they update it, they better know what does it do.
I think we just need to map "weight" to "leaf_weight" once you switch to
making use of leaf_weight and at that point of time a user will expect
that updating weight retains the old behavior. I think you have done
that in later patch.
But mapping leaf_weight to weight seems unnecessary atleast from backward
compatibility point of view.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 29/32] block, aio: Batch completion for bios/kiocbs
Kent Overstreet writes: >> Is the rbtree really faster than a basic (l)list and a sort before >> completing them? Would be simpler. > > Well, depends. With one or two kioctxs? The list would definitely be > faster, but I'm loathe to use an O(n^2) algorithm anywhere where the > input size isn't strictly controlled, and I know of applications out > there that use tons of kioctxs. Out of curiosity, what applications do you know of that use tons of kioctx's? -Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sound fixes for 3.8-rc3
Linus,
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.8
for you to fetch changes up to 6d3cd5d444223c41eabb70dccff14fae4e8cb8b1:
ALSA: hda - add mute LED for HP Pavilion 17 (Realtek codec) (2013-01-07
17:29:55 +0100)
Sound fixes for 3.8-rc3
Nothing too exciting here, just a few regression and trivial fixes,
and new quirks for HD-audio and USB-audio.
- HD-audio mute LED mode enum fix
- Fix kernel panic of Digidesign Mbox2 usb-audio quirk (which was new
in 3.8-rc1)
- Creative BT-D1 usb-audio quirk
- mute LED fixup for HP Pavillion 17 laptop
Alexander Schremmer (1):
ALSA: usb-audio: Add support for Creative BT-D1 via usb sound quirks
Asim Kadav (1):
sound: oss/pas2: Fix possible access out of array
Damien Zammit (1):
ALSA: usb-audio: Fix kernel panic of Digidesign Mbox2 quirk
David Henningsson (2):
ALSA: hda - Switch "On" and "Off" for "Mute-LED Mode" kcontrol
ALSA: hda - add mute LED for HP Pavilion 17 (Realtek codec)
Nickolai Zeldovich (1):
ALSA: au88x0: fix incorrect left shift
sound/oss/pas2_card.c | 5 +
sound/pci/au88x0/au88x0_synth.c | 2 +-
sound/pci/hda/hda_codec.c | 2 +-
sound/pci/hda/patch_realtek.c | 30 ++
sound/usb/midi.c| 4
sound/usb/quirks-table.h| 24 +++-
sound/usb/quirks.c | 16 +++-
sound/usb/usbaudio.h| 1 -
8 files changed, 67 insertions(+), 17 deletions(-)
diff --git a/sound/oss/pas2_card.c b/sound/oss/pas2_card.c
index dabf8a8..7004e24 100644
--- a/sound/oss/pas2_card.c
+++ b/sound/oss/pas2_card.c
@@ -333,6 +333,11 @@ static void __init attach_pas_card(struct address_info
*hw_config)
{
chartemp[100];
+ if (pas_model < 0 ||
+ pas_model >= ARRAY_SIZE(pas_model_names)) {
+ printk(KERN_ERR "pas2 unrecognized model.\n");
+ return;
+ }
sprintf(temp,
"%s rev %d", pas_model_names[(int) pas_model],
pas_read(0x2789));
diff --git a/sound/pci/au88x0/au88x0_synth.c b/sound/pci/au88x0/au88x0_synth.c
index 2805e34..8bef473 100644
--- a/sound/pci/au88x0/au88x0_synth.c
+++ b/sound/pci/au88x0/au88x0_synth.c
@@ -58,7 +58,7 @@ static void vortex_wt_setdsout(vortex_t * vortex, u32 wt, int
en)
if (en)
temp |= (1 << (wt & 0x1f));
else
- temp &= (1 << ~(wt & 0x1f));
+ temp &= ~(1 << (wt & 0x1f));
hwwrite(vortex->mmio, WT_DSREG((wt >= 0x20) ? 1 : 0), temp);
}
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 8353c77..b8fb0a5 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2531,7 +2531,7 @@ static int vmaster_mute_mode_info(struct snd_kcontrol
*kcontrol,
struct snd_ctl_elem_info *uinfo)
{
static const char * const texts[] = {
- "Off", "On", "Follow Master"
+ "On", "Off", "Follow Master"
};
unsigned int index;
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 6ee3459..71ae23d 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5992,6 +5992,30 @@ static void alc269_fixup_quanta_mute(struct hda_codec
*codec,
spec->automute_hook = alc269_quanta_automute;
}
+/* update mute-LED according to the speaker mute state via mic1 VREF pin */
+static void alc269_fixup_mic1_mute_hook(void *private_data, int enabled)
+{
+ struct hda_codec *codec = private_data;
+ unsigned int pinval = AC_PINCTL_IN_EN + (enabled ?
+ AC_PINCTL_VREF_HIZ : AC_PINCTL_VREF_80);
+ snd_hda_set_pin_ctl_cache(codec, 0x18, pinval);
+}
+
+static void alc269_fixup_mic1_mute(struct hda_codec *codec,
+ const struct alc_fixup *fix, int action)
+{
+ struct alc_spec *spec = codec->spec;
+ switch (action) {
+ case ALC_FIXUP_ACT_BUILD:
+ spec->vmaster_mute.hook = alc269_fixup_mic1_mute_hook;
+ snd_hda_add_vmaster_hook(codec, >vmaster_mute, true);
+ /* fallthru */
+ case ALC_FIXUP_ACT_INIT:
+ snd_hda_sync_vmaster_hook(>vmaster_mute);
+ break;
+ }
+}
+
/* update mute-LED according to the speaker mute state via mic2 VREF pin */
static void alc269_fixup_mic2_mute_hook(void *private_data, int enabled)
{
@@ -6043,6 +6067,7 @@ enum
Re: [PATCH v4 RESEND] pwm: atmel: add Timer Counter Block PWM driver
On 08/01/2013 08:10, Thierry Reding wrote:
> On Thu, Dec 20, 2012 at 10:12:56AM +0100, Boris BREZILLON wrote:
>> Hi,
>>
>> Sorry for resend. The previous version still has alignment issues on
>> atmel_tcb_pwm_set_polarity, atmel_tcb_pwm_request and
>> atmel_tcb_pwm_config function parameters.
>>
>> This patch adds a PWM driver based on Atmel Timer Counter Block.
>> Timer Counter Block is used in Waveform generator mode.
>>
>> A Timer Counter Block provides up to 6 PWM devices grouped by 2:
>> * group 0 = PWM 0 and 1
>> * group 1 = PWM 1 and 2
>> * group 2 = PMW 3 and 4
>
> Should this be "PWM 2 and 3" and "PWM 4 and 5"? Or is PWM 1 shared
> between groups 0 and 1?
>
>> +static int atmel_tcb_pwm_request(struct pwm_chip *chip,
>> + struct pwm_device *pwm)
>> +{
> [...]
>> +clk_enable(tc->clk[group]);
>
> You need to check the return value of clk_enable(). There's always a
> small possibility that it may fail.
>
>> +static void atmel_tcb_pwm_disable(struct pwm_chip *chip, struct pwm_device
>> *pwm)
>> +{
> [...]
>> +/* If duty is 0 reverse polarity */
>> +if (tcbpwm->duty == 0)
>> +polarity = !polarity;
>
> Rather than commenting on what the code does, this should say why it
> does so.
>
>> +static int atmel_tcb_pwm_enable(struct pwm_chip *chip, struct pwm_device
>> *pwm)
>> +{
> [...]
>> +/* If duty is 0 reverse polarity */
>> +if (tcbpwm->duty == 0)
>> +polarity = !polarity;
>
> Same here.
>
>> +static int atmel_tcb_pwm_probe(struct platform_device *pdev)
>> +{
> [...]
>> +struct atmel_tcb_pwm_chip *tcbpwm;
>> +struct device_node *np = pdev->dev.of_node;
>> +struct atmel_tc *tc;
>> +int err;
>> +int tcblock;
>> +
>> +err = of_property_read_u32(np, "tc-block", );
>> +if (err < 0) {
>> +dev_err(>dev,
>> +"failed to get tc block number from device tree (error:
>> %d)\n",
>
> Maybe: "failed to get Timer Counter Block number..." to make it
> consistent with the error message below:
Do I have to break the error string so that the line does not exceed 80
characters ?
Checkpath script does not complain about it, and the CodingStyle file specify
that visible
strings should not be broken...
Same question applies to this error, which I converted to a multi-line error in
a previous patch version:
dev_err(chip->dev,
"failed to configure period_ns:\n"
"the other PWM device in this group is already\n"
"configured with a different period_ns value\n");
>
>> +tc = atmel_tc_alloc(tcblock, "tcb-pwm");
>> +if (tc == NULL) {
>> +dev_err(>dev, "failed to allocate Timer Counter Block\n");
>> +return -ENOMEM;
>> +}
> [...]
>> +static const struct of_device_id atmel_tcb_pwm_dt_ids[] = {
>> +{ .compatible = "atmel,tcb-pwm", },
>> +{ /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, mxs_pwm_dt_ids);
>
> This is still wrong.
>
>> +static struct platform_driver atmel_tcb_pwm_driver = {
>> +.driver = {
>> +.name = "atmel-tcb-pwm",
>> +.of_match_table = atmel_tcb_pwm_dt_ids,
>> +},
>> +.probe = atmel_tcb_pwm_probe,
>> +.remove = atmel_tcb_pwm_remove,
>> +};
>> +module_platform_driver(atmel_tcb_pwm_driver);
>> +
>> +MODULE_AUTHOR("Boris BREZILLON ");
>> +MODULE_DESCRIPTION("Atmel Timer Counter Pulse Width Modulation Driver");
>> +MODULE_ALIAS("platform:atmel-tcb-pwm");
>
> I don't think you needMODULE_ALIAS() if the alias is the same as the
> driver name.
>
> Thierry
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Antw: [PATCH 0/5] kfifo cleanup and log based kfifo API
On Tue, Jan 08, 2013 at 04:03:17PM +0100, Ulrich Windl wrote: > >>> Yuanhan Liu schrieb am 08.01.2013 um 15:57 > >>> in > Nachricht <1357657073-27352-1-git-send-email-yuanhan@linux.intel.com>: > > [...] > > My proposal is to replace kfifo_init with kfifo_alloc, where it > > allocate buffer and maintain fifo size inside kfifo. Then we can > > remove buggy kfifo_init. > [...] > > Spontaneously I feel that emitting a critical message if the requested size > is not a power of two would be a good idea, Hi Ulrich, If we can emit all such critical message at compile time, it would be good then. But we can't, as fifo size is runtime determinated in quite many cases. > as well as (in that case) rounding up to the next power of two instead of > rounding down seems not too stupid ;-) There are 2 issues, first, you just can't round the fifo size up to power of 2 for kfifo_init as fifo buffer is allocated outside. And if you do, you may access memory outside the buffer. Second, round up to power of 2 inside kfifo_alloc and DECLARE_KFIFO is simple and should work. But it wastes memory(by allocating more memory) without notifing caller. So, per discussed with Stefani, we better to change the API be log aware to root fix this kind of potential issue. Thanks. --yliu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] block layer runtime pm
On Tue, 8 Jan 2013, Aaron Lu wrote: > So this also reminds me that as long as CONFIG_PM_RUNTIME is selected, > the blk_pm_add/put/peek_request functions will be in the block IO path. > Shall we introduce a new config option to selectively build block > runtime PM functionality? something like CONFIG_BLK_PM_RUNTIME perhaps? > > Just some condition checks in those functions, not sure if it is worth a > new config though. Please suggest, thanks. I don't think it is needed. The new routines will be very quick when blk_pm_runtime_init() hasn't been called, once you add back the checks for the queue's device. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 RESEND] pwm: atmel: add Timer Counter Block PWM driver
On Tue, Jan 08, 2013 at 04:21:59PM +0100, Boris BREZILLON wrote: > Do I have to break the error string so that the line does not exceed 80 > characters ? No. > Checkpath script does not complain about it, and the CodingStyle file > specify that visible strings should not be broken... Correct. > Same question applies to this error, which I converted to a multi-line > error in a previous patch version: > > dev_err(chip->dev, > "failed to configure period_ns:\n" > "the other PWM device in this group is already\n" > "configured with a different period_ns value\n"); Which is a bad idea. It appears in log files as multiple lines, which makes parsing the error for analysis difficult (eg, you may have a log analyser which tells you how many times an error occurs - the above would be treated as three separate errors. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression
At Sat, 22 Dec 2012 14:23:24 -0700, Kevin Fenzi wrote: > > Greetings. > > I've got an issue with sound on my t510. It started in the late 3.4.x > kernels. Sound works on boot and for 5-10min after, then the speakers > stop working at all. > > I posted a while back on the alsa-users list, and someone else had the > same issue: > > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html > > It seems that the speakers(?) are getting moved to state D3 and turning > off. You can manually get it to come back for a few minutes by using > hda-verb to move it back to D0: > > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0 > > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd > is my alsa-info. > > I'd file a bug on the alsa bug tracker, but it still seems to be down > (for many months now?). No response on alsa-users, so now that I have a > bit of time, I am posting here in hopes someone can look. ;) > > Happy to provide more info or try things. It's a known problem that some people have already reported, but currently no clue who actually turns down the pin to D3. Conexant guys wrote me that the codec doesn't do it by itself, and the driver neither, AFAIK. A possible answer is the firmware / BIOS, but who knows. In anyway, could you try to trace the hd-audio events and see whether the power down is *not* issued by the driver when you see this state? See Documentation/sound/alsa/HD-Audio.txt, the section "Tracepoints" for a brief instruction. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/4] block: implement runtime pm strategy
On Tue, 8 Jan 2013, Aaron Lu wrote:
> >> --- a/include/linux/blkdev.h
> >> +++ b/include/linux/blkdev.h
> >> @@ -974,6 +974,40 @@ extern int blk_pre_runtime_suspend(struct
> >> request_queue *q);
> >> extern void blk_post_runtime_suspend(struct request_queue *q, int err);
> >> extern void blk_pre_runtime_resume(struct request_queue *q);
> >> extern void blk_post_runtime_resume(struct request_queue *q, int err);
> >> +
> >> +static inline void blk_pm_put_request(struct request *rq)
> >> +{
> >> + if (!(rq->cmd_flags & REQ_PM) && !--rq->q->nr_pending) {
> >> + pm_runtime_mark_last_busy(rq->q->dev);
> >> + pm_runtime_autosuspend(rq->q->dev);
> >> + }
> >> +}
> >> +
> >> +static inline struct request *blk_pm_peek_request(
> >> + struct request_queue *q, struct request *rq)
> >> +{
> >> + if (q->rpm_status == RPM_SUSPENDED ||
> >> +(q->rpm_status != RPM_ACTIVE && !(rq->cmd_flags & REQ_PM)))
> >> + return NULL;
> >> + else
> >> + return rq;
> >> +}
> >> +
> >> +static inline void blk_pm_requeue_request(struct request *rq)
> >> +{
> >> + if (!(rq->cmd_flags & REQ_PM))
> >> + rq->q->nr_pending--;
> >> +}
> >> +
> >> +static inline void blk_pm_add_request(struct request_queue *q,
> >> + struct request *rq)
> >> +{
> >> + if (!(rq->cmd_flags & REQ_PM) &&
> >> + q->nr_pending++ == 0 &&
> >> + (q->rpm_status == RPM_SUSPENDED ||
> >> + q->rpm_status == RPM_SUSPENDING))
> >> + pm_request_resume(q->dev);
> >> +}
> >
> > These routines also don't belong in include/linux. And they don't need
> > to be marked inline.
>
> OK, will move them.
>
> What about create a new file blk-pm.c for all these block pm related
> code?
Sure, go ahead if Jens doesn't mind. Alternatively, you could put each
of these functions in the file where it gets used.
Just as importantly, all of the public routines added in patch 2/4 to
blk-core.c should have kerneldoc explaining how and where to use them.
In particular, the kerneldoc for blk_pm_runtime_init() has to mention
that the block runtime PM implementation works only for drivers that
use request structures for their I/O; it doesn't work for drivers that
use bio's directly.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] nfsd: Remove write permission from file content
On Sat, Jan 05, 2013 at 12:29:05PM +0800, Yanchuan Nian wrote:
> 2013/1/5 J. Bruce Fields
>
> > On Fri, Jan 04, 2013 at 07:45:35PM +0800, ycn...@gmail.com wrote:
> > > From: Yanchuan Nian
> > >
> > > The write function doesn't be implemented in file content, and it's
> > meaningless
> > > to write data into this file directly. Remove write permission from it.
> >
> > So does it really matter either way?
> >
> No, it doesn't matter. I saw that nfs-utils communicates with nfsd through
> proc fs, so I tried to update the cache by writing data to proc fs
> directly. I found the format of "channel" and "flush" in nfs-utils, but I
> couldn't find the format of "content", so I read the sunrpc source code,
> and found that the write function doesn't be implemented, but the write
> permission is set when registering into proc fs. I also found that
> "content" in pipe fs doesn't have write permission.
OK, so if it had been read-only it might have saved you a little
confusion. Fair enough.
--b.
>
> >
> > OK, applying, but I wonder.
> >
> > --b.
> >
> > >
> > > Signed-off-by: Yanchuan Nian
> > > ---
> > > net/sunrpc/cache.c |2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> > > index 9afa439..9f84703 100644
> > > --- a/net/sunrpc/cache.c
> > > +++ b/net/sunrpc/cache.c
> > > @@ -1614,7 +1614,7 @@ static int create_cache_proc_entries(struct
> > cache_detail *cd, struct net *net)
> > > goto out_nomem;
> > > }
> > > if (cd->cache_show) {
> > > - p = proc_create_data("content", S_IFREG|S_IRUSR|S_IWUSR,
> > > + p = proc_create_data("content", S_IFREG|S_IRUSR,
> > > cd->u.procfs.proc_ent,
> > > _file_operations_procfs, cd);
> > > cd->u.procfs.content_ent = p;
> > > --
> > > 1.7.4.4
> > >
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Antw: [PATCH 0/5] kfifo cleanup and log based kfifo API
>>> Yuanhan Liu schrieb am 08.01.2013 um 15:57 in Nachricht <1357657073-27352-1-git-send-email-yuanhan@linux.intel.com>: [...] > My proposal is to replace kfifo_init with kfifo_alloc, where it > allocate buffer and maintain fifo size inside kfifo. Then we can > remove buggy kfifo_init. [...] Spontaneously I feel that emitting a critical message if the requested size is not a power of two would be a good idea, as well as (in that case) rounding up to the next power of two instead of rounding down seems not too stupid ;-) Sorry, I'm not deeply into recent kernel development. Regards, Ulrich -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
Update efi_call_phys_prelog to install an identity mapping of all available
memory. This corrects a bug on very large systems with more then 512 GB in
which bios would not be able to access addresses above not in the mapping.
The result is a crash that looks much like this.
BUG: unable to handle kernel paging request at 00effd870020
IP: [<78bce331>] 0x78bce330
PGD 0
Oops: [#1] SMP
Modules linked in:
CPU 0
Pid: 0, comm: swapper/0 Tainted: GW
3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
RIP: 0010:[<78bce331>] [<78bce331>] 0x78bce330
RSP: :81601d28 EFLAGS: 00010006
RAX: 78b80e18 RBX: 0004 RCX: 0004
RDX: 78bcf958 RSI: 2400 RDI: 8000
RBP: 78bcf760 R08: 00effd87 R09:
R10: R11: 00c3 R12: 0030
R13: 00effd87 R14: R15: 88effd87
FS: () GS:88effe40() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 00effd870020 CR3: 0160c000 CR4: 06b0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper/0 (pid: 0, threadinfo 8160, task 81614400)
Stack:
78b80d18 0004 78bced7b 880078b81fff
0082 78bce3a8 2400
6202 78b80da0 78bce45d 8107cb5a
Call Trace:
[] ? on_each_cpu+0x77/0x83
[] ? change_page_attr_set_clr+0x32f/0x3ed
[] ? efi_call4+0x46/0x80
[] ? efi_enter_virtual_mode+0x1f5/0x305
[] ? start_kernel+0x34a/0x3d2
[] ? repair_env_string+0x60/0x60
[] ? x86_64_start_reservations+0xba/0xc1
[] ? early_idt_handlers+0x120/0x120
[] ? x86_64_start_kernel+0x154/0x163
Code: Bad RIP value.
RIP [<78bce331>] 0x78bce330
RSP
CR2: 00effd870020
---[ end trace ead828934fef5eab ]---
v2: I noticed a typo on the one sent friday, also ccing the stable tree.
Cc: sta...@vger.kernel.org
Cc: Matt Fleming
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Nathan Zimmer
Signed-off-by: Robin Holt
---
arch/x86/platform/efi/efi_64.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 95fd505..2b20038 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -38,7 +38,7 @@
#include
#include
-static pgd_t save_pgd __initdata;
+static pgd_t *save_pgd __initdata;
static unsigned long efi_flags __initdata;
static void __init early_code_mapping_set_exec(int executable)
@@ -61,12 +61,20 @@ static void __init early_code_mapping_set_exec(int
executable)
void __init efi_call_phys_prelog(void)
{
unsigned long vaddress;
+ int pgd;
+ int n_pgds;
early_code_mapping_set_exec(1);
local_irq_save(efi_flags);
- vaddress = (unsigned long)__va(0x0UL);
- save_pgd = *pgd_offset_k(0x0UL);
- set_pgd(pgd_offset_k(0x0UL), *pgd_offset_k(vaddress));
+
+ n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
+ save_pgd = kmalloc(n_pgds * sizeof(pgd_t), GFP_KERNEL);
+
+ for (pgd = 0; pgd < n_pgds; pgd++) {
+ save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
+ vaddress = (unsigned long)__va(pgd * PGDIR_SIZE);
+ set_pgd(pgd_offset_k(pgd * PGDIR_SIZE),
*pgd_offset_k(vaddress));
+ }
__flush_tlb_all();
}
@@ -75,7 +83,11 @@ void __init efi_call_phys_epilog(void)
/*
* After the lock is released, the original page table is restored.
*/
- set_pgd(pgd_offset_k(0x0UL), save_pgd);
+ int pgd;
+ int n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT) , PGDIR_SIZE);
+ for (pgd = 0; pgd < n_pgds; pgd++)
+ set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), save_pgd[pgd]);
+ kfree(save_pgd);
__flush_tlb_all();
local_irq_restore(efi_flags);
early_code_mapping_set_exec(0);
--
1.6.0.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: kernel BUG at kernel/sched_rt.c:493!
On Tue, Jan 08, 2013 at 09:36:05AM -0500, Steven Rostedt wrote: > > > > I've also managed to reproduce this on 3.8.0-rc2 so it appears the bug > > is still present in the latest kernel. > > Shawn, > > Can you send me your .config file. I've attached the 3.8.0-rc2 config that I used to reproduce this in an 8 core kvm image. Let me know if you need anything else. Thanks, Shawn -- --- This email, along with any attachments, is confidential. If you believe you received this message in error, please contact the sender immediately and delete all copies of the message. Thank you. 3.8.0-rc2.config.gz Description: GNU Zip compressed data
[PATCH 1/5] kfifo: remove unnecessary type check
Firstly, this kind of type check doesn't work. It does something similar
as following:
void * __dummy = NULL;
__buf = __dummy;
__dummy is defined as void *. Thus it will not trigger warnings as
expected.
Second, we don't need that kind of check. Since the prototype
of __kfifo_out is:
unsigned int __kfifo_out(struct __kfifo *fifo, void *buf, unsigned int
len)
buf is defined as void *, so we don't need do the type check. Remove it.
v2: remove ptr and const_ptr, which were used for type checking.
LINK: https://lkml.org/lkml/2012/10/25/386
LINK: https://lkml.org/lkml/2012/10/25/584
Cc: Stefani Seibold
Cc: Andrew Morton
Signed-off-by: Yuanhan Liu
---
include/linux/kfifo.h | 46 --
1 files changed, 12 insertions(+), 34 deletions(-)
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 10308c6..7a18245 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -63,49 +63,47 @@ struct __kfifo {
void*data;
};
-#define __STRUCT_KFIFO_COMMON(datatype, recsize, ptrtype) \
+#define __STRUCT_KFIFO_COMMON(datatype, recsize) \
union { \
struct __kfifo kfifo; \
datatype*type; \
char(*rectype)[recsize]; \
- ptrtype *ptr; \
- const ptrtype *ptr_const; \
}
-#define __STRUCT_KFIFO(type, size, recsize, ptrtype) \
+#define __STRUCT_KFIFO(type, size, recsize) \
{ \
- __STRUCT_KFIFO_COMMON(type, recsize, ptrtype); \
+ __STRUCT_KFIFO_COMMON(type, recsize); \
typebuf[((size < 2) || (size & (size - 1))) ? -1 : size]; \
}
#define STRUCT_KFIFO(type, size) \
- struct __STRUCT_KFIFO(type, size, 0, type)
+ struct __STRUCT_KFIFO(type, size, 0)
-#define __STRUCT_KFIFO_PTR(type, recsize, ptrtype) \
+#define __STRUCT_KFIFO_PTR(type, recsize) \
{ \
- __STRUCT_KFIFO_COMMON(type, recsize, ptrtype); \
+ __STRUCT_KFIFO_COMMON(type, recsize); \
typebuf[0]; \
}
#define STRUCT_KFIFO_PTR(type) \
- struct __STRUCT_KFIFO_PTR(type, 0, type)
+ struct __STRUCT_KFIFO_PTR(type, 0)
/*
* define compatibility "struct kfifo" for dynamic allocated fifos
*/
-struct kfifo __STRUCT_KFIFO_PTR(unsigned char, 0, void);
+struct kfifo __STRUCT_KFIFO_PTR(unsigned char, 0);
#define STRUCT_KFIFO_REC_1(size) \
- struct __STRUCT_KFIFO(unsigned char, size, 1, void)
+ struct __STRUCT_KFIFO(unsigned char, size, 1)
#define STRUCT_KFIFO_REC_2(size) \
- struct __STRUCT_KFIFO(unsigned char, size, 2, void)
+ struct __STRUCT_KFIFO(unsigned char, size, 2)
/*
* define kfifo_rec types
*/
-struct kfifo_rec_ptr_1 __STRUCT_KFIFO_PTR(unsigned char, 1, void);
-struct kfifo_rec_ptr_2 __STRUCT_KFIFO_PTR(unsigned char, 2, void);
+struct kfifo_rec_ptr_1 __STRUCT_KFIFO_PTR(unsigned char, 1);
+struct kfifo_rec_ptr_2 __STRUCT_KFIFO_PTR(unsigned char, 2);
/*
* helper macro to distinguish between real in place fifo where the fifo
@@ -390,10 +388,6 @@ __kfifo_int_must_check_helper( \
unsigned int __ret; \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
- __dummy = (typeof(__val))NULL; \
- } \
if (__recsize) \
__ret = __kfifo_in_r(__kfifo, __val, sizeof(*__val), \
__recsize); \
@@ -432,8 +426,6 @@ __kfifo_uint_must_check_helper( \
unsigned int __ret; \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) \
- __val = (typeof(__tmp->ptr))0; \
if (__recsize) \
__ret = __kfifo_out_r(__kfifo, __val, sizeof(*__val), \
__recsize); \
@@ -473,8 +465,6 @@ __kfifo_uint_must_check_helper( \
unsigned int __ret; \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) \
- __val = (typeof(__tmp->ptr))NULL; \
if (__recsize) \
__ret = __kfifo_out_peek_r(__kfifo, __val, sizeof(*__val), \
__recsize); \
@@ -512,10 +502,6 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
- __dummy = (typeof(__buf))NULL; \
- } \
(__recsize) ?\
__kfifo_in_r(__kfifo, __buf, __n, __recsize) : \
__kfifo_in(__kfifo, __buf, __n); \
@@ -565,10 +551,6 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
Re: [PATCH v2 0/5] staging/fwserial: Address reviewer comments
On Mon, 2013-01-07 at 15:22 -0800, Greg Kroah-Hartman wrote: > On Sat, Dec 15, 2012 at 01:03:14AM -0500, Peter Hurley wrote: > > Overdue respin. > > v2 changes: > >Don't use 'card' when referring to firewire node > >Removed lower clamp in link_speed_to_max_payload() > >Ripped out the bandwidth limit logic > >Drop suggestion to integrate link_speed_to_max_payload() > > & device_max_receive() > >Note required minimum max_rec value for OHCI-compliant devices > > Ugh, I applied the first version of this series, many apologies. Can > you send me follow-on patches with just the differences here? I saw that - no worries. I'll send follow-on patches today or tomorrow. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] libsrp: replace kfifo_init with kfifo_alloc
kfifo_init will use a pre-allocated buffer as fifo buffer; the buffer
size is determinted at caller side. While, kfifo will maintain a real
kfifo buffer size(rounddown power of 2 aligned). So, the two size may
not be equal.
So, if max is not power of 2, this code will not work. As it assume the
kfifo is able to hold max elments, but it is able to hold less than max
only.
To be safe, we should use kfifo_alloc instead, though it will not
address this issue. But a later patch to refactor kfifo_alloc to be a
log API will fix it.
Cc: James E.J. Bottomley
Cc: Stefani Seibold
Cc: Andrew Morton
Signed-off-by: Yuanhan Liu
---
drivers/scsi/libsrp.c | 22 ++
include/scsi/libsrp.h |1 -
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/libsrp.c b/drivers/scsi/libsrp.c
index 0707ecd..63db792 100644
--- a/drivers/scsi/libsrp.c
+++ b/drivers/scsi/libsrp.c
@@ -50,34 +50,32 @@ static int srp_iu_pool_alloc(struct srp_queue *q, size_t
max,
struct srp_buf **ring)
{
int i;
+ int ret;
struct iu_entry *iue;
- q->pool = kcalloc(max, sizeof(struct iu_entry *), GFP_KERNEL);
+ q->pool = kcalloc(max, sizeof(struct iu_entry), GFP_KERNEL);
if (!q->pool)
return -ENOMEM;
- q->items = kcalloc(max, sizeof(struct iu_entry), GFP_KERNEL);
- if (!q->items)
- goto free_pool;
+
+ ret = kfifo_alloc(>queue, max * sizeof(void *), GFP_KERNEL);
+ if (ret < 0) {
+ kfree(q->pool);
+ return ret;
+ }
spin_lock_init(>lock);
- kfifo_init(>queue, (void *) q->pool, max * sizeof(void *));
- for (i = 0, iue = q->items; i < max; i++) {
+ for (i = 0, iue = q->pool; i < max; i++) {
kfifo_in(>queue, (void *) , sizeof(void *));
iue->sbuf = ring[i];
iue++;
}
return 0;
-
- kfree(q->items);
-free_pool:
- kfree(q->pool);
- return -ENOMEM;
}
static void srp_iu_pool_free(struct srp_queue *q)
{
- kfree(q->items);
+ kfifo_free(>queue);
kfree(q->pool);
}
diff --git a/include/scsi/libsrp.h b/include/scsi/libsrp.h
index f4105c9..999b1e7 100644
--- a/include/scsi/libsrp.h
+++ b/include/scsi/libsrp.h
@@ -21,7 +21,6 @@ struct srp_buf {
struct srp_queue {
void *pool;
- void *items;
struct kfifo queue;
spinlock_t lock;
};
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] libiscsi: replace kfifo_init with kfifo_alloc
kfifo_init will use a pre-allocated buffer as fifo buffer; the buffer
size is determinted at caller side. While, kfifo will maintain a real
kfifo buffer size(rounddown power of 2 aligned). So, the two size may
not be equal.
So, if max is not power of 2, this code will not work. As it assume the
kfifo is able to hold max elments, but it is able to hold less than max
only.
To be safe, we should use kfifo_alloc instead, though it will not
address this issue. But a later patch to refactor kfifo_alloc to be a
log API will fix it.
Besides that, I refactored the code a bit with the style used in
libsrp.c: allocated items once by kcalloc.
Cc: Mike Christie
Cc: James E.J. Bottomley
Cc: iscsi list
Cc: Stefani Seibold
Cc: Andrew Morton
Signed-off-by: Yuanhan Liu
---
drivers/scsi/libiscsi.c | 59 ---
include/scsi/libiscsi.h |4 +-
2 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 82c3fd4..8e60f1f 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2485,51 +2485,52 @@ EXPORT_SYMBOL_GPL(iscsi_eh_recover_target);
int
iscsi_pool_init(struct iscsi_pool *q, int max, void ***items, int item_size)
{
- int i, num_arrays = 1;
-
- memset(q, 0, sizeof(*q));
+ int i;
+ int ret;
+ void *item;
- q->max = max;
+ ret = -ENOMEM;
+ q->pool = kcalloc(max, item_size, GFP_KERNEL);
+ if (!q->pool)
+ goto err_out;
- /* If the user passed an items pointer, he wants a copy of
-* the array. */
- if (items)
- num_arrays++;
- q->pool = kzalloc(num_arrays * max * sizeof(void*), GFP_KERNEL);
- if (q->pool == NULL)
- return -ENOMEM;
+ ret = kfifo_alloc(>queue, max * sizeof(void *), GFP_KERNEL);
+ if (ret < 0)
+ goto free_pool;
- kfifo_init(>queue, (void*)q->pool, max * sizeof(void*));
-
- for (i = 0; i < max; i++) {
- q->pool[i] = kzalloc(item_size, GFP_KERNEL);
- if (q->pool[i] == NULL) {
- q->max = i;
- goto enomem;
+ q->items_ptr = NULL;
+ /* If the user passed an items pointer, he wants a copy of the array */
+ if (items) {
+ q->items_ptr = kcalloc(max, sizeof(void *), GFP_KERNEL);
+ if (!q->items_ptr) {
+ ret = -ENOMEM;
+ goto free_fifo;
}
- kfifo_in(>queue, (void*)>pool[i], sizeof(void*));
+ *items = q->items_ptr;
}
- if (items) {
- *items = q->pool + max;
- memcpy(*items, q->pool, max * sizeof(void *));
+ for (i = 0, item = q->pool; i < max; i++, item += item_size) {
+ kfifo_in(>queue, , sizeof(void *));
+ if (q->items_ptr)
+ q->items_ptr[i] = item;
}
return 0;
-enomem:
- iscsi_pool_free(q);
- return -ENOMEM;
+free_fifo:
+ kfifo_free(>queue);
+free_pool:
+ kfree(q->pool);
+err_out:
+ return ret;
}
EXPORT_SYMBOL_GPL(iscsi_pool_init);
void iscsi_pool_free(struct iscsi_pool *q)
{
- int i;
-
- for (i = 0; i < q->max; i++)
- kfree(q->pool[i]);
kfree(q->pool);
+ kfree(q->items_ptr);
+ kfifo_free(>queue);
}
EXPORT_SYMBOL_GPL(iscsi_pool_free);
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 6e33386..c4262c6 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -231,8 +231,8 @@ struct iscsi_conn {
struct iscsi_pool {
struct kfifoqueue; /* FIFO Queue */
- void**pool; /* Pool of elements */
- int max;/* Max number of elements */
+ void*pool; /* Pool of elements */
+ void**items_ptr;/* element pointers */
};
/* Session's states */
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kfifo: log based kfifo API
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(_dev->notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(_dev->notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Cc: Stefani Seibold
Cc: Andrew Morton
Cc: linux-o...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: libertas-...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: open-is...@googlegroups.com
Cc: linux-s...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: linux-ser...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: d...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Signed-off-by: Yuanhan Liu
---
arch/arm/plat-omap/Kconfig |2 +-
arch/arm/plat-omap/mailbox.c|6 +++-
arch/powerpc/sysdev/fsl_rmu.c |2 +-
drivers/char/sonypi.c |9 ---
drivers/hid/hid-logitech-dj.c |7 +++--
drivers/iio/industrialio-event.c|2 +-
drivers/iio/kfifo_buf.c |3 +-
drivers/infiniband/hw/cxgb3/cxio_resource.c |8 --
drivers/media/i2c/cx25840/cx25840-ir.c |9 +--
drivers/media/pci/cx23885/cx23888-ir.c |9 +--
drivers/media/pci/meye/meye.c |6 +---
drivers/media/pci/meye/meye.h |2 +
drivers/media/rc/ir-raw.c |7 +++--
drivers/memstick/host/r592.h|2 +-
drivers/mmc/card/sdio_uart.c|4 ++-
drivers/mtd/sm_ftl.c|5 +++-
drivers/net/wireless/libertas/main.c|4 ++-
drivers/net/wireless/rt2x00/rt2x00dev.c |5 +--
drivers/pci/pcie/aer/aerdrv_core.c |3 +-
drivers/platform/x86/fujitsu-laptop.c |5 ++-
drivers/platform/x86/sony-laptop.c |6 ++--
drivers/rapidio/devices/tsi721.c|5 ++-
drivers/scsi/libiscsi_tcp.c |6 +++-
drivers/staging/omapdrm/omap_plane.c|5 +++-
drivers/tty/n_gsm.c |4 ++-
drivers/tty/nozomi.c|5 +--
drivers/tty/serial/ifx6x60.c|2 +-
drivers/tty/serial/ifx6x60.h|3 +-
drivers/tty/serial/kgdb_nmi.c |7 +++--
drivers/usb/host/fhci.h |4 ++-
drivers/usb/serial/cypress_m8.c |4 +-
drivers/usb/serial/io_ti.c |4 +-
drivers/usb/serial/ti_usb_3410_5052.c |7 +++--
drivers/usb/serial/usb-serial.c |2 +-
include/linux/kfifo.h | 31 +--
include/linux/rio.h |1 +
include/media/lirc_dev.h|4 ++-
kernel/kfifo.c |9 +--
mm/memory-failure.c |3 +-
net/dccp/probe.c|6 +++-
net/sctp/probe.c|6 +++-
samples/kfifo/bytestream-example.c |8 +++---
samples/kfifo/dma-example.c |5 ++-
samples/kfifo/inttype-example.c |7 +++--
samples/kfifo/record-example.c |6 ++--
45 files changed, 142 insertions(+), 108 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 665870d..7eda02c 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -124,7 +124,7 @@ config OMAP_MBOX_FWK
DSP, IVA1.0 and IVA2 in OMAP1/2/3.
config OMAP_MBOX_KFIFO_SIZE
- int "Mailbox kfifo default buffer size (bytes)"
+ int "Mailbox kfifo default buffer size (bytes, should be power of 2. If
not, will roundup to power of 2"
depends on
[PATCH 4/5] kfifo: remove kfifo_init
kfifo_init is buggy, we should never use that. Instead, we should use
kfifo_alloc.
Cc: Stefani Seibold
Cc: Andrew Morton
Signed-off-by: Yuanhan Liu
---
include/linux/kfifo.h | 27 ++-
kernel/kfifo.c| 23 ---
2 files changed, 2 insertions(+), 48 deletions(-)
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 7a18245..4bf984e 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -27,14 +27,14 @@
*
* - Modify the declaration of the "struct kfifo *" object into a
* in-place "struct kfifo" object
- * - Init the in-place object with kfifo_alloc() or kfifo_init()
+ * - Init the in-place object with kfifo_alloc()
* Note: The address of the in-place "struct kfifo" object must be
* passed as the first argument to this functions
* - Replace the use of __kfifo_put into kfifo_in and __kfifo_get
* into kfifo_out
* - Replace the use of kfifo_put into kfifo_in_spinlocked and kfifo_get
* into kfifo_out_spinlocked
- * Note: the spinlock pointer formerly passed to kfifo_init/kfifo_alloc
+ * Note: the spinlock pointer formerly passed to kfifo_alloc
* must be passed now to the kfifo_in_spinlocked and kfifo_out_spinlocked
* as the last parameter
* - The formerly __kfifo_* functions are renamed into kfifo_*
@@ -350,26 +350,6 @@ __kfifo_int_must_check_helper( \
})
/**
- * kfifo_init - initialize a fifo using a preallocated buffer
- * @fifo: the fifo to assign the buffer
- * @buffer: the preallocated buffer to be used
- * @size: the size of the internal buffer, this have to be a power of 2
- *
- * This macro initialize a fifo using a preallocated buffer.
- *
- * The numer of elements will be rounded-up to a power of 2.
- * Return 0 if no error, otherwise an error code.
- */
-#define kfifo_init(fifo, buffer, size) \
-({ \
- typeof((fifo) + 1) __tmp = (fifo); \
- struct __kfifo *__kfifo = &__tmp->kfifo; \
- __is_kfifo_ptr(__tmp) ? \
- __kfifo_init(__kfifo, buffer, size, sizeof(*__tmp->type)) : \
- -EINVAL; \
-})
-
-/**
* kfifo_put - put data into the fifo
* @fifo: address of the fifo to be used
* @val: the data to be added
@@ -770,9 +750,6 @@ extern int __kfifo_alloc(struct __kfifo *fifo, unsigned int
size,
extern void __kfifo_free(struct __kfifo *fifo);
-extern int __kfifo_init(struct __kfifo *fifo, void *buffer,
- unsigned int size, size_t esize);
-
extern unsigned int __kfifo_in(struct __kfifo *fifo,
const void *buf, unsigned int len);
diff --git a/kernel/kfifo.c b/kernel/kfifo.c
index 59dcf5b..d07f480 100644
--- a/kernel/kfifo.c
+++ b/kernel/kfifo.c
@@ -78,29 +78,6 @@ void __kfifo_free(struct __kfifo *fifo)
}
EXPORT_SYMBOL(__kfifo_free);
-int __kfifo_init(struct __kfifo *fifo, void *buffer,
- unsigned int size, size_t esize)
-{
- size /= esize;
-
- if (!is_power_of_2(size))
- size = rounddown_pow_of_two(size);
-
- fifo->in = 0;
- fifo->out = 0;
- fifo->esize = esize;
- fifo->data = buffer;
-
- if (size < 2) {
- fifo->mask = 0;
- return -EINVAL;
- }
- fifo->mask = size - 1;
-
- return 0;
-}
-EXPORT_SYMBOL(__kfifo_init);
-
static void kfifo_copy_in(struct __kfifo *fifo, const void *src,
unsigned int len, unsigned int off)
{
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] kfifo cleanup and log based kfifo API
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc/init. This may introduce
several potential issues.
First, the kfifo size is not what we want. Say, if we want to
allocate a kfifo with size of 127 elements. Then in the end, we can
only hold 64 elements. Here is a similar example at
drivers/hid/hid-logitech-dj.c:
if (kfifo_alloc(_dev->notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do something like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(_dev->notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Second, kfifo_init used a pre-allocated buffer, and the actual
buffer size is determined in caller side, while the actual kfifo
buffer size is maintained in kfifo_init, which will be rounded down
power of 2 without notifying to caller. Take the example of code at
drivers/scsi/libiscsi.c:
/* If the user passed an items pointer, he wants a copy of
* the array. */
if (items)
num_arrays++;
q->pool = kzalloc(num_arrays * max * sizeof(void*), GFP_KERNEL);
if (q->pool == NULL)
return -ENOMEM;
kfifo_init(>queue, (void*)q->pool, max * sizeof(void*));
for (i = 0; i < max; i++) {
q->pool[i] = kzalloc(item_size, GFP_KERNEL);
if (q->pool[i] == NULL) {
q->max = i;
goto enomem;
}
kfifo_in(>queue, (void*)>pool[i], sizeof(void*));
}
Assume max is not power of 2, this piece of code will not work! As
it assumes the kfifo will hold max elements, but actually it can
only hold rounddown_power_of_2(max).
My proposal is to replace kfifo_init with kfifo_alloc, where it
allocate buffer and maintain fifo size inside kfifo. Then we can
remove buggy kfifo_init.
After we change the kfifo_alloc to be a log API, all above issue
will be gone as said by Stefani.
Here is the patch summary:
patch 1 is a cleanup patch to cleanup the unneeded type check.
patch 2 and 3 turn the only 2 users of kfifo_init to kfifo_alloc
patch 4 remove kfifo_init
patch 5 log based kfifo API
Thanks!
--yliu
Cc: Stefani Seibold
Cc: Andrew Morton
Cc: James E.J. Bottomley
Cc: iscsi list
Cc: Mike Christie
---
Yuanhan Liu (5):
kfifo: remove unnecessary type check
libsrp: replace kfifo_init with kfifo_alloc
libiscsi: replace kfifo_init with kfifo_alloc
kfifo: remove kfifo_init
kfifo: log based kfifo API
arch/arm/plat-omap/Kconfig |2 +-
arch/arm/plat-omap/mailbox.c|6 +-
arch/powerpc/sysdev/fsl_rmu.c |2 +-
drivers/char/sonypi.c |9 ++-
drivers/hid/hid-logitech-dj.c |7 +-
drivers/iio/industrialio-event.c|2 +-
drivers/iio/kfifo_buf.c |3 +-
drivers/infiniband/hw/cxgb3/cxio_resource.c |8 ++-
drivers/media/i2c/cx25840/cx25840-ir.c |9 ++-
drivers/media/pci/cx23885/cx23888-ir.c |9 ++-
drivers/media/pci/meye/meye.c |6 +-
drivers/media/pci/meye/meye.h |2 +
drivers/media/rc/ir-raw.c |7 +-
drivers/memstick/host/r592.h|2 +-
drivers/mmc/card/sdio_uart.c|4 +-
drivers/mtd/sm_ftl.c|5 +-
drivers/net/wireless/libertas/main.c|4 +-
drivers/net/wireless/rt2x00/rt2x00dev.c |5 +-
drivers/pci/pcie/aer/aerdrv_core.c |3 +-
drivers/platform/x86/fujitsu-laptop.c |5 +-
drivers/platform/x86/sony-laptop.c |6 +-
drivers/rapidio/devices/tsi721.c|5 +-
drivers/scsi/libiscsi.c | 59
drivers/scsi/libiscsi_tcp.c |6 +-
drivers/scsi/libsrp.c | 22 +++---
drivers/staging/omapdrm/omap_plane.c|5 +-
drivers/tty/n_gsm.c |4 +-
drivers/tty/nozomi.c|5 +-
drivers/tty/serial/ifx6x60.c|2 +-
drivers/tty/serial/ifx6x60.h|3 +-
drivers/tty/serial/kgdb_nmi.c |7 +-
RE: [patch] bnx2x: NULL dereference on error in debug code
> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Dan Carpenter > Sent: Tuesday, January 08, 2013 3:42 PM > To: Eilon Greenstein > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel- > janit...@vger.kernel.org > Subject: [patch] bnx2x: NULL dereference on error in debug code > > "vfop" is NULL here. I've changed the debugging to not use it. > > Signed-off-by: Dan Carpenter > --- > Only needed in linux-next. > > diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > index 71fcef0..3eef972 100644 > --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > @@ -463,8 +463,7 @@ static int bnx2x_vfop_qdtor_cmd(struct bnx2x *bp, > return bnx2x_vfop_transition(bp, vf, bnx2x_vfop_qdtor, >cmd->block); > } > - DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop. rc %d\n", > -vf->abs_vfid, vfop->rc); > + DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop.\n", vf->abs_vfid); > return -ENOMEM; > } > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html And now acking it properly. Acked-by Ariel Elior -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] videobuf2-dma-contig: user can specify GFP flags
> Ok, then I would simply pass the flags from the driver without any > alternation > in the allocator itself, so drivers can pass 'GFP_KERNEL' or > 'GFP_KERNEL | GFP_DMA' depending on their preference. Please also update > all > the existing clients of vb2_dma_dc allocator. I taked a look at drivers that use dma-contig. They use the structure vb2_alloc_ctx which is just a name, there is not a real vb2_alloc_ctx structure implementation. "Now" driver must gain access to vb2_dc_conf to set the correct flags. I have the following ideas: 1. replace all the names and expose vb2_dc_conf to all drivers (like dma- sg, it export vb2_dma_sg_desc to all its users) 2. create an helper which configure flags. This maintain the vb2_dc_conf private vb2_set_mem_flags(struct vb2_alloc_ctx *alloc_ctx, gfp_t flags) 3. rename vb2_dc_conf to vb2_alloc_ctx because it is an implementation vb2_alloc_ctx and (at the moment) it is used only by dma-contig -- Federico Vaga -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Consult] our latest kernel and latest Android under arm Samsung S5PV210 with yaffs2 file system
On Tue, Jan 08, 2013 at 06:25:06PM +0800, Chen Gang F T wrote: > use yaffs2 file system for android > it seems yaffs2 is a standard file system for android. > for my android HTC phone is also yaffs2 file system. yaffs2 is not a _standard_ file system for Android. There may be some phones which use it, but the much more common is either FAT (for the older phones) or ext4. The Google AOSP releases for pretty much all modern Nexus phones (Galaxy Nexus and newer if I recall correctly, certainly for GN, N4, N7, etc.) all use ext4. > current: > I am trying to use our latest kernel (such as next-20130104) > can compile from the source code successfully. > it has no source code for yaffs2 file system. So if your existing Android device is using yaffs2, you'll need to integrate yaffs2, since yaff2 is not in the upstream kernel. As far as hardware support, it will depend on the specifics of your development board, and I'm not enough of an ARM expert to answer that question. Others hopefully on this list will be able to answer it. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] bnx2x: NULL dereference on error in debug code
> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Dan Carpenter > Sent: Tuesday, January 08, 2013 3:42 PM > To: Eilon Greenstein > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel- > janit...@vger.kernel.org > Subject: [patch] bnx2x: NULL dereference on error in debug code > > "vfop" is NULL here. I've changed the debugging to not use it. > > Signed-off-by: Dan Carpenter > --- > Only needed in linux-next. > > diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > index 71fcef0..3eef972 100644 > --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c > @@ -463,8 +463,7 @@ static int bnx2x_vfop_qdtor_cmd(struct bnx2x *bp, > return bnx2x_vfop_transition(bp, vf, bnx2x_vfop_qdtor, >cmd->block); > } > - DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop. rc %d\n", > -vf->abs_vfid, vfop->rc); > + DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop.\n", vf->abs_vfid); > return -ENOMEM; > } > Right you are. Ack. Thanks Dan, Ariel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sunrpc: verbs: Avoid 1kb stack
On Mon, Jan 07, 2013 at 11:41:36AM -0800, Joe Perches wrote: > 16 * 64 is a bit much. > Use kmalloc_array instead. I thought there was some reason we didn't do this. Grepping up through the callers It looks like the result is xprt_rdma_send_request returns -EIO, and as far as I can tell that gets passed up to the application on the client. That doesn't sound right. --b. > > Signed-off-by: Joe Perches > --- > net/sunrpc/xprtrdma/verbs.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c > index 745973b..9cfebb4 100644 > --- a/net/sunrpc/xprtrdma/verbs.c > +++ b/net/sunrpc/xprtrdma/verbs.c > @@ -1736,8 +1736,13 @@ rpcrdma_register_default_external(struct > rpcrdma_mr_seg *seg, > int mem_priv = (writing ? IB_ACCESS_REMOTE_WRITE : > IB_ACCESS_REMOTE_READ); > struct rpcrdma_mr_seg *seg1 = seg; > - struct ib_phys_buf ipb[RPCRDMA_MAX_DATA_SEGS]; > int len, i, rc = 0; > + struct ib_phys_buf *ipb = kmalloc_array(RPCRDMA_MAX_DATA_SEGS, > + sizeof(*ipb), > + GFP_KERNEL); > + > + if (!ipb) > + return -ENOMEM; > > if (*nsegs > RPCRDMA_MAX_DATA_SEGS) > *nsegs = RPCRDMA_MAX_DATA_SEGS; > @@ -1770,6 +1775,9 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg > *seg, > seg1->mr_len = len; > } > *nsegs = i; > + > + kfree(ipb); > + > return rc; > } > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers: i2c: muxes: fix sizeof(ptr)
This is not really a bug as mux->busses is a multilevel pointer, so
the result of sizeof(ptr) is the same as sizeof(*ptr).
But I think this is more logical and according to CodingStyle rules like this.
This is also what is done for mux->states a few lines above.
Regards,
2013/1/8, Laurent Navet :
> sizeof when applied to a pointer typed expression gives the size of
> the pointer
>
> The semantic patch that makes this output is available
> in scripts/coccinelle/misc/noderef.cocci.
>
> More information about semantic patching is available at
> http://coccinelle.lip6.fr/
>
> Signed-off-by: Laurent Navet
> ---
> drivers/i2c/muxes/i2c-mux-pinctrl.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c
> b/drivers/i2c/muxes/i2c-mux-pinctrl.c
> index 7fa5b24..f958d0f 100644
> --- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
> +++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
> @@ -167,7 +167,7 @@ static int __devinit i2c_mux_pinctrl_probe(struct
> platform_device *pdev)
> }
>
> mux->busses = devm_kzalloc(>dev,
> -sizeof(mux->busses) * mux->pdata->bus_count,
> +sizeof(*mux->busses) * mux->pdata->bus_count,
> GFP_KERNEL);
> if (!mux->busses) {
> dev_err(>dev, "Cannot allocate busses\n");
> --
> 1.7.10.4
>
>
--
« On ne résout pas un problème avec les modes de pensée qui l’ont engendré. »
« You cannot solve current problems with current thinking. Current
problems are the result of current thinking »
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 UPDATED 15/24] cfq-iosched: enable full blkcg hierarchy support
On Mon, Jan 07, 2013 at 08:34:05AM -0800, Tejun Heo wrote: [..] > +weight leaf_weight > + root : 125125 > + A: 500750 > + B: 250500 > + AA : 500500 > + AB : 1000500 > + > +root never has a parent making its weight is meaningless. For backward > +compatibility, weight is always kept in sync with leaf_weight. B, AA > +and AB have no child and thus its tasks have no children cgroup to > +compete with. They always get 100% of what the cgroup won at the > +parent level. Considering only the weights which matter, the hierarchy > +looks like the following. > + > + root > + /| \ > + A Bleaf > + 500 250 125 > + / | \ > + AA AB leaf > + 500 1000 750 > + > +If all cgroups have active IOs and competing with each other, disk > +time will be distributed like the following. > + > +Distribution below root. The total active weight at this level is > +A:500 + B:250 + C:125 = 875. > + > + root-leaf : 125 / 875 =~ 14% > + A : 500 / 875 =~ 57% > + B(-leaf) : 250 / 875 =~ 28% > + > +A has children and further distributes its 57% among the children and > +the implicit leaf node. The total active weight at this level is > +AA:500 + AB:1000 + A-leaf:750 = 2250. > + > + A-leaf: ( 750 / 2250) * A =~ 19% > + AA(-leaf) : ( 500 / 2250) * A =~ 12% > + AB(-leaf) : (1000 / 2250) * A =~ 25% Hi Tejun, What does (-leaf) is supposed to signify? I can understand that A-leaf tells the share of A's tasks which are effectively in A-leaf group. Will just plain AA and AB be more clear? Rest looks good to me. Thanks for updating the blkio-controoler.txt too. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
At Tue, 08 Jan 2013 15:32:13 +0100, David Henningsson wrote: > > On 01/08/2013 01:56 PM, Takashi Iwai wrote: > >> I'll test with enable_msi=0 later. > > > > Thanks. > > > > FWIW, below is a patch I'm considering to merge (after testing, of > > course). Could you buys check it? > > > > > > Takashi > > > > --- > > From: Takashi Iwai > > Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT & co > > For reference, I'm seeing some of this too, and have asked for people to > test with enable_msi=0 and/or power_save_controller=0. I'm waiting for > replies from people with the hardware. OK, good to know! So far, I disabled the runtime PM up to PantherPoint in the patch. LynxPoint, Haswell and 3400 are still with runtime PM, as these were the platforms mostly tested for the feature. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: i2c: muxes: fix sizeof(ptr)
sizeof when applied to a pointer typed expression gives the size of
the pointer
The semantic patch that makes this output is available
in scripts/coccinelle/misc/noderef.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Laurent Navet
---
drivers/i2c/muxes/i2c-mux-pinctrl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c
b/drivers/i2c/muxes/i2c-mux-pinctrl.c
index 7fa5b24..f958d0f 100644
--- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
+++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
@@ -167,7 +167,7 @@ static int __devinit i2c_mux_pinctrl_probe(struct
platform_device *pdev)
}
mux->busses = devm_kzalloc(>dev,
- sizeof(mux->busses) * mux->pdata->bus_count,
+ sizeof(*mux->busses) * mux->pdata->bus_count,
GFP_KERNEL);
if (!mux->busses) {
dev_err(>dev, "Cannot allocate busses\n");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Sun, Jan 06, 2013 at 07:06:52PM +0100, Daniel Vetter wrote: > On Thu, Jan 03, 2013 at 06:11:23PM -0500, J. Bruce Fields wrote: > > On Thu, Jan 03, 2013 at 04:16:24PM -0500, Josh Boyer wrote: > > > On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields > > > wrote: > > > > I got a crash after a few minutes of running 3.8.0-rc2, was able to > > > > switch to a vt and look at dmesg: > > > > > > > > [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > > > elapsed... GPU hung > > > > [ 490.963019] [drm] capturing error event; look for more information > > > > in /debug/dri/0/i915_error_state > > > > [ 492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > > > elapsed... GPU hung > > > > [ 492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, > > > > declaring wedged! > > > > [ 492.965621] [drm:i915_reset] *ERROR* Failed to reset chip. > > > > > > > > Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such > > > > problem. > > > > > > I'm not questioning that you haven't seen that error in F17, but we have > > > had quite a few bug reports with similar error messages for a while now. > > > Apparently there are lots of ways GPUs can get hung, so they might be > > > different from what you're seeing. Just wanted to point out that it > > > might not be a new 3.8 change that caused it. > > > > OK, sure. It reproduced very quickly after the upgrade, so I assumed it > > was a regression. > > > > I'm running 3.7.0 now which hasn't shown any problem. > > > > I'll try a newer kernel again to see if it's really that easy for me to > > reproduce. > > If you hit this again (even better if you have a way to reproduce) Unfortunately I wasn't able to reproduce after working a couple more hours on 3.8 again. However: > please grab the i915_error_state file from debugfs As I said in the original mail, I've already done that: http://fieldses.org/~bfields/3.8-hang/ > and file a bug on > bugs.freedesktop.org against DRM - DRI (Intel). Would it still be useful for me to file a bug? (Just going through the new-account confirmation dance now.) --b. > We do know of a few recent > issues introduced around 3.7 kernels, preliminary patches are floating > around. The error state should be good enough to decide whether you're > hitting the same issues. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at kernel/sched_rt.c:493!
> > I've also managed to reproduce this on 3.8.0-rc2 so it appears the bug > is still present in the latest kernel. Shawn, Can you send me your .config file. Thanks, -- 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/
[PATCH] PCI: Make pci_find_upstream_pcie_bridge() handle non PCIE VFs well
pci_find_upstream_pcie_bridge() doesn't handle well non PCIE VFs
that are part of a PCIE PF device.
Signed-off-by: Tadeusz Struk
---
drivers/pci/search.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index bf969ba..8ecdab2 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -23,6 +23,8 @@ EXPORT_SYMBOL_GPL(pci_bus_sem);
* if the device isn't connected to a PCIe bridge (that is its parent is a
* legacy PCI bridge and the bridge is directly connected to bus 0), return its
* parent
+ * if the device is a VF that doesn't have PCIe cap,
+ * but the PF is a PCIE, return NULL
*/
struct pci_dev *
pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
@@ -31,6 +33,10 @@ pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
if (pci_is_pcie(pdev))
return NULL;
+
+ if (pdev->is_virtfn && pci_is_pcie(pdev->physfn))
+ return NULL;
+
while (1) {
if (pci_is_root_bus(pdev->bus))
break;
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
On 01/08/2013 01:56 PM, Takashi Iwai wrote: I'll test with enable_msi=0 later. Thanks. FWIW, below is a patch I'm considering to merge (after testing, of course). Could you buys check it? Takashi --- From: Takashi Iwai Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT & co For reference, I'm seeing some of this too, and have asked for people to test with enable_msi=0 and/or power_save_controller=0. I'm waiting for replies from people with the hardware. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator
On Tue, 08 Jan 2013 07:50:41 +0100 Marek Szyprowski wrote: > > Couldn't this performance difference be due to the usage of GFP_DMA inside > > the VB2 code, like Federico's new patch series is proposing? > > > > If not, why are there a so large performance penalty? > > Nope, this was caused rather by a very poor CPU access to non-cached (aka > 'coherent') memory and the way the video data has been accessed/read > with CPU. Exactly. Uncached memory *hurts*, especially if you're having to touch it all with the CPU. jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/25] ab8500_charger: don't use [delayed_]work_pending()
On Sat, Dec 22, 2012 at 2:56 AM, Tejun Heo wrote: > There's no need to test whether a (delayed) work item in pending > before queueing, flushing or cancelling it. Most uses are unnecessary > and quite a few of them are buggy. > > Remove unnecessary pending tests from ab8500_charger. Only compile > tested. > > Signed-off-by: Tejun Heo > Cc: Srinidhi Kasagar > Cc: Linus Walleij Works like a charm for us, thanks! Reviewed-by: Linus Walleij Tested-by: Marcus Cooper Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/6] uprobes: add bp_vaddr argument to consumer handler
On Sun, Dec 23, 2012 at 04:49:10PM +0100, Oleg Nesterov wrote:
> On 12/22, Oleg Nesterov wrote:
> >
> > Forgot to ask...
> >
> > On 12/22, Oleg Nesterov wrote:
> > >
> > > On 12/21, Anton Arapov wrote:
> > > >
> > > > struct uprobe_consumer {
> > > > - int (*handler)(struct uprobe_consumer *self, struct pt_regs
> > > > *regs);
> > > > + int (*handler)(struct uprobe_consumer *self, unsigned long
> > > > bp_vaddr, struct pt_regs *regs);
> > >
> > > It seems that we can do better...
> > >
> > > Just change regs->ip before calling ->handler().
> >
> > Josh, Frank, will it work for you?
>
> Wait, probably I was confused by this patch and 4/6...
>
> To simplify, lets ignore the normal uprobes. Yes I still think that it
> would be better to set "regs->ip = orig_return_vaddr" before calling
> ->handler() and not pass it as an argument.
>
> But, probably uprobe_consumer also needs to know bp_vaddr? IOW, the
> address of the function which we are going to return from? In this case,
> yes, we also need another argument. And prepare_uretprobe/etc should
> be changed to record bp_vaddr passed from handle_swbp(). And
> uretprobe_run_handlers() should pass this bp_vaddr, not orig_return_vaddr.
>
> Or I am confused.
>
> Anton?
Oleg, you are absolutely right and change the ip before calling the
->handle is much better then what I 'invented'.
I'm working on v2 to address this and other issues, will post it soon.
Anton.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/22] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
On 01/07/2013 02:31 AM, Linus Torvalds wrote:
> On Sat, Jan 5, 2013 at 11:54 PM, Alex Shi wrote:
>>
>> I just looked into the aim9 benchmark, in this case it forks 2000 tasks,
>> after all tasks ready, aim9 give a signal than all tasks burst waking up
>> and run until all finished.
>> Since each of tasks are finished very quickly, a imbalanced empty cpu
>> may goes to sleep till a regular balancing give it some new tasks. That
>> causes the performance dropping. cause more idle entering.
>
> Sounds like for AIM (and possibly for other really bursty loads), we
> might want to do some load-balancing at wakeup time by *just* looking
> at the number of running tasks, rather than at the load average. Hmm?
Millions thanks for your suggestions! :)
It's worth to try use instant load -- nr_running in waking balancing, I
will try this. but in this case, I tried to print sleeping tasks by
print_task() in sched/debug.c. Find the 2000 tasks were forked on just 2
LCPUs which in different cpu sockets whenever with/without this load avg
patch.
So, I am wondering if it's worth to consider the sleeping tasks' load in
fork/wake balancing. Does anyone consider this in history?
===
print_task(struct seq_file *m, struct rq *rq, struct task_struct *p)
{
if (rq->curr == p)
SEQ_printf(m, "R");
+ else if (!p->on_rq)
+ SEQ_printf(m, "S");
else
SEQ_printf(m, " ");
...
@@ -166,13 +170,14 @@ static void print_rq(struct seq_file *m, struct rq
*rq, int rq_cpu)
read_lock_irqsave(_lock, flags);
do_each_thread(g, p) {
- if (!p->on_rq || task_cpu(p) != rq_cpu)
+ if (task_cpu(p) != rq_cpu)
continue;
===
>
> The load average is fundamentally always going to run behind a bit,
> and while you want to use it for long-term balancing, a short-term you
> might want to do just a "if we have a huge amount of runnable
> processes, do a load balancing *now*". Where "huge amount" should
> probably be relative to the long-term load balancing (ie comparing the
> number of runnable processes on this CPU right *now* with the load
> average over the last second or so would show a clear spike, and a
> reason for quick action).
Many thanks for suggestion!
Will try it. :)
>
>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: [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le mardi 08 janvier 2013 à 13:56 +0100, Takashi Iwai a écrit :
> At Tue, 08 Jan 2013 13:28:55 +0100,
> Vincent Blut wrote:
> >
> > Le lundi 07 janvier 2013 à 09:32 +0100, Takashi Iwai a écrit :
> > > At Sat, 05 Jan 2013 22:24:03 +0100,
> > >
> > > One more thing to test is whether azx_runtime_resume() is properly
> > > called before this error happens. Could you put a debug print and
> > > check it? If it's not called, it implies that the refcount or
> > > something else got broken. If it's called but the device doesn't
> > > respond, it's a hardware-specific issue, and the likely solution is to
> > > add a device-specific quirk.
> > >
> >
> > Ok, I added a debug printk() which is called:
> >
> > $ dmesg | grep -i debug
> > [ 5330.371523] [debug] Probably needs a device-specific quirk!
> >
> > As usual, when it is called the sound become very choppy.
>
> OK. So it's not the driver code but really a problem in the deeper
> level.
Sad, by the way I'm puzzled due to the fact that nobody hit this issue,
those audio controllers are quite common, no?
>
> > I'll test with enable_msi=0 later.
>
> Thanks.
There isn't any positive effect with this parameter.
>
> FWIW, below is a patch I'm considering to merge (after testing, of
> course). Could you buys check it?
I'll give it a try.
>
>
> Takashi
>
> ---
> From: Takashi Iwai
> Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT & co
>
> We've got a few bug reports that the runtime D3 results in the dead
> HD-audio controller. It seems that the problem is in a deeper level
> than the sound driver itself, so as a temporal solution, disable the
> feature for these controllers again.
>
> Reported-by: Vincent Blut
> Reported-by: Maurizio Avogadro
> Cc: [v3.7]
> Signed-off-by: Takashi Iwai
> ---
> sound/pci/hda/hda_intel.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index cca8727..0b6aeba 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -573,9 +573,12 @@ enum {
> #define AZX_DCAPS_PM_RUNTIME (1 << 26) /* runtime PM support */
>
> /* quirks for Intel PCH */
> -#define AZX_DCAPS_INTEL_PCH \
> +#define AZX_DCAPS_INTEL_PCH_NOPM \
> (AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE | \
> - AZX_DCAPS_COUNT_LPIB_DELAY | AZX_DCAPS_PM_RUNTIME)
> + AZX_DCAPS_COUNT_LPIB_DELAY)
> +
> +#define AZX_DCAPS_INTEL_PCH \
> + (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME)
>
> /* quirks for ATI SB / AMD Hudson */
> #define AZX_DCAPS_PRESET_ATI_SB \
> @@ -3586,13 +3589,13 @@ static void azx_remove(struct pci_dev *pci)
> static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
> /* CPT */
> { PCI_DEVICE(0x8086, 0x1c20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* PBG */
> { PCI_DEVICE(0x8086, 0x1d20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* Panther Point */
> { PCI_DEVICE(0x8086, 0x1e20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* Lynx Point */
> { PCI_DEVICE(0x8086, 0x8c20),
> .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools/perf: let it build from perf-*-src-pkg
Thanks (mostly) to uapi the package created from perf-*-src-pkg FTBFS: |CC perf.o |In file included from util/../perf.h:8:0, | from util/cache.h:7, | from perf.c:12: |arch/x86/include/asm/unistd.h:4:29: fatal error: uapi/asm/unistd.h: No such file or directory | |CC perf.o |In file included from util/../perf.h:106:0, | from util/cache.h:7, | from perf.c:12: |include/linux/perf_event.h:17:35: fatal error: uapi/linux/perf_event.h: No such file or directory | |CC perf.o |In file included from include/uapi/linux/perf_event.h:19:0, | from util/../perf.h:106, | from util/cache.h:7, | from perf.c:12: |util/include/asm/byteorder.h:2:49: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory | |CC perf.o |In file included from util/include/../../../../include/linux/list.h:7:0, | from util/include/linux/list.h:4, | from util/parse-events.h:7, | from perf.c:15: |util/include/linux/const.h:1:50: fatal error: ../../../../include/uapi/linux/const.h: No such file or directory | |In file included from builtin-kvm.c:26:0: |arch/x86/include/asm/svm.h:4:26: fatal error: uapi/asm/svm.h: No such file or directory | |In file included from util/evsel.c:21:0: |include/linux/hw_breakpoint.h:5:38: fatal error: uapi/linux/hw_breakpoint.h: No such file or directory | |CC util/evsel.o |In file included from util/perf_regs.h:5:0, | from util/evsel.c:23: |arch/x86/include/perf_regs.h:6:27: fatal error: asm/perf_regs.h: No such file or directory | | CC util/rbtree.o |In file included from ../../lib/rbtree.c:24:0: |util/include/linux/rbtree_augmented.h:2:56: fatal error: ../../../../include/linux/rbtree_augmented.h: No such file or directory This patch adds the missing files. Signed-off-by: Sebastian Andrzej Siewior --- sort tools/perf/MANIFEST > MANIFEST && mv MANIFEST tools/perf/MANIFEST ? tools/perf/MANIFEST | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/perf/MANIFEST b/tools/perf/MANIFEST index 80db3f4..39d4106 100644 --- a/tools/perf/MANIFEST +++ b/tools/perf/MANIFEST @@ -11,11 +11,21 @@ lib/rbtree.c include/linux/swab.h arch/*/include/asm/unistd*.h arch/*/include/asm/perf_regs.h +arch/*/include/uapi/asm/unistd*.h +arch/*/include/uapi/asm/perf_regs.h arch/*/lib/memcpy*.S arch/*/lib/memset*.S include/linux/poison.h include/linux/magic.h include/linux/hw_breakpoint.h +include/linux/rbtree_augmented.h +include/uapi/linux/perf_event.h +include/uapi/linux/const.h +include/uapi/linux/swab.h +include/uapi/linux/hw_breakpoint.h arch/x86/include/asm/svm.h arch/x86/include/asm/vmx.h arch/x86/include/asm/kvm_host.h +arch/x86/include/uapi/asm/svm.h +arch/x86/include/uapi/asm/vmx.h +arch/x86/include/uapi/asm/kvm.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched: Consequences of integrating the Per Entity Load Tracking Metric into the Load Balancer
On 8 January 2013 07:06, Preeti U Murthy wrote: > On 01/07/2013 09:18 PM, Vincent Guittot wrote: >> On 2 January 2013 05:22, Preeti U Murthy wrote: >>> Hi everyone, >>> I have been looking at how different workloads react when the per entity >>> load tracking metric is integrated into the load balancer and what are >>> the possible reasons for it. >>> >>> I had posted the integration patch earlier: >>> https://lkml.org/lkml/2012/11/15/391 >>> >>> Essentially what I am doing is: >>> 1.I have disabled CONFIG_FAIR_GROUP_SCHED to make the analysis simple >>> 2.I have replaced cfs_rq->load.weight in weighted_cpuload() with >>> cfs.runnable_load_avg,the active load tracking metric. >>> 3.I have replaced se.load.weight in task_h_load() with >>> se.load.avg.contrib,the per entity load tracking metric. >>> 4.The load balancer will end up using these metrics. >>> >>> After conducting experiments on several workloads I found out that the >>> performance of the workloads with the above integration would neither >>> improve nor deteriorate.And this observation was consistent. >>> >>> Ideally the performance should have improved considering,that the metric >>> does better tracking of load. >>> >>> Let me explain with a simple example as to why we should see a >>> performance improvement ideally:Consider 2 80% tasks and 1 40% task. >>> >>> With integration: >>> >>> >>>40% >>> 80%40% >>> cpu1 cpu2 >>> >>> The above will be the scenario when the tasks fork initially.And this is >>> a perfectly balanced system,hence no more load balancing.And proper >>> distribution of loads on the cpu. >>> >>> Without integration >>> --- >>> >>> 40% 40% >>> 80%40% 80%40% >>> cpu1 cpu2OR cpu1 cpu2 >>> >>> Because the view is that all the tasks as having the same load.The load >>> balancer could ping pong tasks between these two situations. >>> >>> When I performed this experiment,I did not see an improvement in the >>> performance though in the former case.On further observation I found >>> that the following was actually happening. >>> >>> With integration >>> >>> >>> Initially 40% task sleeps 40% task wakes up >>>and select_idle_sibling() >>>decides to wake it up on cpu1 >>> >>>40% -> -> 40% >>> 80%40%80%40% 80% 40% >>> cpu1 cpu2cpu1 cpu2 cpu1 cpu2 >>> >>> >>> This makes load balance trigger movement of 40% from cpu1 back to >>> cpu2.Hence the stability that the load balancer was trying to achieve is >>> gone.Hence the culprit boils down to select_idle_sibling.How is it the >>> culprit and how is it hindering performance of the workloads? >>> >>> *What is the way ahead with the per entity load tracking metric in the >>> load balancer then?* >>> >>> In replies to a post by Paul in https://lkml.org/lkml/2012/12/6/105, >>> he mentions the following: >>> >>> "It is my intuition that the greatest carnage here is actually caused >>> by wake-up load-balancing getting in the way of periodic in >>> establishing a steady state. I suspect more mileage would result from >>> reducing the interference wake-up load-balancing has with steady >>> state." >>> >>> "The whole point of using blocked load is so that you can converge on a >>> steady state where you don't NEED to move tasks. What disrupts this is >>> we naturally prefer idle cpus on wake-up balance to reduce wake-up >>> latency. I think the better answer is making these two processes load >>> balancing() and select_idle_sibling() more co-operative." >>> >>> I had not realised how this would happen until I saw it happening in the >>> above experiment. >>> >>> Based on what Paul explained above let us use the runnable load + the >>> blocked load for calculating the load on a cfs runqueue rather than just >>> the runnable load(which is what i am doing now) and see its consequence. >>> >>> Initially: 40% task sleeps >>> >>>40% >>> 80%40% -> 80% 40% >>> cpu1 cpu2 cpu1 cpu2 >>> >>> So initially the load on cpu1 is say 80 and on cpu2 also it is >>> 80.Balanced.Now when 40% task sleeps,the total load on cpu2=runnable >>> load+blocked load.which is still 80. >>> >>> As a consequence,firstly,during periodic load balancing the load is not >>> moved from cpu1 to cpu2 when the 40% task sleeps.(It sees the load on >>> cpu2 as 80 and not as 40). >>> Hence the above scenario remains the same.On wake up,what happens? >>> >>> Here comes the point of making both load balancing and wake up >>> balance(select_idle_sibling) co operative. How about we always schedule >>> the woken up task on the prev_cpu? This seems more sensible considering >>> load balancing considers blocked load as being a part of the load of cpu2. >> >> Hi Preeti, >> >> I'm not sure that we want such steady
Re: [PATCH] perf bench: Flush stdout before starting bench suite
At Tue, 8 Jan 2013 18:39:26 +0900,
Namhyung Kim wrote:
>
> From: Namhyung Kim
>
> perf bench prints header message for bench suite before starting the
> benchmark. However if the stdout is redirected to a file and bench
> suite forks child processes this (and possibly other debugging
> messages too) will be repeated multiple times.
>
> $ perf bench sched messaging
> # Running sched/messaging benchmark...
> # 20 sender and receiver processes per group
> # 10 groups == 400 processes run
>
>Total time: 0.100 [sec]
>
> $ perf bench sched messaging > result.txt
> $ wc -l result.txt
> 391
>
> In this file, there were so many "Running sched/messaging benchmark..."
> lines. This was because stdout is converted to fully-buffered due to
> the redirection and inherited child processes. Other lines are printed
> after reaping all those tasks.
>
> So fix it by flushing stdout before starting bench suites.
Thanks a lot, I couldn't notice this problem.
Acked-by: Hitoshi Mitake
>
> Cc: Hitoshi Mitake
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/builtin-bench.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/perf/builtin-bench.c b/tools/perf/builtin-bench.c
> index cae9a5fd2ecf..afd1255a632f 100644
> --- a/tools/perf/builtin-bench.c
> +++ b/tools/perf/builtin-bench.c
> @@ -159,6 +159,7 @@ static void all_suite(struct bench_subsys *subsys)
> /* FROM HERE */
> printf("# Running %s/%s benchmark...\n",
> subsys->name,
> suites[i].name);
> + fflush(stdout);
>
> argv[1] = suites[i].name;
> suites[i].fn(1, argv, NULL);
> @@ -225,6 +226,7 @@ int cmd_bench(int argc, const char **argv, const char
> *prefix __maybe_unused)
> printf("# Running %s/%s benchmark...\n",
> subsystems[i].name,
> subsystems[i].suites[j].name);
> + fflush(stdout);
> status = subsystems[i].suites[j].fn(argc - 1,
> argv + 1, prefix);
> goto end;
> --
> 1.7.11.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: i2c-hid: add ACPI support
Hi Mika,
On Tue, Jan 8, 2013 at 2:05 PM, Mika Westerberg
wrote:
> The HID over I2C protocol specification states that when the device is
> enumerated from ACPI the HID descriptor address can be obtained by
> executing "_DSM" for the device with function 1. Enable this.
Hehe, funny thing, I worked on the very same patch last Friday. I was
not able to send it upstream as I still don't have an ACPI 5 enabled
device...
So thanks for submitting (and testing) this!
Before the review, I just have a quick question. All the HID/i2c
devices I saw so far present a reset line (through a GPIO). Does the
shipped device you have present this line, and if yes, how this meld
with the code (i.e. should we take this into account).
Please note that I can only compare this to my patch, based on the
DSDT example Microsoft gave in its spec. So sorry if I'm asking
useless things, but I like to understand... :)
Here are a few comments:
>
> Signed-off-by: Mika Westerberg
> ---
> drivers/hid/i2c-hid/i2c-hid.c | 73
> +++--
> 1 file changed, 71 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 9ef22244..b2eebb6 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -810,6 +811,70 @@ static int __devinit i2c_hid_fetch_hid_descriptor(struct
> i2c_hid *ihid)
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static struct i2c_hid_platform_data *
> +i2c_hid_acpi_pdata(struct i2c_client *client)
> +{
> + static u8 i2c_hid_guid[] = {
> + 0xF7, 0xF6, 0xDF, 0x3C, 0x67, 0x42, 0x55, 0x45,
> + 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE,
> + };
> + struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
> + struct i2c_hid_platform_data *pdata = NULL;
> + union acpi_object params[4], *obj;
> + struct acpi_object_list input;
> + struct acpi_device *adev;
> + acpi_handle handle;
> +
> + handle = ACPI_HANDLE(>dev);
> + if (!handle || acpi_bus_get_device(handle, ))
> + return NULL;
> +
> + input.count = ARRAY_SIZE(params);
> + input.pointer = params;
> +
> + params[0].type = ACPI_TYPE_BUFFER;
> + params[0].buffer.length = sizeof(i2c_hid_guid);
> + params[0].buffer.pointer = i2c_hid_guid;
> + params[1].type = ACPI_TYPE_INTEGER;
> + params[1].integer.value = 1;
Can you confirm that any value here is ok (this is what I read from
the DSDT example Microsoft gave, Arg1 is not used).
> + params[2].type = ACPI_TYPE_INTEGER;
> + params[2].integer.value = 1; /* HID function */
> + params[3].type = ACPI_TYPE_INTEGER;
> + params[3].integer.value = 0;
Again, the DSDT example showed that no Arg3 was used... But again, I
never wrote ACPI driver, so I may be wrong.
> +
> + if (ACPI_FAILURE(acpi_evaluate_object(handle, "_DSM", , )))
> + return NULL;
As you are returning NULL here, the error that will be raised is
-EINVAL. I think it should be -ENODEV in this case. I have no strong
opinion on this, but this can be achieved by returning the error from
the function, and the returned i2c_hid_platform_data as an argument.
Or maybe just an error message will be sufficient.
> +
> + obj = (union acpi_object *)buf.pointer;
> + if (obj->type != ACPI_TYPE_INTEGER)
> + goto fail;
Again, I would like to know what happened here in case of a failure.
So an error message would be good.
> +
> + pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + goto fail;
idem (and returning -ENOMEM would be better IMHO).
> +
> + pdata->hid_descriptor_address = obj->integer.value;
> +
> +fail:
> + kfree(buf.pointer);
> + return pdata;
> +}
> +
> +static struct acpi_device_id i2c_hid_acpi_match[] = {
> + {"ACPI0C50", 0 },
I never saw this _CID/_HID. Just out of curiosity, is this a
standardized _CID or is it a _HID specific to a device?
> + {"PNP0C50", 0 },
> + { },
> +};
> +MODULE_DEVICE_TABLE(acpi, i2c_hid_acpi_match);
> +#else
> +static inline struct i2c_hid_platform_data *
> +i2c_hid_acpi_pdata(struct i2c_client *client)
> +{
> + return NULL;
> +}
> +#endif
> +
> static int __devinit i2c_hid_probe(struct i2c_client *client,
> const struct i2c_device_id *dev_id)
> {
> @@ -822,8 +887,11 @@ static int __devinit i2c_hid_probe(struct i2c_client
> *client,
> dbg_hid("HID probe called for i2c 0x%02x\n", client->addr);
>
> if (!platform_data) {
> - dev_err(>dev, "HID register address not provided\n");
> - return -EINVAL;
> + platform_data = i2c_hid_acpi_pdata(client);
> + if (!platform_data) {
> + dev_err(>dev, "HID register address not
>
[patch] bnx2x: NULL dereference on error in debug code
"vfop" is NULL here. I've changed the debugging to not use it. Signed-off-by: Dan Carpenter --- Only needed in linux-next. diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c index 71fcef0..3eef972 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c @@ -463,8 +463,7 @@ static int bnx2x_vfop_qdtor_cmd(struct bnx2x *bp, return bnx2x_vfop_transition(bp, vf, bnx2x_vfop_qdtor, cmd->block); } - DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop. rc %d\n", - vf->abs_vfid, vfop->rc); + DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop.\n", vf->abs_vfid); return -ENOMEM; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fix multiple mark_page_accessed called when sequentially writing a file with blocksize less than PAGE_SIZE ,which might pollute the LRU.
sequential write to a file with blocksize less than PAGE_SIZE will call
mark_page_accessed multiple times,
if (!pagevec_space(pvec))
__pagevec_lru_add(pvec, lru);
it seems this trick fix this problem,but not quite thoroughly. there's a chance
that when another page was added to the pvec before the 14th page was
secondly mark_page_accesseded, then the 14th page was still active.
diff --git a/fs/open.c b/fs/open.c
index 9b33c0c..a418419 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -674,6 +674,13 @@ int open_check_o_direct(struct file *f)
return 0;
}
+
+static void
+file_w_state_init(struct file_w_state *wstat)
+{
+ wstat->prev_w_pos=-1;
+}
+
static int do_dentry_open(struct file *f,
int (*open)(struct inode *, struct file *),
const struct cred *cred)
@@ -730,6 +737,7 @@ static int do_dentry_open(struct file *f,
f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC);
file_ra_state_init(>f_ra, f->f_mapping->host->i_mapping);
+ file_w_state_init(>f_wstat);
return 0;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7617ee0..b90d3ff 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -746,6 +746,10 @@ struct file_ra_state {
loff_t prev_pos;/* Cache last read() position */
};
+struct file_w_state {
+ loff_t prev_w_pos;
+};
+
/*
* Check if @index falls in the readahead windows.
*/
@@ -787,6 +791,7 @@ struct file {
struct fown_struct f_owner;
const struct cred *f_cred;
struct file_ra_statef_ra;
+ struct file_w_state f_wstat;
u64 f_version;
#ifdef CONFIG_SECURITY
diff --git a/mm/filemap.c b/mm/filemap.c
index 83efee7..ea144a9 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2287,6 +2287,9 @@ static ssize_t generic_perform_write(struct file *file,
long status = 0;
ssize_t written = 0;
unsigned int flags = 0;
+ unsigned long prev_pos=file->f_wstat.prev_w_pos;
+ unsigned long prev_off=(prev_pos & (PAGE_CACHE_SIZE -1));
+ pgoff_t prev_index=(prev_pos >> PAGE_CACHE_SHIFT);
/*
* Copies from kernel address space cannot fail (NFSD is a big user).
@@ -2296,12 +2299,14 @@ static ssize_t generic_perform_write(struct file *file,
do {
struct page *page;
+ pgoff_t index;
unsigned long offset; /* Offset into pagecache page */
unsigned long bytes;/* Bytes to write to page */
size_t copied; /* Bytes copied from user */
void *fsdata;
offset = (pos & (PAGE_CACHE_SIZE - 1));
+ index = pos >> PAGE_CACHE_SHIFT;
bytes = min_t(unsigned long, PAGE_CACHE_SIZE - offset,
iov_iter_count(i));
@@ -2334,7 +2339,8 @@ again:
pagefault_enable();
flush_dcache_page(page);
- mark_page_accessed(page);
+ if (index != prev_index || offset != prev_off)
+ mark_page_accessed(page);
status = a_ops->write_end(file, mapping, pos, bytes, copied,
page, fsdata);
if (unlikely(status < 0))
@@ -2359,6 +2365,8 @@ again:
}
pos += copied;
written += copied;
+ prev_index = index;
+ prev_off = offset;
balance_dirty_pages_ratelimited(mapping);
if (fatal_signal_pending(current)) {
@@ -2367,6 +2375,7 @@ again:
}
} while (iov_iter_count(i));
+ file->f_wstat.prev_w_pos=pos;
return written ? written : status;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] omap: Avoid crashes in the case of hwmod misconfiguration
omap hwmod is really sensitive to hwmod misconfiguration.
Getting a minor clock wrong always ended up in a crash.
Attempt to be more resilient by not assigning variables with
error codes and then attempting to use them.
Without this patch, missing a clock ends up with something like this:
omap_hwmod: ehrpwm0: cannot clk_get opt_clk ehrpwm0_tbclk!
Unable to handle kernel NULL pointer dereference at virtual address 002a!
pgd = c0004000!
[002a] *pgd=!
Internal error: Oops: 5 [#1] SMP ARM!
Modules linked in:!
CPU: 0Not tainted (3.8.0-rc2-12157-g76c7825-dirty #291)!
PC is at __clk_prepare+0x10/0x70!
LR is at clk_prepare+0x1c/0x34!
pc : []lr : []psr: a113!
sp : cf04fef8 ip : fp : !
r10: ffea r9 : r8 : !
r7 : fffe r6 : 0001 r5 : fffe r4 : fffe!
r3 : cf041ac0 r2 : cf04ff00 r1 : r0 : fffe!
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel!
Control: 10c5387d Table: 80004019 DAC: 0015!
Process swapper/0 (pid: 1, stack limit = 0xcf04e240)!
Stack: (0xcf04fef8 to 0xcf05)!
fee0: cf041ac0 c07749f4!
ff00: fffe c03e386c c07499cc c073c070 c073d2fc c06d4e4c c073c070 c071cc18!
ff20: c06d4c4c c0708284 c06c91bc c0025e28 c073a030 0001!
ff40: c06f5f60 c06f5f40 c06d5324 c06d533c cf04e000 c0008870 c06d5324 c060abe8!
ff60: c07082e8 0002 0001 c06f5f60 c06f5f40 c077d700 0099 c04a43d4!
ff80: 0001 0001 c06c91bc c04a42dc !
ffa0: c000d678 !
ffc0: !
ffe0: 0013 9e7befee f7bbaaab!
[] (__clk_prepare+0x10/0x70) from []
(clk_prepare+0x1c/0x34)!
[] (clk_prepare+0x1c/0x34) from [] (_init+0x200/0x288)!
[] (_init+0x200/0x288) from []
(omap_hwmod_for_each+0x28/0x58)!
[] (omap_hwmod_for_each+0x28/0x58) from []
(omap_hwmod_setup_all+0x18/0x34)!
[] (omap_hwmod_setup_all+0x18/0x34) from []
(do_one_initcall+0x90/0x160)!
[] (do_one_initcall+0x90/0x160) from []
(kernel_init+0xf8/0x290)!
[] (kernel_init+0xf8/0x290) from []
(ret_from_fork+0x14/0x3c)!
Code: e92d4038 e2504000 01a05004 0a15 (e594302c) !
---[ end trace 1b75b31a2719ed1c ]---!
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b!
Signed-off-by: Pantelis Antoniou
---
arch/arm/mach-omap2/omap_hwmod.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..2b58e21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -783,7 +783,9 @@ static int _init_interface_clks(struct omap_hwmod *oh)
if (IS_ERR(c)) {
pr_warning("omap_hwmod: %s: cannot clk_get
interface_clk %s\n",
oh->name, os->clk);
- ret = -EINVAL;
+ if (ret == 0)
+ ret = -EINVAL;
+ continue;
}
os->_clk = c;
/*
@@ -819,7 +821,9 @@ static int _init_opt_clks(struct omap_hwmod *oh)
if (IS_ERR(c)) {
pr_warning("omap_hwmod: %s: cannot clk_get opt_clk
%s\n",
oh->name, oc->clk);
- ret = -EINVAL;
+ if (ret == 0)
+ ret = -EINVAL;
+ continue;
}
oc->_clk = c;
/*
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] omap: DT node Timer iteration fix
The iterator correctly handles of_node_put() calls.
Remove it before continue'ing the loop.
Without this patch you get:
ERROR: Bad of_node_put() on /ocp/timer@44e31000!
[] (unwind_backtrace+0x0/0xe0) from []
(of_node_release+0x2c/0xa0)!
[] (of_node_release+0x2c/0xa0) from []
(of_find_matching_node_and_match+0x78/0x90)!
[] (of_find_matching_node_and_match+0x78/0x90) from []
(omap_get_timer_dt+0x78/0x90)!
[] (omap_get_timer_dt+0x78/0x90) from []
(omap_dm_timer_init_one.clone.2+0x34/0x2bc)!
[] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from []
(omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)!
[] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from
[] (time_init+0x20/0x30)!
[] (time_init+0x20/0x30) from [] (start_kernel+0x1a8/0x2fc)!
Signed-off-by: Pantelis Antoniou
---
arch/arm/mach-omap2/timer.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 691aa67..b8ad6e6 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -165,15 +165,11 @@ static struct device_node * __init
omap_get_timer_dt(struct of_device_id *match,
struct device_node *np;
for_each_matching_node(np, match) {
- if (!of_device_is_available(np)) {
- of_node_put(np);
+ if (!of_device_is_available(np))
continue;
- }
- if (property && !of_get_property(np, property, NULL)) {
- of_node_put(np);
+ if (property && !of_get_property(np, property, NULL))
continue;
- }
of_add_property(np, _disabled);
return np;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] capemgr: Beaglebone DT overlay based cape manager
Hi Arnd, On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote: > On Tuesday 08 January 2013, Lee Jones wrote: >>> If there is not, there is no way to automatically load the overlays; you >>> can always >>> use the kernel command line, or have the a user space application to >>> request the loading >>> of a specific board's overlay. >> >> Unfortunately, there is no way to probe the UIBs. :( > > I thought that some of the newer UIBs had it, just not the old ones. > As Pantelis says, we could at least detect the ones that have an EEPROM > on them, and use a command line option or device tree attribute for the > others. > > Arnd So I gather the new ones have an eeprom? Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 RESEND] pwm: atmel: add Timer Counter Block PWM driver
On 08/01/2013 08:10, Thierry Reding wrote:
> On Thu, Dec 20, 2012 at 10:12:56AM +0100, Boris BREZILLON wrote:
>> Hi,
>>
>> Sorry for resend. The previous version still has alignment issues on
>> atmel_tcb_pwm_set_polarity, atmel_tcb_pwm_request and
>> atmel_tcb_pwm_config function parameters.
>>
>> This patch adds a PWM driver based on Atmel Timer Counter Block.
>> Timer Counter Block is used in Waveform generator mode.
>>
>> A Timer Counter Block provides up to 6 PWM devices grouped by 2:
>> * group 0 = PWM 0 and 1
>> * group 1 = PWM 1 and 2
>> * group 2 = PMW 3 and 4
>
> Should this be "PWM 2 and 3" and "PWM 4 and 5"? Or is PWM 1 shared
> between groups 0 and 1?
This is a mistake, this should be:
* group 0 = PWM 0 and 1
* group 1 = PWM 2 and 3
* group 2 = PMW 4 and 5
>
>> +static int atmel_tcb_pwm_request(struct pwm_chip *chip,
>> + struct pwm_device *pwm)
>> +{
> [...]
>> +clk_enable(tc->clk[group]);
>
> You need to check the return value of clk_enable(). There's always a
> small possibility that it may fail.
>
>> +static void atmel_tcb_pwm_disable(struct pwm_chip *chip, struct pwm_device
>> *pwm)
>> +{
> [...]
>> +/* If duty is 0 reverse polarity */
>> +if (tcbpwm->duty == 0)
>> +polarity = !polarity;
>
> Rather than commenting on what the code does, this should say why it
> does so.
>
Is this an acceptable explanation ?
/*
* If duty is 0 the timer will be stopped and we have to
* configure the output correctly on software trigger:
* - set output to high if PWM_POLARITY_INVERSED
* - set output to low if PWM_POLARITY_NORMAL
*
* This is why we're reverting polarity in this case.
*/
>> +static int atmel_tcb_pwm_enable(struct pwm_chip *chip, struct pwm_device
>> *pwm)
>> +{
> [...]
>> +/* If duty is 0 reverse polarity */
>> +if (tcbpwm->duty == 0)
>> +polarity = !polarity;
>
> Same here.
>
>> +static int atmel_tcb_pwm_probe(struct platform_device *pdev)
>> +{
> [...]
>> +struct atmel_tcb_pwm_chip *tcbpwm;
>> +struct device_node *np = pdev->dev.of_node;
>> +struct atmel_tc *tc;
>> +int err;
>> +int tcblock;
>> +
>> +err = of_property_read_u32(np, "tc-block", );
>> +if (err < 0) {
>> +dev_err(>dev,
>> +"failed to get tc block number from device tree (error:
>> %d)\n",
>
> Maybe: "failed to get Timer Counter Block number..." to make it
> consistent with the error message below:
>
>> +tc = atmel_tc_alloc(tcblock, "tcb-pwm");
>> +if (tc == NULL) {
>> +dev_err(>dev, "failed to allocate Timer Counter Block\n");
>> +return -ENOMEM;
>> +}
> [...]
>> +static const struct of_device_id atmel_tcb_pwm_dt_ids[] = {
>> +{ .compatible = "atmel,tcb-pwm", },
>> +{ /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, mxs_pwm_dt_ids);
>
> This is still wrong.
>
>> +static struct platform_driver atmel_tcb_pwm_driver = {
>> +.driver = {
>> +.name = "atmel-tcb-pwm",
>> +.of_match_table = atmel_tcb_pwm_dt_ids,
>> +},
>> +.probe = atmel_tcb_pwm_probe,
>> +.remove = atmel_tcb_pwm_remove,
>> +};
>> +module_platform_driver(atmel_tcb_pwm_driver);
>> +
>> +MODULE_AUTHOR("Boris BREZILLON ");
>> +MODULE_DESCRIPTION("Atmel Timer Counter Pulse Width Modulation Driver");
>> +MODULE_ALIAS("platform:atmel-tcb-pwm");
>
> I don't think you needMODULE_ALIAS() if the alias is the same as the
> driver name.
>
> Thierry
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 RESEND] pwm: atmel: add Timer Counter Block PWM driver
On Tue, Jan 08, 2013 at 01:43:56PM +0100, Boris BREZILLON wrote:
> On 08/01/2013 08:10, Thierry Reding wrote:
> > On Thu, Dec 20, 2012 at 10:12:56AM +0100, Boris BREZILLON wrote:
[...]
> >> +static void atmel_tcb_pwm_disable(struct pwm_chip *chip, struct
> >> pwm_device *pwm)
> >> +{
> > [...]
> >> + /* If duty is 0 reverse polarity */
> >> + if (tcbpwm->duty == 0)
> >> + polarity = !polarity;
> >
> > Rather than commenting on what the code does, this should say why it
> > does so.
> >
>
> Is this an acceptable explanation ?
>
> /*
>* If duty is 0 the timer will be stopped and we have to
>* configure the output correctly on software trigger:
>* - set output to high if PWM_POLARITY_INVERSED
>* - set output to low if PWM_POLARITY_NORMAL
>*
>* This is why we're reverting polarity in this case.
>*/
Yes, that should work.
Thierry
pgpkuZvZg2X6P.pgp
Description: PGP signature
Re: [PATCH RFT] regulator: s5m8767: Convert to regulator_[get|set]_voltage_sel_regmap
On Tue, Jan 08, 2013 at 08:38:52PM +0800, Axel Lin wrote: > 2013/1/8 Mark Brown > Or do you mean Linus' current tree? ( This looks not a 3.8 material. ) I meant Linus' tree since I was starting a new topic branch (not having seen the fix branch). No need to regenerate. signature.asc Description: Digital signature
Re: [PATCH 05/11] spi/pxa2xx: make clock rate configurable from platform data
On Tue, Jan 08, 2013 at 02:41:53PM +0200, Mika Westerberg wrote: > On Tue, Jan 08, 2013 at 11:02:28AM +, Mark Brown wrote: > > No, the way to do this is to fix x86 to enable the clock API there. The > > x86 maintainers couldn't be bothered when I submitted a patch and > > getting anyone to take a patch to make it available by default appears > > to be unreasonably hard but perhaps if someone from Intel tries the x86 > > maintainers might take a patch... > Do you mean enabling CONFIG_COMMON_CLK on x86? Yes. > > We shouldn't be adding special case code to every driver that might need > > a clock that gets used on an Intel system. > I agree and it is cleaner to have the same API for all arches. However, I'm > not sure how do we create the fixed clocks then? There is nothing in ACPI > namespace (or in the ACPI 5.0 spec) that allows you to describe clocks and > their relationships. I'm sure it's not beyond the bounds of possibility that we could solve this problem... > So then we end up either: > 1. Creating a custom board file for Lynxpoint which creates the > clocks. This is something I think x86 maintainers don't want to > see. > 2. Creating the clock in the driver itself in its ACPI enumeration > implementation. This might work but it litters the drivers with > clock details. > Or is there something I'm missing? Well, it seems fairly clear to me that the SoC wiring ought to be done outside the driver. It is something that needs to be resolved for your smartphone SoCs for this and for other things like platform data for external chips, what's actually happening in practical systems here is that people are just hacking the arch code as there's no mechanism for providing configuration at present. signature.asc Description: Digital signature
[PATCH] clk: remove unreachable code
while reparenting a clock, NULL check is done for clock in consideration and its new parent. So re-check is not required. If done, else part becomes unreachable. Signed-off-by: Rajagopal Venkat --- drivers/clk/clk.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 251e45d..f896584 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1048,10 +1048,7 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent) hlist_del(>child_node); - if (new_parent) - hlist_add_head(>child_node, _parent->children); - else - hlist_add_head(>child_node, _orphan_list); + hlist_add_head(>child_node, _parent->children); #ifdef CONFIG_COMMON_CLK_DEBUG if (!inited) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lockdep: Rename print_unlock_inbalance_bug() to print_unlock_imbalance_bug()
Fix the typo in the function name (s/inbalance/imbalance)
Signed-off-by: Srivatsa S. Bhat
---
kernel/lockdep.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 7981e5b..5cf12e7 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -3203,7 +3203,7 @@ static int __lock_acquire(struct lockdep_map *lock,
unsigned int subclass,
}
static int
-print_unlock_inbalance_bug(struct task_struct *curr, struct lockdep_map *lock,
+print_unlock_imbalance_bug(struct task_struct *curr, struct lockdep_map *lock,
unsigned long ip)
{
if (!debug_locks_off())
@@ -3246,7 +3246,7 @@ static int check_unlock(struct task_struct *curr, struct
lockdep_map *lock,
return 0;
if (curr->lockdep_depth <= 0)
- return print_unlock_inbalance_bug(curr, lock, ip);
+ return print_unlock_imbalance_bug(curr, lock, ip);
return 1;
}
@@ -3317,7 +3317,7 @@ __lock_set_class(struct lockdep_map *lock, const char
*name,
goto found_it;
prev_hlock = hlock;
}
- return print_unlock_inbalance_bug(curr, lock, ip);
+ return print_unlock_imbalance_bug(curr, lock, ip);
found_it:
lockdep_init_map(lock, name, key, 0);
@@ -3384,7 +3384,7 @@ lock_release_non_nested(struct task_struct *curr,
goto found_it;
prev_hlock = hlock;
}
- return print_unlock_inbalance_bug(curr, lock, ip);
+ return print_unlock_imbalance_bug(curr, lock, ip);
found_it:
if (hlock->instance == lock)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] gpiolib: add gpiod_get and gpiod_put functions
On Tuesday 08 January 2013, Alexandre Courbot wrote: > > Adds new GPIO allocation functions that work with the opaque descriptor > interface. > > Signed-off-by: Alexandre Courbot I think you need to reorder the patches slightly, since the gpiod_get function introduced here is already being used in the first patch, which breaks bisection. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] gpio: introduce descriptor-based interface
On Tuesday 08 January 2013, Alexandre Courbot wrote: > This series introduce a first take at implementing the RFC for the new GPIO > API > that I submitted last month. It proposes a new, opaque descriptor-based GPIO > API > that becomes available when GPIOlib is compiled, and provides a safer, more > abstract alternative to the current integer-based interface. GPIOlib internals > are also switched to use the descriptor logic, and the former integer API > becomes a lightweight wrapper around the new descriptor-based API. > > Functionally speaking the new API is identical to the integer-based API, with > only the prefix changing from gpio_ to gpiod_. However, the second patch > introduces new functions for obtaining GPIOs from a device and a consumer > name, > in a fashion similar to what is done with e.g. regulators and PWMs. I like the interface, good idea! A few questions: Is there a plan for migrating all the existing users of the current GPIO interface? How do you want to deal with drivers that work on platforms that currently don't use gpiolib but have their own implementation of asm/gpio.h? Are we going to phase them out? If we are adding a new way to deal with GPIOs, would it make sense to have that more closely integrated into pinctrl in one form or another? My feeling is that there is already a significant overlap between the two, and while the addition of the gpiod_* functions doesn't necessarily make this worse, it could be a chance to improve the current situation to make the interface more consistent with pinctrl. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
